ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
69363
|
Tue May 4 14:45:47 2021 |
| Faith | faithlessangel85@gmail.com | Bug report | Linux | 3.1.2 | Bug: "Append on edit" triggers too often | The command "Append on edit = " is getting executed everytime, when a dropdown menu is changed. This happens even at the first creation of an entry, so the append text stucks up multiple times in the text body. |
69364
|
Tue May 4 15:24:56 2021 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Bug report | Linux | 3.1.2 | Re: Bug: "Append on edit" triggers too often | I can confirm the issue also for "prepend on edit".
To be more precise, it gets executed everytime the condition state changes, if placed in the config without condition, or if placed in a condition, everytime the condition gets activated.
Faith wrote: |
The command "Append on edit = " is getting executed everytime, when a dropdown menu is changed. This happens even at the first creation of an entry, so the append text stucks up multiple times in the text body.
|
|
69393
|
Wed Sep 15 13:52:59 2021 |
| Bolko Beutner | bolko.beutner@desy.de | Question | Linux | Other | 3.1.2 | Re: Reverse proxy of Elog using Docker and Nginx? | I have the same problem -- did you find a solution in using the nginx revese proxy with user login?
Andrew Wade wrote: |
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.
|
|
|
|
|
|
69417
|
Sun Nov 21 23:20:15 2021 |
| Harry Martin | harrymartin772@gmail.com | Question | Linux | 3.1.2 | Body of new messages not getting saved when submitted | I've been using elog for a few years now. I've had the current setup working for me up until today.
If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved. The body (the part I can see in the editor) does not get saved.
Yesterday, I did do some updates on the server machine. Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines). Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also. About 50 packages were updated altogether.
Here are the packages that were updated yesterday (in case this is of interest to solving the issue):
bind9-host:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
ckeditor:amd64 (4.5.7+dfsg-2, 4.5.7+dfsg-2+deb9u1)
cron:amd64 (3.0pl1-128+deb9u1, 3.0pl1-128+deb9u2)
dnsutils:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
firefox-esr:amd64 (78.14.0esr-1~deb9u1, 78.15.0esr-1~deb9u1)
libapache2-mod-php7.0:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
libavcodec57:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libavfilter6:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libavformat57:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libavresample3:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libavutil55:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libbind9-140:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libcups2:amd64 (2.2.1-8+deb9u6, 2.2.1-8+deb9u7)
libcupsimage2:amd64 (2.2.1-8+deb9u6, 2.2.1-8+deb9u7)
libdns162:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libdns-export162:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libdw1:amd64 (0.168-1, 0.168-1+deb9u1)
libelf1:amd64 (0.168-1, 0.168-1+deb9u1)
libfaad2:amd64 (2.8.0~cvs20161113-1+deb9u2, 2.8.0~cvs20161113-1+deb9u3)
libicu57:amd64 (57.1-6+deb9u4, 57.1-6+deb9u5)
libisc160:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libisccc140:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libisccfg140:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libisc-export160:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libjbig2dec0:amd64 (0.13-4.1, 0.13-4.1+deb9u1)
liblwres141:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libnghttp2-14:amd64 (1.18.1-1+deb9u1, 1.18.1-1+deb9u2)
libntfs-3g871:amd64 (1:2016.2.22AR.1+dfsg-1+deb9u1, 1:2016.2.22AR.1+dfsg-1+deb9u2)
libopencv-core2.4v5:amd64 (2.4.9.1+dfsg1-2, 2.4.9.1+dfsg1-2+deb9u1)
libopencv-imgproc2.4v5:amd64 (2.4.9.1+dfsg1-2, 2.4.9.1+dfsg1-2+deb9u1)
libpostproc54:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libpython3.5:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
libpython3.5-minimal:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
libpython3.5-stdlib:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
libruby2.3:amd64 (2.3.3-1+deb9u9, 2.3.3-1+deb9u10)
libsdl1.2debian:amd64 (1.2.15+dfsg1-4, 1.2.15+dfsg1-4+deb9u1)
libswresample2:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libswscale4:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
ntfs-3g:amd64 (1:2016.2.22AR.1+dfsg-1+deb9u1, 1:2016.2.22AR.1+dfsg-1+deb9u2)
php7.0-cli:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-common:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-curl:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-intl:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-json:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-mbstring:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-opcache:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-readline:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-xml:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
python3.5:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
python3.5-minimal:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
ruby2.3:amd64 (2.3.3-1+deb9u9, 2.3.3-1+deb9u10)
tzdata:amd64 (2021a-0+deb9u1, 2021a-0+deb9u2)
This is a devuan ascii server only for clients on a local area network. |
69418
|
Sun Nov 21 23:49:42 2021 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Question | Linux | 3.1.2 | Re: Body of new messages not getting saved when submitted | Hello Harry,
the elog server (elogd) is a standalone application written in C and contains a full webserver and logfile management system.
There are no other dependencies to apache or python.
You can use a webserver like apache or nginx in combination with elog to act as a proxy,
e.g. to handle the encryption part of the communication between your web browser and the elogd, but you don't need to.
Regarding the first part of your message:
The elog server worked normally; entries (including the text body) got saved correctly until the last update?
The only thing in your list of updates, I can think of making this problem could be the update of ckeditor as it is the text editor used by elog.
The other packages should not be related to elog... but I am not a package maintainer.
I compiled elog from source and it brings the necessary files with it.
Best wishes,
Sebastian
Harry Martin wrote: |
I've been using elog for a few years now. I've had the current setup working for me up until today.
If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved. The body (the part I can see in the editor) does not get saved.
Yesterday, I did do some updates on the server machine. Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines). Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also. About 50 packages were updated altogether.
Here are the packages that were updated yesterday (in case this is of interest to solving the issue):
[...]
This is a devuan ascii server only for clients on a local area network.
|
|
69419
|
Mon Nov 22 00:44:21 2021 |
| Harry Martin | harrymartin772@gmail.com | Question | Linux | 3.1.2 | Re: Body of new messages not getting saved when submitted | Thank you for your quick response, Sebastion. The new version of ckeditor is 4.5.7 -- is this version compatible with elog 3.1.2? It is possible that I am using an outdated elog or outdated ckeditor due to the fact that this server is a bit old; I am looking to upgrade this machine soon, but I have several other issues to resolve first.
Sebastian Schenk wrote: |
Hello Harry,
the elog server (elogd) is a standalone application written in C and contains a full webserver and logfile management system.
There are no other dependencies to apache or python.
You can use a webserver like apache or nginx in combination with elog to act as a proxy,
e.g. to handle the encryption part of the communication between your web browser and the elogd, but you don't need to.
Regarding the first part of your message:
The elog server worked normally; entries (including the text body) got saved correctly until the last update?
The only thing in your list of updates, I can think of making this problem could be the update of ckeditor as it is the text editor used by elog.
The other packages should not be related to elog... but I am not a package maintainer.
I compiled elog from source and it brings the necessary files with it.
Best wishes,
Sebastian
Harry Martin wrote: |
I've been using elog for a few years now. I've had the current setup working for me up until today.
If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved. The body (the part I can see in the editor) does not get saved.
Yesterday, I did do some updates on the server machine. Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines). Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also. About 50 packages were updated altogether.
Here are the packages that were updated yesterday (in case this is of interest to solving the issue):
[...]
This is a devuan ascii server only for clients on a local area network.
|
|
|
69420
|
Mon Nov 22 19:28:28 2021 |
| Harry Martin | harrymartin772@gmail.com | Question | Linux | 3.1.2 | Re: Body of new messages not getting saved when submitted | (disregard my recent post here about missing package -- that wasn't the elog server!)
I can see that ckeditor was upgraded 11/19, which is would be prior to my recent attempts to use elog. It was apparently a security update, so I am not sure it is sensible to downgrade. OTOH, I am the only person here, and I have all sides carefully barracaded, so I don't think it would be much of an issue. But please disabuse me of my ignorance if need be.
Harry Martin wrote: |
Thank you for your quick response, Sebastion. The new version of ckeditor is 4.5.7 -- is this version compatible with elog 3.1.2? It is possible that I am using an outdated elog or outdated ckeditor due to the fact that this server is a bit old; I am looking to upgrade this machine soon, but I have several other issues to resolve first.
Sebastian Schenk wrote: |
Hello Harry,
the elog server (elogd) is a standalone application written in C and contains a full webserver and logfile management system.
There are no other dependencies to apache or python.
You can use a webserver like apache or nginx in combination with elog to act as a proxy,
e.g. to handle the encryption part of the communication between your web browser and the elogd, but you don't need to.
Regarding the first part of your message:
The elog server worked normally; entries (including the text body) got saved correctly until the last update?
The only thing in your list of updates, I can think of making this problem could be the update of ckeditor as it is the text editor used by elog.
The other packages should not be related to elog... but I am not a package maintainer.
I compiled elog from source and it brings the necessary files with it.
Best wishes,
Sebastian
Harry Martin wrote: |
I've been using elog for a few years now. I've had the current setup working for me up until today.
If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved. The body (the part I can see in the editor) does not get saved.
Yesterday, I did do some updates on the server machine. Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines). Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also. About 50 packages were updated altogether.
Here are the packages that were updated yesterday (in case this is of interest to solving the issue):
[...]
This is a devuan ascii server only for clients on a local area network.
|
|
|
|
69421
|
Mon Nov 22 19:45:08 2021 |
| Harry Martin | harrymartin772@gmail.com | Question | Linux | 3.1.2 | Re: Body of new messages not getting saved when submitted | After downgrading ckeditor, my elog installation is working again. Thanks for your help.
Harry Martin wrote: |
(disregard my recent post here about missing package -- that wasn't the elog server!)
I can see that ckeditor was upgraded 11/19, which is would be prior to my recent attempts to use elog. It was apparently a security update, so I am not sure it is sensible to downgrade. OTOH, I am the only person here, and I have all sides carefully barracaded, so I don't think it would be much of an issue. But please disabuse me of my ignorance if need be.
Harry Martin wrote: |
Thank you for your quick response, Sebastion. The new version of ckeditor is 4.5.7 -- is this version compatible with elog 3.1.2? It is possible that I am using an outdated elog or outdated ckeditor due to the fact that this server is a bit old; I am looking to upgrade this machine soon, but I have several other issues to resolve first.
Sebastian Schenk wrote: |
Hello Harry,
the elog server (elogd) is a standalone application written in C and contains a full webserver and logfile management system.
There are no other dependencies to apache or python.
You can use a webserver like apache or nginx in combination with elog to act as a proxy,
e.g. to handle the encryption part of the communication between your web browser and the elogd, but you don't need to.
Regarding the first part of your message:
The elog server worked normally; entries (including the text body) got saved correctly until the last update?
The only thing in your list of updates, I can think of making this problem could be the update of ckeditor as it is the text editor used by elog.
The other packages should not be related to elog... but I am not a package maintainer.
I compiled elog from source and it brings the necessary files with it.
Best wishes,
Sebastian
Harry Martin wrote: |
I've been using elog for a few years now. I've had the current setup working for me up until today.
If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved. The body (the part I can see in the editor) does not get saved.
Yesterday, I did do some updates on the server machine. Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines). Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also. About 50 packages were updated altogether.
Here are the packages that were updated yesterday (in case this is of interest to solving the issue):
[...]
This is a devuan ascii server only for clients on a local area network.
|
|
|
|
|
|