Body of new messages not getting saved when submitted, posted by Harry Martin on Sun Nov 21 23:20:15 2021
|
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. |
Re: Body of new messages not getting saved when submitted, posted by Sebastian Schenk on Sun Nov 21 23:49:42 2021
|
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. |
|
Re: Body of new messages not getting saved when submitted, posted by Harry Martin on Mon Nov 22 00:44:21 2021
|
Thank you for your quick response, Sebastion. The new version of ckeditor is 4.5.7 -- is this version compatible with elog 3.1.2? It is possible
that I am using an outdated elog or outdated ckeditor due to the fact that this server is a bit old; I am looking to upgrade this machine soon, but I have
several other issues to resolve first. |
|
Re: Body of new messages not getting saved when submitted, posted by Harry Martin on Mon Nov 22 19:28:28 2021
|
(disregard my recent post here about missing package -- that wasn't the elog server!)
I can see that ckeditor was upgraded 11/19, which is would be prior to my recent attempts to use elog. It was apparently a security update,
so I am not sure it is sensible to downgrade. OTOH, I am the only person here, and I have all sides carefully barracaded, so I don't think it |
|
Re: Body of new messages not getting saved when submitted, posted by Harry Martin on Mon Nov 22 19:45:08 2021
|
After downgrading ckeditor, my elog installation is working again. Thanks for your help.
Harry
Martin wrote:
(disregard my recent post here about missing package -- that wasn't |
|
Restrict edit time = 0 behavior intended?, posted by Chris Körner on Mon Nov 15 11:35:55 2021
|
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 |
|
Re: Restrict edit time = 0 behavior intended?, posted by Chris Körner on Mon Nov 15 11:48:25 2021
|
Actually this is related to post 68993 from Sebastian Schenk in Jul 2019. Are there any new workarounds
I may have missed?
Chris |
|
Re: Restrict edit time = 0 behavior intended?, posted by Sebastian Schenk on Mon Nov 15 14:02:42 2021
|
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 |
|
Re: Restrict edit time = 0 behavior intended?, posted by Chris Körner on Tue Nov 16 15:14:42 2021
|
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. |
Shared logbook and elog.cfg file across multiple installations, posted by Anthony on Mon Nov 15 15:41:04 2021
|
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 |
|
Re: Shared logbook and elog.cfg file across multiple installations, posted by Sebastian Schenk on Mon Nov 15 17:40:08 2021
|
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 |
|
Re: Shared logbook and elog.cfg file across multiple installations, posted by Anthony on Tue Nov 16 13:05:05 2021
|
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. |
|
results of security scan, posted by David Stops on Mon Nov 1 12:52:23 2021
|
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 |
|
Re: results of security scan, posted by Stefan Ritt on Tue Nov 2 12:07:46 2021
|
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 |
|
Re: results of security scan, posted by David Stops on Thu Nov 4 13:48:00 2021
|
Thanks, I'll try that and see what happens
David |
|
While mirroring, data fields not preserved, posted by Rob Calkins on Tue Oct 26 01:21:01 2021
|
While running two e-log books that were mirrored, I ended up with the situation of two entries with the same number/id. The mirroring did what
it said it would, increment the local logbook entry and grab the entry from the remote logbook. However, when it did, it did not preserve the fields in
the log book that are specified in the config file such as "Author", "Priority", "Subject" ect. I ended up with a very |
|
Too many open files - issue?, posted by Rob Calkins on Fri Oct 15 23:57:38 2021
|
Has anyone had issues with having too many files open? I'll setup my server and let it go but after a while, I end up with a lot of "cannot
create socket: Too many open files" errors being reported. I have a sync to another e-log going which I suspect is part of the cause since that
e-log server hasn't had this issue. I suspect that there are files being opened, going into some return loop code and then never getting closed. I'm |
|
Re: Too many open files - issue?, posted by Stefan Ritt on Mon Oct 25 13:34:06 2021
|
The code segements you show are from the command line tool elog.c, not the server elogd.c. The tool is called to submit a new message from the command
line. Even if there would be a file not properly closed, it will be closed by the operating system once the program finishes. So no problem of too many
open files there. |
wrong server HTTP status code when login failed, posted by Chris Körner on Thu Oct 21 14:57:14 2021
|
Hi,
I am trying to access elog through a python client (https://github.com/paulscherrerinstitute/py_elog) and found a strage strange behavior which
may be related server side problem. The python script generates get/post messages via the python requests library. This works fine so far and I can view |
|
Re: wrong server HTTP status code when login failed, posted by Chris Körner on Thu Oct 21 15:19:16 2021
|
Seems like I've discovered another bug here related to umlauts in my name. :D
I was submitting this post and forgot to put an icon. Elog seems to have saved a copy of my message, which I could not edit since my username
does not match the bugged name saved for this message. |
|
wrong server HTTP status code when login failed, posted by Chris Körner on Thu Oct 21 15:17:52 2021
|
Hi,
I am trying to access elog through a python client (https://github.com/paulscherrerinstitute/py_elog) and found a strage strange behavior which
may be related server side problem. The python script generates get/post messages via the python requests library. This works fine so far and I can view |