Hello,
    If you delete a message from the middle of a logbook that contains a 
bunch of messages, the message numbers do not get updated properly.  For 
instance, if you have 20 messages in the logbook, and delete number 15, 
entry numbers 16 through 20 all do not get subtracted by one; their numbers 
stay the same with #15 just missing in the middle.  

Mo

> Hello,
>     If you delete a message from the middle of a logbook that contains a 
> bunch of messages, the message numbers do not get updated properly.  For 
> instance, if you have 20 messages in the logbook, and delete number 15, 
> entry numbers 16 through 20 all do not get subtracted by one; their numbers 
> stay the same with #15 just missing in the middle.  
> 
> Mo

That's how it's supposed to be. Once a unique message ID is attached to a 
message, it stays there forever. Think of links to message like

http://midas.psi.ch/elogdemo/Forum/68

If you have such a link in a message or as a bookmark in your browser, and 
the ID gets changed from 68 to 67, then your link would be off.

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.

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.

Any ideas?

> > 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.

> 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.

Ok that sounds a good idea to me, I will work on that.

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

No this is not possible.

In version 2.0.4 of eLog I was having some problems with saving my 
configuration file once I edited it on the web using the config. command.
I keep getting the message "Cannot open file %s: elogd.cfg".  I made sure 
the file was in the right directory.  I dont know if I am doing something 
wrong or if its a bug?

Mo.

> In version 2.0.4 of eLog I was having some problems with saving my 
> configuration file once I edited it on the web using the config. command.
> I keep getting the message "Cannot open file %s: elogd.cfg".  I made sure 
> the file was in the right directory.  I dont know if I am doing something 
> wrong or if its a bug?

The error display is certainly wrong. I fixed that and you can download the 
updated version at 

http://midas.psi.ch/cgi-bin/cvsweb/elog/elogd.c

As for the error, you should check the file permissions. If you run the 
daemon under a user which has no write access to the directory or file, you 
would get the described error.

Where can I get more information about the config and themes file. I
downloaded the latest version (2.0.4) and the config file docs seem out of
date. I would like to get the icons working as well as getting the email to
work. The demo page at the elog home site shows both but I cannot find ant
references to the icons.

> Where can I get more information about the config and themes file. I
> downloaded the latest version (2.0.4) and the config file docs seem out of
> date. I would like to get the icons working as well as getting the email 
to
> work. The demo page at the elog home site shows both but I cannot find ant
> references to the icons.

Oops, I forgot the "IOptions" statement to documentation. Please see the 
updated version at

http://midas.psi.ch/elog/config.html

look for "IOptions". For the Email notification see the whole 
section "Email 
notification" near the bottom of the page.

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

> 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

Has been fixed in 2.0.4, have a look at

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

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.

> 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.

Has been fixed in 2.0.4 (as you can see from this entry). Please make sure 
not to submit too long lines via "elog". For browser submissions, the line 
length is limited to 78 characters, but not for "elog" submissions.

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

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

Has been fixed in 2.0.4

Hello,

I have a question concerning the following situation:

There is a one logbook with two possible acces methods (defined in config 
file) one for readonly access and one for read/write access. Both entries in 
the elogd.cfg file pointing to the same logbook.

When an allowed person enters a logbook entry with an email notification the 
link to the message is given inside the email. 
This link points to the read/write logbook entry.

Is it possible to alter the link in the email notification that it points to 
the corresponding readlonly logbook entry? 

Thank you for hints, best regards,


Stefan Siegel  

Having the URL link to a different logbook is right now not possible. But 
what about setting up a single logbook with a write password. Everybody can 
access it for reading, but only these people who know the write password 
can enter messages.