Hey Enrico,

Do you activate also all options with your build ? (pam/ldap/kb5/ssl)

Can you compare ldd command results on elogd binaries builded by yourself and the one from RPM ?

$ ldd /path/to/elogd

Also, size of both elogd files.

Regards

Enrico,

When using RPM in OpenShift, I guess all the RPM dependencies are correctly installed.

FYI, I met a problem with elogd docker built with alpine Linux image and running on Synology NAS (x86_64). The ImageMagick dependencies libs provided by alpine for X86_64 are optimized for better CPU than mine with AVX2 (or something like that), and elogd failed to save a log with any enclosure (core exit, bad instruction), as some thumbnails are generated while saving.

As I didn't find any easy workaround w/o rebuilding all IM libs, so I switch to Debian images more conservative in CPU optimization, but bigger :-( before to switch to minideb that's run fine in my case.

It's not easy to debug in container w/o making one specially for that, so you should try to build a docker based on alma9 image, compiling elogd from sources (you can follow https://github.com/loll31/elog-ldap for the process).

Good luck

NB : The ldd result from my minideb Docker :

root@9ac6063e87bf:/# ldd -v /usr/local/sbin/elogd                                                                                                        

        linux-vdso.so.1 (0x00007ffd0e794000)                                                                                                             

        libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007fc00ac35000)                                                                            

        libldap-2.5.so.0 => /lib/x86_64-linux-gnu/libldap-2.5.so.0 (0x00007fc00abd6000)                                                                  

        liblber-2.5.so.0 => /lib/x86_64-linux-gnu/liblber-2.5.so.0 (0x00007fc00abc6000)                                                                  

        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc00a9ac000)                                                                      

        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc00a98c000)                                                                        

        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc00a7a9000)                                                                                

        libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007fc00a328000)                                                                      

        libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007fc00a30b000)                                                                        

        libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007fc00a0ef000)                                                                    

        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc00a010000)                                                                                

        /lib64/ld-linux-x86-64.so.2 (0x00007fc00f959000)                                                                                                 

        libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007fc009eda000)                                                                    

        libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x00007fc009ea9000)                                                                          

        libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 (0x00007fc009cf3000)                                                                

        libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007fc009cde000)                                                                        

        libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 (0x00007fc009c90000)                                                                      

        libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6 (0x00007fc009c47000)                                                                    

        libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fc009bc4000)                                                                          

        libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 (0x00007fc009bb8000)                                  

Also, you have the option to rebuild RPM from SRPMS or SOURCES via ELOG buildrpm script.

You will need to install rpmbuild tools...

Options (ldap, kb5, etc) can be set from options or by editing defaults.

Wouldn't it make sense for ELog (by default) to still notify, but not send the attachments by e-mail if the size limit is reached?

We recently tried upgrading the ND280 elog instance to elog 3.1.0. [1] We seem to have some problems with this 'auto-save' functionality.  Specifically, it doesn't seem to play nice with the fact that we prefer to disable user's ability to edit old messages.  So we have (up to now), had the following set of commands specified in elogd.ccfg

Menu commands = List, New, Reply, Delete, Duplicate, Copy to, Move to, Find, Help

The problem is that we now get auto-saved messages, but no ability for the user to actually go back and finish the draft message.  You can see an example of this state in this test elog

http://neut17.triumf.ca:8080/demo/

Clicking on the draft message you can see that it can't be editted.  If you try to click 'new' then edit the draft, you get the message 'Error: Command "Edit" not allowed'.  So we had zombie draft messages, until we added the edit command back; but that defeats our preference that users not mess up old messages.

In general this auto-saving seems like a useful feature.  So the ideal solution for me would be to have some mode where users could edit/finish draft messages, but where we could still disable users from editting completed/finished messages.  Ie, where we can omit 'Edit' from the menu command, but still get auto-save.

A less ideal, but perhaps simpler solution would be that if an elog has omitted 'Edit' from the menu commands, then this auto-save/save functionality is disabled so that we don't get uneditable draft messages.

[1] https://midas.psi.ch/elogs/Forum/67855

When using the Webserver authentication in combination with "File" and "Self register = 3", it is possible to keep track of registrations and control access still. This is very useful, and upon clicking on the logbook for the first time, the user is asked to register by typing their username, full name and email address.

First issue here is that they can still edit the box with their username, which might cause confusion if somebody decides to choose a different username and is then surprised about why they cannot automatically login again. Is it possible to lock this field from being edited?

The second issue is more minor, but the user has to manually type their name and email address, even though the webserver may already be able to provide this information in the headers. Specifically, it would be useful to read the name from the X-Forwarded-Name header and email address from the X-Forwarded-Email header. 

My config file snippet is below:

Authentication = Webserver, File
allow password change = 0
Password file = webserver.passwords
Self register    = 3
 

Hello. We are using explicity subdir names on our elog server to manage a large number of "Top groups" and sub "groups". When we create a new logbook from a template in the same group, it would be beneficial to automatically give a new subdir based on the previous one. At the very least, it should not reuse the same parameter as the template (see below).

At the moment, it copies the subdir parameter from the template logbook, which results in the new logbook writing to the same location as the template. That is very confusing and has the potential to be harmful as people can (and recently did) decide to delete these "duplicate" entries. But they are not duplicates, they are the exact same entries as the template logbook and deleting them removes them forever!

The way around this at the moment is to manually update the subdir after copying, but then the logbooks need to be re-indexed before the new logbook will display correctly. That requires a manual restart of the elogd process, which is less than ideal. 

We are installing a new data center which will be based on Windows 2012 servers.  Our current center is on Windows 2008 and will be decommissioned this year - 2008 servers (because of the security issue) will not be allowed in the new data center.  So game plan is to install latest ELOG (3.1.2) on the 2012 server at the new data center and move the logs over from the 2008 server.  I've looked through entries and do not see anything about moving the logs over from one system to another.  In this case there are 2 concerns:

1.  Has anyone moved the log entries from one system over to another?

2.  Since we are also looking at updating version of ELOG - are there conversion steps necessary for the log entries or will v3.1.2 be able to use the log files from v2.9.2 as is?

Thank you, Lesley