ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
69309
|
Tue Feb 23 17:20:39 2021 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Question | Linux | V3.1.4-80633ba | Re: Date conversion | If you define a field as "datetime" then you'll get the standard ELOG input field for datetime. It will be stored as seconds of the epoch (seconds since 1.1.1970).
You can define a field as a default string input, then it is stored as a string. But you can convert that string by a shell scripts into seconds of the epoch. See "subst" command in the documentation of the elog syntax:
Subst <attribute> = <string>
When submitting logbook entries, attribute values can be substituted by some text. This text can contain arbitrary fixed text and following values:
- $<attribute>: The entered value of the attribute itself
- $host: The host name where
elogd is running
- $remote_host: The host name of the host from with the entry was submitted
- $short_name: The login name (if password file is present)
- $long_name: The full name from the password file for the current user
- $user_email: The email address from the password file for the current user
- $logbook: The name of the current logbook
- $date: The current date, formatted via "Date format"
- $utcdate: The current UTC date (GMT) and time, formatted via "Date format"
- $version: The version of the ELOG server in the form x.y.z
- $revision: The Subversion reversion of the ELOG server as an integer number
- $shell(<command>): <command> gets passed to the operating system shell and the result is taken for substitution.
Following example use this feature to add the remote host name to the author:
Subst Author = $author from $remote_host
Following example substitutes an attribute with the contents of a file:
Subst Info = $shell(cat /tmp/filename) (Unix)
Subst Info = $shell(type c:\tmp\filename) (Windows)
A special option are automatically generated tags, which are automatically incremented for each new message. This is achieved by putting #'s into the substitution string, which is used as a placeholder for the incrementing index. Each "#" stands for one digit, thus the statement
Subst Number = XYZ-#####
results in automatically created attributes "Number" of the form
XYZ-00001
XYZ-00002
XYZ-00003
and so on. In addition to the #'s one may specify format specifiers which are passed to the strftime function. This allows to create tags wich contain the current year, month and so on. Once the date part of the attribute changes, the index restarts from one. The statement
Subst Number = XYZ-%Y-%b-###
results in automatically created attributes "Number" of the form
XYZ-2005-Oct-001
XYZ-2005-Oct-002
XYZ-2005-Oct-003
and
XYZ-2005-Nov-001
XYZ-2005-Nov-002
on the next month.
Martin Neumann wrote: |
Hi,
I am trying to figure out how ELOG works and I have a problem.
I have one datetime attribute, where I want the user to be able to enter the time in ISO8601 format (YYYY-MM-DD HH:MM) instead of the buttons.
How do I manage that this input is converted correctly into the internal format?
I tried adding a hidden locked Attribute called IntDate and use "Subst IntDate = $start" but the result is dates in 1970, even though I have set the Time Format to "%F %H:%M"
|
|
69308
|
Tue Feb 23 12:12:14 2021 |
| Martin Neumann | elog.20.beazy@spamgourmet.com | Question | Linux | V3.1.4-80633ba | Date conversion | Hi,
I am trying to figure out how ELOG works and I have a problem.
I have one datetime attribute, where I want the user to be able to enter the time in ISO8601 format (YYYY-MM-DD HH:MM) instead of the buttons.
How do I manage that this input is converted correctly into the internal format?
I tried adding a hidden locked Attribute called IntDate and use "Subst IntDate = $start" but the result is dates in 1970, even though I have set the Time Format to "%F %H:%M" |
69307
|
Mon Feb 22 12:29:16 2021 |
| Stefano Lacaprara | stefano.lacaprara@pd.infn.it | Question | Linux | ELOG V3.1.3- | Problem in logging with LDAP and passwd | Dear experts,
I have a logbook which has authentication as follow
Authentication = LDAP, File
Password file = PASSWD.file
LDAP server = ldaps://it-ldap-XXX.XXX.XX:1636
LDAP userbase = ou=people,ou=RGY,o=XXX,c=XX
LDAP login attribute = uid
LDAP register = 0
Self register = 0
Allow password change = 0
Some of the my user (but not all) have issue in accessing this protected elogbook.
The ldap password is correct (we checked).
What I see in the log is as follow:
22-Feb-2021 11:25:51 [XXX.YYY.ZZZ.QQ] {Beam Run} LOGIN user "USERNAME" (attempt)
22-Feb-2021 11:25:59 [XXX.YYY.ZZZ.QQ] {Beam Run} LOGIN user "USERNAME" (attempt)
The user USERNAME is present in PASSWD.file.
For other user, for which the login works, I do see an (attempt) and then (success)
we tried the standard stuff: clear cache/cookies and with different browser. We also tried to remove the user from PASSWD.file and
create it again, but nothing has worked.
Any suggestion how I can debug this problem?
Thanks in advance,
Stefano |
69306
|
Fri Feb 19 19:48:11 2021 |
| Gabriel Lopez | gabelopez@bnl.gov | Bug report | Linux | 3.1.4 | Re: Path disclosure on unfound file | Thank you for your work. Works like a charm!
Stefan Ritt wrote: |
I made a new RPM: https://elog.psi.ch/elog/download/RPMS/elog-3.1.4-3.el7.x86_64.rpm
Gabriel Lopez wrote: |
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
Stefan Ritt wrote: |
Ok, I fixed the code in the current commit (395e101add19f0fe8a11a25d0822e511f34d94d1). The path gets stripped, and we see a

