Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 1 of 238  Not logged in ELOG logo
Entry   , posted by Damian Goeldi on Mon Sep 15 13:16:58 2025 

The ETH physics department is running an ELOG behind an Apache reverse proxy:

ProxyPass / http://localhost:$port/ retry=0
ProxyPassReverse / http://localhost:$port/
ProxyAddHeaders off

Authentication is done on the Apache side using LDAP authentication, example:

<Location /demo>
  Use PhysLDAP
  AuthType Basic
  AuthBasicProvider ldap
...
  Require valid-user
  RewriteEngine On
  RewriteCond %{LA-U:REMOTE_USER} (.+)
  RewriteRule . - [E=RU:%1,NS]
  RequestHeader add X-Forwarded-User %{RU}e
</Location>

And all ELOGs use the config, example:

[demo]
Authentication = Webserver

For the PSI-Praktikum we had to create a logbook that is accessible without an ETH-Account. A new logbook was added, which is not authenticated via the proxy, but the ELOG internal authentication. In order to grant access to the students, I was made admin for that logbook. A configuration according to https://elog.psi.ch/elog/config.html#groups is used:

 

icon4.gif   collapse does not seem to work as expected, posted by Harry Martin on Thu Jul 17 23:43:25 2025 

When I click on "collapse," even several times, I still see all the replies in each thread rather than just one entry representing each entire thread.

I am running elogd 3.1.5 on devuan chimaera (bullseye) which I built from source.  I had the same results with 3.1.4 and 3.1.3.

I tried to disable the quick filter just to see if that impacted the behavior, but it didn't.

If there are any other tests I can use to narrow the problem, please suggest them.  Without a working collapse feature, I cannot get a quick birdseye view of, say, all open threads.

    icon4.gif   Re: collapse does not seem to work as expected, posted by Harry Martin on Fri Jul 18 22:42:02 2025 

I should add that this does not happen in every logbook.  I'm looking into what the distinction is that causes this in certain logbooks and not in others.

Harry Martin wrote:

When I click on "collapse," even several times, I still see all the replies in each thread rather than just one entry representing each entire thread.

I am running elogd 3.1.5 on devuan chimaera (bullseye) which I built from source.  I had the same results with 3.1.4 and 3.1.3.

I tried to disable the quick filter just to see if that impacted the behavior, but it didn't.

If there are any other tests I can use to narrow the problem, please suggest them.  Without a working collapse feature, I cannot get a quick birdseye view of, say, all open threads.

 

       icon4.gif   Re: collapse does not seem to work as expected, posted by Harry Martin on Fri Jul 18 23:10:33 2025 

Figured it out:  I had "Sort Attributes" set on the logbooks that were failing to collapse correctly.  At least, I think that is the distinction.  

I think I can live with "Sort Attributes" disabled; I don't recall why I chose to set the "Sort Attributes" in the first place.  But I still think this is an issue.

Harry Martin wrote:

I should add that this does not happen in every logbook.  I'm looking into what the distinction is that causes this in certain logbooks and not in others.

Harry Martin wrote:

When I click on "collapse," even several times, I still see all the replies in each thread rather than just one entry representing each entire thread.

I am running elogd 3.1.5 on devuan chimaera (bullseye) which I built from source.  I had the same results with 3.1.4 and 3.1.3.

I tried to disable the quick filter just to see if that impacted the behavior, but it didn't.

If there are any other tests I can use to narrow the problem, please suggest them.  Without a working collapse feature, I cannot get a quick birdseye view of, say, all open threads.

 

 

          icon4.gif   Re: collapse does not seem to work as expected, posted by Harry Martin on Sat Jul 19 00:02:45 2025 

I also notice that collapse does not work properly if I have anything selected in the quick filter.

Harry Martin wrote:

Figured it out:  I had "Sort Attributes" set on the logbooks that were failing to collapse correctly.  At least, I think that is the distinction.  

I think I can live with "Sort Attributes" disabled; I don't recall why I chose to set the "Sort Attributes" in the first place.  But I still think this is an issue.

Harry Martin wrote:

I should add that this does not happen in every logbook.  I'm looking into what the distinction is that causes this in certain logbooks and not in others.

Harry Martin wrote:

When I click on "collapse," even several times, I still see all the replies in each thread rather than just one entry representing each entire thread.

I am running elogd 3.1.5 on devuan chimaera (bullseye) which I built from source.  I had the same results with 3.1.4 and 3.1.3.

I tried to disable the quick filter just to see if that impacted the behavior, but it didn't.

