I'm not sure if this is a configuration problem or a bug, but running
v2.5.4subver1.413, elogd runs as user ROOT (UID0) even though the following
is in the elogd.cfd file:

Usr = nobody
Grp = essadm

All other directives added to the cfg file work, so I know eLog is reading
the cfg file.  

The elogd binary *is not* setuid 0.

Thanks

The help text on the website says the following:

"The command Select can be used to select multiple messages for deletion of
moving to other logbooks."

This is not clear but was the intent to indicate that SELECT can be used to
either select multiple log entries for deletion OR for moving to another
logbook?  If the latter, then this does not work if one adds the MOVE TO
menu item to the list.  If the former then the helptext is a little misleading.

Thanks!

> First - Some of the logbook entries should not be viewed by certain users.  
> What would be the easiest way to restrict viewing some entries?  

The easiest way is to define two logbooks, with two different password files.
The more restricted logbook contains only those users who are allowed to see the
restricted entries. Use the commands "Move to" to move entries between the two
logbooks (see documentation).

> Second - I have a welcome page for the ELOG that lists some info about the 
> ELOG.  When I start the ELOG, the user sees the login page.  After the user 
> logs in, the welcome page appears listing the restrictions.  Right now, I 
> have a hyperlink that takes the user to new, find, etc.  But I would like 
> to take the user right to the logbook and not have to come back to the 
> welcome page everytime.  How can I do this?

Right now you need an exteral page on a public webserver. This page contains
then links to your elog server. I the next version I will implement the
possibility to server *.html files directly through elog. You can then put your
welcome page under themes/default/Welcome.html, and access it through the
starting link:

http://your.elog.server/logbook/Welcome.html

You will only see the Welcome page once, since all links in elog will point back
to .../logbook/ and not to .../logbook/Welcome.html. The config option "Welcome
page = Welcome.html" you have to remove then of course. 

I am working on a logbook for a lab.  I have two questions...
First - Some of the logbook entries should not be viewed by certain users.  
What would be the easiest way to restrict viewing some entries?  

Second - I have a welcome page for the ELOG that lists some info about the 
ELOG.  When I start the ELOG, the user sees the login page.  After the user 
logs in, the welcome page appears listing the restrictions.  Right now, I 
have a hyperlink that takes the user to new, find, etc.  But I would like 
to take the user right to the logbook and not have to come back to the 
welcome page everytime.  How can I do this?

I have attached the code I have so far.  They are in .txt format for easier 
viewing.

Thanks!

> > I was trying to do some hard coded spaces using:
> > 
> > Thread display = For: $Date for Shutdown.   $DataCenter:
> > $short summary. Coordinator: $Shutdown Coordinator.
> > 
> > The spacing actually works mthe first time, but upon going back into editing
> > the config file, the coded spaces are gone, replaced with real spaces, and
> > when saved all real multiple spaces are, as one would expect, ignored.  The
> > spacing reverts back to normal.
> > 
> > I tried other html tags but these show up as literals.
> 
> I fixed that in revision 1.448. The problem also showed up even in normal
> logbook entry displays and in replies (before this fix, the   in this text
> whould not have shown up). Get the new version from CVS.

As always - fantastic!

Thanks

> I was trying to do some hard coded spaces using:
> 
> Thread display = For: $Date for Shutdown.   $DataCenter:
> $short summary. Coordinator: $Shutdown Coordinator.
> 
> The spacing actually works mthe first time, but upon going back into editing
> the config file, the coded spaces are gone, replaced with real spaces, and
> when saved all real multiple spaces are, as one would expect, ignored.  The
> spacing reverts back to normal.
> 
> I tried other html tags but these show up as literals.

I fixed that in revision 1.448. The problem also showed up even in normal
logbook entry displays and in replies (before this fix, the   in this text
whould not have shown up). Get the new version from CVS.

I was trying to do some hard coded spaces using:

Thread display = For: $Date for Shutdown.   $DataCenter:
$short summary. Coordinator: $Shutdown Coordinator.

The spacing actually works mthe first time, but upon going back into editing
the config file, the coded spaces are gone, replaced with real spaces, and
when saved all real multiple spaces are, as one would expect, ignored.  The
spacing reverts back to normal.

I tried other html tags but these show up as literals.

Thanks

Hi everybody,

several people have reported of strange problems concering the login/logout
behaviour of elog. After editing elogd.cfg, they could not logout any more
from a logbook, or they were not able to log in. Here comes some
explanation. If you are not interested in the details, skip to the last section.

The login parameters (user name and password) are sored in cookies, which of
course have to be enabled for the elog site in your browser. Each cookie can
contain an optionsl "path=..." statement, which defines for which subtree in
the URL the cookie is valid. If you use a "global" password file (one where
the "password file = ..." statement is in the [global] section of
elogd.cfg), the elogd server stores a cookie with path "/", so it will apply
to the whole site and therefore to all underlying lobooks. If your password
file is defined in an individual logbook section, the elogd server stores a
cookie with path "/<logbook>", so that it applies only to the specific logbook.

The problem arises now if one moves the password file statement from the
global section to the logbook section or back. The browser might still have
old cookies, whic can override any newly set cookie.

Long story short conclusion: If you observe this behaviour, just delete all
cookies in your browser and you should be fine. I added some additional code
to version 2.5.4 which catches a few cases but unfortunately not all.