ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
68583
|
Mon Mar 20 22:44:27 2017 |
| Andrew Daviel | advax@triumf.ca | Question | Linux | 2.7.5 | Re: Issue with zero-length mail attachments |
Andrew Daviel wrote: |
We have elog-2.7.5-1.i386 on SL 5
If I create an elog entry using the web interface, and include an inline image, email is sent with a zero-length named attachment - the MIME header is present, but no content.
In the config file, Email Format = 47, though I also tried with format = 63.
Is this a bug that was fixed in a later version, or a configuration error (or a new bug) ?
|
Probably us not having ImageMagick installed. elog was able to attach pdf's, xpm's and xbm's to email, but not jpeg's or png's, though they inlined OK in HTML on the server.
It seems OK, I think, after installing ImageMagick and restarting. |
66327
|
Tue Apr 21 22:13:26 2009 |
| Andreas Wilke | wilke4all@hotmail.de | Question | Windows | 2.7.5-2130 | Mirror Server Funktion | Ich möchte meine "lokale" ELOG Installation mit einem Server in der Firma synchronisieren.
Dazu habe ich in der entfernten Firewall ein Portmapping auf den ELOG Server in der Firma eingerichtet.
Wenn ich von meiner "lokalen" Maschine im Browser http://meinedomain.dyndns.xx:PORT aufrufe, kann ich auf den ELOG Server zugreifen.
Ich habe in meiner "lokalen" Installation in der Section [global] den Mirror-Server = http://meinedomain.dyndns.xx:PORT angeben.
Beim Synchornisieren bekomme ich jedoch den Hinweis "Fehler beim Zugriff auf entfertes Logbuch".......
|
2091
|
Fri Nov 24 23:08:33 2006 |
| Andreas Warburton | andreas.warburton@gmail.com | Question | Linux | Windows | 2.6.2-1755 | Resubmit-as-new-entry behaviour when synchronizing/mirroring | Hello,
I am running two ELOG installations: one on my Windows laptop; the other on a Debian linux web server. I have mirroring set up between the two installations. This has worked well for over a year. I am hoping that someone can help me regarding the following odd behaviour.
1. I edit (create) an entry on my Windows laptop. This entry gets mirrored or synchronized to the Linux machine.
2. I can view the entry fine both on the Windows side and on the Linux side.
3. I then edit the entry on the Linux side. After saving, the revised entry is visible on the Linux side.
4. I then have the same entry number available on both installations, but the two have different content due to my edit.
5. If I then synchronize, the original (unedited) entry is preserved along with the new entry, so both the Windows and Linux installations now have TWO entries each, representing the unedited and edited versions. The time stamps are identical, but the edited version is given a new ID number.
As a check, I explicitly added the line "Resubmit default = 0", which I know refers to editing and not synchronization, to my config file. The weird thing is that the synchronize/mirror operation seems to be acting with a "Resubmit default = 2" kind of behaviour.
Has anyone observed this happening?
Thanks for any comments or insights.
Cheers,
Andreas |
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
|
68519
|
Sat Dec 24 10:40:00 2016 |
| Andreas Warburton | awarburt@physics.mcgill.ca | Question | Mac OSX | 3.1.2 | elogd crashes during Find and Mirror operations under MacOS | When installing ELOG 3.1.2 on my Mac Sierra (10.12.2) with the latest XCode 8.2.1, it seemed to install fine but for one warning when building elogd:
cc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -DHAVE_SSL -I /opt/local/include -o elogd
src/elogd.c crypt.o auth.o regex.o mxml.o -lssl
src/elogd.c:13840:13: warning: '__builtin___strlcpy_chk' will always overflow
destination buffer [-Wbuiltin-memcpy-chk-size]
strlcpy(user_email, user_list[i], NAME_LENGTH);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'
__builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
My installation was done with "sudo make install", as the instructions state. I have also been using the prescribed "launchctl" approach.
1. Is the above warning something that needs attention/correcting?
2. My elogd crashes now every time that I attempt any kind of "Find" operation.
3. I synchronize my MacOS version of elog with a linux-based version on my university's web server. I have installed 3.1.2 on the linux server, and it is running there without problems. When I now try to synchronize my 3.1.2 ELOG on MacOS laptop with the same version on my linux server, it appears to do the first mirroring operation correctly, but elogd crashes when I try a second synchronization at a later time. (For now, I have "Mirror simulate = 1" to prevent inadvertent damage.)
Can anyone help me with the above points?
Thank you,
Andreas
|
Draft
|
Tue Jan 3 12:43:56 2017 |
| Andreas Warburton | awarburt@physics.mcgill.ca | Question | Mac OSX | 3.1.2 | Re: elogd crashes during Find and Mirror operations under MacOS |
Stefan Ritt wrote: |
The current GIT revision (c017d07) fixes the problem with the strlcpy() function (macOS 10.12.2, XCode 8.2). Can you try if that fixes your other problems, too?
Plese remember to use the recursive clone to get that version:
git clone https://bitbucket.org/ritt/elog --recursive
Stefan
Andreas Warburton wrote: |
When installing ELOG 3.1.2 on my Mac Sierra (10.12.2) with the latest XCode 8.2.1, it seemed to install fine but for one warning when building elogd:
cc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -DHAVE_SSL -I /opt/local/include -o elogd
src/elogd.c crypt.o auth.o regex.o mxml.o -lssl
src/elogd.c:13840:13: warning: '__builtin___strlcpy_chk' will always overflow
destination buffer [-Wbuiltin-memcpy-chk-size]
strlcpy(user_email, user_list[i], NAME_LENGTH);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'
__builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
My installation was done with "sudo make install", as the instructions state. I have also been using the prescribed "launchctl" approach.
1. Is the above warning something that needs attention/correcting?
2. My elogd crashes now every time that I attempt any kind of "Find" operation.
3. I synchronize my MacOS version of elog with a linux-based version on my university's web server. I have installed 3.1.2 on the linux server, and it is running there without problems. When I now try to synchronize my 3.1.2 ELOG on MacOS laptop with the same version on my linux server, it appears to do the first mirroring operation correctly, but elogd crashes when I try a second synchronization at a later time. (For now, I have "Mirror simulate = 1" to prevent inadvertent damage.)
Can anyone help me with the above points?
Thank you,
Andreas
|
|
|
68524
|
Tue Jan 3 12:45:13 2017 |
| Andreas Warburton | awarburt@physics.mcgill.ca | Question | Mac OSX | 3.1.2 | Re: elogd crashes during Find and Mirror operations under MacOS | Thank you very much (both Andreas and Stefan)! The build now runs without warnings, and I am now able to do Find operations without crashes. I still am having some issues with the synchronization, but I suspect that this is elog-content related, so will in the coming days do some more testing from CERN (where I have higher bandwidth with my home institution in Canada). Incidentally, I had to add a line to Makefile in order to be able to build on my Mac. See below, in case you want to update the Mac Makefile for others.
Many thanks again,
Andreas
ifdef USE_SSL
ifneq ($(USE_SSL),0)
CFLAGS += -DHAVE_SSL
CFLAGS += -I /opt/local/include
LIBS += -lssl
endif
endif
(You may wish to update the distribution if you think it may benefit other Mac users.)
Stefan Ritt wrote: |
The current GIT revision (c017d07) fixes the problem with the strlcpy() function (macOS 10.12.2, XCode 8.2). Can you try if that fixes your other problems, too?
Plese remember to use the recursive clone to get that version:
git clone https://bitbucket.org/ritt/elog --recursive
Stefan
Andreas Warburton wrote: |
When installing ELOG 3.1.2 on my Mac Sierra (10.12.2) with the latest XCode 8.2.1, it seemed to install fine but for one warning when building elogd:
cc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -DHAVE_SSL -I /opt/local/include -o elogd
src/elogd.c crypt.o auth.o regex.o mxml.o -lssl
src/elogd.c:13840:13: warning: '__builtin___strlcpy_chk' will always overflow
destination buffer [-Wbuiltin-memcpy-chk-size]
strlcpy(user_email, user_list[i], NAME_LENGTH);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'
__builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
My installation was done with "sudo make install", as the instructions state. I have also been using the prescribed "launchctl" approach.
1. Is the above warning something that needs attention/correcting?
2. My elogd crashes now every time that I attempt any kind of "Find" operation.
3. I synchronize my MacOS version of elog with a linux-based version on my university's web server. I have installed 3.1.2 on the linux server, and it is running there without problems. When I now try to synchronize my 3.1.2 ELOG on MacOS laptop with the same version on my linux server, it appears to do the first mirroring operation correctly, but elogd crashes when I try a second synchronization at a later time. (For now, I have "Mirror simulate = 1" to prevent inadvertent damage.)
Can anyone help me with the above points?
Thank you,
Andreas
|
|
|
68539
|
Mon Jan 9 17:15:56 2017 |
| Andreas Warburton | awarburt@physics.mcgill.ca | Bug report | Mac OSX | V3.1.2-edc5e85 | elogd crashes during SSL Mirror operations involving attachments | 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
|
|