If there are any other tests I can use to narrow the problem, please suggest them.  Without a working collapse feature, I cannot get a quick birdseye view of, say, all open threads.

 

 

 

             icon2.gif   Re: collapse does not seem to work as expected, posted by Harry Martin on Mon Aug 18 03:14:51 2025 

I am not sure if either "Sort Attributes" or the Quick Filter are the main issue, though they could be.  I have implemented a work-around for now, but it really would be nice if this worked as expected.  Or perhaps someone can provide an example of a logbook with working "collapse" functionality.  Thank you for this nifty program; everything else aside, this tool helps keep my work in order.

Harry Martin wrote:

I also notice that collapse does not work properly if I have anything selected in the quick filter.

Harry Martin wrote:

Figured it out:  I had "Sort Attributes" set on the logbooks that were failing to collapse correctly.  At least, I think that is the distinction.  

I think I can live with "Sort Attributes" disabled; I don't recall why I chose to set the "Sort Attributes" in the first place.  But I still think this is an issue.

Harry Martin wrote:

I should add that this does not happen in every logbook.  I'm looking into what the distinction is that causes this in certain logbooks and not in others.

Harry Martin wrote:

When I click on "collapse," even several times, I still see all the replies in each thread rather than just one entry representing each entire thread.

I am running elogd 3.1.5 on devuan chimaera (bullseye) which I built from source.  I had the same results with 3.1.4 and 3.1.3.

I tried to disable the quick filter just to see if that impacted the behavior, but it didn't.

If there are any other tests I can use to narrow the problem, please suggest them.  Without a working collapse feature, I cannot get a quick birdseye view of, say, all open threads.

 

 

 

 

icon4.gif   3-level conditional not working, posted by Harry Martin on Thu Mar 20 07:34:24 2025 

Not sure if this is a bug or not; if it is not, kindly reclassify the category.

Following is a small example of what I will dub a 3-level, conditional logbook:

[cond_test]
attributes = region, manufacturer, model

show attributes edit = region
options region = american{1}, japanese{2}, european{3}

{1} options manufacturer = ford, chrysler, gm
{2} options manufacturer = toyota{4}, nissan{5}, mitsubishi{6}
{3} options manufacturer = audi, mercedes, bmw, volvo, fiat
{1,2,3} show attributes edit = region, manufacturer
{4} options model = corolla, prius, miata
{5} options model = sentra, murano
{6} options model = starion, outlander, mirage
{4,5,6} show attributes edit = region, manufacturer, model

This example is hardly complete, but it is sufficient to demonstrate the issue I am running into.  This works until I select from the 2nd level (manufacturer); it won't display the dropdown for the model (I think my show attribute edit is supposed to display that).  Is there a restriction on how many levels of conditional I can have?  If there is, it would be disappointing because I am trying to do something similar to this example.

I hope there is something very simple I can do to correct this, or perhaps a completely different approach that accomplishes the same thing.  I'd like to stick with the multi-level selection process as I have done here.

I am running elog 3.1.5 on Devuan Chimaera (approx. Debian Bullseye, sans systemd) in a Virtualbox VM.

    icon4.gif   Re: 3-level conditional not working, posted by Harry Martin on Sun Jul 20 23:20:02 2025 

Tried a variant, this time for NEW entries (not EDIT), which I meant to do to begin with; sorry if that was confusing. 

[cond_test]
attributes = region, manufacturer, model

options region = american{us}, japanese{jp}, european{eu}
show attributes = region

{us} options manufacturer = ford, chrysler, gm
{jp} options manufacturer = toyota{toy}, nissan{nis}, mitsubishi{mit}
{eu} options manufacturer = audi, mercedes, bmw, volvo, fiat
{us} show attributes = region, manufacturer
{jp} show attributes = region, manufacturer
{eu} show attributes = region, manufacturer

{toy} options model = corolla, prius, miata
{nis} options model = sentra, murano
{mit} options model = starion, outlander, mirage
{toy,nis,mit} show attributes = region, manufacturer, model

 I'm not sure if my multi-character conditional names are allowed or not, but they do seem to work... somewhat.  Note that I even tried a couple different ways of specifying which attributes to show (single versus multiple OR conditionals).  The problem now is that all of the attributes are always shown, seeming to ignore the conditionals entirely.

Harry Martin wrote:

Not sure if this is a bug or not; if it is not, kindly reclassify the category.

Following is a small example of what I will dub a 3-level, conditional logbook:

