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

elog -h 192.168.0.25 -p 80 -l Database -a Type=test1 -a OS=W2K -a Loc=room1
-a Status=operational

doing anything wrong here?

Note: When I hit ctrl-break, it exits to cmd prompt, and the entry appears 
in the logbook.... ?

> elog -h 192.168.0.25 -p 80 -l Database -a Type=test1 -a OS=W2K -a Loc=room1
> -a Status=operational
> 
> doing anything wrong here?

opps nevermind, i didn't realize I had to put something in for the ending 
body text.  Anyway to skip that part?

> elog -h 192.168.0.25 -p 80 -l Database -a Type=test1 -a OS=W2K -a Loc=room1
> -a Status=operational
> 
> doing anything wrong here?

> opps nevermind, i didn't realize I had to put something in for the ending 
> body text.  Anyway to skip that part?
> 
> > elog -h 192.168.0.25 -p 80 -l Database -a Type=test1 -a OS=W2K -a Loc=room1
> > -a Status=operational
> > 
> > doing anything wrong here?

Due to frequent requests, the elog utility reads the message body text from the 
console (stdin), if it's missing on the command line (like in your case). Under 
Linux, you can then pipe some text into elog

cat message.txt | elog -h ...

or under Windows

type message.txt | elog -h ...

If you enter the text directly, you have to finish it with Ctrl-Z / Return
(Windows) or Ctrl-D (Linux). If you do not want any text, you can write

elog -h .... -a Status=operational " "

to submit an empty text (well, almost empty, contains single blank).

I tried to add a file with the  "Bottom text = <file>" option.

Although one would suggest that the bottom text file is included in every 
page, I only saw the file appear in the page that appears when you issue 
the "cmd=Edit" command.

Resolving this would enhance the ability to create skin.

> I tried to add a file with the  "Bottom text = <file>" option.
> 
> Although one would suggest that the bottom text file is included in every 
> page, I only saw the file appear in the page that appears when you issue 
> the "cmd=Edit" command.

That's really weired. The file is displayed at the bottom of single messages, 
and the message list, but NOT at the form, which you reach with the "Edit" 
command. So all I can suggest ist the following:

- Hit the reload button on your browser each time you change that file, to 
make sure the browser does not display a page from its cache

- The HTML file is *included* in the normal page, so it should not contain 
<HTML> or <BODY> tags. Start with a simple file containing something like

<center>Test</center>

and see what you get.

- Make sure the file is in the elog "resource" directory, which gets 
displayed if you start elogd with the "-v" flag.

Let me know if any of this helped.

Is there a way to configure elog so users that have their email notification
on only get notified for updates to logs they have access to? I've looked
all through the documentation and I can't seem to find a way to do this.

If not is there some way I can work around this without to much trouble?  I
have lots of logs and would really hate to have to make configuration
changes in all of them .

Having the message body mailed to you is very convenient but some of my
users only get to see their logs. If the body gets mailed to them they get
to see everything anyway. 

When I had to use separate password files this wasn't an issue.

> Is there a way to configure elog so users that have their email notification
> on only get notified for updates to logs they have access to? I've looked
> all through the documentation and I can't seem to find a way to do this.

I guess you have a global password file and use "login user" statements for 
your logbooks. I have added some code which does per default not send any 
email to people who are not in the "login user" list, in case this list is 
present. New code under CVS. Please give it a try and let me know if it works 
for you.

- STefan

You guessed right. I give it a try soon as I get a chance. Thanks.

> I guess you have a global password file and use "login user" statements for 
> your logbooks. I have added some code which does per default not send any 
> email to people who are not in the "login user" list, in case this list is 
> present. New code under CVS. Please give it a try and let me know if it works 
> for you.
> 
> - STefan

I have had this installed for about two weeks now and it seems to be working
fine. I haven't seen any problems at all and none of the other users have
reported any.

Thanks.  This is very helpful.

> > Is there a way to configure elog so users that have their email notification
> > on only get notified for updates to logs they have access to? I've looked
> > all through the documentation and I can't seem to find a way to do this.
> 
> I guess you have a global password file and use "login user" statements for 
> your logbooks. I have added some code which does per default not send any 
> email to people who are not in the "login user" list, in case this list is 
> present. New code under CVS. Please give it a try and let me know if it works 
> for you.
> 
> - STefan

Great program!  Thank you.

Short of manually editing the logbook files, is there a way I can change the
date of an entry?  I want to transfer my "Linux Journal", which I have been
writing as a regular document for several months, into elog so I can take
advantage of the threading, sorting, find, etc.

> Short of manually editing the logbook files, is there a way I can change the
> date of an entry?  I want to transfer my "Linux Journal", which I have been
> writing as a regular document for several months, into elog so I can take
> advantage of the threading, sorting, find, etc.

