Dear elog users & developers,

the subject line says it all: when using webserver authentication, how is it possible to restict access of users to any given elog? Only using the apche rules? Admin user and Login user do not seem to be doing anything for me. I am using elog as packaged by debian for buster, using an apache ssl proxy. Thank you for providing this software,

Christian

Dear all,

I figured it out. Current global config is (using kerberos instead)

[global]
port = 8081
Default encoding = 0
SSL = 0
Authentication = Kerberos
URL = https://my_url_here/
interface = 127.0.0.1
Password file = global.pwd
SMTP host = my_mail_host
Logfile = /var/log/elog.log
Logging level = 3
User = elog
Grp = elog

Best,

Christian

Would it be possible to create a new command "List format <attribute> = <css_class_name>,<css_class_value>,<width>,<size>", or is there another way to achieve this?

Okay, found some solution for my problem:

And file themes/default/pikett.css contains:

That works like a charm - until I log in to the logbook. Then the include of the CSS in the header is garbled with some "prefix" of random chars:

And a quick check in the source code shows some bad code:

L7615: function "show_html_header"

Here css_base is a not initialized local variable of the function. In fact the above line is the only reference of that variable char css_base[1000].

The bug is still present in elog-3.1.4-611489b

Hi Andreas,

the bug you have found was already reported in an earlier issue, together with the same solution you have found.
https://elog.psi.ch/elogs/Forum/69368

Best wishes,
Sebastian

Hi Stefan,

I've just tried to read the $text with subst into another field and failed.
It looks like $text is only available for the execution of shell scripts in the "execute new|edit|delete = <script>" command.

Could that be added? I can think of a multitude of applications:

• In my case I want to fill an attribute X either with free text or generated from other fields. The list view will show just X and not how it was generated.
• I could fill an attribute automatically with the character length of the text.
• I could parse the text in a shell script and set other attributes according to the content.

Thank you for considering it.

Cheers, Andreas

$text is the full body text and can go over many lines. Since attributes are restricted to single lines, it's not possible to substitute them with the body text.

Stefan

While the input widget of text attributes is a single line, they can easily be multi-line in the display - when you use HTML at least.
And of course the user can parse the text field and generate a single line, if he wants to.
If you leave it to me, I'll create wonderful applications to that feature :-)

Please? ;-)

Sure, attributes can be shown multi-line, but they cannot be stored in the elog internal database. The database is a very old design and only allows for single line attributes. Just look at a YYMMDDa.log file and you will see that. I would have to change the database format to somethign more advanced like XML, but that would take me a couple of weeks or months.

Soooorrryy! ;-)

Hi Stefan,
no problem: if I just strip all newlines from the $text field (in HTML you use <br> anyway, the newline has no function apart from whitespace), and my multiline attribute is fine to go.
I do not intend to make the attribute editable: it is just used for display. Because that allows me to create the attribute either from free text or from combining other fields - depending on conditional attributes.

As a special feature you could strip all newlines beforehand, when providing the $text for subst statements.

Cheers, Andreas

I should tell that I found a simpler way to achieve the same:
I suppress the "text" field and use a single line text input field instead.
The single line input in "free text" modes just contains "<br>" : I would have had to use those in the text field anyway.

I am not Stefan, but maybe I can add to this issue.

Personally I think it is not a good way to dump all the information into the text field and try to let the server parse it.
This could be archived more simply by using e.g. the python elog scripts or using the elog command tool to directly submit well structured elog entires.

As you have mentioned you could use the "execute new|edit|delete" commands to do the things you want to do.
Let the called script fetch the elog entry and alter it in the way you like and resubmit the entry.
(You have to make sure to don't generate a endless loop and you have to proably have to use a forwarding script as the elog "execute" command waits for finished execution).
This way you don't touch the 1500 characters limit of passing $text to the execute command.

Also the point "filling an attribute X with free text" needs some kind of (extended) parsing, which isn't possible with the subst command.
In our elog we such an attribute X, which is in some conditions filled with a set of other attributes and on other conditions just a normal input field, so the user could type custom text in.

"fill an attribute automatically with the character length of the text" could be done with the above mentioned execute command or it could be done on the clientside (e.g. browser using javascript or if automatically generated by a script, then directly by the script)

I hope it helps to build our application.
Best wishes,
Sebastian

Hello Stefan,

I stubbled on a issue with our elog.
We introduced an attribute "mode" to one of the elogs and it breaks the "Find" function as this attribute is already used for the viewing settings "full", "summary" and "threaded".
(HTTP parameter pollution)

I suspect other special attributes used by the internals of elog should also not be allowed.
A quick search in the "Find" reveals these attributes in the URL, so I guess, these should also be avoided.
This list could be incomplete

npp, ma, da, ya, mb, db, yb, attach, reverse, mode

A simple workaround would be updating the documentation to add these to the list of forbidden attributes.
https://elog.psi.ch/elog/config.html
Maybe a warning can be added, if the elog behaves unexpected, try other attribute names, as they can conflict with internal attributes.

A fix could be to add a prefix for internal attributes, which can't be used for user attributes.

Best wishes,
Sebastian

PS: I also noticed using the "Find" command, the generated URL contains 2 reverse attributes like "reverse=0&reverse=1"

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

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.

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.

Hello!

We have a number of local ELOG servers, all mirrored to a single "remote" ELOG server.  We have users that create updates at the local server, and some at the remote server, which can run the risk of record conflicts.  Right now, the local servers perform a "Mirror cron" every 5 minutes, but even that leaves the door open to potential conflicts.

I found an open-source JAVA-based app called DirSync Pro (https://www.dirsyncpro.org/) which is capable of performing real-time mirroring, and has conflict handling.  I "took it for a spin", and it does do what it claims.  However, because each ELOG server performs record "indexing", it doesn't recognize records that aren't part of the current list of records. Restarting the ELOG server obviously corrects that, but I was wondering if there is another way to get the server to recognize newer "remotely-generated" records without restarting the server.

As always, I'm appreciative for the outstanding working that has been done to make ELOG the great application that it is!

Hello Frank,

It seems, you are using the mirror function of elog. It should resolve conflicts by itself acording to the documented rules. (https://elog.psi.ch/elog/config.html)
As I don't use this function, I can't say how good it works.

If you don't want to use this function, I would suggest using the "Execute new | edit | delete" feature to trigger a script after each change of elog entries.
This script could itself run "rsync" or your sync solution to make the sync and
should afterwards call "killall -HUP elogd" on the remote to let elog re-read the config (and this sould also update the indices)
(see Server Configuration https://elog.psi.ch/elog/adminguide.html)

If you have a sync-solution, which itself permanently observes folders for changes and syncs it by itself,
It should have the option to run a command after sucessful sync or you need an other method to call "killall -HUP elogd" after sync.

Personally I would recommend the mirror function as it has a internal conflict resolution.
I hope this helps.

Best wishes,
Sebastian

PS: I don't know anything about your setup, but maybe there is a solution, where you don't need the local servers.
As I think, the mirror function is mainly for backup reasons of a main server to a secondary one or similar.

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

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 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