ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
66895
|
Wed Sep 8 15:31:33 2010 |
| Devin Bougie | dab66@cornell.edu | Request | Linux | 2.7.5 | difficulty with slow connections (was Re: frequent crashes on SL4) |
Hi Stefan,
> There was a timeout of 1 sec. in the elogd daemon, which probably is too short for a satellite connection. Unfortunately I have no satellite here
> around to test it, so I "blindly" increased it to 6 seconds in the current SVN version. Please give it a try.
The latest release (2.8.0-2313) does fix this problem. Our user is now able to modify entries and upload attachments using their satellite connection.
Thank you very much for your time and help. I am sorry I didn't receive this in time to help test the old SVN version.
Sincerely,
Devin |
66898
|
Tue Sep 14 01:15:22 2010 |
| Mark Bergman | mark.bergman@uphs.upenn.edu | Bug report | Linux | 2.8.0 | elog 2.8.0 as daemon crashes when editing selected threaded list |
I recently upgraded elog from 2.7.8 to 2.8.0 (and moved servers, removed unused logbooks, etc.). I'm now having a problem where elog consistently crashes when attempting to edit multiple entries. This is a very common use case, as we use a "status" field, set to "open" or "closed" to track problems. When a problem is resolved, we will go to the "list" display, set it to "threaded", "select" the thread, and then edit it, to change the status field for all posts in the thread to "closed".
Now, as soon as the "edit" button is clicked, elog crashes. This happens on every thread and logbook that I've tried. The elog logfile itself doesn't show anything useful.
However, if eLog is run with "-v" in place of "-D", it does not crash.
Environment:
CentOS 5.4
eLog 2.8.0 built Aug 5 2010, 12:24:11
|
66899
|
Tue Sep 14 11:58:22 2010 |
| Jack Dapid | daniel.dobos@cern.ch | Question | Linux | ELOG V2.8. | Password problem after elogd restart |
Hi.
I have ELOG V2.8.0-2313 installed on a SLC 5.5 release and all works fine, Users can register them-self and I see for each of them in the passwd file:
<name>test</name>
<password>***something***</password>
....
after a '/etc/rc.d/init.d/elogd restart' the logins don't work anymore (they did before the restart)
and the passwd file changed:
<name>test</name>
<password encoding="SHA256">***something else***</password>
....
Any idea what goes wrong?
Cheers, Jack |
66900
|
Tue Sep 14 23:29:15 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | ELOG V2.8. | Re: Password problem after elogd restart |
Jack Dapid wrote: |
Hi.
I have ELOG V2.8.0-2313 installed on a SLC 5.5 release and all works fine, Users can register them-self and I see for each of them in the passwd file:
<name>test</name>
<password>***something***</password>
....
after a '/etc/rc.d/init.d/elogd restart' the logins don't work anymore (they did before the restart)
and the passwd file changed:
<name>test</name>
<password encoding="SHA256">***something else***</password>
....
Any idea what goes wrong?
Cheers, Jack
|
Please have a look at https://midas.psi.ch/elogs/Forum/66872 |
66904
|
Wed Sep 15 01:04:21 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.7.8 | Re: honor "user" field in the Apache SSL request object or environment variables in SSL process groups? |
Owen LaGarde wrote: |
Will elog defer user identification and authorization to the ssl engine of a *local* Apache proxy? I'd like to try elog in a site that requires the service port positively authenticate and identify users via smartcard certificate ID. Per SOP they have Apache+mod_ssl setting SSLUserName=SSL_CLIENT_S_DN_CN which sets both the SSL request object's "user" field and the REMOTE_USER environment var relative to the mod_ssl's session's process group leader. Users auth with Apache's mod_ssl as a single-signon replacement for web apps which have traditional native, internal user accounts/passwords, but those passwords are subsumed by the Apache/smartcard/mod_ssl setup. The web apps define internal accounts matching the users' cert IDs but do not allow any management of the [unused] passwords. Can elog do this?
|
This is not implemented at the moment. |
66910
|
Fri Sep 17 14:54:51 2010 |
| marco meneghelli | marco.meneghelli@bo.infn.it | Info | Linux | 2.8.0 | Cannot bind to port 8080 |
good morning,
I have installed elog 2.8.0 from terminal but when I type
elogd -p 80
or simply
elogd
the system tells me
Cannot bind to port 8080
Can someone help me?
Thanks
Marco M |
66911
|
Mon Sep 20 14:54:21 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Info | Linux | 2.8.0 | Re: Cannot bind to port 8080 |
marco meneghelli wrote: |
good morning,
I have installed elog 2.8.0 from terminal but when I type
elogd -p 80
or simply
elogd
the system tells me
Cannot bind to port 8080
Can someone help me?
Thanks
Marco M
|
Under linux, only the "root" user can start programs on ports below 1024. If you get problems binding to ports above 1024 (such as 8080) it means that some other program uses already that port. You can check what is running usually with
netstat -l -p
|
66912
|
Wed Sep 22 14:21:50 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.8.0 | Re: elog 2.8.0 as daemon crashes when editing selected threaded list |
Mark Bergman wrote: |
I recently upgraded elog from 2.7.8 to 2.8.0 (and moved servers, removed unused logbooks, etc.). I'm now having a problem where elog consistently crashes when attempting to edit multiple entries. This is a very common use case, as we use a "status" field, set to "open" or "closed" to track problems. When a problem is resolved, we will go to the "list" display, set it to "threaded", "select" the thread, and then edit it, to change the status field for all posts in the thread to "closed".
Now, as soon as the "edit" button is clicked, elog crashes. This happens on every thread and logbook that I've tried. The elog logfile itself doesn't show anything useful.
However, if eLog is run with "-v" in place of "-D", it does not crash.
Environment:
CentOS 5.4
eLog 2.8.0 built Aug 5 2010, 12:24:11
|
I tried to reproduce your problem with following simple configuration file:
[Bergman]
Attributes = Author, Status
Options Status = open, closed
Preset Author = $long_name
The result was that it worked fine (see attachments). Maybe there is another setting in your configuration file which causes the problem. Can you try the simple configuration and see if it still crashes? |
Attachment 1: open.png
|
|
Attachment 2: closed.png
|
|