[cond_test]
attributes = region, manufacturer, model

show attributes edit = region
options region = american{1}, japanese{2}, european{3}

{1} options manufacturer = ford, chrysler, gm
{2} options manufacturer = toyota{4}, nissan{5}, mitsubishi{6}
{3} options manufacturer = audi, mercedes, bmw, volvo, fiat
{1,2,3} show attributes edit = region, manufacturer
{4} options model = corolla, prius, miata
{5} options model = sentra, murano
{6} options model = starion, outlander, mirage
{4,5,6} show attributes edit = region, manufacturer, model

This example is hardly complete, but it is sufficient to demonstrate the issue I am running into.  This works until I select from the 2nd level (manufacturer); it won't display the dropdown for the model (I think my show attribute edit is supposed to display that).  Is there a restriction on how many levels of conditional I can have?  If there is, it would be disappointing because I am trying to do something similar to this example.

I hope there is something very simple I can do to correct this, or perhaps a completely different approach that accomplishes the same thing.  I'd like to stick with the multi-level selection process as I have done here.

I am running elog 3.1.5 on Devuan Chimaera (approx. Debian Bullseye, sans systemd) in a Virtualbox VM.

 

       icon2.gif   [CLOSED] Re: 3-level conditional not working, posted by Harry Martin on Sat Aug 16 22:19:03 2025 

Closed.  This "problem" was due to the same lack of document eyesight as https://elog.psi.ch/elogs/Forum/69889.   Sorry for all the noise.  New eyeglasses are forthcoming...

Harry Martin wrote:

Tried a variant, this time for NEW entries (not EDIT), which I meant to do to begin with; sorry if that was confusing. 

[cond_test]
attributes = region, manufacturer, model

options region = american{us}, japanese{jp}, european{eu}
show attributes = region

{us} options manufacturer = ford, chrysler, gm
{jp} options manufacturer = toyota{toy}, nissan{nis}, mitsubishi{mit}
{eu} options manufacturer = audi, mercedes, bmw, volvo, fiat
{us} show attributes = region, manufacturer
{jp} show attributes = region, manufacturer
{eu} show attributes = region, manufacturer

{toy} options model = corolla, prius, miata
{nis} options model = sentra, murano
{mit} options model = starion, outlander, mirage
{toy,nis,mit} show attributes = region, manufacturer, model

 I'm not sure if my multi-character conditional names are allowed or not, but they do seem to work... somewhat.  Note that I even tried a couple different ways of specifying which attributes to show (single versus multiple OR conditionals).  The problem now is that all of the attributes are always shown, seeming to ignore the conditionals entirely.

Harry Martin wrote:

Not sure if this is a bug or not; if it is not, kindly reclassify the category.

Following is a small example of what I will dub a 3-level, conditional logbook:

[cond_test]
attributes = region, manufacturer, model

show attributes edit = region
options region = american{1}, japanese{2}, european{3}

{1} options manufacturer = ford, chrysler, gm
{2} options manufacturer = toyota{4}, nissan{5}, mitsubishi{6}
{3} options manufacturer = audi, mercedes, bmw, volvo, fiat
{1,2,3} show attributes edit = region, manufacturer
{4} options model = corolla, prius, miata
{5} options model = sentra, murano
{6} options model = starion, outlander, mirage
{4,5,6} show attributes edit = region, manufacturer, model

This example is hardly complete, but it is sufficient to demonstrate the issue I am running into.  This works until I select from the 2nd level (manufacturer); it won't display the dropdown for the model (I think my show attribute edit is supposed to display that).  Is there a restriction on how many levels of conditional I can have?  If there is, it would be disappointing because I am trying to do something similar to this example.

I hope there is something very simple I can do to correct this, or perhaps a completely different approach that accomplishes the same thing.  I'd like to stick with the multi-level selection process as I have done here.

I am running elog 3.1.5 on Devuan Chimaera (approx. Debian Bullseye, sans systemd) in a Virtualbox VM.

 

 

icon8.gif   show attributes directive does not work?, posted by Harry Martin on Sat Aug 16 02:48:42 2025 Screenshot_2025-08-15_17-57-59.png

Follows a very simple logbook definition:

[simple]
Comment = test show attributes directive
Attributes = a, b, c
Show Attributes = a

(Assume that all attributes are used farther down.  This is for illustration only.)   

To see what I see when I run this tiny elogd.cfg, see attachment.

