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 etc. and all work fine. As written before, also the "example" logbook works (without password protection).

I also tried `/` at the end of the URL but it has no effect.

I am pretty clueless currently...

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.

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.

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

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

We obtained a certificate from let's encrypt in order to replace the self signed certificate provided with elog. We copied the new certificates replacing the older server.crt

The problem is that when restarted elog raises an error related to the fact it is looking for server.crt and it doesn't find it anymore.

I searched in elog config file in order to find a way to indicate the new certificate but I didn't find how to manage this issue.

Any suggestion?

Hi Giuseppe,

The new certificate files should be copy under ssl folder (/usr/local/elog/ssl or /usr/share/elog/ssl by example, closed to templates and script directories) in place of the embedded (autosigned) certificate files enclosed with ELOG source.

It seems that there is no parameter to set a custom path.

SSL = <0 | 1>
Turn on Secure Socket Layer transport. If SSL is on, one can connect via https://... to the elogd daemon. If the URL = directive is used, make sure to use https://... instead of http://... there. The ELOG distribution contains a simple self-signed certificate in the ssl subdirectory. One can replace this certificate and key with a real ceritficate to avoid browser pop-up windows warning about the self-signed certificate. The default for this option is 0.

Hi Laurent,

thanks very much! Probably I've copied the certificate in the wrong directory. I'll try ASAP