| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
66891
|
Fri Sep 3 19:04:46 2010 |
 | Renee Poutissou | renee@triumf.ca | Comment | Linux | Mac OSX | 2.8.0 | Re: Synchronizing mirror causes corruption of logbook entries with multiple logbooks defined? |
| Andreas Luedeke wrote: |
|
| Glenn Horton-Smith wrote: |
|
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? [...]
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.
|
We plan to use ELOG with mirror servers in a larger scale here, so I'm interested to know more about your problem.
Could you boil down your configuration to a minimum that still allows a reproduction of the problem and post those configurations as attachments?
Then I would try to reproduce it here. Best case I'll find a bug fix, worst case I'll reconsider the use of mirror servers ;-)
|
I have been using the mirror mechanism for one year for the online T2K /ND280 (neutrino oscillation experiment at J-PARC, Japan). It has been a savior to allow access to all collaborators to the Elog. The experiment online computers are all behind a double firewall that allow only communication through ssh and http in one direction: from the inside to the outside. The master Elog is located in Canada and accessible remotely to all collaborators. The mirror Elog is located inside the firewall on one of the online machines in Japan and synchronization is setup to run automatically every 5 minutes. There are 10 logbooks defined for each of the sub-detector groups.
At first I encountered a big problem when messages were added on both sides. It turned out that Elog mirroring does not work when the two instances are running on different time zones. After I set the machine in Canada to run on Japan time (JST), no further problems have happened. Postings are routinely entered on either of the Elogs and synchronization works well. This feature is essential to having a workable Elog for the T2K experiment.
I had reported the problem of timezones to Stefan last year. He was going to put it on his wish list.
|
|
67064
|
Tue May 3 20:05:29 2011 |
 | Andreas Warburton | andreas.warburton@gmail.com | Question | Linux | Mac OSX | 2.9.0-2396 | Unwanted faux DST date shifts to time stamps in mirror transactions | Hi,
I have a MacOSX 10.6.7 laptop that periodically synchronizes my logbook with that on a Debian linux web server. Both instances of ELOG are 2.9.0-2396.
When I create a new entry on the laptop, the indicated time stamp is correct. When I click Synchronize on the laptop, the entry that gets mirrored to the Debian server has a time stamp exactly one hour earlier (in the past) on the Debian side.
Likewise, when I create a new entry on the Debian server, the indicated time stamp is correct. When I click Synchronize on the laptop, the entry that gets mirrored from the Debian machine to the laptop has a time stamp that is exactly one hour in the future on the laptop.
This appears to be due to an incorrect handling of times with regard to "summer" (daylight savings) and "standard" time when mirroring between these two different machines.
Is there a straightforward workaround to immunize against this sensitivity?
Thanks!
Andreas
|
|
68547
|
Fri Jan 13 08:27:15 2017 |
 | Andreas Warburton | awarburt@physics.mcgill.ca | Bug report | Linux | Mac OSX | V3.1.2-edc5e85 | Re: elogd crashes during SSL Mirror operations involving attachments | The attached screenshot shows the behaviour after doing a synchronization (with Mirror simulate = 1) following first having ensured that the local (Mac) and remote (linux) ELOGs initially showed "All entries identical" when doing a simulated synchronization, and then having edited local entries 9707 and 9709 by uploading (different) attachments to them.