"Show attributes" does not seem to be working because all of the attributes are shown, not just those specified in the directive.  Or do I misunderstand/forget something?

 

    icon8.gif   [CLOSED] Re: show attributes directive does not work? -- It does, if you use show attributes edit, posted by Harry Martin on Sat Aug 16 14:31:49 2025 

Well, it DOES work.... but only if you use the "Show Attributes Edit" directive.  "Show Attributes" is only for the single entry pages, whereas "Show Attributes Edit" is for the "entry pages."

I should have read the docs more carefully, sorry.  But isn't this a bit inconsistent with the way other directives work?  Usually one uses "<Directive>" for new entries, "<Directive Edit>" for editing existing entries, and "<Directive Reply>" for replies.  So I am guessing that "Show Attributes Edit" will be used for new and edit?

Harry Martin wrote:

Follows a very simple logbook definition:

[simple]
Comment = test show attributes directive
Attributes = a, b, c
Show Attributes = a

(Assume that all attributes are used farther down.  This is for illustration only.)   

To see what I see when I run this tiny elogd.cfg, see attachment.

"Show attributes" does not seem to be working because all of the attributes are shown, not just those specified in the directive.  Or do I misunderstand/forget something?

 

 

icon8.gif   once a week we are having elogd segault?, posted by mathew goebel on Fri Jul 18 17:46:43 2025 

Jul 17 20:36:21 elog kernel: elogd[179095]: segfault at 7ffda4d82000 ip 00007f97033a1406 sp 00007ffda4d58c38 error 6 in libc-2.28.so[7f9703374000+1cd000]

Elog version ELOG V3.1.5-30ada1df 

Running on a Rehdat 8 enterprise server

compiled with a Makefile change :: change -Wno-unused-result to -Wno-unused-value

Wondering if anyone has been seeing this?

    icon2.gif   Re: once a week we are having elogd segault?, posted by mathew goebel on Wed Aug 6 17:08:46 2025 

We have since discovered that the security team is scanning the box in question once a week when the service crashes, with nexpose.

So if you see something similar then you might want to explore that.

mathew goebel wrote:

Jul 17 20:36:21 elog kernel: elogd[179095]: segfault at 7ffda4d82000 ip 00007f97033a1406 sp 00007ffda4d58c38 error 6 in libc-2.28.so[7f9703374000+1cd000]

Elog version ELOG V3.1.5-30ada1df 

Running on a Rehdat 8 enterprise server

compiled with a Makefile change :: change -Wno-unused-result to -Wno-unused-value

Wondering if anyone has been seeing this?

 

       icon2.gif   Re: once a week we are having elogd segault?, posted by Stefan Ritt on Thu Aug 7 11:04:39 2025 

Probably some very strange URL form nexpose to trigger a potential buffer overflow. If I get the precise URL which crashes elogd, I can reproduce and fix it.

Otherwise my usual advice: Run elogd behind an Apache proxy and do the authentication there. This way nexpose does not get to elogd, it will stop at the Apache (without the proper credentials).

Steafn

mathew goebel wrote:

We have since discovered that the security team is scanning the box in question once a week when the service crashes, with nexpose.

So if you see something similar then you might want to explore that.

mathew goebel wrote:

Jul 17 20:36:21 elog kernel: elogd[179095]: segfault at 7ffda4d82000 ip 00007f97033a1406 sp 00007ffda4d58c38 error 6 in libc-2.28.so[7f9703374000+1cd000]

Elog version ELOG V3.1.5-30ada1df 

Running on a Rehdat 8 enterprise server

compiled with a Makefile change :: change -Wno-unused-result to -Wno-unused-value

Wondering if anyone has been seeing this?

 

 

icon4.gif   passing %s to $shell interpreted differently in preset vs preset on reply, posted by Harry Martin on Wed Jun 18 01:20:47 2025 

I am finding that '%s' passed to a $shell(...) command must be escaped when calling from Preset on reply, but not when calling Preset new.  Example:

[tickler]
Comment = Automated Tickler List Experiment
Attributes = Blurb, TickleDate
Type TickleDate = date
Required Attributes = Blurb
Preset TickleDate = $shell(date -d 'now + 30 days' '+%s')
Preset on reply TickleDate = $shell(date -d 'now + 30 days' '+%%s')
Date Format = %Y-%m-%d

Note that I have to escape the Preset on Reply's shell command argument with double percent signs, but not on Preset new.  The configuration I have provided here does work and correctly overrides the output per the Date Format spec.  This scenario should be easy to reproduce.

