Wikibase Homepage not available

[ravikcs]

The proxy forwards traffic to port 80 of the VM.

According to the docker-compose.yml configuration, the reverse proxy (Traefik) listens on port 80 of the VM and appears to handle all traffic, including SSL encryption.

Additionally, the application (Wikibase) is also configured to listen on port 80. This raises the question: should the application be directly listening on the same port as the reverse proxy?

In the browser, we encounter a "Too many redirects" error. Upon investigating the logs using docker logs, we observe issues with Let's Encrypt SSL certificate creation, likely due to the setup behind the external proxy. However, since Traefik manages SSL certificate creation and listens on port 80, it should theoretically handle the process correctly with Let's Encrypt.

[rti]

Hi @ravikcs,

Thanks a lot for contacting us.

should the application be directly listening on the same port as the reverse proxy?

It is true that both, the wikibase container and the reverse proxy container listen on port 80. But this happens on the virtual network interfaces of the containers, both have their own, so there is no conflict. Only the reverse proxy port 80 gets forwarded to the host machines port 80 and is therefore available to the outside world. The wikibase container port 80 is only available internally to the virtual network of the docker compose stack.

In the browser, we encounter a "Too many redirects" error.

issues with Let's Encrypt SSL certificate creation

I suspect this could be two different things. Could you please share the logs, your .env file, and any further adjustments you might have done?

For Traefik to successfully obtain certificates from LetsEncrypt, it needs:

• A public IP address
• A domain name registered in public DNS and set in .env *_PUBLIC_HOST
• The domain names DNS A record pointing to the public IP address
• A valid E-Mail address set in .env MW_ADMIN_EMAIL

Best, Robert

[ravikcs]

Hello @rti ,

Thanks for the follow-up. I have attached the .env file for your reference. Also, the logs I get for Traefik:

2024-09-05T08:05:09Z ERR Unable to obtain ACME certificate for domains error="cannot get ACME client ACME challenge not specified, please select TLS or HTTP or DNS Challenge" ACME CA=https://acme-v02.api.letsencrypt.org/directory acmeCA=https://acme-v02.api.letsencrypt.org/directory domains=["metabelgica.ilabt.imec.be"] providerName=letsencrypt.acme routerName=wikibase@docker rule=Host(metabelgica.ilabt.imec.be)

env_file.txt

[rti]

Hi @ravikcs,

Thanks a lot for the information!

You need to specify three different hostnames in your .env file. WIKIBASE_PUBLIC_HOST, WDQS_FRONTEND_PUBLIC_HOST and QUICKSTATEMENTS_PUBLIC_HOST all need to be distinct, but can be subdomains. E.g. query.metabelgica.ilabt.imec.be should work. But of cause you need to add the respective DNS records as well.

Traefik complaining about the challenge type missing is weird. It is clearly stated here: https://github.com/wmde/wikibase-release-pipeline/blob/66d59fafdbc701bc0694120564733d7ccd116cbf/deploy/docker-compose.yml#L189

Maybe making the domain names distinct prevents Traefik from getting confused and already helps?

Did you make any other changes besides the .env file?

Best, Robert

[SvenLieber]

Hi @rti ,

many thanks already for your quick replies! I am also involved with the infrastructure setup together with @ravikcs .

I was just about to ask about those three _HOST variables when you already answered. Does this need to be domains? I was wondering if we could have something like metabelgica.ilabt.imec.be/query, but I remember some issues with Let's Encrypt then as well.

Thanks for pointing us to the DNS issue. I'm not an expert on that matter, but it seems that the DNS is okay: https://mxtoolbox.com/SuperTool.aspx?action=a%3ametabelgica.ilabt.imec.be&run=toolpage

As far as I know we did not make any other changes than the .env file. I have seen that just a few days ago you changed the port mapping such that the wikibase container no longer has a 8880:80 port mapping, only traefik as you mentioned above. We will now try everything again with the updated config.

For the rest I only know that the VM on which we run the docker setup is behind a reverse proxy (ilabt.imec.be (not under our control) that forwards all traffic on port 80. If necessary we can ping the ICT team managing this to perform needed changes, for example for DNS records.

[rti]

Hi @SvenLieber,

Thanks for your post.

Does this need to be domains? I was wondering if we could have something like metabelgica.ilabt.imec.be/query, but I remember some issues with Let's Encrypt then as well.

Yes, at the moment this can only be domain names. Running from a sub folder is unfortunately not trivial, but definitely worth a feature request, ideally at https://phabricator.wikimedia.org/maniphest/task/edit/form/125/

Yes, DNS seems properly forwarding to idlab.proxy.ilabt.imec.be which is probably the reverse proxy you mentioned.

The port mapping change is probably unrelated. I'd actually suggest to not use the main branch. This is where our development happens at the moment. Better to check out deploy-3 which contains our latest stable release.

Best, Robert

[SvenLieber]

Hi @rti ,

the ICT department responsible for our proxy solved the issue. Apparently their proxy does exactly what traefik is supposed to do. So they created new DNS records, configured their proxy, configured SSL correctly and we removed all traefik parts from the config.

Thus if there are no other questions or remarks this issue can be closed according to me.

Many thanks!

Best, Sven

[rti]

Glad to hear that. Thanks a lot for reporting back.

Also thanks for describing your use case. This helps product design on our side.

Best Robert