Hi Stefan!

In the user manual under misc it says this: "The elog program makes it possible to submit logbook entries automatically by the system or from scripts. In some shift logbooks this feature is used to enter alarm messages automatically into the logbook. "

Ok what am trying to do is have all messages update (somehow) without the user entering each record. I want my alarm system to be able to keep-up2-date on the expirations, by simply updating the 'date' fields I have in the logbooks (JS). I am getting used to JavaScript, and have all of that working as far as the actual 'alarms' are concerned. But they are useless if the dates are stagnent (ie. not updateing at least once per day).

So can you refer me to the 'shift books' you reference above, so I can understand how to write the code necessary? I've spend much time searching the net on this and experimenting, so I did try to find out before I posted. I believe using a combination of the Elog Utility, with a dedicated 'start page' that is mostly JS, will be part of the solution...

Thanks soo much for your help and awesome creation! :)

John

Hello, dear ELOG's gurus.
Please help me to understand a problem with mirroring function.
It appears in ELOG V3.1.4-a04faf9f - the last official Windows release, as well as previous 3.1.3 Windows release, which I have checked for comparison.

When I'm using a manual configuration with "mirror server, cron, user" options for one (master) of two servers, it operates well, except the situation, when a new entry is submitted at the second (slave) server.
For example, for a new entry with a real ID#2 at Slave its logfile gives "NEW entry #0", so logfile of the master server gives "MIRROR: Error receiving message: Received wrong entry id "0"".
After that Master deletes this entry at Slave "MIRROR delete remote entry #2".

In case of mirror functions in both .cfg files (Master to Slave, Slave to Master) both servers hung on after the first mirror process.

Now let's imagine, what I want to do. 
Master, as a main-operation global log, is off-operation, Slave automatically becomes a reserv-operation local log with full information from Master due to previous periodic mirroring.
Users work with Slave, submit new entries - all with #0 ID.
After repairing Master starts active mirroring and just deletes all new entries from Slave.

It seems, that the problem is not with mirroring, but with a new entry ID, as was mentioned in https://elog.psi.ch/elogs/Forum/68850
Were these ID#0/mirror problems resolved somehow or may be it is not a problem, but simply my errors in ELOG configuration?
Is there a chance to get an up-to-date Windows-release with working both-sides mirror function and all other addings after V3.1.4-a04faf9f ?

Best regards,
Sergei

If you've upgraded from an elog 2.x version to an 3.x version, then all entries of a logbook will be moved into subfolder, one for each year.

If you then switch back to the 2.x version of elog, it'll not find any entries.

You can move them back to the folder for the logbook (one directory up) and they'll be found again after the next restart of elog.

Cheers, Andreas

Thanks to you, Stefan !

You software is very usefull for us and it's nice to have support.

Have a nice day !

I have been using elog for over 10 years. Suddenly my elog installation has changed (probably from a recent update. My /etc/elogd.cfg has changed to the original demo configuration. Even after changing it to my configuration from backup none of the entries for the logbooks apper even though the tabs for the logboos are ther all logbooks are empty. I have looced at the logbook files and the entries seem to be there but are not showing on the web interface. Has something changed? Is there a new location for the logbooks and other files? Is there a change from the 32-bit to the 64-bit version that will cause this. I am running CentOS 7 fully patched and updated. Will there be a CentOS 8 compatible version?

Hi Stefan

we are running elog

An ELOG vulnerability has been reported, thanks to Asif Akbar of Trend Micro Security Researchworking with Trend Micro's Zero Day Initiative:

https://www.zerodayinitiative.com/advisories/ZDI-20-252/

The issue has been fixed in the current release 3.1.4-033e292 and in the RPM http://elog.psi.ch/elog/download/RPMS/elog-latest.x86_64.rpm

Best,
Stefan

Thanks for the detailed investiations and report. Finally I could reproduce the problem by having messages with a text body size close to 250000 bytes (some internal limit). Never thought that someone really has the patience to write 250'000 chars in a single message, but I guess you did some copy/paste from a large file. Thought in such cases people use attachments. Nevertheless, I fixed an internal memory allocation problem, now it shoudl be fine to have such large messages. Change is committed.

Stefan