Hallo. Ik heb Discourse Image en Discourse een paar uur geleden bijgewerkt met ./launcher rebuild app. Tijdens het proces kreeg ik enkele fouten die werden opgelost door verouderde plugin-installatielijnen uit app.yml te verwijderen. Er zijn geen andere configuratiewijzigingen aangebracht. Nu heb ik een draaiende Docker-container die luistert naar TCP-poorten 80 en 443, maar nginx in de container weigert SSL/TLS-verbindingen te accepteren. error.log binnen de container toont geen fouten, access.log toont geen verzoeken, telnet naar poort 443 toont verbindingsweigering, HTTP-toegang op TCP-poort 80 werkt, maar we hebben problemen met SSO-authenticatie (waarschijnlijk is het een probleem met alleen-veilige cookies). Launcher restart en discourse-doctor helpen niet. Het opnieuw starten van nginx binnen de container helpt ook niet. Waar moet ik nu kijken en wat moet ik doen?
it will do if ufw is enabled and not set-up to allow connections on https port 443
Edit: youâll need this port to be open for mail-receiver to work properly
Ik heb niets gedaan met de configuratie van ufw, iptables, etc. De poort was precies geopend vóór de update. Kan de configuratie zijn gewijzigd met het Discourse-updateproces?
it absolutely could, Discourse docker container should step in front of ufw. However, not have prt 443 open causes issues in cross-talk between different containers or issue with telnet
what deos .\launcher logs app return? (you can use MS word to redact your domain name, etc.)
do you access your server through PuTTy or another SSH client? opening port 22 ?
Ik zie dit probleem ook op een zelf-gehoste instantie na een recente rebuild. Geen wijzigingen in de configuratie behalve de rebuild zelf. Ik kan de server benaderen via SSH en dit is de output van ./launcher logs app.
run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
run-parts: executing /etc/runit/1.d/install-ssl
Started runsvdir, PID is 45
ok: run: redis: (pid 55) 0s
supervisor pid: 53 unicorn pid: 76
Docker container draait zoals blijkt uit mijn output van docker ps. (container id geredigeerd)
local_discourse/app â/sbin/bootâ 16 minuten geleden Omhoog 16 minuten 0.0.0.0:80-\u003e80/tcp, [::]:80-\u003e80/tcp, 0.0.0.0:443-\u003e443/tcp, [::]:443-\u003e443/tcp, 0.0.0.0:5432-\u003e5432/tcp, [::]:5432-\u003e5432/tcp app
Een belangrijk punt om te benadrukken, we gebruiken LetsEncrypt niet voor onze certificaten, vanwege de vereiste specifieke issuer. Dit certificaat is echter niet gewijzigd en werkte prima voor de rebuild (en certificaten die op deze manier zijn uitgegeven, werken al jaren op onze instanties).
Er lijkt een discrepantie te zijn tussen het IP dat nginx verwacht (lokaal IP 127.0.0.1) en degene die aan de container is toegewezen. Het lijkt erop dat de container in bridge-modus draait? Hier zijn de netwerkinstellingen van de container. (Let op: dit logboek is van toen ik dit probleem vrijdag voor het eerst identificeerde en begon te onderzoeken)
"Labels": {
"org.opencontainers.image.created": "2025-07-25T21:40:36+00:00"
},
"NetworkSettings": {
"Bridge": "",
"SandboxID": "[REDACTED]",
"SandboxKey": "[REDACTED]",
"Ports": {
"443/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "443"
},
{
"HostIp": "::",
"HostPort": "443"
}
],
"5432/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "5432"
},
{
"HostIp": "::",
"HostPort": "5432"
}
],
"80/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "80"
},
{
"HostIp": "::",
"HostPort": "80"
}
]
},
"HairpinMode": false,
"LinkLocalIPv6Address": "",
"LinkLocalIPv6PrefixLen": 0,
"SecondaryIPAddresses": null,
"SecondaryIPv6Addresses": null,
"EndpointID": "[REDACTED]",
"Gateway": "172.17.0.1",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"IPAddress": "172.17.0.2",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"MacAddress": "[REDACTED]",
"Networks": {
"bridge": {
"IPAMConfig": null,
"Links": null,
"Aliases": null,
"MacAddress": "[REDACTED]",
"DriverOpts": null,
"GwPriority": 0,
"NetworkID": "[REDACTED]",
"EndpointID": "[REDACTED]",
"Gateway": "172.17.0.1",
"IPAddress": "172.17.0.2",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"DNSNames": null
}
}
}
Er lijkt een recent samengevoegde PR te zijn die een nieuwe var-vereiste heeft geĂŻntroduceerd voor app.yml. Dit lijkt nog niet gedocumenteerd te zijn, maar je moet ENABLE_SSL: true toevoegen aan je app.yml-bestand.
That sounds like a bug. Ssl has been on by default for some years. Can you link to the commit?
I see it in the code in the ssl template. I may be missing something since Iâm in my phone and github is having issues, but it looks like itâll break every self hosted site.
Itâs this one here, definitely an unintended bug with merging the ssl-on-boot configuration:
Iâve updated the ENABLE_SSL to be 1 by default here:
Thanks for the catch @tanya_byrne
Goed gered, Jeff! Bedankt!
Bedankt voor de oplossing @featheredtoast
Bedankt, jongens. We hebben het probleem ook opgelost.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.