Hi Christof,

wow thanks, that's (almost) exactly what I was looking for! I only had to add

 --- src/elogd.c.orig 2012-02-03 09:11:42.000000000 +0100
+++ src/elogd.c 2012-02-03 09:11:32.000000000 +0100
@@ -8375,6 +8375,10 @@
    strcpy(list[i], "remote_host");
    strlcpy(value[i++], rem_host, NAME_LENGTH);

+   /* add LDAP author */
+   strcpy(list[i], "http_user");
+   strlcpy(value[i++], http_user, NAME_LENGTH);
+

    /* add local host */
    strcpy(list[i], "host");
    strlcpy(value[i++], host_name, NAME_LENGTH);

Preset Author = $http_user

to work.  I fully support getting your patches into upstream.

The issue is still present and now it's quite urgent to move this last service into the Swarm. Does anyone maybe have an idea what's wrong? To sum up: if there is a non-empty password file, the login page chokes in an infinite loop of redirects. I am using the same HAProxy load balancer configuration as for all the other services (running Apache, NGINX, GitLab, XWiki, etc.):

backend be_elog.km3net.de
    mode http

    option forwardfor except 127.0.0.1
    http-request add-header X-Forwarded-Proto https if { ssl_fc }

    server-template km3net-elog- 1 km3net-elog_elog:8080 check resolvers docker init-addr libc,none

If a message is submitted via the elog command then the reply string '> ' is only inserted in the first line if a reply is made.
This message was submitted with the following commandline:
elog -v -h midas.psi.ch -p 80 -s elogdemo -l Forum -a "Icon=icon4.gif" -a "Author=Heiko Scheit"  -a "Author Email=h.scheit@mpi-hd.mpg.de" -a "Subject=elog submit problem" "...Message-text..."

Please press the reply button to see the problem.

When the option 'Reverse sort = 1' is used then the first entry
is not displayed (ID=1) when threaded mode is requested.

Probably you can see the problem using this link and switching 
on reverse sort.  

http://midas.psi.ch/elogdemo/Linux/last20?mode=threaded

The exit status of elog is always 1.  It should be zero for
a successful submission.

With elog it is possible to submit messages to a password protected
logbook without specifying the -u option.  I.e. NO PASSWORD is
necessary to submit a message.  I assume it is related to the problem
of expiring password-cookies while entering the message using a web
browser.

> > With elog it is possible to submit messages to a password protected
> > logbook without specifying the -u option.  I.e. NO PASSWORD is
> > necessary to submit a message.  I assume it is related to the problem
> > of expiring password-cookies while entering the message using a web
> > browser.
> 
> Indeed this problem is related to the expiring password cookies. As a 
> reminder: For the submission of a new entry, the password is checked when
one 
> presses the "New" button, but NOT for the "submit". This is because a 
> password can expire between the "New" and the "Submit", so a entered message 
> could not be sent. The question is now what to do with the standalone
"elog".
> 
> Right now, elog does a normal submission where the password is not checked, 
> which is maybe not what one wants. But what to do? If elog sends a special 
> flag "please do check password on submit", someone could analyze the source 
> code, remove the flag from elog and then still submit messages without a 
> password. If I put an additional flag to the web browser submission "please 
> do not check the password since the cookie might have been expired", someone 
> can add this flag into elog and still bypass the password checking.

I guess it cannot and doesn't have to be 100% save.  Maybe if the web
interface is used for a new message a long random number (let's call
it newID) can be included, which elog remembers for some time (say 1
day).  Now elogd accepts a new message only if 

  1) the cookies is there and valid or
  2) if the cookies are NOT THERE, but the newID matches one of the
       stored ones.     

The new message is rejected if the cookies are there, but are wrong.

> Anothe thing which bothers me is if you specify the password explicitly on 
> the command line of elog, it's visible in some scripts etc, which yould be a 
> security issue as well.

Maybe the encoded password should be specified.  I use wget to
retrieve some entries automatically over a cron job and with wget
you specify a cookie-file with --cookie-file (or something like
this).  The content of this file corresponds to the content of the
netscape cookie file.

> 
> Any ideas?

Can one delete or edit messages with elog?  If yes then this should not be
possible.

The last x link TEXT now shows up like this

   'Last 20 entries?mode=threaded'

I can not reproduce this with the elogdemo logbook, however.