URL causes elogd to crash when a global password file name doesn't match any group's password file name. 

The offending URL is copied from the address field of the browser after sorting a logbook by on of the fileds.

After login out and using the copied URL, elogd shows the authentication dialog and then crashes after the credentials are submited.

Some debugging point me to a NULL pointer on the following instruction in line   25502  of elogd.c :

  if (lbs->pwd_xml_tree) {

The work around was to name the global password file as the password file of one of the groups.

When I run a mirror server and both logbooks using SSL/KRB5 then the cron job causes a segmentation fault.

I haven't tried to check it with a simple configuration yet.
My set-up: two elogd on same server, one running "german" on port 444, the other "english" on port 445.
Both are behind an apache webserver configured reverse proxy, to hide the ports for external access.
I'll try to reproduce the fault with a "minimal configuration" soon and report again.


Debug output from GDB:

run -x -c /usr/local/elog/elogd_en.cfg
Starting program: /opt/elog-2.9.0/elog/elogd -x -c /usr/local/elog/elogd_en.cfg
elogd 2.9.0 built May 30 2011, 11:14:32 revision 2414
File "/var/run/elogd.pid" exists, using "/var/run/elogd.pid.445" instead.
Falling back to default group "elog"
Falling back to default user "elog"
User "elog" not found
Falling back to default user "nobody"
FCKedit detected
Falling back to default group "elog"
Falling back to default user "elog"
User "elog" not found
Falling back to default user "nobody"
ImageMagick detected
Indexing logbooks ... done
SSLServer listening on port 445 ...

Program received signal SIGSEGV, Segmentation fault.
0x0030b7b5 in SSL_write () from /lib/libssl.so.6

elogd is crashing with a segv when I try to create a new logbook by clicking the "Create new logbook" button
with an existing logbook selected in the dropdown list as a template. I've attached my config file for
reference. As a specific example, I'm logged in as the admin user, viewing logbook "1248", which has no entries,
and I click "Config" -> "Change config file" -> "Create new logbook", Select "1248" from dropdown list, enter
"1250" for the new logbook name, and click "Create new logbook".

The server crashes, and my web browser has the following as the (incorrect) URL it's trying to load:
(Incorrect because the "/ATLAS" shouldn't be there.)

https://localhost:8080/ATLAS/1250/?cmd=Config

Nevertheless, the config file and logbook directory are properly modified for the new logbook, and on restarting
the server, everything is fine.

Oh, just noticed that if I manually enter the URL:

https://localhost:8080/ATLAS/1250/

or actually, any text in place of the "1250", it also crashes the elogd process. So, perhaps there are two bugs?

(1) Incorrect URL being given to the web client after logbook creation
(2) Requesting any incorrect URL of this form crashes elogd

Since updating to version 2.5.8 we have been having problems with the elogd 
service crashing whenever anyone attempts to log out. We are using stunnel 
4.09 on a Win 2k system.

When someone tries to log out of e-log from their desktop the machine 
hosting the service throws an error popup wanting to report to Microsoft. 
The error signature has the following information:

szAppName: elogd.exe
szAppVer: 0.0.0.0
szModName: elogd.exe
szMidVer: 0.0.0.0
offset: 0003586a

Clicking to get the technical information it wants to send it shows these 
two file names:

C:\DocumentsandSettings\krobinde\LOCALS~1\temp\WER6F.tmp.dir00
\elogd.exe.mdmp
C:\DocumentsandSettings\krobinde\LOCALS~1\temp\WER6F.tmp.dir00\appcompat.txt

Let me know if there is any further information you need.

My MacOS (10.12.2) elogd version V3.1.2 is a recent git commit (edc5e85), due to the fix to my earlier-described issue solved in the thread here: https://midas.psi.ch/elogs/Forum/68519.

I am trying to (re-)set up Mirror functionality with a linux server running the standard public (V3.1.2-bd75964).  I had initially updated the linux server so that it also had the latest git commit (edc5e85), but could then not even add new logbook entries that involved attachments to it.  I therefore rolled the linux server back to the standard public 3.1.2 version.

On the remote Mac, synchronizations usually look like they are going to work fine, with Mirror simulate = 1 switched on.  After I set Mirror simulate = 0, and if the server and remote logbook are already identical, I *occasionally* get the proper "All Entries Identical" synchronization result.  Unfortunately, this is very rare, and usually there is a failure whereby the remote (Mac) logbook decides that a significant fraction of its entries (usually sequential, from some seemingly random entry all the way up to the last entry) are missing on the linux server and need to be submitted back to the server from the remote Mac.

When the local and remote logbooks are not identical, and a record in need of synchronization contains an attachment, there is again destructive behaviour similar to that described above, except that the Mac elogd executable usually crashes.  (As in the case of the already-identical synchronizations described above, I only tested this after observing the correct expected behaviour first with Mirror simulate = 1.)

I'd be grateful for some help/suggestions.  My current testing suggests that my problems are likely not elog-content dependent.  (The logbook now undergoing synching has less than 10 entries in it.)

More generally, the issue of having things behave fine with Mirror simulate = 1, but then experiencing corruption/damage when switching to Mirror simulate = 0 seems serious to me.

Many thanks, Andreas

When installing ELOG 3.1.2 on my Mac Sierra (10.12.2) with the latest XCode 8.2.1, it seemed to install fine but for one warning when building elogd:

cc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -DHAVE_SSL -I /opt/local/include -o elogd 
src/elogd.c crypt.o auth.o regex.o mxml.o  -lssl
src/elogd.c:13840:13: warning: '__builtin___strlcpy_chk' will always overflow
      destination buffer [-Wbuiltin-memcpy-chk-size]
            strlcpy(user_email, user_list[i], NAME_LENGTH);
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'
  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.

My installation was done with "sudo make install", as the instructions state.  I have also been using the prescribed "launchctl" approach.

1. Is the above warning something that needs attention/correcting?

2. My elogd crashes now every time that I attempt any kind of "Find" operation.

3. I synchronize my MacOS version of elog with a linux-based version on my university's web server.  I have installed 3.1.2 on the linux server, and it is running there without problems.  When I now try to synchronize my 3.1.2 ELOG on MacOS laptop with the same version on my linux server, it appears to do the first mirroring operation correctly, but elogd crashes when I try a second synchronization at a later time.  (For now, I have "Mirror simulate = 1" to prevent inadvertent damage.)

Can anyone help me with the above points?

Thank you,

Andreas

Hello,

I'm facing with a crash, which happen when I sort the entries by a datetime attribute (sort or rsort) and then i change the display mode from Full, Summary and Threaded.

For example, the elogd crashes when I try to connect from the Full display to Summary in sort mode. The issue presents for example by entering with the following URL:

http://host.name.com:8080/65+nm/?mode=summary&sort=Record+date

Can you please help me?

Here I reduced my elogd.cfg at minimum and I still get this issue:

[global]
port = 8080

[65 nm]
Attributes = Record date

Type Record date = datetime
Preset Record date = $date
List Display = Record date
Start page = ?sort=Record date

A query to a logbook can crash the demon.

Query:
https://pc8059.psi.ch:444/SwissFEL+Injector/?jcmd=Find&m0a=10&d0a=27&y0a=2011&npp=1&reverse=0

gdb dump:
SSLServer listening on port 444 ...

Program received signal SIGSEGV, Segmentation fault.
show_elog_list (lbs=0xae72618, past_n=0, last_n=0, page_n=0, default_page=1, info=0x0) at src/elogd.c:20797
20797         message_id = msg_list[index].lbs->el_index[msg_list[index].index].message_id;