prinnydood wrote: |
I can confirm this issue exists on version 3.1.3, which I have installed elog on Debian 10.
The issue also exists on version 3.14 (1.20190113git283534d97d5a.el7), which I tested on an AmazonLinux EC2 instance.
This is what I found:
1. if I leave out the extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish
2. if I include any random extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish.php or /gibberish.htm or /gibberish.asdfasd
3. if I include any .html extension specifically at the end of the URL for a non-existent page, elog exposes the path /usr/share/elog/themes/default/gibberish.html. This is a bug... Example: /gibberish.html exposes the path, and likewise, /.gibberish.html ( "dot" + gibberish) exposes the path
4. if I include a valid, existent .html file which is located in the directory /usr/share/elog/themes/default/, and call it, elog exposes the html document. Example: I created an html file called gibberish.html (containing <html><body><p>Hello world</p></body></html>) in my system's /usr/share/elog/themes/default/ directory. After navigating back to the /gibberish.html URL, I was presented with the HTML file.
Turning on -v (verbose mode), the response by elogd when accessing these are: "GET /elog/gibberish.html HTTP/1.0 Returned 605 bytes" (displays "Hello world" html file), and "GET /elog/gibberish.asdfasd HTTP/1.0 Returned 605 bytes" (displays red error box).
=====
My guess: the program seems to be caring about the files ONLY if they have html file extension. Please see the screenshots below.
====
What are the security implications? Not much, I think. From what I can tell, exposing the "/usr/share/themes/elog" path, and also exposing the elog version when the file does not exist. Hope this reply helps anyone else with the same question.
(I am sure the error exposing the version can be removed by editing the source code--this is probably beyond my capabilities at this point).
|
|
|
|
|
69305
|
Fri Feb 19 09:59:04 2021 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.4 | Re: Path disclosure on unfound file | I made a new RPM: https://elog.psi.ch/elog/download/RPMS/elog-3.1.4-3.el7.x86_64.rpm
Gabriel Lopez wrote: |
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
Stefan Ritt wrote: |
Ok, I fixed the code in the current commit (395e101add19f0fe8a11a25d0822e511f34d94d1). The path gets stripped, and we see a

prinnydood wrote: |
I can confirm this issue exists on version 3.1.3, which I have installed elog on Debian 10.
The issue also exists on version 3.14 (1.20190113git283534d97d5a.el7), which I tested on an AmazonLinux EC2 instance.
This is what I found:
1. if I leave out the extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish
2. if I include any random extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish.php or /gibberish.htm or /gibberish.asdfasd
3. if I include any .html extension specifically at the end of the URL for a non-existent page, elog exposes the path /usr/share/elog/themes/default/gibberish.html. This is a bug... Example: /gibberish.html exposes the path, and likewise, /.gibberish.html ( "dot" + gibberish) exposes the path
4. if I include a valid, existent .html file which is located in the directory /usr/share/elog/themes/default/, and call it, elog exposes the html document. Example: I created an html file called gibberish.html (containing <html><body><p>Hello world</p></body></html>) in my system's /usr/share/elog/themes/default/ directory. After navigating back to the /gibberish.html URL, I was presented with the HTML file.
Turning on -v (verbose mode), the response by elogd when accessing these are: "GET /elog/gibberish.html HTTP/1.0 Returned 605 bytes" (displays "Hello world" html file), and "GET /elog/gibberish.asdfasd HTTP/1.0 Returned 605 bytes" (displays red error box).
=====
My guess: the program seems to be caring about the files ONLY if they have html file extension. Please see the screenshots below.
====
What are the security implications? Not much, I think. From what I can tell, exposing the "/usr/share/themes/elog" path, and also exposing the elog version when the file does not exist. Hope this reply helps anyone else with the same question.
(I am sure the error exposing the version can be removed by editing the source code--this is probably beyond my capabilities at this point).
|
|
|
|
69304
|
Fri Feb 19 08:35:53 2021 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 3.1.4 | Re: export/archive a logbook | Find -> Export to: CSV (or any other format) -> Search
Jacky Li wrote: |
Hi,
I have an elogd server serves many logbooks. May I know what is a good way to export or achive one its logbooks? Thank you.
Jacky
|
|
69303
|
Thu Feb 18 19:21:57 2021 |
| Jacky Li | zli@hawaii.edu | Question | Linux | 3.1.4 | export/archive a logbook | Hi,
I have an elogd server serves many logbooks. May I know what is a good way to export or achive one its logbooks? Thank you.
Jacky |
69302
|
Thu Feb 18 12:06:12 2021 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.4-2 | Re: elog server go to high CPU and hangs | 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 |
|