It could be I am doing something incorrectly, but it seems to me that there is no reason why the calls should need to be handled differently.  I can live with this for the moment, but I do hope it is fixed in a later release so that $shell calls have consistent syntax and semantics.

 

icon1.gif   WYSIWYG Editor Not Showing in HTML Mode, posted by Pawel Nita on Mon May 5 11:39:17 2025 

Hi all,

I'm experiencing an issue on Kubuntu 24.04 where the WYSIWYG editor (in HTML mode) doesn't appear at all. This happens across multiple browsers (tested with Firefox and Chromium). The editor area is simply blank, without any visible toolbar or editable content area.

Has anyone encountered this on Kubuntu or found a workaround? Any tips would be appreciated!

Thanks in advance,
Pawel

icon5.gif   Re: Custom input forms implementation , posted by Marcel Zauner-Wieczorek on Mon Apr 28 11:50:25 2025 

Please excuse my double-posting. But my first entry was not displayed on the forum and I haven't received feedback yet. I think this is because I responded to an entry that was still in draft mode, whereas my entry was a "normal" entry. My initial entry has the Message ID: 69870 and was in reply to: 68348

***

Dear Andreas and Stefan,

First of all thank you for the template for a checklist. I have created my own version of it and the HTML looks fine. For comparison, I temporarily also included the shiftcheck template provided by Stefan to my ELOG.

However, I have the same problem as JD. After submitting the data in shiftcheck, I receive the error "Cannot open file passwords.pwd: No such file or directory" and the URL is http://localhost:8085/ShiftCheck/?cmd=Submit&suppress=1&unm=&upwd=&Author=Marcel+Zauner-Wieczorek&edit_id=&D=1&M=4&Shift=Morning&a4=&h2=&a5=&a6=&c1=&c2=&c3=&c4=&c5=&bb1=&cr1=&cr9=&cr18=&cr20=&cr21=&cr23=&cr24="

I have tried to include the path of the password file in the cfg file (using "", <>, <"">, and only the path name), but then the elogd.exe won't start at all unless I change it back to the simple "Password file = passwords.pwd".

Here is an excerpt of my config file:

    ****

    [global]
    port = 8085
     

    Password file = passwords.pwd
    Login expiration = 1
    Admin user = Marcel
    Login user = Marcel

    Self register = 1

    Group General = ShiftCheck
    Group Gas phase instruments = Checklist_MARGA

    Restrict edit time = 1
    Admin restrict edit time = 0
    Autosave = 60

    [ShiftCheck]
    Comment = Shift Check List

    Attributes = Author, D, M, Y, Shift, a1, a2, a3, a4, a5, h1, h2, h3, h4, h5, c1, c2, c3, c4, c5, c6, c7, bb1, cr1, cr2, cr3, cr4, cr5, cr6, cr7, cr8, cr9, cr10, cr11, cr12, cr13, cr14, cr15, cr16, cr17, cr18, cr19, cr20, cr21, cr22, cr23, cr24, cr25, cr26, sw1, sw2, sw3, sw4, sw5
    Quick filter = Shift, Author
    Options Shift = Morning, Evening, Night

    Enable attachments = 0
    Show text = 0
    Custom new form = shiftcheck.html
    Custom edit form = shiftcheck.html
    Custom display form = shiftcheck.html
    List after submit = 1

     

    [Checklist_MARGA]
    Comment = Check List for MARGA

    Date Format = %d.%m.%Y
    Time Format = %d.%m.%Y %H:%M:%S

    Reverse sort = 1

    Attributes = Author, D, M, Y, On, DP2h, T_SJAC, T_heat, EC_An, EC_Cat, IonBal, IS_Cat_Ae, IS_An_Ae, IS_Cat_Ga, IS_An_Ga, P1, P2, Err, Com


    Quick filter = Author

    Enable attachments = 0
    Show text = 0
    Custom new form = checklist_MARGA.html
    Custom edit form = checklist_MARGA.html
    Custom display form = checklist_MARGA.html
    List after submit = 1
    ***

I am actually confused about the passwords.pwd file. I have successfully created several users with passwords and I can use their credentials to log into the different labbooks. However, none of these users (let along their (encrypted) passwords) turn up in the passwords.pwd file. I don't know where ELOG saves these information, but it's apparently not the passwords.pwd file that is defined in the cfg file and that I have access to.

I hope that someone can help me with this issue. Otherwise, I would omit the password function within ELOG and find an external solution for a password protection.

Cheers,

Marcel

ELOG V3.1.5-3fb85fa6