You cannot change the entry date, since this is kind of system stamp which 
should not be modified. But you can add an attribute like "Issue" for your 
Linux Journal, where you can add manually the month and year of release or so. 
Then you can preset this attribute with the current date, which you can change 
for older issues, like

Attributes = ...., Issue
Preset Issue = $date
Date format = %B %Y

Hope this helps.

- Stefan

> > Short of manually editing the logbook files, is there a way I can change the
> > date of an entry?  I want to transfer my "Linux Journal", which I have been
> > writing as a regular document for several months, into elog so I can take
> > advantage of the threading, sorting, find, etc.
> 
> You cannot change the entry date, since this is kind of system stamp which 
> should not be modified. But you can add an attribute like "Issue" for your 
> Linux Journal, where you can add manually the month and year of release or so. 
> Then you can preset this attribute with the current date, which you can change 
> for older issues, like
> 
> Attributes = ...., Issue
> Preset Issue = $date
> Date format = %B %Y
> 
> Hope this helps.
> 
> - Stefan


Yes! Thank you.  But now another question.  How can I hide the entry date
attribute on the summary screens and automatically sort by Issue?  No point in
showing both dates.

> > > Short of manually editing the logbook files, is there a way I can change the
> > > date of an entry?  I want to transfer my "Linux Journal", which I have been
> > > writing as a regular document for several months, into elog so I can take
> > > advantage of the threading, sorting, find, etc.
> > 
> > You cannot change the entry date, since this is kind of system stamp which 
> > should not be modified. But you can add an attribute like "Issue" for your 
> > Linux Journal, where you can add manually the month and year of release or so. 
> > Then you can preset this attribute with the current date, which you can change 
> > for older issues, like
> > 
> > Attributes = ...., Issue
> > Preset Issue = $date
> > Date format = %B %Y
> > 
> > Hope this helps.
> > 
> > - Stefan
> 
> 
> Yes! Thank you.  But now another question.  How can I hide the entry date
> attribute on the summary screens and automatically sort by Issue?  No point in
> showing both dates.


I figured out how to hide columns, using the "Display search" parameter.  (BTW,
suggest you modify the Administrator manual to mention that "Display search" applies
  to the initial display as well as any "Find"s.  I had seen this, but assumed it
only applied to actual search results.)  Still have not figured out how to change
the default sort attribute however.

> I figured out how to hide columns, using the "Display search" parameter.  (BTW,
> suggest you modify the Administrator manual to mention that "Display search" applies
>   to the initial display as well as any "Find"s.  I had seen this, but assumed it
> only applied to actual search results.) 

Fully agree. The name comes from historical reasons. I renamed "Display search" 
to "List Display". Will come in the next version.

> Still have not figured out how to change
> the default sort attribute however.

There is a little trick to do that:

Start page = ?rsort=Issue

Since sorting is done only lexically, you need a special date format like

Date format = %Y %m %d

in order to sort correctly.

> > I figured out how to hide columns, using the "Display search" parameter.  (BTW,
> > suggest you modify the Administrator manual to mention that "Display search" applies
> >   to the initial display as well as any "Find"s.  I had seen this, but assumed it
> > only applied to actual search results.) 
> 
> Fully agree. The name comes from historical reasons. I renamed "Display search" 
> to "List Display". Will come in the next version.
> 
> > Still have not figured out how to change
> > the default sort attribute however.
> 
> There is a little trick to do that:
> 
> Start page = ?rsort=Issue
> 
> Since sorting is done only lexically, you need a special date format like
> 
> Date format = %Y %m %d
> 
> in order to sort correctly.

Thanks again!  That did the trick.  One little hassle is that I had to go back and edit
all the Issue fields in my existing records so they would have the correct date format.

Rock on OSS!

Is it possible to preset an attribute with the current weeknumber?

> Is it possible to preset an attribute with the current weeknumber?

No. All you can do is 

Date format = %W

which displays the week number in the "Entry date" field. This number goes 
from 00 to 53. Some systems support "%V", which runs from 01 to 53.

In the current source which ive compiled and am using on our elog system, 
the feature that you put in for me that says "Entry is currently being 
edited by Joe Bloggs on 192.168.0.10" has vanished.

It removes existing locks from before updating the binary but doesnt but 
new ones on.

Is this something that was removed intentionally or by accident ?

Thanks

> In the current source which ive compiled and am using on our elog system, 
> the feature that you put in for me that says "Entry is currently being 
> edited by Joe Bloggs on 192.168.0.10" has vanished.
> 
> It removes existing locks from before updating the binary but doesnt but 
> new ones on.
> 
> Is this something that was removed intentionally or by accident ?

No, but there is now a flag "Use Lock = 0 | 1" which is zero by default, 
since not all people want this feature. So put a "Use Locl = 1" and you 
should be fine gain.

Excellent thanks

