If I have a couple of attachments in a log book entry, I can link to that entry "http://example.edu/elog/Sandbox/7", I get the appropriate log in page, and after logging it, it takes me to the entry.

However, if I link directly an attachment, "http://example.edu/elog/Sandbox/7/1", I receive a plain log in page that doesn't have the stylesheet applied, and logging in, I am directed to " http://example.edu/elog/Sandbox/7/" which throws an invalid error. If I am already logged in the browser, it links correctly. 

I assume the problem must stem from messed up relative URL somewhere, hence the lack of stylesheet, or from the redirect incorrectly handling the /. (Looking at the source for the two login pages, the only difference is "<input type=hidden name=redir value="7">" versus "<input type=hidden name=redir value="7/1">". ) But that reaches the end of my ability...

This breaks the attachment links in emails.

Any help would be much appreciated!

I'm not of the skill level to help, but for what its worth, running Ubuntu 12.04, used alien to install the latest RPM with only two little snags. I had to create a link from libssl.so.1.0.0 to libssl.so.6, which is a trick I've pulled with other software, not sure what the proper fix is. I also had to make similar changes to the init script.

We have been experiencing corruption of logbook entries by elogd mirror synchronization. Has anyone else encountered this? Is there a known cause and/or workaround for it?

Details

We have two elog servers set up with identical elogd.cfg and password files, except that one server has "Mirror server" pointing to the other host. There are three logbooks defined.  (Their names are DoubleChooz, BigBrotherTable, and FlushingTable.)  When the mirror synchronization happens, whether by "Mirror cron" or by an administrator hitting the "Synchronize all logbooks" link, it often happens that entries requiring synchronization are corrupted on both servers (not just the one to which the entry was copied). This is particularly likely to happen if entries have been made on both servers since the previous sync.

Looking at the logbook files themselves, we see that the corrupted entries will have attributes from the wrong logbooks. E.g., we'll see an empty "Barometer: " line in a DoubleChooz logbook file, where "Barometer" is an attribute that is only in the FlushingTable logbook, or we will see there are unexpected DoubleChooz logbook attributes in the FlushingTable files.

Strangely, the entries will not be identical on the two machines after syncing, and they stay non-identical on further syncs.

Most disturbingly, data is lost from entries that were perfectly valid before the sync, on both servers.

This was happening with elogd 2.7.8, and continued to happen after upgrading to 2.8.0. Both servers are running Linux. One is a 32-bit machine and another 64-bit, in case that might matter (but read on).

I made copies of both servers' files and ran two elogd servers on my Mac on different ports, compiled from a fresh checkout of 2.8.0, and the same behavior was observed as I repeatedly made test entries and synchronized.  This suggests it isn't specific to Linux architecture, 64-bit or otherwise.

A problem recently developed for our elog...after running without much problem the elog daemon was restarted on an ubuntu server running apache2. Now the server gives 502 Proxy Error messages:

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /elog.

Reason: Error reading from remote server

I did a force-reload of apache after making sure the modules are enabled. I also restarted elogd but to no avail. One symptom seems to be that the GET request is empty...that is before it was:

"GET /elog/sample_elog/etcetera HTTP/1.1"

but now it is just

"GET /elog HTTP/1.1"

Just started out of the blue...

Any ideas?

Hi,

I wonder if it is possible to set a minimum default value for the height of the text box when submitting new entries. If I understood well, by default the text box height automatically resizes in order that all the elements of the page are visible. Actually for our needs having a minimum height of the text box fixed (for instance 500px)  is by far more useful of viewing the attachment box (we know it is down scrolling the page :) ). We know it is possible to resize the text box using the mouse but doing this every time one creates a new entry can be annoying. Setting a default minimum size would be more confortable. Is it possible to do this?

Thank you 

Beppe

I tried with Message Height = 100 inside the conifguration of my logbook, but nothing changed as you can see in the first picture...

What I'm looking for is a way, if possible, to start by default with a wider message box, someting like fig2. For our purpose, using wide tables, it would be very useful to have a wider message box in order to have a full look to the message content, and also having it by default without modifying it by hand with the mouse every time we submit something to elog.

Beppe