> - elogd should not tell us to run elconv when both old-style and corresponding new-style elog entries exist

I removed that check completely. The old format was used up to 2002, so I expect that all users have upgraded in meantime.

Stefan

Hi Christian,

 I have also the need to do auth on the webserver, but  I tried to integrate it into elogd as far as I could.

However, I do not try to set a special cookie to set the username, but always use 
 "X-Forwarded-User".  Like this, every request is authenticated by the webserver in front.

If that's not too heavy for you, try out the applied patch.

HTH,

Christof

PS:

@Stefan:

If you are willing to integrate this into the official tree, 

I can provide some docs for it (like setting author 

directly etc.)

-----------------------------------------------------------------
Christof Hanke e-mail hanke@rzg.mpg.de
RZG (Rechenzentrum Garching) phone +49-89-3299-1041
Computing Center of the Max-Planck-Gesellschaft (MPG) and the
Institut für Plasmaphysik (IPP)
 

 <Location /elog/admin>

        Use PhysLDAP

        Use RequirePhysLDAPGroup isg


        RewriteEngine On

        RewriteCond %{LA-U:REMOTE_USER} (.+)

        RewriteRule . - [E=RU:%1]

        RequestHeader add X-Forwarded-User %{RU}e

</Location>

   /* extract REMOTE_USER */

   if ((p = strstr(request, "X-Forwarded-User:")) != NULL) {

      p += 17;

      while (*p && *p == ' ')

         p++;

      strlcpy(remote_user, p, sizeof(remote_user));

      if (strchr(remote_user, '\r'))

         *strchr(remote_user, '\r') = 0;


         char sid[32];

         /* get a new session ID */

         sid_new(NULL, remote_user, (char *) inet_ntoa(rem_addr), sid);


         /* set SID cookie */

         set_sid_cookie(NULL, sid);

         // TODO: set lbs!

   }

set_cookie (lbs=0x0, name=0x483b22 "sid", value=0x7ffffffd7590 "4831386B7B333A99", 
global=0, expiration=0x7ffffffd7300 "")

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.

 I've a little experience of digging myself out of (in my case, self-induced) problems using ELOG.   I'm also aware that I may be the least experienced/qualified user..

First:  Archive your work directories.  Then at least whatever you do from here, you've got the status quo to fall back on.  Also, record anything you can remember (ID number, thread, etc) of the deleted entry/entries.

I've found that ELOG can hang in an infinite loop if it tries to find an entry that is no longer there - and that depends upon how you approach the point where the missing entry would be.  ELOG's own delete works fine in normal circumstances.  I'm talking about abnormal circumstances, for example when idiots (me) are playing around with the yymmdda.log files, or *possibly* if the disk is full, and you then try deleting the entry that caused the full disk problem.  Whether that is what you are seeing, I cannot say at present. 

However, to progress this:  When you are stuck, unable to edit anything, in a[nother] terminal, try the process report

ps -A

two or three times, with a short interval between commands.  (Or other switches if you know how to select to view the elogd process on your system).   If elogd is using seconds of CPU time between each ps command, it's probably in an infinite loop.  If you need to be sure, wait a minute and check again.  If so, you'll have to stop the daemon, possibly requiring a computer reboot.  In my experience, ELOG does not get stuck in an infinite loop when just indexing the pages when the daemon starts, but experts may well know better.

This may at least diagnose whether you cannot edit because ELOG is stuck in an infinite loop, or has some other cause.

If it is the infinite loop, the trick is to find which entry causes the loop without getting stuck in that loop next time around. 

David Pilgram.

 Hi David,

you have been very helpful indeed. The problem was the one you spot, I've deleted the  buggy entry removing the ***.log file, and this caused disaster..... now it is working again, thanks a lot, I have all my PhD thesis in ELOG....

Sara

Don't get too excited yet!

When you reply to an entry in ELOG, then some additional data is added to that original entry. 

So, if you reply today (say 02/06/11) to an entry made yesterday, then you will find that the file 110602a.log has a large change (the new entry in full, plus elog extra codes), *and* an additional line added into 110601a.log.  Deleting 110602a.log will not remove the line in 110601a.log, and that could still cause problems, that is, wandering into an infinite loop.

To save a lot of effort, I'll suggest that you (a) keep the back-ups up to date, and keep two (the latest and the one before that); (b) proceed carefully at least to start with.  If you fall into the infinite loop again, then flag it up and I (or someone else) will be able to give further pointers.

David Pilgram.

So unless you are sure that

> Dear all,
>   I have some logbook which uses preset text depending on some option values, and uses text files for this.
> 
> something similar to:
> 
> Options Type = Start of shift{1}, 2h{2}, 4h{3}, 6h{4}, End of shift {5}
> 
> {1} Preset text = MCProdStart.txt
> {2} Preset text = MCProd2h.txt
> {3} Preset text = MCProd4h.txt
> {4} Preset text = MCProd6h.txt
> {5} Preset text = MCProdEnd.txt
> 
> I wonder if there is a way to change/edit the text files from the web interface if you are admin of that logbook, or if the only way is to change the files directly in the elog server.
> 
> thanks Stefano

No, you can only edit this on the file level.

Stefan