| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69408
|
Tue Nov 2 12:07:46 2021 |
 | Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | elog-3.1.4-2 | Re: results of security scan |
The elgod.c progarm itself is rather weak in SSL, since I just don't have time to catch up with the latest SSL enhancements. The safest you can do is to put an industry-strenth web server like Apache in front of elogd and let that server handle the SSL layer.
Stefan
| David Stops wrote: |
|
Recently central IT scanned our elog server and reported the following "vulnerabilities"
- 42873 (1) - SSL Medium Strength Cipher Suites Supported (SWEET32)
- 51192 (1) - SSL Certificate Cannot Be Trusted
- 65821 (1) - SSL RC4 Cipher Suites Supported (Bar Mitzvah)
- 85582 (1) - Web Application Potentially Vulnerable to Clickjacking
Is there any easy way of preventing these
Thanks and Best Wishes
David
|
|
|
69409
|
Thu Nov 4 13:48:00 2021 |
| David Stops | djs@star.sr.bham.ac.uk | Question | Linux | elog-3.1.4-2 | Re: results of security scan |
Thanks, I'll try that and see what happens
David
| Stefan Ritt wrote: |
|
The elgod.c progarm itself is rather weak in SSL, since I just don't have time to catch up with the latest SSL enhancements. The safest you can do is to put an industry-strenth web server like Apache in front of elogd and let that server handle the SSL layer.
Stefan
| David Stops wrote: |
|
Recently central IT scanned our elog server and reported the following "vulnerabilities"
- 42873 (1) - SSL Medium Strength Cipher Suites Supported (SWEET32)
- 51192 (1) - SSL Certificate Cannot Be Trusted
- 65821 (1) - SSL RC4 Cipher Suites Supported (Bar Mitzvah)
- 85582 (1) - Web Application Potentially Vulnerable to Clickjacking
Is there any easy way of preventing these
Thanks and Best Wishes
David
|
|
|
|
69411
|
Mon Nov 15 11:48:25 2021 |
| Chris Körner | chris.koerner@physik.uni-halle.de | Bug report | Windows | 3.14 | Re: Restrict edit time = 0 behavior intended? |
Actually this is related to post 68993 from Sebastian Schenk in Jul 2019. Are there any new workarounds I may have missed?
| Chris Körner wrote: |
|
Hi,
I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately.
|
|
|
69412
|
Mon Nov 15 14:02:42 2021 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Bug report | Windows | 3.14 | Re: Restrict edit time = 0 behavior intended? |
Hi Chris,
my old entry was related to the admin options of edit time.
The option "Admin restrict edit time" was implemented later, see ab8b98c
As a workaround you should be able to give "Restrict edit time" a ridiculous high number in the specific logbook, which should overwrite the global.
In the documentation is no rule specified for diabling global settings for specific logbooks, as far as i know.
Best wishes,
Sebastian
| Chris Körner wrote: |
|
Actually this is related to post 68993 from Sebastian Schenk in Jul 2019. Are there any new workarounds I may have missed?
| Chris Körner wrote: |
|
Hi,
I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately.
|
|
|
|
69414
|
Mon Nov 15 17:40:08 2021 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Question | All | 3.1.4 | Re: Shared logbook and elog.cfg file across multiple installations |
Hi Anthony,
the elog has a mirroring function, which synchornizes config and logs between multiple instances.
See the bottom section of https://elog.psi.ch/elog/config.html
Best wishes,
Sebastian
| Anthony wrote: |
|
Hi,
I'm wondering if it's possible to have a shared logbook and elog.cfg between multiple instances of elog. Ideally, I'd like to have my logbooks folder and elog.cfg hosted on a nextcloud instance while running the elog service locally. I've tried this using symlinks and shortcuts on windows with no luck. I was able to install elog into my mounted nextcloud folder, but this isn't ideal as I would like this to work from multiple computers.
Any ideas or thoughts on how I can do this (if I can actually do this)?
|
|
|
69415
|
Tue Nov 16 13:05:05 2021 |
| Anthony | anthony.weathers@pm.me | Question | All | 3.1.4 | Re: Shared logbook and elog.cfg file across multiple installations |
Thank you Sebastian!
I admittidely haven't looked through the page in a while, so I completely missed this feature. This should solve the problem, although in a slightly different implementation than what I was trying for.
| Sebastian Schenk wrote: |
|
Hi Anthony,
the elog has a mirroring function, which synchornizes config and logs between multiple instances.
See the bottom section of https://elog.psi.ch/elog/config.html
Best wishes,
Sebastian
| Anthony wrote: |
|
Hi,
I'm wondering if it's possible to have a shared logbook and elog.cfg between multiple instances of elog. Ideally, I'd like to have my logbooks folder and elog.cfg hosted on a nextcloud instance while running the elog service locally. I've tried this using symlinks and shortcuts on windows with no luck. I was able to install elog into my mounted nextcloud folder, but this isn't ideal as I would like this to work from multiple computers.
Any ideas or thoughts on how I can do this (if I can actually do this)?
|
|
|
|
69416
|
Tue Nov 16 15:14:42 2021 |
| Chris Körner | chris.koerner@physik.uni-halle.de | Bug report | Windows | 3.14 | Re: Restrict edit time = 0 behavior intended? |
Hi Sebastian,
thanks for the reply. It is just a bit confusing that these similar settings behave so differently. For me it is no big deal to set the time for every logbook independently instead of [global], but it leaves more room for configuration errors.
Best,
Chris
| Sebastian Schenk wrote: |
|
Hi Chris,
my old entry was related to the admin options of edit time.
The option "Admin restrict edit time" was implemented later, see ab8b98c
As a workaround you should be able to give "Restrict edit time" a ridiculous high number in the specific logbook, which should overwrite the global.
In the documentation is no rule specified for diabling global settings for specific logbooks, as far as i know.
Best wishes,
Sebastian
| Chris Körner wrote: |
|
Actually this is related to post 68993 from Sebastian Schenk in Jul 2019. Are there any new workarounds I may have missed?
| Chris Körner wrote: |
|
Hi,
I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately.
|
|
|
|
|
69418
|
Sun Nov 21 23:49:42 2021 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Question | Linux | 3.1.2 | Re: Body of new messages not getting saved when submitted |
Hello Harry,
the elog server (elogd) is a standalone application written in C and contains a full webserver and logfile management system.
There are no other dependencies to apache or python.
You can use a webserver like apache or nginx in combination with elog to act as a proxy,
e.g. to handle the encryption part of the communication between your web browser and the elogd, but you don't need to.
Regarding the first part of your message:
The elog server worked normally; entries (including the text body) got saved correctly until the last update?
The only thing in your list of updates, I can think of making this problem could be the update of ckeditor as it is the text editor used by elog.
The other packages should not be related to elog... but I am not a package maintainer.
I compiled elog from source and it brings the necessary files with it.
Best wishes,
Sebastian
| Harry Martin wrote: |
|
I've been using elog for a few years now. I've had the current setup working for me up until today.
If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved. The body (the part I can see in the editor) does not get saved.
Yesterday, I did do some updates on the server machine. Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines). Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also. About 50 packages were updated altogether.
Here are the packages that were updated yesterday (in case this is of interest to solving the issue):
[...]
This is a devuan ascii server only for clients on a local area network.
|
|