Has anyone had issues with having too many files open? I'll setup my server and let it go but after a while, I end up with a lot of "cannot create socket: Too many open files" errors being reported.  I have a sync to another e-log going which I suspect is part of the cause since that e-log server hasn't had this issue. I suspect that there are files being opened, going into some return loop code and then never getting closed. I'm not a C programmer but I see lines like :

fh = open(tmp_filename, O_RDONLY);
      if (fh > 0) {
         read(fh, result, size - 1);
         close(fh);
      }

      /* remove temporary file */
      remove(tmp_filename);

This looks like it opens the file but unless the remove function closes the file, it will remain open even through the file has been deleted. Maybe this isn't the correct behaviour of 'remove' and I am mistaken?

There are also parts like :

 fh = open(textfile, O_RDONLY | O_BINARY);
      if (fh < 0) {
         printf("Message file \"%s\" does not exist.\n", textfile);
         return 1;
      }

      size = (INT) lseek(fh, 0, SEEK_END);
      lseek(fh, 0, SEEK_SET);

      if (size > (INT) (sizeof(text) - 1)) {
         printf("Message file \"%s\" is too long (%zd bytes max).\n", textfile, sizeof(text));
         return 1;
      }
This looks like for the second error, it will complain that the file is too long, return an error message but not close the file and would leave it open. Is this a reasonable avenue to pursue or am I mis-reading the code?   Thanks.

Recently central IT scanned our elog server and reported the following "vulnerabilities"

• 42873 (1) - SSL Medium Strength Cipher Suites Supported (SWEET32)
• 51192 (1) - SSL Certificate Cannot Be Trusted
• 65821 (1) - SSL RC4 Cipher Suites Supported (Bar Mitzvah)
• 85582 (1) - Web Application Potentially Vulnerable to Clickjacking

Is there any easy way of preventing these

Thanks and Best Wishes

David

The elgod.c progarm itself is rather weak in SSL, since I just don't have time to catch up with the latest SSL enhancements. The safest you can do is to put an industry-strenth web server like Apache in front of elogd and let that server handle the SSL layer.

Stefan

Hi,

I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately.

Actually this is related to post 68993 from Sebastian Schenk in Jul 2019. Are there any new workarounds I may have missed?

Hi,

I'm wondering if it's possible to have a shared logbook and elog.cfg between multiple instances of elog.  Ideally, I'd like to have my logbooks folder and elog.cfg hosted on a nextcloud instance while running the elog service locally.  I've tried this using symlinks and shortcuts on windows with no luck.  I was able to install elog into my mounted nextcloud folder, but this isn't ideal as I would like this to work from multiple computers.

Any ideas or thoughts on how I can do this (if I can actually do this)?

Hi Anthony,

the elog has a mirroring function, which synchornizes config and logs between multiple instances.
See the bottom section of https://elog.psi.ch/elog/config.html

Best wishes,
Sebastian

Hi Chris,

my old entry was related to the admin options of edit time.
The option "Admin restrict edit time" was implemented later, see ab8b98c

As a workaround you should be able to give "Restrict edit time" a ridiculous high number in the specific logbook, which should overwrite the global.
In the documentation is no rule specified for diabling global settings for specific logbooks, as far as i know.

Best wishes,
Sebastian