Dear, sir! There is a problem with a configuration file.

The code was compiled by Cygwin (gcc-core, gcc-g++, make, gdb, libssl-dev).  After a compilation a reference to our own css-file was written in configuration file and css-file was included in a folder “themes/default” of the project.

The problem is that in running elog-3.1.4-1 (and upper versions) css-file name in a code of a page has some random symbols before file-name, for example: <link rel="stylesheet" type="text/css" href="ø9öÿeLogOUK.css">. It was found that the problem is resolved if a string “Password file=passwd” is deleted, but in this case it is impossible to set passwords to the users.

Here is an example of configuration file which is taken from the forum and just one string (CSS=elogOUK.css) has added to the code

[global]

; port under which server is listening

Port = 8080

CSS = eLogOUK.css

[Accelerator]

Comment = Accelerator Logbook

; use user level password access

Password file = passwd

Login expiration = 1000

Admin user = ritt

Self register = 1

; look and feel

Guest menu commands = Back, Find, Login, Help

Guest find menu commands = Find, Login, Help

Date format = %B %d, %Y

; attributes

Attributes = Author, Author Email, Category, Subject

Options Category = Routine entry, Shift summary, Problem, Fix, Question, Info, Other

Extendable attributes = Category

Required Attributes = Category, Subject

Thread display = $Subject, entered by $author on $Entry date

Quick filter = Date, Category

; title as shown in the browser

Page Title = Accelerator Logbook - $subject

; preset author and email

Preset Author = $long_name

Preset Author Email = $user_email

; these attributes cannot be changed

Locked Attributes = Author, Author Email

; only author can change its own entry

Restrict edit = 1

; options for reply

Subst on reply subject = Re: $Configuration Name

Remove on reply = Author, Author Email

; No Email notification

Suppress Email to users = 1

____________________________________________________________________

What can be done to resolve this problem?

An experiment's ELOG installation, using the default theme, names logbooks after its subsystem's acronyms.  One subsystem is referred to as KTAG, but when this name (or its lowercase version) is used for a logbook name, the logbook appears unformatted.  Changing the name, even to K-TAG, works fine.  Nothing close to KTAG appears in elog.css.  Does anyone know why this happens and whether it is possible or worth the while to get around the "problem"?

Running elog-3.1.4-3 Can't add users through the web interface. Clicking add user and writing all the fields in with something doesn't add a user into the PWD file of that logbook. Running a tail -f on the password file shows elog writes the user info with the hashed password 3 times and then deletes the information about 20 seconds later. Has anyone else had a similar issue? This is running on RHEL8.3

I can confirm the issue also for "prepend on edit".
To be more precise, it gets executed everytime the condition state changes, if placed in the config without condition, or if placed in a condition, everytime the condition gets activated.

The command "Append on edit = " is getting executed everytime, when a dropdown menu is changed. This happens even at the first creation of an entry, so the append text stucks up multiple times in the text body.

Hi Sebastian,

You're absolutely correct that the users at the chambers could directly use the remote ELOG server (without having a local server), and I did originally think about this.  Unfortunately, there are times that our network "goes down" (for maintenance and other issues), and it was important to maintain the users' ability to perform regular 'local' updates at the temperature chambers, regardless of the network status.

In our situation, having a remote server also became particularly useful in the event that the 'local' computer at a specific temperature chamber "went down".  The user can continue to update the respective logbook at the remoter server, knowing that it would eventually synchronize with the respective local server(s).

Thanks for the great feedback!
Frank

Hi Frank,

I am not sure, if I understood your setup correctly. But in my eyes, you don't need the local elog servers. The only difference for the users at the chambers would be to directly use the 'mirror' remote elog url instead of the local elog url in their browsers. "which is regularly updated..." could mean, that you are using some kind of automatism to add entries to the local elogs, but you could also use these directly on the remote 

If you have concers about users editing the wrong chamber elog, there is a usermanagement to only allow certain users to certain elogs (on the remote).

As for the part "having a record conflict". That would be totally fine and handled by the mirror function.
See the part "If new entries exist locally and remotely having the same entry ID"... in the documentation of the function.

As you state, that you are working on windows. There is no "killall" command to send the signal, as far as i know.
Then a script could kill the elog and start it again. But this should have the disadvantage of loosing the login session of the users.

Best wishes,
Sebastian

Hi Sebatian,

Thank you for taking the time to answer...very much appreciated!

Although I'm running Windows OS, I do understand your approach, and will work on an analogous solution.

Our setup is interesting -- we're running many temperature chambers, each one having a dedicated computer running a unique instance of ELOG, each of which is regularly updated to let users know what the progress is for the lengthy temperature testing.  All of these individual logbooks regularly synchronize to a common 'mirror' ELOG server, which shows all the logbooks in one location.  Users can view all the logbooks on one screen, by connecting to the mirror server.  Since this can be done remotely, it also makes it convenient to add "updates" remotely to the mirror server, which eventually synchronizes with each individual computer at the temperature chambers.  As you might imagine, if there is a user doing an update at the temperature chamber computer while another user enters an update remotely to the mirror server, there is a chance of having a record conflict.

I was trying to avoid conflicts by having real-time mirroring, where a change on either end is detected and immediately "synchronized", thereby reducing or eliminating conflicts.

In any case, if I do come up with a good solution for Windows, I'll be sure to share what I did.

Cheers,
Frank