| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
68838
|
Tue Aug 28 23:38:55 2018 |
 | Andrew Wade | awade@caltech.edu | Question | Linux | Other | 3.1.2 | Re: Reverse proxy of Elog using Docker and Nginx? | It does indeed seem to be a cookie stripping issue. I just need to figure out how to get Nginx to forward these properly.
Thanks for the help.
| Stefan Ritt wrote: |
|
Actually this forum works through an Apache reverse proxy with authentication and it works, so I suspect that the problem has to do with jwilder/nginx-proxy. Since we don't have this here, all I can propose is that you do debugging yourself. Run elogd with the -v flag so that you see all requests coming from the user through the proxy. Compare the requests through Apache and Nginx to see if any argumets are stripped or mangled. Upon successful login, elog sets a cookie with a unique session-ID (the cookie name is "sid") to the browser. If you proxy strips that cookie, you would land on the login page. Maybe look in that direction.
Stefan
| Andrew Wade wrote: |
|
Yes, I tried setting the URL parameter to the url used by the proxy. It goes to the correct address but that landing is the login page.
Andrew
| Stefan Ritt wrote: |
|
Have you tried the "URL = ..." statement? This determines you elog redirects if you log in. If you reach elog through a proxy, the URL is a different one that if you access it directly. In your case the proxy URL might be necessary.
Stefan
| Andrew Wade wrote: |
|
I've been trying to configured a Synology NAS to run my personal elog with a reverse proxy to the outside world. The best way seems to be running Elog in a Docker instance and then running a separate connected Docker running a nginx-proxy (in this case jwilder/nginx-proxy). This second container manages the certificates to letsencrypt and mapping URL requests to relevant containers so that connection is secured properly.
It worked great in the initial test. However, I have an issue with authentication. When I password protect the elog it goes to a login page. When I give an correct password it loops back to the login page (incidentally when I give an incorrect password it gives an 'Invalid user name or password!' warning). So I know that its getting the correct password but there is some issue that is resetting or ignoring the authentication. I am never able to actually get to the protected content.
Does anyone have any experience in using Nginx to setup a secure reverse proxy? Any insights into why this would mess with the authentication of elog?
Side note: I have tried using Apache to do the same and authentication worked fine. But the pre-canned jwilder/nginx-proxy docker manages all the certificates automatically and seamlessly and allows me to have multiple services running on the same outward facing port on my router. There is no equivalent (as far as I know) that uses Apache for proxying with letsencrypt.
|
|
|
|
|
|
68582
|
Sat Mar 18 02:10:33 2017 |
 | Andrew Daviel | advax@triumf.ca | Question | Linux | 2.7.5 | Issue with zero-length mail attachments | 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) ?
|
|
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
|
|
|
|