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

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://). 

 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.

 Hi Stefan,

I'd like to request a feature: automatic alphabetization of the items in the Quick Filter menus.

We track quite a few detector assemblies, which are produced with non-sequential designations. It would be useful if the Quick Filter list was automatically sorted alphabetically to make it more convenient for folks to find a particular item.

I know people can always search by designation but it would be handy to have this alpha sorting feature. Would it be possible to include that in a future release?

Thanks again for a *very* useful logging system!

Dennis

The order of items in a Quick Filter menu is exactly as in the configuration file. Like if you have items

Options Type = C, D, A, B

they are shown like that in the quick filter menu. If you want to sort them, just do the sorting yourself in the configuration file like

Options Type = A, B, C, D

I have not implemented automatic sorting since some people want a different order, like some main topics at top. So by following the order from the configuration file, everybody can be satisfied just by chaning the order in the config file.

- Stefan 

 Yes, I have been manually sorting and resorting. We have extendable attributes and the list keeps growing so I have to resort every so often. I thought perhaps a simple alphanumeric sort as an option would be popular with most users so I thought I'd ask for it. It would really simplify things for me. Users who want to sort manually could do so by disabling the option. It never hurts to ask!

Ok, I implemented

Sort attribute options = 1

in the current SVN revision.