Version 2.3.9 of elog has been released today. Enhancements are:

- Added options "Use Lock", "Title image"

- New "Email format" specifies what is sent exactly in an email 
notification. This may now include also attachments

- "Format <attribute>" lets you assign separate style sheet classes to each 
attribute, making the web display more powerful (see this forum, 
the "subject" uses a separate formatting). Note that this feature requires 
an update of the old "default.css" CSS file, if a elog version prior to 
2.3.9 is already installed on a system.

- "Execute new/edit/delete" lets one execute shell commands on the server 
side for new, edited or deleted messages. Since this can cause security 
problems, a new flag "-x" has been added to the elogd daemon to enable this 
feature. It can be used to synchronize the elog database with other 
databases, or to send SMS messages to people.

- New "Logging level" option gives enhanced logging capabilities, including 
read and write access logging to individual elog entries.

- The elog utility can now edit existing messages, and correctly quotes 
messages with "> " on replies.

A few small bugs have been fixed, refer to the ChangeLog for more details.

Can you give a syntax example of the Logging Level option ?



> Version 2.3.9 of elog has been released today. Enhancements are:
> 
> - Added options "Use Lock", "Title image"
> 
> - New "Email format" specifies what is sent exactly in an email 
> notification. This may now include also attachments
> 
> - "Format <attribute>" lets you assign separate style sheet classes to each 
> attribute, making the web display more powerful (see this forum, 
> the "subject" uses a separate formatting). Note that this feature requires 
> an update of the old "default.css" CSS file, if a elog version prior to 
> 2.3.9 is already installed on a system.
> 
> - "Execute new/edit/delete" lets one execute shell commands on the server 
> side for new, edited or deleted messages. Since this can cause security 
> problems, a new flag "-x" has been added to the elogd daemon to enable this 
> feature. It can be used to synchronize the elog database with other 
> databases, or to send SMS messages to people.
> 
> - New "Logging level" option gives enhanced logging capabilities, including 
> read and write access logging to individual elog entries.
> 
> - The elog utility can now edit existing messages, and correctly quotes 
> messages with "> " on replies.
> 
> A few small bugs have been fixed, refer to the ChangeLog for more details.

> Can you give a syntax example of the Logging Level option ?

Please refer to the documentation (http://midas.psi.ch/elog/config.html), I just 
updated it. "Logging Level = 3" is the maximum level which includes writes and 
reads.

Cheers

It appears Im having problems getting this to work, my config is as follows, yet 
its not updating the log file since i installed the new RPM 2.3.9, is there a 
problem or am I doing something wrong ?

Thanks in advance.

[global]
port = 81
Logbook dir = /data
Logbook Tabs = 1
Main Tab = Home
Page title = LogBook System
SMTP host = support.localnet
Logfile = /var/log/elogd.log
Logging level = 3
Resource dir = /usr/local/elog
Welcome title = <img src="logo.gif"><p><font size=4 color=white>Customer Relational 
Management System</font>
Page title = Customer Relational Management System
Bottom text = bottom.html
URL = http://172.16.24.108:81/

> > Can you give a syntax example of the Logging Level option ?
> 
> Please refer to the documentation (http://midas.psi.ch/elog/config.html), I just 
> updated it. "Logging Level = 3" is the maximum level which includes writes and 
> reads.

> It appears Im having problems getting this to work, my config is as follows, yet 
> its not updating the log file since i installed the new RPM 2.3.9, is there a 
> problem or am I doing something wrong ?

Oops, there was a bug. I added the resource directory in front of the logfile name, 
which is not correct if the logfile name contains an absolute path. I fixed that in 
the current CVS version. As a temporary fix, remove the resource dir in your elogd.cfg 
or remove the full path in the logfile (the file will the be put into the resource dir 
of course...).

   I would like to implement ELOG as a logbook for our Windows 2000 
servers.  After making the recommendation, my supervisor replied: 

"The problem and perhaps the only problem is what happens when the server 
is down. Electronic log books should be able to replicate from more than 
one source so you can document let’s say from your laptop – and upload to 
the server later."

   Can anyone help me out here with some scenarios to improve fault-
tolerance?  

   Perhaps installing it on multiple servers and synchronizing the data 
and config folders with the NT File Replication Service?  

   Or installing it on one server and each administrator's laptop and 
using Offline Files to synchronize the data?

Any feedback would be appreciated,

Shawn Larson

I was thinking since some time already about mirroring between elog servers, 
and actually started already some implementation.

The problem with mirroring on the file level does not work. Assume two 
servers "serv1" and "serv2". Then assume that one message gets submitted on 
serv1 and at the same day another message gets submitted on serv2. Now you 
have on both servers a file 030726a.log, but you cannot copy this file 
simply from one server to the other, since you would overwrite the message 
submitted on the other server. Furthermore, you need file level access, 
which is maybe easy between your laptop and your desktop computer, but not 
if the two mirror servers are in different countries. Like in our 
collaboration we have three servers located in Switzerland, Italy and Japan 
(meg.psi.ch, meg.pi.infn.it, meg.icepp.s.u-tokyo.ac.jp), where we cannot 
have direct disk access.

So what I propose is the following mirror scheme:

o Each elog server may contain a list of mirror servers in the configuration 
file

o Each elog server calculates an MD5 checksum from all local messages

o Synchronization between servers can be triggered manually (by clicking 
on "Synchronize") or automatically at a given time and interval

o On Synchronization, the elogd server fetches the MD5 list from the mirror 
server and compares it with the local list

o If a message has been edited remotely but not locally, it's fetched and 
stored locally, same in the other direction

o If a message got edited on both sides since the last synchronization, the 
user is asked to resolve the conflict (keep local or keep remote message)

o If there is a new message locally, its submitted at the remote server, but 
with the same submission date/time as locally, same in the other direction

o If new messages are present on both sides, their message ID is changed so 
that it is unique, then they are copied over. If there are already replies 
to this message, their link (using the message ID) is changed accordingly

So I plan to implement this scheme in the next time. The MD5 checksum is 
already there. If anybody has comments or additional wishes concerning 
mirroring, telling them right now would be great, since I then can 
accomodate them easier during the implementation.

- Stefan

Contribution available for all who wants to make SKIN for ELOG!

You are invited to benefit from this free info!

Just click on the "Contributions" tab to find the info (look for ID6).

Or... goto          http://midas.psi.ch/elogdemo/Contributions/6