Wikipedia Article deleted, posted by Sebastian Schenk on Thu Jan 19 15:28:16 2023
|
Hello,
I noticed the wikipedia article of the ELOG got deleted
in November 2021. |
Re: Wikipedia Article deleted, posted by Stefan Ritt on Thu Jan 19 17:00:37 2023
|
I agree. I ahead ;-) I think it is not a good idea if the ELOG author pushes on that, but better someone else.
Best,
Stefan |
|
Re: Wikipedia Article deleted, posted by Andreas Luedeke on Fri Jan 20 10:25:23 2023
|
It looks to me like only an author of an article can contradict a deletion. I did not find a single method to even comment on the deletion.
I am not an Wikipedia expert, can anyone suggest on how to push for the article to be restored? Or do we just write it again, until people stop
deleting it? |
|
Re: Wikipedia Article deleted, posted by Sebastian Schenk on Fri Jan 20 13:12:48 2023
|
I have requested an undeletion of the article. The article was deleted "PROD", which means that someone tagged it. And if noone removes
the tag, it could be deleted.
I could revive the article. So in the future, One should have an eye on it and maybe update the current version of the software. |
|
Re: Wikipedia Article deleted, posted by Edmund Blomley on Mon Jan 23 21:21:56 2023
|
It was now moved to the Draft space (which I did not even now existed so far): https://en.wikipedia.org/wiki/Draft:ELOG
Sebastian
Schenk wrote:
I have requested an undeletion of the article. The article was deleted |
|
Re: Wikipedia Article deleted, posted by Stefan Ritt on Mon Jan 23 22:24:23 2023
|
I added some more references, that's about all I can do. Not sure if that is enough.
Stefan
Edmund |
|
Re: Wikipedia Article deleted, posted by Edmund Blomley on Tue Jan 24 11:31:59 2023
|
If I understand it correctly I think it has to be submitted for review with the blue button on that page, just not sure if that should come from your
side or someone else
Stefan |
|
Re: Wikipedia Article deleted, posted by Andreas Luedeke on Fri Jan 27 22:25:18 2023
|
It appears to me that this is a really stupid problem: the article provides many links to sources, but they are just links, not "references".
That does not count, since links could be something else than references.
I'll try to edit it and transform the list of external links into references to verify the text. Lets hope that this will suffice. |
|
Re: Wikipedia Article deleted, posted by John Kelly on Sat Jan 28 08:11:05 2023
|
Wikipedia has been an unreliable source for a very long time, just for the reasons that we are seeing here now with psi
and Elog. Those that 'run' Wikipedia are political and authoratative. I have not only had these negative experiences with 'them' but know
of many others that have as well. I see no reason why an organization as ours with such great ideas, programs and people need to be on their |
|
Re: Wikipedia Article deleted, posted by David Pilgram on Sat Jan 28 14:26:07 2023
|
I am rather with John on this.
I deliberately stopped contributing to Wikipedia years ago after I added an observation to an entry. That is, a piece of what could be
called original research. It was shot down in flames for being precisely that: original research. From what I read in the Draft:Elog |
Invalid Content-Length in header when running behind a load balancer, posted by Tamas Gal on Wed Jan 25 14:36:33 2023 
|
I am still struggling to get ELOG running behind a load balancer and hope to get some advice here. As already reported in https://elog.psi.ch/elogs/Forum/69542 I
observed an infinite loop of redirects when prompted to log in and using a non-empty password file. Without a password, the service worked as
expected. This was with version 3.1.3. |
|
Re: Invalid Content-Length in header when running behind a load balancer, posted by Tamas Gal on Wed Jan 25 19:51:29 2023
|
I put the ELOG service behind an Apache reverse proxy which is now sitting behind the HAProxy. It works like this, but it's just a workaround. I
am pretty sure that ELOG has problems to communicate with HAProxy correctly and it seems that Apache is more forgiving. So that the chain HAProxy ->
Apache -> ELOG and vice versa is working. |
Upload via command line through Apache reverse proxy and load balancer, posted by Tamas Gal on Wed Jan 25 18:41:27 2023
|
After fiddling around I managed to get ELOG working behind the load balancer HAProxy by stacking ELOG together with an Apache reverse proxy in a Docker
stack. I am currently pretty convinced that something with the HTTP communication is somehow faulty in ELOG and Apache is more forgiving than HAProxy,
since the configuration is the same as without Apache. So putting ELOG behind an Apache and then Apache behind the HAProxy is working. |
|
Too many redirects when running behind load balancer?, posted by Tamas Gal on Tue Jul 19 11:01:00 2022
|
We were running ELOG for many many years in our experiments and the instance was operated on a Debian XEN server as a container. I am now trying to migrate
it into our Docker Swarm cluster and I am using the https://hub.docker.com/r/de1lz/elog-docker Docker image, which works very well with our logbooks
when I run it as a single container. However, when I put the container behind my load balancer (HAProxy) using the simple HTTP mode (which works very |
|
Re: Too many redirects when running behind load balancer?, posted by Stefan Ritt on Tue Jul 19 11:13:09 2022
|
Probably you need a setting
URL = https://elog.test.km3net.de
or so in your elogd.cfg file. |
|
Re: Too many redirects when running behind load balancer?, posted by Tamas Gal on Tue Jul 19 11:17:44 2022
|
Thanks for the quick reply! Sorry, I forgot to paste the "global" part of the config, I have that URL already set:
[global]
;Main Settings |
|
Re: Too many redirects when running behind load balancer?, posted by Tamas Gal on Tue Jul 19 11:24:36 2022
|
I also tried the default configuration (example config) and it that works behind the load balancer. So I guess it's related to the password-page,
which causes this redirect loop? Our logbooks are all password protected, so when a logbook URL is clicked, it should first present the login-form, and
that's where it chokes. |
|
Re: Too many redirects when running behind load balancer?, posted by Stefan Ritt on Tue Jul 19 11:40:59 2022
|
Yeah, after you enter a password, elog redirects to what it finds in "URL". You can trace that by opening "development tools" in
Google Chrome, go to "network" and watch packets going back and forth. I never worked with the load balancer, but maybe you need a different
"URL" containing a '/' at the end? |
|
Re: Too many redirects when running behind load balancer?, posted by Tamas Gal on Tue Jul 19 12:36:04 2022
|
My problem is that I don't even reach the page where I can enter a password. If you go to https://elog.test.km3net.de and click on a logbook,
you'll see that it immediately goes into a redirect loop. I already logged the routing but there is nothing else...
Stefan |
|
Re: Too many redirects when running behind load balancer?, posted by Tamas Gal on Tue Jul 19 12:38:12 2022
|
Attached is the log, where you can see that `Operations+IT` redirects to `Operations+IT/` and that redirects to `Operations+IT` again, which then goes
to `elog.test.km3net.de` and `Operations+IT` again etc. etc.
EDIT: I use the very same load balancer confugration for dozens of other services incl. Apache, Nginx, GitLab, Mattermost, RocketChat |
|
Re: Too many redirects when running behind load balancer?, posted by Stefan Ritt on Tue Jul 19 12:48:42 2022
|
Yes I see the redirects. You say with the example logbook it works, right? Is it the password protection which triggers the problem or anything else?
Does it work if you take out the password protection? The key is to identify which setting in your config file triggers the problem, so you can bracket
the problem down between the example logbook and your logbook definition. |
|
Re: Too many redirects when running behind load balancer?, posted by Tamas Gal on Tue Jul 19 12:57:37 2022
|
Yes, I used the empty `passwd` file from example. When I then click on one of the logbooks, I get to the page where I can register a user (see attached
screenshot). After clickin on "Save" for the user registration, I again get the redirect error. Once there is a registered user (i.e. a
non-empty password file) the redirect issue is persistent. Any idea where the problem might be? I just emptied the password file again, so you can |
|
Re: Too many redirects when running behind load balancer?, posted by Tamas Gal on Fri Jan 20 14:11:52 2023
|
The issue is still present and now it's quite urgent to move this last service into the Swarm. Does anyone maybe have an idea what's wrong? To
sum up: if there is a non-empty password file, the login page chokes in an infinite loop of redirects. I am using the same HAProxy load balancer configuration
as for all the other services (running Apache, NGINX, GitLab, XWiki, etc.): |
|
Duplicated \n in "plain" format with new WebKit, posted by Andrey on Tue Dec 27 12:44:52 2022
|
Dear Stefan,
There is a problem with editing an Elog page in "plain" format with the following "User Agent" :
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Safari/605.1.15" |
|
bug report to webkit.org , posted by Andrey on Wed Dec 28 16:09:30 2022
|
It shound't be a "bug report", sorry. I have changed the category to "Info".
It seems to be really a bug in the WebKit core. I have created a bug report there. For reference: https://bugs.webkit.org/show_bug.cgi?id=249923
|
|
a hack around, posted by Andrey on Thu Dec 29 20:26:11 2022
|
FYI.
Removing "wrap=hard" on the line #11461 in the elogd.cxx file resolves my problem.
|
|
a hack around, posted by Konstantin Olchanski on Fri Dec 30 00:46:03 2022
|
- rsprintf("<textarea rows=%d cols=%d wrap=hard name=\"Text\">\n", height, width);
+ rsprintf("<textarea rows=%d cols=%d name=\"Text\">\n", height, width);
|
|
webkit bug, posted by Andrey Pashnin on Mon Jan 2 12:32:13 2023
|
FYI
They seem to have accepted the bug report:
|
|
a hack around, posted by Stefan Ritt on Wed Jan 4 09:33:25 2023
|
> - rsprintf("<textarea rows=%d cols=%d wrap=hard name=\"Text\">\n", height, width);
> + rsprintf("<textarea rows=%d cols=%d name=\"Text\">\n", height, width);
>
|
|
a hack around, posted by Stefan Ritt on Wed Jan 4 09:39:38 2023
|
Ahh, now I remember. Well, the I put that in like 25 years ago ;-)
Let's assume the user write a very long line and relies on the wrapping of the text box. So the input might look like the
|
|
editing on a smartphone, posted by Andrey Pashnin on Wed Jan 4 10:05:38 2023
|
oh! so, that's the cause of another problem I faced a while ago.
When people edited an ELOG page on a narrow screen device (a.k.a smartphone) it put the extra CRLF and made the page look like the attachment below
(it broke the original formatting).
|
|
editing on a smartphone, posted by Stefan Ritt on Wed Jan 4 10:12:43 2023
|
Yepp, that's right. But without the "wrap=hard", you could get one single long line which is almost impossible to read. So there is no perfect solution
for all cases. I see three options
|
|
config option?, posted by Andrey Pashnin on Wed Jan 4 11:03:45 2023
|
How about adding a config option?
Ideally, it might be nice to have this option "per record" or "per logbook", but "per instance" should be good enough. |
|
config option?, posted by Stefan Ritt on Wed Jan 4 11:43:00 2023
|
Ok, I added an option
Hard wrap = 0 | 1
|
|
config option?, posted by Andrey Pashnin on Wed Jan 4 11:53:35 2023
|
| That's great! Thank you very much. |
|
wrap "pre" tag in a "div" with fixed width, posted by Andrey Pashnin on Wed Jan 4 11:39:39 2023
|
I'm sorry for being annoying...
but I have tried to wrap the <pre> tag in a <div> and it seems to do the trick
(the text is a single line with repeating aaa-b-cc sequence)
|
|
wrap "pre" tag in a "div" with fixed width, posted by Stefan Ritt on Wed Jan 4 12:17:46 2023
|
| Didn't work for me. The text is just truncated after the width and no extra lines are added. |
|
wrap "pre" tag in a "div" with fixed width, posted by Andrey Pashnin on Wed Jan 4 14:05:25 2023
|
Sorry, I forgot to mention that I also added some styles to the <pre> tag:
style="white-space: normal"
(see the screenshot on my previous post) |
|
wrap "pre" tag in a "div" with fixed width, posted by Stefan Ritt on Wed Jan 4 14:23:12 2023
|
> Sorry, I forgot to mention that I also added some styles to the <pre> tag:
> style="white-space: normal"
> (see the screenshot on my previous post)
|
|
white-space: pre-wrap", posted by Andrey Pashnin on Wed Jan 4 14:38:54 2023
|
> I guess we want "white-space: pre-wrap" which keeps the old line breaks.
Yep. You're right. Thanks! |
|
URL causes elog crash, posted by Germano Massullo on Tue Dec 20 21:16:37 2022
|
Hello, the following URL
https://foo.bar/elog/Shift+Reports/?new_user_name=a2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.coma2seferewd@fonomsdfef.com&new_full_name=a2seferewd%40fanneat.com&new_user_email=a2seferewd%40fanneat.com&newpwd=asdf&newpwd2=asdf&cmd=Save
causes elog 3.1.4 to crash. I attach full GDB trace |
|
Re: URL causes elog crash, posted by Stefan Ritt on Wed Jan 4 13:38:29 2023
|
I added a user name validation in the current version.
Stefan
Germano |
|
Post using html form --> not solved ... , posted by Hayg Guler on Wed Jan 4 11:00:01 2023
|
Dear All,
Just want to come back to this issue I faced.
In the config file, I call an html form to format input. The way I call the html file inside my config file is described below. |
|
Re: Post using html form --> not solved ... , posted by Stefan Ritt on Wed Jan 4 12:38:07 2023
|
When you log in manually to a logbook, a session ID is created and stored in a cookie "sid". On your shift check list you need some code to
copy this session ID into your current form. In the code form 2010, I used "unm" and "upwd", but this was removed since it's not
safe. So now you need somethign like: |
|
duplicated/extra newlines (LF) after submit with Safari (since 15.4), posted by Andrey on Tue May 10 09:31:40 2022
|
I think this is a bug report.
However, I am not sure whether the problem is in the new version of Apple's WebKit (15.4) or in the ELOG itself.
|
|
reproduced on the latest newly compiled Elogd, posted by Andrey on Tue May 10 10:58:12 2022
|
I have just setup a new ELOG server on another machine. I took the latest source code from here: http://elog.psi.ch/elog/download/tar/elog-latest.tar.gz.
Compiled it and ran.
Still the same problem with Safari. |
|
RESOLVED HERE:, posted by Andrey Pashnin on Wed Jan 4 11:54:55 2023
|
| see https://elog.psi.ch/elogs/Forum/69594 |
|
please DELETE this thread, posted by Andrey Pashnin on Wed Jan 4 11:58:19 2023
|
I added a reply to my previous post about this issue (a few months ago) to point to the solution, but ELOG moved it to the top of the forum.
And I cannot delete this now, because I change my user name from "Andrey" to "Andrey Pashnin" :)
|