Is there a possibility to integrate into ELOG some more features in terms 
of page formating?

Currently, the .cfg file allows you to specify only the data structure of 
the dataentry/consultation HTML page. And you only have very limited 
possibilities to change the layout of the page (basically only the order of 
attributes on the page and with the help of the .css file the font, color 
and background of the page as a whole).

What we would like to do is to :
+ apply a stylesheet class to an attribute (change the particular TD class)
+ specify the width of a textfield (sometimes it is really not necessary to 
have such a long textfield area for a 3-letter long code)
+ put an attribute on the same line as the previous one (instead of putting 
it automatically on the next line)

Therefore, in addition to the current attributes & parameters, we suggest 
the following syntax in the .cfg file:
+ parameter AttribPos which would specify the position of an attribute, 
it's lenght (for text attributes only) and the .css class to apply
+ parameters in [] are optional
AttribPos AttribName = same_line, width, [class]

Examples: 
AttribPos DateUp =  0,20, [important]   
+ Attribute "DateUp" will be put on the next line, the textfield width will 
be 20 characters and a .important class will be applied to it from the 
default (or specified) .css file.

AttribPos DateUp =  1,15,
+ this puts the DateUp attribute on the same line, width 15

We believe that these improvements would help to make the ergonomy of the 
screen better and thus facilitate the user-dataentry/consultation. 

Thank you very much for your request, well motivated and described. I hope I 
will soon find time to impelment this.

I implemented your request. The syntax is:

Format <attribute> = <flags>,<css_class_name>,<css_class_value>,<width>,<size>

<flags>
  Sum of following values:
    1: Display attribute in same line as previous attribute
    2: Display radio buttons or check boxes in separate lines (if applicable)

<css_class_name>,<css_class_value> 
  Cascading Style Sheet class names used for cells containing attribute name
  or value, respectively. The classes must be defined in the style sheet file 
  (usually themes/default/default.css)

<width>> 
  Width of the text entry field in characters

<size> 
  Maximum number of characters allowed. 

Default is "0, attribname, attribvalue, 80, 500". Trailing parameters can be 
ommitted, so specifying for example only the flags is possible.

In order to have several attributes in one line, each line is now a separate 
table. This requires adjustment of the CSS class "attribname". Best you use 
the current default stylesheet (http://midas.psi.ch/elogdemo/default.css).

You can compare the two different approaches (one attribute per line/multiple 
attributes per line) in this forum and the "archive" logbook. The "subject" 
field in this forum also uses a different style class.

Note that if you upgrade to the current CVS version 
(http://midas.psi.ch/cgi-bin/cvsweb/elog/src/elogd.c?rev=1.129), you also 
have to change following options in your elogd.cfg:

- The style sheet must contain the new class "attribhead"
- "Email message body" has been replaces by "Email format"
- "Filtered browsing" is now off by default
- Locking (during editing of messages) is disabled by default, and enabled 
by "Use lock = 1"

Very interesting, indeed!
Thank you very much for the implementation. I believe this is a big step ahead 
in terms of ELOG screen formating (and therefore easier/more ergonomic 
dataentry/reading).

We will test your modifications as soon as you make a new release.

Tomas


> I implemented your request. The syntax is:
> 
> Format <attribute> = <flags>,<css_class_name>,<css_class_value>,<width>,<size>
> 
> <flags>
>   Sum of following values:
>     1: Display attribute in same line as previous attribute
>     2: Display radio buttons or check boxes in separate lines (if applicable)
> 
> <css_class_name>,<css_class_value> 
>   Cascading Style Sheet class names used for cells containing attribute name
>   or value, respectively. The classes must be defined in the style sheet file 
>   (usually themes/default/default.css)
> 
> <width>> 
>   Width of the text entry field in characters
> 
> <size> 
>   Maximum number of characters allowed. 
> 
> Default is "0, attribname, attribvalue, 80, 500". Trailing parameters can be 
> ommitted, so specifying for example only the flags is possible.
> 
> In order to have several attributes in one line, each line is now a separate 
> table. This requires adjustment of the CSS class "attribname". Best you use 
> the current default stylesheet (http://midas.psi.ch/elogdemo/default.css).
> 
> You can compare the two different approaches (one attribute per line/multiple 
> attributes per line) in this forum and the "archive" logbook. The "subject" 
> field in this forum also uses a different style class.
> 
> Note that if you upgrade to the current CVS version 
> (http://midas.psi.ch/cgi-bin/cvsweb/elog/src/elogd.c?rev=1.129), you also 
> have to change following options in your elogd.cfg:
> 
> - The style sheet must contain the new class "attribhead"
> - "Email message body" has been replaces by "Email format"
> - "Filtered browsing" is now off by default
> - Locking (during editing of messages) is disabled by default, and enabled 
> by "Use lock = 1"