The fact that the synchronization is suggesting to renumber two different entry IDs to the same number looks like a bug.
Best regards,
Andreas W.
| Andreas Warburton wrote: |
|
My MacOS (10.12.2) elogd version V3.1.2 is a recent git commit (edc5e85), due to the fix to my earlier-described issue solved in the thread here: https://midas.psi.ch/elogs/Forum/68519.
I am trying to (re-)set up Mirror functionality with a linux server running the standard public (V3.1.2-bd75964). I had initially updated the linux server so that it also had the latest git commit (edc5e85), but could then not even add new logbook entries that involved attachments to it. I therefore rolled the linux server back to the standard public 3.1.2 version.
On the remote Mac, synchronizations usually look like they are going to work fine, with Mirror simulate = 1 switched on. After I set Mirror simulate = 0, and if the server and remote logbook are already identical, I *occasionally* get the proper "All Entries Identical" synchronization result. Unfortunately, this is very rare, and usually there is a failure whereby the remote (Mac) logbook decides that a significant fraction of its entries (usually sequential, from some seemingly random entry all the way up to the last entry) are missing on the linux server and need to be submitted back to the server from the remote Mac.
When the local and remote logbooks are not identical, and a record in need of synchronization contains an attachment, there is again destructive behaviour similar to that described above, except that the Mac elogd executable usually crashes. (As in the case of the already-identical synchronizations described above, I only tested this after observing the correct expected behaviour first with Mirror simulate = 1.)
I'd be grateful for some help/suggestions. My current testing suggests that my problems are likely not elog-content dependent. (The logbook now undergoing synching has less than 10 entries in it.)
More generally, the issue of having things behave fine with Mirror simulate = 1, but then experiencing corruption/damage when switching to Mirror simulate = 0 seems serious to me.
Many thanks, Andreas
|
|
| Attachment 1: Screen_Shot_2017-01-13_at_8.24.07_AM.png
|
|
|
68548
|
Fri Jan 13 21:05:49 2017 |
| Andreas Warburton | awarburt@physics.mcgill.ca | Bug report | Linux | Mac OSX | V3.1.2-edc5e85 | Re: elogd crashes during SSL Mirror operations involving attachments | When I switch from SSL = 1 to SSL = 0 and I use http:// instead of https://, the ability to upload attachments to logbook entries returns. With both Chrome and Safari browsers, with SSL = 1 the file upload hangs after only a small percentage of the file has been uploaded. I ran the following openssl diagnostic on my elogd port. Would anyone have advice on what might be causing such errors?
tapajo [/usr/local/elog/elog-latest] openssl s_client -connect elog.hep.xxx.xxx.xx:80xx -state -nbio | grep "^SSL"
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
SSL_connect:unknown state
depth=0 C = EU, ST = SomeState, L = SomeCity, O = SomeOranization, OU = SomeOrganizationUnit, CN = localhost
verify error:num=18:self signed certificate
verify return:1
depth=0 C = EU, ST = SomeState, L = SomeCity, O = SomeOranization, OU = SomeOrganizationUnit, CN = localhost
verify return:1
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:error in unknown state
SSL_connect:error in unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL handshake has read 1733 bytes and written 871 bytes
SSL-Session:
SSL3 alert read:warning:close notify
SSL3 alert write:warning:close notify
| Andreas Warburton wrote: |
|
The attached screenshot shows the behaviour after doing a synchronization (with Mirror simulate = 1) following first having ensured that the local (Mac) and remote (linux) ELOGs initially showed "All entries identical" when doing a simulated synchronization, and then having edited local entries 9707 and 9709 by uploading (different) attachments to them.
The fact that the synchronization is suggesting to renumber two different entry IDs to the same number looks like a bug.
Best regards,
Andreas W.
| Andreas Warburton wrote: |
|
My MacOS (10.12.2) elogd version V3.1.2 is a recent git commit (edc5e85), due to the fix to my earlier-described issue solved in the thread here: https://midas.psi.ch/elogs/Forum/68519.
I am trying to (re-)set up Mirror functionality with a linux server running the standard public (V3.1.2-bd75964). I had initially updated the linux server so that it also had the latest git commit (edc5e85), but could then not even add new logbook entries that involved attachments to it. I therefore rolled the linux server back to the standard public 3.1.2 version.
On the remote Mac, synchronizations usually look like they are going to work fine, with Mirror simulate = 1 switched on. After I set Mirror simulate = 0, and if the server and remote logbook are already identical, I *occasionally* get the proper "All Entries Identical" synchronization result. Unfortunately, this is very rare, and usually there is a failure whereby the remote (Mac) logbook decides that a significant fraction of its entries (usually sequential, from some seemingly random entry all the way up to the last entry) are missing on the linux server and need to be submitted back to the server from the remote Mac.
When the local and remote logbooks are not identical, and a record in need of synchronization contains an attachment, there is again destructive behaviour similar to that described above, except that the Mac elogd executable usually crashes. (As in the case of the already-identical synchronizations described above, I only tested this after observing the correct expected behaviour first with Mirror simulate = 1.)
I'd be grateful for some help/suggestions. My current testing suggests that my problems are likely not elog-content dependent. (The logbook now undergoing synching has less than 10 entries in it.)
More generally, the issue of having things behave fine with Mirror simulate = 1, but then experiencing corruption/damage when switching to Mirror simulate = 0 seems serious to me.
Many thanks, Andreas
|
|
|
|
69229
|
Wed Sep 30 18:57:44 2020 |
| Ekaterina Korobkina | ekorobk@ncsu.edu | Question | Linux | Mac OSX | earlier then 20 | moving eLog to another computer | Our Unix server died, so we decided to move our old eLog to the new server, running Mac OSX. Elog version is earlier then 2013, I can not say
I read that on OSX eLog must be intalled through "make" command
if I need to install eLog first, how to add all old information later?
|
|
69230
|
Sat Oct 3 11:08:27 2020 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Question | Linux | Mac OSX | earlier then 20 | Re: moving eLog to another computer |
- you need to copy your logbooks into the "logbooks" directory.
- you need to copy your elog.cfg logbook config file to the new elog folder and reference it at start-up (something like "elogd -c /usr/local/elog/elogd.cfg ...")
Some people modify other stuff (CSS, java scripts) but if you had you would know what you did.
If the old ELOG was a 2.x version and the new is 3.x, then on the first start-up all logbook data files are copied into sub-folders for each year.
This is only done (automatically) during the first start-up, afterwards you can not use a 2.x version anymore (you won't want that anyway).
| Ekaterina Korobkina wrote: |
|
Our Unix server died, so we decided to move our old eLog to the new server, running Mac OSX. Elog version is earlier then 2013, I can not say
I read that on OSX eLog must be intalled through "make" command
if I need to install eLog first, how to add all old information later?
|
|
|
69644
|
Fri Feb 3 16:54:57 2023 |
| Stefan Ritt | A stefan.ritt@psi.ch | Info | Linux | Mac OSX | 3.1.5 | New elog version 3.1.5 | A new version 3.1.5 of elog has been released with all accumulated fixes over the past actually few years. I made a tar file, a RPM, but I could not compile yet a windows version.
https://elog.psi.ch/elog/download.html
Best,
Stefan |
|
69645
|
Fri Feb 3 20:26:46 2023 |
| Antonio Bulgheroni | Looking antonio.bulgheroni@gmail.com | Info | Linux | Mac OSX | 3.1.5 | Re: New elog version 3.1.5 | Looking forward to the windows installer.
Thanks a lot and keep up the good work!
cheers,
toto
| Stefan Ritt wrote: |
|
A new version 3.1.5 of elog has been released with all accumulated fixes over the past actually few years. I made a tar file, a RPM, but I could not compile yet a windows version.
https://elog.psi.ch/elog/download.html
Best,
Stefan
|
|
|