For heightened security, we allow access to our ELOG installation from offsite through an apache proxy.  Therefore, the URL for our ELOG becomes http://www.lepp.cornell.edu/proxy/elog/ .  Everything seems to work properly with this setup except for the "reset password" utility.  When trying to reset ones password, the link sent in the "Password recovery" email becomes, for example:

http://www.lepp.cornell.edu/proxy/elog/ERL+W128/?redir=%3Fcmd%3DChange+password...

When using this link, the redirect redirects you to:

http://www.lepp.cornell.edu/ERL+W128/?cmd=Change%20password...

Which does not work.  Instead, the redirect should point to:

http://www.lepp.cornell.edu/proxy/elog/ERL+W128/?cmd=Change%20password...

Jul  9 19:05:00 elogd[27009]: Falling back to default group "elog"
Jul  9 19:05:00 elogd[27009]: Falling back to default user "elog"
Jul  9 19:05:02 elogd[27009]: Cannot restore original GID/UID.
Jul  9 19:05:02 elogd[27009]: Cannot remove pidfile "/var/run/elogd.pid" ; Permission denied
Jul  9 19:05:05 elogd[27013]: Falling back to default group "elog"
Jul  9 19:05:05 elogd[27013]: Falling back to default user "elog"
Jul  9 19:05:05 elogd[27013]: Cannot restore original GID/UID.
Jul  9 19:05:05 elogd[27013]: Cannot remove pidfile "/var/run/elogd.pid" ; Permission denied
Jul  9 19:05:05 elogd[27016]: Falling back to default group "elog"
Jul  9 19:05:05 elogd[27016]: Falling back to default user "elog"
Jul  9 19:05:06 elogd[27016]: Cannot restore original GID/UID.
Jul  9 19:05:06 elogd[27016]: Cannot remove pidfile "/var/run/elogd.pid" ; Permission denied

Jul  9 19:47:08 elogd[27335]: elogd server aborted.

Jul  9 19:47:16 elogd[27359]: elogd 2.7.3 built Apr 18 2008, 14:08:31 
Jul  9 19:47:16 elogd[27359]: revision 2104
Jul  9 19:47:16 elogd[27359]: Falling back to default group "elog"
Jul  9 19:47:16 elogd[27359]: Falling back to default user "elog"
Jul  9 19:47:16 elogd[27360]: Falling back to default group "elog"
Jul  9 19:47:16 elogd[27360]: Falling back to default user "elog"
Jul  9 19:47:16 elogd[27360]: Cannot restore original GID/UID.
Jul  9 19:47:16 elogd[27360]: Cannot remove pidfile "/var/run/elogd.pid" ; Permission denied
Jul  9 19:47:16 elogd[27359]: ImageMagick detected

I get the following error where thumbnails should go: Cannot create thumbnail, please check ImageMagick installation.

I restarted elog and check the log, it does in fact detect ImageMagick and it does have the most recent version. I'm running ubuntu 2.6.24-19-server.  Is there something else I should be checking?

 Try the following:

• Put logfile = elog.log into your elogd.cfg
• Upload an image to get the error
• Examine your elog.log file

You should get something like:

23-Jul-2008 15:10:38 [] Server listening on port 8080 ..
23-Jul-2008 15:10:52 [stefan@127.0.0.1] {demo} SHELL "convert "logbooks\demo\080723_151052_Capture.png" "logbooks\demo\080723_151052_Capture.png.png""

In your logfile. Now try the "convert" command manually under the same account elogd is running. Possible reasons for problems are:

• The "convert" command is not in your path or links to another program. Unfortunately ImageMagick chose a pretty standard name for this program
• The account under which elogd is running does not have write access to the logbook directory
• converts wants to call ghostscript for PDF conversion, but it is not installed
• ...

My Elog running on windows 2003 sp1 is crashing with this error "  Faulting application elogd.exe, version 0.0.0.0, faulting module elogd.exe, version 0.0.0.0, fault address 0x00061330."  the version of elogd.exe is  has a built date of 2/22/2008.  Will upgrading to the latest windows binary resolve this issue?    Thanks!!

 

 I would give it a try!

One of my shifters just managed to make an anonymous logbook entry even though the Author attribute is required.

It turns out that he had two tabs in his browser opened/logged into the Elog.  He logged out in one tab only.   Then he

did some other work on the desktop.  Then he returned to the browser to make a new logbook entry, finding the tab which

still showed the logged in menu, including the link for "New".  The Shifer is on day two, so he did not give any special

notice to seeing Anonymous in the Author field instead of his name.  He did point it out when I came in, and noted that

no warning was given about making an anonymous entry.

I tested the same scenario myself.  One cannot preview an anonymous entry (when Author field is a required attribute).

A warning is given.  However, one can submit the anonymous entry, and no warning is given.

Alan

 What configuration do you use? I tried to reproduce your problem with a "minimal" configuration like

[demo]
Attributes = Author, Subject
Preset Author = $long_name
Locked Attributes = Author

When I log out from the second browser tab and click on "New" on the first browser tab, I am shown the login page, not the new entry page. I guess your "menu commands" and "guest menu commands" allow non-logged in users to issue a "New" command. Try removing that.

Stefan