> Ive just installed the RPM of Elog 2.3.2 and ive found a bug relating to 
> port bindings, basically im running elog bound to port 81 and when i 
> install the new RPM it refuses to bind to this port, i tried port 8080 and 
> that worked fine
> 
> Any ideas ?

This is a bug I discovered myself just today, so we are working on it. I 
expect this to be fixed by tomorrow or somewhen during this weekend.

- Stefan

> > Ive just installed the RPM of Elog 2.3.2 and ive found a bug relating to 
> > port bindings, basically im running elog bound to port 81 and when i 
> > install the new RPM it refuses to bind to this port, i tried port 8080 
and 
> > that worked fine

The bug has been fixed in V 2.3.3 which has been released today.

> After upgrading from 2.3.1 to 2.3.3, elog is not able to load any resources
> as stylesheets, images or passwordfiles.
> 
> Cannot open file /usr/local/elogdata/logbooks/djeks/password!

If you installed from the RPM, elogd runs under the user "elog". If you have 
installed a previous version under a different user, it might be that elogd 
does not have read or write access to it. A 

"chown -R elog.elog /usr/local/elogdata"

might help.

- Stefan

> I was wondering if you can help me understand the concept and if i am doing 
> something wrong with securing Elog via SSL
> 
> Basically im running elog on a redhat 8 box with stunnel already installed 
> as part of OpenSSL, on the server i ran the command specified in the 
> instructions
> 
> stunnel -d 443 -r 172.16.24.108:81
> 
> This command runs on the server, but when I access https://172.16.24.108/ i 
> get a page cannot be displayed, ive also put the URL = 
> https://172.16.24.108 entry in the elogd.cfg file
> 
> HELP!!!!!!!

Can you access your server locally under http://172.16.24.108:81 ??? If not, 
then you maybe specified the wrong port, so check elogd.cfg and the "-p" flag 
when starting elogd. If you can access it, and cannot access it under 
https://, then something must be wrong with your stunnel configuration. Maybe 
you run already a secure server under port 443? User "netstat -a" to check 
that.

> Let me start by saying that I really like ELOG-- it's a nice tool.
> 
> I'm trying out version 2.3.3. The problem that I'm having is with
> attachments disappearing when I do the following:
> 
> 1. create a new entry that contains one or more attachments.
> 2. verify that the new entry from step 1 saved correctly.
> 3. reply to the entry from step 1.
> 4. return to the entry from step 1 only to find the attachments gone.
> 
> The attachement files are still in the logbook directory, it's just that
> they are no longer attached to the entry.

This is a known problem and has been fixed in version 2.3.4, which has been 
released today. To prove that it's working, I attached the current 
elogd.cfg from this forum.

> Is there a way to change the title entry for individual log books, and 
> forms ive completely rebranded our system but ut stil says ELOG ENTRIES on 
> the summary screen

I changed the default title recently to "ELOG - <logbook>" where <logbook> 
is the name of the current logbook. For the individual messages, the 
title "ELOG" can be changed with the elogd.cfg option "Page title". This 
title can even contain attributes from the logook entry like:

Page title = ELOG - $subject

where $subject gets replaced by the subject of the logbook entry.

> I need something to set the title of the page when on the summary page for 
> the logbook, as it just says ELOG - Config DB (this isnt set anywhere)

I added the option "Summary page title = xxx" in a similar way than the "Page 
title". The new version is at

http://midas.psi.ch/cgi-bin/cvsweb/elog/src/elogd.c?rev=1.64

It will be included in the release 2.3.5 of elog.

- Stefan

> I noticed that when I put in a password such as <test1> a person can login 
> with the password <test2> or any other number at the end.  Is the 
> encryption not able to tell the difference between numbers?  The encrypted 
> passwords even look the same in the password file.  Is this a bug?

This is really strange. Encryption only works on ASCII characters and does 
not distinguish between letters and digits. When I try to reporoduce that, 
the system distinguishes well between "test1" and "test2". The first gives 
encrypted "dGVzdDE=" and the second gives "dGVzdDI=", note the different "E" 
and "I". So I have no clue right now what is wrong in your installation. If 
running under Linux, you can compile elogd after adding "-DHAVE_CRYPT" and "-
lcrypt" to the Makefile to use the standard Linux crypt() function, but I 
would rather like to understand what is wrong in your case.

- Stefan