Hallo. Ich habe vor einigen Stunden Discourse Image und Discourse mit ./launcher rebuild app aktualisiert. Dabei sind einige Fehler aufgetreten, die durch das Entfernen veralteter Plugin-Installationszeilen aus app.yml behoben wurden. Es wurden keine weiteren Konfigurationsänderungen vorgenommen. Jetzt habe ich einen laufenden Docker-Container, der an die TCP-Ports 80 und 443 gebunden ist, aber Nginx im Container weigert sich, SSL/TLS-Verbindungen anzunehmen. Die error.log-Datei im Container zeigt keine Fehler mit Zertifikaten, access.log zeigt keine Anfragen, Telnet zum Port 443 zeigt eine Verbindungsverweigerung, HTTP-Zugriff am TCP-Port 80 funktioniert, aber wir haben Probleme mit der SSO-Authentifizierung (wahrscheinlich ein Problem mit nur sicheren Cookies). Launcher-Neustart und discourse-doctor helfen nicht. Ein Neustart von Nginx im Container hilft ebenfalls nicht. Wo soll ich jetzt suchen und was soll ich tun?
das wird passieren, wenn ufw aktiviert ist und nicht so eingerichtet ist, dass Verbindungen zum HTTPS-Port 443 zugelassen werden
Bearbeiten: Sie benötigen diesen Port, damit mail-receiver ordnungsgemäß funktioniert
Ich habe nichts mit der Konfiguration von ufw, iptables usw. gemacht. Der Port war vor dem Update genau geöffnet. Könnte die Konfiguration durch den Discourse-Aktualisierungsprozess geändert worden sein?
Das könnte es absolut, der Discourse-Docker-Container sollte sich vor ufw schalten. Das Nicht-Öffnen von Port 443 verursacht jedoch Probleme bei der Kommunikation zwischen verschiedenen Containern oder Probleme mit telnet.
Was gibt .\launcher logs app zurück? (Sie können MS Word verwenden, um Ihren Domainnamen usw. zu schwärzen.)
Greifen Sie über PuTTy oder einen anderen SSH-Client auf Ihren Server zu? Port 22 geöffnet?
Ich sehe dieses Problem auch auf einer selbst gehosteten Instanz nach einem kürzlichen Rebuild. Keine Änderungen in der Konfiguration außer dem Rebuild selbst. Ich kann auf den Server über SSH zugreifen und dies ist die Ausgabe von ./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
Der Docker-Container läuft, wie meine Ausgabe von docker ps beweist. (Container-ID geschwärzt)
local_discourse/app “/sbin/boot” 16 minutes ago Up 16 minutes 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
Eine wichtige Anmerkung: Wir verwenden OpenSSL nicht für unsere Zertifikate, da wir einen bestimmten Aussteller benötigen. Dieses Zertifikat hat sich jedoch nicht geändert und funktionierte vor dem Rebuild einwandfrei.
Es scheint eine Diskrepanz zwischen der IP, die Nginx erwartet (lokale IP), und der IP zu geben, die dem Container zugewiesen ist. Es sieht so aus, als ob der Container im Bridge-Modus läuft? Hier sind die Netzwerkeinstellungen des Containers.
"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
}
}
}
Es scheint, dass ein neuer PR eine neue Variablenanforderung in die app.yml eingeführt hat. Dies scheint noch nicht dokumentiert zu sein, aber Sie müssen ENABLE_SSL: true zu Ihrer app.yml-Datei hinzufügen.
Das klingt nach einem Fehler. SSL ist seit einigen Jahren standardmäßig aktiviert. Können Sie den Commit verlinken?
Ich sehe es im Code in der SSL-Vorlage. Möglicherweise übersehe ich etwas, da ich mich gerade auf meinem Handy befinde und GitHub Probleme hat, aber es sieht so aus, als würde es jede selbst gehostete Website kaputt machen.
Das ist dieser hier, definitiv ein unbeabsichtigter Fehler beim Zusammenführen der ssl-on-boot-Konfiguration:
Ich habe ENABLE_SSL hier standardmäßig auf 1 gesetzt:
Danke für den Hinweis @tanya_byrne
Guter Save, Jeff! Danke!
Danke für die Korrektur @featheredtoast
Danke, Leute. Wir haben das Problem auch gelöst.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.