Unfortunately I only got 1/2 hour to go back to this... I was trying to avoid copying the whole remote elog server from 20 people (that's what I get with the automatic cloning, right?)

So, I set SSL=0 and removed the password file, but still got the same result. Then I looked in the code a bit, and can see that the problem happens in retrieve_remote_md5(...) in the lines:

   p = strstr(text, "ELOG HTTP ");
   if (!p) {
      if (isparam("debug"))
         rsputs(text);
      sprintf(error_str, loc("Remote server is not an ELOG server"));

in elogd.c, where I see text is filled by retrieve_url()

So what seems to fail is that retrieve_url() gets back a string from the remote server which doesn't include the string "ELOG HTTP ". But I don't know what that really means. Here is what I get if I try:

bash-3.2$ /usr/local/sbin/elogd -v -m -p 8080 -c /usr/local/elog/elogd.cfg -D

I get the following output:

Indexing logbook "ATLAS Trigger" in "/usr/local/elog/logbooks/ATLAS Trigger/" ... 

Config [ATLAS Trigger],                           MD5=1FAE83FC1D3B920AFDB3DC5F49C25FAF

Entries:

  ID   1, 090728a.log, ofs     0, thead, MD5=8D8E44C14FCFA9E2FC24CEC14E60D5ED

After sort:

  ID   1, 090728a.log, ofs     0

ok

Indexing logbook "Top physics and SLT" in "/usr/local/elog/logbooks/Top/" ... 

Config [Top physics and SLT],                           MD5=C6A82A4BD6FF708BFDA3EA8719ECE48C

Found empty logbook "Top physics and SLT"

Indexing logbook "Trigger Slices and Core SW" in "/usr/local/elog/logbooks/Slices/" ... 

Config [Trigger Slices and Core SW],                           MD5=316B8D7A8FBA661518FD61D3BAC39F3C

Entries:

  ID   2, 090727a.log, ofs     0, thead, MD5=AA8B0B0972718F9BD95F5BA89E70DD97

  ID   3, 090727a.log, ofs  3870, thead, MD5=A69E46D18074A59C4445B72EE72F025D

  ID   4, 090727a.log, ofs  8354, thead, MD5=0DC3AF86F2A88ACD76E766FA1AA08665

  ID   5, 090730a.log, ofs     0, thead, MD5=59299CDFA98983EB33EC08CF1A8FF7C0

  ID   6, 090730a.log, ofs 10120, thead, MD5=0039C61DA667AA36D06A5772F8E3D0FA

After sort:

  ID   2, 090727a.log, ofs     0

  ID   3, 090727a.log, ofs  3870

  ID   4, 090727a.log, ofs  8354

  ID   5, 090730a.log, ofs     0

  ID   6, 090730a.log, ofs 10120

ok

Retrieving entries from "https://www.pp.rhul.ac.uk:8080/ATLAS Trigger"...

Remote server is not an ELOG server

Tried installing on Fedora 11 - failed dependency on libssl.so.6 I have libssl.so.8 installed. What do I need to do to install this package?

thanks,

nbc

The easiest is if you install from source by downloading the tar ball. It's hard these days to make a RPM which runs on all possible distributions. I would have to maintain a zoo of new and old distributions, which I don't have the hardware for. Or you go and install libssl.so.6 by hand.  

 It is working with the correct time stamp now. Thanks you very much Stefan.

Your problem is here. I wrote that synchronization is not possible through SSL, but you try to access https://www.pp.rhul.ac.uk:8080 which is SSL (because you have https:// not http://). 

Sorry my late reply but I'm pretty busy these days...

I don't have a clear solution, just a few thoughts:

- Network handling has benn improved recently, so I propose you first upgrade to Version 2.7.7

- Looking at your sync logs, I see many lines of the form

19-Jun-2009 15:41:05 [lance@127.0.0.1] {NSS} MIRROR change entry #1095 to #23357
19-Jun-2009 15:41:05 [lance@127.0.0.1] {NSS} DELETE entry #1095
19-Jun-2009 15:41:05 [lance@127.0.0.1] {NSS} MIRROR send entry #23357

this indicates that you add entries to both logbooks (with ID 1095) in this case. Then elog has a problem, since you have new entries with ID 1095 on both sides. So the only solution is to re-submit the entry #1095 on the source logbook as a new entry (with ID #23357 in this case), delete the old one and then submit the new one. This happens very often, which takes quite some time. Mirroring mainly makes sense if there is one active logbook where new entries gets submitted, and the second logbook is mainly as backup and read-only. Then mirroring is very effective. If you submit on both sides very heavily new entries, the merge process is quite complicated.

- If nothing has changed on both sides and you still have heavy synchronization work, it means that both logbooks kind of became inconsistent, and elog tries to sort that out. So a good starting point is to manually copy all xxxxxxa.log files from one side to the other, thus ensuring both logbooks are 100% identical. Then restart both elogd servers, issue a manual synchronization, and make sure it reports back to you that everything is identical.

Hope some of this helps,

  Stefan
 

 Ah, I see. Hmm, ok it doesn't work without the s either. I can't access the server in that case. Ok, I think I'll just wait for this feature to be available. Thanks for your help!

 Of course you also have to switch your mirror server not to use SSL as well. You can check this then by accessing it directly via http://www.pp.rhul.ac.uk:8080/ATLAS Trigger from the same computer. Also make sure that you don't have any firewall issue.