Hello, This is coming up as a high vulnerability in our scans. Are there plans to update the rpm for this fix? If so is there an ETA? Any update would be much appreciated. Currently running elog-3.1.4-2 

Dear expert,
  I'm running the latest git version of elog ELOG V3.1.4-395e101a on ubuntu 20.04.2.
I'm experiencing frequent hangs of the elog server: the status is always reported as running, but the web server is not responding.
The only hint I have of something strange is that the elogd process is using a lot of CPU (50-100%), the log do not show anything suspect 
as far as I can see.

Has anyone experienced something similar or has any idea how can I start to debug the problem?

Sorry for lack of many information, but I don't know what to look at.

Thanks in advance
  Stefano

Dear Stefano,

Try the entry I wrote some time ago elog:68655

David.


> Dear expert,
>   I'm running the latest git version of elog ELOG V3.1.4-395e101a on ubuntu 20.04.2.
> I'm experiencing frequent hangs of the elog server: the status is always reported as running, but the web server is not responding.
> The only hint I have of something strange is that the elogd process is using a lot of CPU (50-100%), the log do not show anything suspect 
> as far as I can see.
> 
> Has anyone experienced something similar or has any idea how can I start to debug the problem?
> 
> Sorry for lack of many information, but I don't know what to look at.
> 
> Thanks in advance
>   Stefano

Usually a restart of the elogd server helps. If the problem persists, one of the logbooks might be corrupt. Try to disable one logbook at a time to figure out which one it is. Then 
remove that one and set it up freshly.

Stefan

I made a new RPM: https://elog.psi.ch/elog/download/RPMS/elog-3.1.4-3.el7.x86_64.rpm

Thank you for your work. Works like a charm!

Hello all,

I have the issue, that we can't list entries older than 1 year, if "Last default = 31" (or any other number, but they are restricted to 1, 3, 7, 31, 92, 182, 364) is active.
The quick filter displays the option for "-- all entries --" but selecting this only reloads the default time frame (31 days).

A workaroud is to select a different time e.g. 1 day and then modifying the URL to ?last=1000 or so, gives acces to the old entries.
But this is not the intended way to do it.

The Find results are also affected by this. e.g. selecting 1.1.2020 to 1.6.2020 with "Last default = 31" yields 0 results.
The "Show last default" atrtribute for 1, 3, 7, 31, 92, 182, 364 work fine and overwrite the "last default" time in the quick filter.

In the Find page, there will be a "All entries" option at the top of the date selection box, if "Show last default" equals to 1, 3, 7, 31, 92, 182 or 364
(2, Bug: it is empty for "Show last default = 0" and not All entries")

Selecting "All entries" or the empty first value in the Find "show last:" date , will give a Find result with the "Last default" time constraint.

Thus it is not possible to get any entry older then the longst period possible (364 days), if you don't know about the workaround.

Best wishes,
Sebastian

PS: I use a self-compiled version of elog up to the 395e101 commit in the bitbucket repository with pull request #7 (which hasn't been merged for over 1,5 years) and a simple patch for our local LDAP.

Elog version:  ELOG V3.1.4-611489ba

I am running openldap on the localhost.  For some reason now, elogd is segfaulting when (I believe) when a new user is being added to the password file.  For example:

1. I delete user passord file defined in elogd.cfg

2. Bind/Authenticate to LDAP successfully

3.  Segfaults in auth.c ldap_adduser_file()

Makefile:
...
ELOGDIR    = /opt/elog
DESTDIR    = $(ROOT)$(PREFIX)/bin
SDESTDIR   = $(ROOT)$(PREFIX)/sbin
RCDIR      = $(ROOT)/etc/rc.d/init.d
SRVDIR     = $(ROOT)/usr/lib/systemd/system

# flag for SSL support
USE_SSL    = 1

# flag for Kerberos support, please turn off if you don't need Kerberos
USE_KRB5   = 0

# flag for LDAP support, please turn off if you don't need LDAP
USE_LDAP   = 1# flag for PAM support, please turn of if you don't need PAM
USE_PAM    = 0
...

For authentication, I am using openldap in the localhost:

----
Authentication = LDAP
LDAP server = ldap://localhost:389
LDAP userbase = ou=people,dc=example,dc=org
LDAP login attribute = uid
LDAP register = 1
Password file = /opt/elog/users
 

gdb output

----------

(gdb) run -s /opt/elog -c /opt/elog/elogd.cfg -f /var/run/elog/elog.pid
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/ubuntu/UPGRADE-42221/work-src/elog/elogd -s /opt/elog -c /opt/elog/elogd.cfg -f /var/run/elog/elog.pid
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
elogd 3.1.4 built Apr 22 2021, 19:19:39 revision 611489ba
File "/var/run/elog/elog.pid" exists, overwriting it.
CKeditor detected
ImageMagick detected
Indexing logbooks ... done
Server listening on port 9011 ...

Breakpoint 1, ldap_adduser_file (lbs=0x555556811ad8, user=0x7ffffffd3bd0 "testuser", password=0x5555558ea110 <_value+6000> "testuser", error_str=0x7ffffffd53d0 "", error_size=<optimized out>) at src/auth.c:350
350       if (rc != LDAP_SUCCESS) {
(gdb) n
337       rc = ldap_search_ext_s(
(gdb) n
350       if (rc != LDAP_SUCCESS) {
(gdb) n
358       for(entry = ldap_first_entry(ldap_ld,result);
(gdb) n
371                   if(strcmp(attribute,"mail")==0 || strcmp(attribute,"rfc822Mailbox")==0)
(gdb) n
361          for(attribute = ldap_first_attribute(ldap_ld,entry,&ber);
(gdb) n
365             if((values = ldap_get_values(ldap_ld,entry,attribute)) != NULL ) {
(gdb) n
366                for(i=0; values[i] != NULL; i++) {
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
ldap_adduser_file (lbs=0x555556811ad8, user=0x7ffffffd3bd0 "testuser", password=0x5555558ea110 <_value+6000> "testuser", error_str=<optimized out>, error_size=<optimized out>) at src/auth.c:366
366                for(i=0; values[i] != NULL; i++) {
(gdb) p attribute
$1 = 0x5555567f6a20 "uid"
(gdb) p values
$2 = (char **) 0x567f74f0
 

This user in LDAP:
-------------------------
# TESTUSER, people, example.org
dn: uid=TESTUSER,ou=people,dc=example,dc=org
uid: TESTUSER
cn: TESTUSER
givenName: TESTUSER
sn:: VEVTVFVTRVIg
mail: TESTUSER
uidNumber: 10000
gidNumber: 10000
homeDirectory: /dev/null
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
userPassword:: e1NTSEF9Y21ua1lsdFpMZ3ZrZlZ4OUp3MFN3cUY3NWIzdkFCSWY=