Hi Stefan,

After 21.Oct, all the emails sent out by this discussion form now are addressed to

ELOG@ananke.jtan.com
the name of the server my mails are sent to.

Before that the emails were addressed to 

ELOG@emix.psi.ch

Obviouisly my real email address is there, in the headers (as it would appear for a BCC)

The only consequence for me was these emails turned up in the wrong mailbox, but perhaps it has wider implications?

> Hi Stefan,
> 
> After 21.Oct, all the emails sent out by this discussion form now are addressed to
> 
> ELOG@ananke.jtan.com
> the name of the server my mails are sent to.
> 
> Before that the emails were addressed to 
> 
> ELOG@emix.psi.ch
> 
> Obviouisly my real email address is there, in the headers (as it would appear for a BCC)
> 
> The only consequence for me was these emails turned up in the wrong mailbox, but perhaps it has wider implications?

Indeed on Oct. 21st the SMPT server sending out emails from this forum has been changed. I checked my own mails coming 
from the forum, but I could not find any hint of what you describe above. The "From:" header contains "noreply@psi.ch" 
and the "To:" header is my email address. The "Received:" header contains our SMTP server, but you should not that field 
for filtering your email.

- Stefan

Hi Stefan,

I have a thread of 70 entries.  I added another entry, which was saved, but elog crashed.
It would restart, but crash every time I then tried to access that 71 entry thread.

By editing the yymmdda.log files to remove the latest entry, all was well again.
Add a test new entry (much smaller) also crashed elog as before.

If it is any help, this is the error message I caught on a console:

src/elogd.c:703: xrealloc: Assertion `*((unsigned int *) (temp + old_size)) == 0xdeadc0de' failed.
./log: line 1:  3123 Aborted    

Now I have got around this, by ending that thread with reference to a new one to continue, but is this to be
expected?  

If this is something (like memory allocation) that would have been in hiding from the start, I cannot imagine
that it is likely to be hit often enough to actually "bug fix" - it might, in any case, cause problems elsewhere.

Hi,

Here is what happens (I think) if E-log encounters a full file system where it keeps the user authorization file:

1. When a user connects, E-log will make a backup of the file. The backup will be corrupt since the file system is full.

2. E-log will modify the contents of the original file, and write it back. The file will be corrupt since the file system is full.

3. Now, both the backup and the normal file are corrupt and you cannot log on, until someone cleans up the file system and restores a valid copy of the file.

Would it be possible to fix this ? Like abort if step 1 is not successful. And restore the backup file if step 2 is not successful.

Thanks a lot for you help 

Soren

Ok, I finally found some time (I'm pretty busy these days) to add a check for a potential full file system in SVN revision 2258. So before the password file would get corrupted, elog shows an error message about the full file system and just stops to work until space is freed up. 

Great. We fully appreciate that your are busy (with other things than E-log).

Thanks for the resolution.

Soren

Hi,

I use the following attribute definition:

Options <attribute> = <list> 

However, I am being limited by the list length limit of 100. I have 103 items, but I only see 100.

Could the limit be extended (to 200 for instance) ?

Thanks a lot for your help

Soren

You can change that yourself. Just find following line in elogd.c:

#define MAX_N_LIST      100

Thanks. This is a good explanation. It might indeed be better to re-group the options to have a shorter list.

Soren

* Withdrawn *

The HTML layout produced by elogd is horrendous to deal with programmatically; I give up.

Hi,

I'm writing a greasemonkey script to slightly alter the look of the pages served by the ELOG server.  One difficulty that I'm struggling with is how to identify what type of page ELOG has created.  While I have several methods to determine the page type, such as a log entry vs. log entries summary, the solutions are not straight forward and not clean.  As far as I tell, there's no specific identification in HTML document currently that describes and identifies the type of page being served by the ELOG server.

So, I'm requesting that the pages created by ELOG be identified in some fashion with the META element, such as:

    <meta name="description" content="elog log entry" />

or

    <meta name="description" content="elog log summary" />

or even using the keywords attribute:

    <meta name="keywords" content="elog log summary" />

Thanks!

Sorry, I didn't yet have time to implement your request.

Have you considered to download an entry in plain text? Like this entry you can load with

https://midas.psi.ch/elogs/Forum/66555?cmd=Download

which should be much easier to interprete. If you write your entries in ELCode or plain format, it should be even easier. 

Like many educational institutions we get "educational certificates" that are chain certificates..

With apache the full certificate chain is working as expected..

For elog I copied the appropriate files to server.crt and server.key

Netscape 3 is happy with that setup, Internet Explorer and Opera are mentioning the open certificate chain.

When I tried to copy the file known as SSLCACertificateFile in Apache to chain.crt elogd does not longer work and 

openssl s_client -showcerts -connect <myserver>:<elogd_port>

only shows: 

CONNECTED(00000003)
25523:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:562:

What do I do wrong?

Gerhard Schneider

> Like many educational institutions we get "educational certificates" that are chain certificates..
> 
> With apache the full certificate chain is working as expected..
> 
> For elog I copied the appropriate files to server.crt and server.key
> 
> Netscape 3 is happy with that setup, Internet Explorer and Opera are mentioning the open certificate chain.
> 
> When I tried to copy the file known as SSLCACertificateFile in Apache to chain.crt elogd does not longer work 
and 
> 
> openssl s_client -showcerts -connect <myserver>:<elogd_port>
> 
> only shows: 
> 
> CONNECTED(00000003)
> 25523:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:562:

To be honest I'm not an expert on SSL. I just use following code inside ELOG to initialize the SSL connection:

SSL_CTX *init_ssl(void)
{
   char str[256];
   SSL_METHOD *meth;
   SSL_CTX *ctx;

   SSL_library_init();
   SSL_load_error_strings();

   meth = SSLv23_method();
   ctx = SSL_CTX_new(meth);

   strlcpy(str, resource_dir, sizeof(str));
   strlcat(str, "ssl/server.crt", sizeof(str));
   if (!file_exist(str)) {
      eprintf("Cerificate file \"%s\" not found, aborting\n", str);
      return NULL;
   }
   if (SSL_CTX_use_certificate_file(ctx, str, SSL_FILETYPE_PEM) < 0)
      return NULL;

   strlcpy(str, resource_dir, sizeof(str));
   strlcat(str, "ssl/server.key", sizeof(str));
   if (!file_exist(str)) {
      eprintf("Key file \"%s\" not found, aborting\n", str);
      return NULL;
   }
   if (SSL_CTX_use_PrivateKey_file(ctx, str, SSL_FILETYPE_PEM) < 0)
      return NULL;
   if (SSL_CTX_check_private_key(ctx) < 0)
      return NULL;

   strlcpy(str, resource_dir, sizeof(str));
   strlcat(str, "ssl/chain.crt", sizeof(str));
   if (file_exist(str))
      SSL_CTX_use_certificate_chain_file(ctx, str);

   return ctx;
}

Maybe I need something different for chain certificates, but I don't know. I just copied these calls from the 
example which comes with the libssl library which I'm using. Maybe somebody has an idea how this could be 
improved. Actually looking at the code I see that the 'chain.crt' file is used. If you send me your files 
privately I could try them and see if I get a specific error code from the SSL library.

> Like many educational institutions we get "educational certificates" that are chain certificates..
>  
> only shows: 
> 
> CONNECTED(00000003)
> 25523:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:562:
> 
> What do I do wrong?
> 

After reading the OpenSSL Documentation:

The certificates must be in PEM format and must be sorted starting with the subject's certificate (actual client or
server certificate), followed by intermediate CA certificates if applicable, and ending at the highest level (root) CA.

The chain.crt has to be of the following format:

HOST CERTIFICATE
INTERMEDIATE CERTIFICATE
ROOT CERTIFICATE

Then it is working w/o problems

GS

When locks are enabled, users should see a pop-up window asking them to submit an entry if they edit an entry but then go away from that page or 
close the browser without submitting the changes.  However, it only appears as though this works when using the plain or ELCode editors.  When 
using the HTML editor, no such pop-up appears.

If possible, a fix for this would be greatly appreciated.

Many thanks,
Devin

> When locks are enabled, users should see a pop-up window asking them to submit an entry if they edit an entry but then go away from that page or 
> close the browser without submitting the changes.  However, it only appears as though this works when using the plain or ELCode editors.  When 
> using the HTML editor, no such pop-up appears.
> 
> If possible, a fix for this would be greatly appreciated.
> 
> Many thanks,
> Devin

Thanks for reporting this problem, I fixed it in SVN revision 2256.

We have been running elog for a couple of years now and this morning it stopped working.

We have tried to rstart it and it says successful start but still does not run, when doing a restart it says stop failed start success.

Does anyone have any ideas.

thanks

You shoudl start elogd interactively in a DOS box to see if there is any error. Maybe disk full or a network problem... 

 It is running on a linux box, we have started in it in a telnet session, and no errors appear, as I am new to e-log is there an error log anywhere.

 Have fixed this by removing the last added user from the Passwd file.

 Have fixed this by removing the last added user from the Passwd file.