obfuscate password in verbose logging, posted by Mark Bergman on Thu Apr 26 23:57:04 2012
|
I'm trying to debug an issue with elogd (2.9.1) and was reminded that using the "-v" option exposes
user passwords. This wasn't a huge problem for us in the past, but we're now using kerberos authentication,
meaning that the exposed username/password applies to lots of sensitive systems within our university.
I'd suggest that the "-v" option hide passwords. If they need to be revealed for debugging
purposes, make that a separate (and very well documented) option. Maybe something like:
"--really-include-passwords-as-clear-text-in-log-output". :) |
|
ELOG crashes when editing threads, posted by Louis de Leseleuc on Fri Sep 14 17:59:44 2012
|
Hi,
I am experiencing repeated crashing of the elog daemon.
If I go into select mode while in threaded view, I can select an entire thread by selecting the top entry.
When I do so then press the Edit button, the server crashes.
I have to manually restart it. Syslog shows no error.
This does not happen under Summary or Full view.
Running Ubuntu 12.04, ELOG 2.9.2-2455
I can provide my elog.cfg if necessary.
Cheers!
Louis
P.S. i just crashed the forums ELOG following those same steps!! Sorry!! At least it was restarted in no time. |
Crash with long image names, posted by Josef Uher on Sun Sep 16 21:14:12 2012 
|
Hi All,
I found that elog crashes if I try to upload an image with long name. It actually uploads the file after the crash. It crashes also if in the full view with attachments visible. If I shorten the name all is fine.
The crash report screenshot is attached. It looks like a too small buffer (?).
|
|
Re: Importing XML, posted by Andreas Luedeke on Thu Oct 4 11:35:12 2012
|
| David Chastain wrote: |
|
[...] Basically, I am trying to take spreadsheet data, convert it into XML and upload it as a logbook so I don't have to perform lots of data entry. I also tried .CSV but have had no luck. Any thoughts or ideas?
|
I've successfully imported a large amount of entries from old non-ELOG logbooks via XML.
The only problem that I did run into was the date format: ELOG is very restrictive on the imported format; it has to be either "MM/DD/YY(YY) (HH:MM:SS)" or "DD.MM.YY(YY) (HH:MM:SS)".
When you export entries ELOG honours the "Date format" that you've specified in your elogd.cfg, therefore you cannot import the exported file until you reformat the date in the file.
Andreas |
|
ELOG crash related to Kerberos, SSL and Login users, posted by Andreas Luedeke on Mon Nov 26 15:57:49 2012
|
I'm using Kerberos and SSL and experience problems with individual setting of "Login user =" for different logbooks.
Sometimes (not every time, but most times) the server crashes under the following condition:
When I login at one logbook and then change to a logbook, that has a restricted "Login user" list with my login
name not in it. It created the following GDB output:
Program received signal SIGSEGV, Segmentation fault.
show_elog_list (lbs=0x916b768, past_n=0, last_n=0, page_n=0, default_page=1, info=0x0) at src/elogd.c:19793
19793 message_id = msg_list[index].lbs->el_index[msg_list[index].index].message_id;
Expected behaviour would be to show me the login page with the error message:
"you don't have access to this logbook".
This message is never shown for the attached configuration file.
If I remove the "Guest" commands for logbook "TestB" then elogd behaves properly.
For the moment I've just disabled "Login user" settings.
Regards
Andreas |
|
Error 554 MailTransferAgentServer ESMTP not accepting messages, posted by Ron Beekman on Mon Dec 10 16:28:27 2012
|
Hello,
We use ELOG for many years and enjoy it's functions every day!
Lately, we see errors whenever we add an entry in elog: 554 MailTransferAgentServer ESMTP not accepting messages
We see this from various ELOG servers. Other (non ELOG) servers using the same MailTransferAgentServer do not heve this error.
We are able to send mail messages from the ELOG machines manually via TELNET. So, from a functional point of view, all works well.
We had this error in the past and found out that the cause of this error lies in (network) time-outs.
Questions:
1) Has anyone seen this error before?
2) Is it possible to increase the timeout value used by ELOG?
3) Are the emails that could not be sent stored in a queue/resent later or are they lost?
4) is there a fix?
Any replies are highly appreciated!
T I A !
|
|
elogd crashes with malloc() memory corruption, posted by Mark Bergman on Fri Mar 1 16:35:21 2013
|
I'm having an issue with ELog 2.9.2 revision 2455 where it crashes consistently with:
*** glibc detected *** /usr/local/sbin/elogd: malloc(): memory corruption: 0x0000000014977210 ***
(the address varies). The crash seems to be triggered by the attempt to email a log entry. The log entry itself is saved. If I open the existing message for editing, make no changes, then Submit the message (in order to send email), the daemon crashes.
The behavior is consistent on multiple servers, each running CentOS5.9.
|
|
Incomplete SSL proxy instructions, insecure result., posted by Konstantin Olchanski on Fri Mar 22 19:41:31 2013
|
The instructions for securing elogd using an SSL proxy are incomplete.
http://midas.psi.ch/elog/adminguide.html#secure
http://midas.psi.ch/elogs/contributions/11
If you follow these instructions, elogd will still listen for and accept non-SSL connections on it's own TCP port bypassing the SSL proxy.
(True, the elogd TCP port number is somewhat secret, so there is some security-by-obscurity here).
To secure the elogd TCP port against connections that bypass the SSL proxy, elogd has to be started
with the "-n localhost" command line options.
To add this option, one has to edit /etc/init.d/elogd. I do not know if this change will be lost when the elog rpm package is updated.
It would be better if this option could have been specified through elogd.conf.
The "-n" command line option is not documented here
http://midas.psi.ch/elog/adminguide.html#config
but is visible if you run "elogd -h".
P.S. Even with "-n localhost", users of the local machine can bypass the SSL proxy.
K.O. |