Stefan,

Everything has been working great since we last spoke (Version 2.7.8), until InfoSec decided to change how the Certs were created.  Now they come with a little bit of code in the .key file before the Hash.. when I put the new .CRT and .KEY in the SSL folder I am asked on starting Elogd to provide a "PEM PassPhrase".  As you can expect, if you do not enter one, or the incorrect one, it does not just turn off SSL, it exits the program.  The key begins like this in the new versions:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,ACF4A8B263EAA51D

(that little encode piece on the end is not the actual one in the key.  I am assuming it is a passphrase key so it will know what the right passphrase is that should be entered.

We are assuming that this is the "Install password" they have set up to use to install the certs on all of the IIS servers we have.  If that is indeed the case.. Does elog save this passphrase somewhere?  does Elog save it in the registry? does it save it encrypted? Or with access security permissions set on the keys?  I have a feeling that the answer to most of this is probably "no", but to know where we go from here, that is the place to start.

Thanks

Chuck

The pass phrase should not be stored anywhere for security reasons. Actually ELOG cannot stored it encrypted, because strong encryption is a one-way encryption which cannot be reverted, so ELOG would have to store it in plain text, which is not good. Actually all SSL web servers have this problem. See for example:

http://www.akadia.com/services/ssh_test_certificate.html

In Step 3 they tell you how to remove the pass phrase for Apache. The same holds true for ELOG.

I just typed a long text into this elog, clicked "submit" and it bombed with "you must select an Icon", returned me to the editor with all my text gone gone gone. I do not want to select icons, I just want to report a problem with elog. Well, 2 problems, now.

K.O.

Well, first RTFM: "Fields marked with a * are required" on top of the elog entry page. Then, use a reasonable browser on a reasonable OS  

On Google Chrome the text is still there (actually I just tried it with this entry). No idea what Safari under OSX does. Under Windows, Safari keeps the text. Actually this is controlled by the FCKEditor inside elog which is written by someone else. So complain there! Funny: We have about 1000+ entries in this forum, and you are the first one complaining about this.

My logbook kept crashing whenever I tried to reply to an existing entry. I found that the percent sign "%", when used in the subject line, will crash the elogd service when you try to reply to the entry. This appears to only happen with windows installations. I tested this on your Linux logbook and it didn't crash.

Here is the message taken from the Windows event viewer after the crash:
An unhandled win32 exception occurred in elogd.exe [5224].

Thank you for Elog, you have done a good job with it.  It is a great logbook.

Mike

 Since we updated to 2.7.8 we've found a problem.

Previously, when we used 

Subst on reply subject = Re: $subject

We have been experiencing corruption of logbook entries by elogd mirror synchronization. Has anyone else encountered this? Is there a known cause and/or workaround for it?

Details

We have two elog servers set up with identical elogd.cfg and password files, except that one server has "Mirror server" pointing to the other host. There are three logbooks defined.  (Their names are DoubleChooz, BigBrotherTable, and FlushingTable.)  When the mirror synchronization happens, whether by "Mirror cron" or by an administrator hitting the "Synchronize all logbooks" link, it often happens that entries requiring synchronization are corrupted on both servers (not just the one to which the entry was copied). This is particularly likely to happen if entries have been made on both servers since the previous sync.

Looking at the logbook files themselves, we see that the corrupted entries will have attributes from the wrong logbooks. E.g., we'll see an empty "Barometer: " line in a DoubleChooz logbook file, where "Barometer" is an attribute that is only in the FlushingTable logbook, or we will see there are unexpected DoubleChooz logbook attributes in the FlushingTable files.

Strangely, the entries will not be identical on the two machines after syncing, and they stay non-identical on further syncs.

Most disturbingly, data is lost from entries that were perfectly valid before the sync, on both servers.

This was happening with elogd 2.7.8, and continued to happen after upgrading to 2.8.0. Both servers are running Linux. One is a 32-bit machine and another 64-bit, in case that might matter (but read on).

I made copies of both servers' files and ran two elogd servers on my Mac on different ports, compiled from a fresh checkout of 2.8.0, and the same behavior was observed as I repeatedly made test entries and synchronized.  This suggests it isn't specific to Linux architecture, 64-bit or otherwise.