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.):
backend be_elog.km3net.de
mode http
option forwardfor except 127.0.0.1
http-request add-header X-Forwarded-Proto https if { ssl_fc }
server-template km3net-elog- 1 km3net-elog_elog:8080 check resolvers docker init-addr libc,none
Tamas Gal wrote: |
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 have a one-shot, if you like.
Btw. I have SSL termination in the load balancer, so ELOG does not need to do any SSL related things (the swarm is in a locally isolated network, so all internal communication between the load balancer and the swarm machines are safe). Maybe that's the issue? On the other hand, the main page loads fine and uses SSL termination too, so I don't know, maybe there is logic behind the authentication which collides with the SSL termination.
Stefan Ritt wrote: |
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 open files - issue?, posted by Stefan Ritt on Mon Oct 25 13:34:06 2021
|
The code segements you show are from the command line tool elog.c, not the server elogd.c. The tool is called to submit a new message from the command line. Even if there would be a file not properly closed, it will be closed by the operating system once the program finishes. So no problem of too many open files there.
Rob Calkins wrote: |
Has anyone had issues with having too many files open? I'll setup my server and let it go but after a while, I end up with a lot of "cannot create socket: Too many open files" errors being reported. I have a sync to another e-log going which I suspect is part of the cause since that e-log server hasn't had this issue. I suspect that there are files being opened, going into some return loop code and then never getting closed. I'm not a C programmer but I see lines like :
fh = open(tmp_filename, O_RDONLY);
if (fh > 0) {
read(fh, result, size - 1);
close(fh);
}
/* remove temporary file */
remove(tmp_filename);
This looks like it opens the file but unless the remove function closes the file, it will remain open even through the file has been deleted. Maybe this isn't the correct behaviour of 'remove' and I am mistaken?
There are also parts like :
fh = open(textfile, O_RDONLY | O_BINARY);
if (fh < 0) {
printf("Message file \"%s\" does not exist.\n", textfile);
return 1;
}
size = (INT) lseek(fh, 0, SEEK_END);
lseek(fh, 0, SEEK_SET);
if (size > (INT) (sizeof(text) - 1)) {
printf("Message file \"%s\" is too long (%zd bytes max).\n", textfile, sizeof(text));
return 1;
}
This looks like for the second error, it will complain that the file is too long, return an error message but not close the file and would leave it open. Is this a reasonable avenue to pursue or am I mis-reading the code? Thanks.
|
|
Re: Too many logbooks during user registration, posted by Stefan Ritt on Tue Aug 7 18:39:37 2007
|
Steve Jones wrote: | Stefan, we require registration with elog. We have quite a number of logbooks and when someone requests a login account AND elects to register with all of the logbooks, the resulting URL is apparently too long for browsers to handle when the admins click on the link embedded in the email notification. For example, FireFox (latest ver) appears to truncate the URL *after* submission (the correct URL is there before submission).
My question: Is it possible to limit - or remove - the checkboxes that the user can select during registration? I realize that this is a browser issue but I doubt I can persuade those guys to fix FireFox.
Thanks. |
I changed the current SVN version (#1909) to show only the list of logbooks if there are ten or less logbooks, in order not to make the URL too long. On the activation by the administrator, the list of subscribed logbooks appears as previously, but all are unchecked. So it's the task of the administrator to enable subscriptions or not. |
Re: Too many logbooks during user registration, posted by Steve Jones on Tue Sep 11 15:30:11 2007
|
Stefan Ritt wrote: |
Steve Jones wrote: | Stefan, we require registration with elog. We have quite a number of logbooks and when someone requests a login account AND elects to register with all of the logbooks, the resulting URL is apparently too long for browsers to handle when the admins click on the link embedded in the email notification. For example, FireFox (latest ver) appears to truncate the URL *after* submission (the correct URL is there before submission).
My question: Is it possible to limit - or remove - the checkboxes that the user can select during registration? I realize that this is a browser issue but I doubt I can persuade those guys to fix FireFox.
Thanks. |
I changed the current SVN version (#1909) to show only the list of logbooks if there are ten or less logbooks, in order not to make the URL too long. On the activation by the administrator, the list of subscribed logbooks appears as previously, but all are unchecked. So it's the task of the administrator to enable subscriptions or not. |
Quote: | So the list is shown to the one requesting the registration? Would it be possible to have an option that, when selected, simply did not list any logbooks? I can see a customer becoming confused if they did not see their logbook listed. Just turn off the selection completely. Otherwise, this will work but I fear will generate more questions as in "Why isn't logbook <blah> listed?"
Thanks!
|
|
Re: Too many logbooks during user registration, posted by Stefan Ritt on Tue Sep 11 21:25:11 2007
|
Steve Jones wrote: | So the list is shown to the one requesting the registration? Would it be possible to have an option that, when selected, simply did not list any logbooks? I can see a customer becoming confused if they did not see their logbook listed. Just turn off the selection completely. Otherwise, this will work but I fear will generate more questions as in "Why isn't logbook <blah> listed?" |
I agree, that's inconsistent. So I removed the logbook list completely (SVN revision 1914) and added a note on the user notification that they should click 'config' to subscribe to any logbook. |
Re: Time Display Format, posted by james Goedsir on Wed Sep 2 09:39:20 2009
|
james Goedsir wrote: |
My Time field is displayed i a 12 Hour format I would like to change it to 24 Hours, can someone advised how it can be done
|
Sorted no problem |
Re: Thumbnails not working, posted by Stefan Ritt on Wed Jul 23 15:14:58 2008
|
Kevin O'Sullivan wrote: |
I get the following error where thumbnails should go: Cannot create thumbnail, please check ImageMagick installation.
I restarted elog and check the log, it does in fact detect ImageMagick and it does have the most recent version. I'm running ubuntu 2.6.24-19-server. Is there something else I should be checking?
|
Try the following:
- Put logfile = elog.log into your elogd.cfg
- Upload an image to get the error
- Examine your elog.log file
You should get something like:
23-Jul-2008 15:10:38 [] Server listening on port 8080 ..
23-Jul-2008 15:10:52 [stefan@127.0.0.1] {demo} SHELL "convert "logbooks\demo\080723_151052_Capture.png" "logbooks\demo\080723_151052_Capture.png.png""
In your logfile. Now try the "convert" command manually under the same account elogd is running. Possible reasons for problems are:
- The "convert" command is not in your path or links to another program. Unfortunately ImageMagick chose a pretty standard name for this program
- The account under which elogd is running does not have write access to the logbook directory
- converts wants to call ghostscript for PDF conversion, but it is not installed
- ...
|
Re: Threaded emails, posted by Stefan Ritt on Fri Nov 21 11:28:31 2008
|
Paul O'Shaughnessy wrote: |
Can you email a thread of log entries. I think this would be a very useful function, which would enable the logger in effect to send an entire history of a particular issue to the interested parties.
|
Well, kind of. If you notify yourself with elog entries, they are grouped in a thread in your email application. From there you can forward the thread to someone. Or you forward the link to one entry in the thread, and if the link is the opened, the interested parties see the whole link. Sending the whole thread inside elog is however not possible. |
|