Ciao. Ho aggiornato Discourse Image e Discourse alcune ore fa usando ./launcher rebuild app. Durante il processo, ho riscontrato alcuni errori che sono stati risolti rimuovendo le righe deprecate di installazione dei plugin da app.yml. Non sono state apportate altre modifiche alla configurazione. Ora ho un container Docker in esecuzione che ascolta sulle porte TCP 80 e 443, ma nginx nel container rifiuta di accettare connessioni SSL/TLS. Il file error.log all’interno del container non mostra errori con i certificati, access.log non mostra richieste, telnet alla porta 443 mostra il rifiuto della connessione, l’accesso HTTP sulla porta TCP 80 funziona, ma abbiamo problemi di autenticazione SSO (probabilmente è un problema con i cookie sicuri). Il riavvio del launcher e discourse-doctor non aiutano. Anche il riavvio di nginx all’interno del container non aiuta. Dove devo guardare ora e cosa devo fare?
lo farà se ufw è abilitato e non configurato per consentire connessioni sulla porta https 443
Modifica: avrai bisogno che questa porta sia aperta affinché mail-receiver funzioni correttamente
Non ho fatto nulla con la configurazione di ufw, iptables, ecc. La porta era esattamente aperta prima dell’aggiornamento. La configurazione potrebbe essere cambiata con il processo di aggiornamento di Discourse?
Assolutamente sì, il container Docker di Discourse dovrebbe posizionarsi davanti a ufw. Tuttavia, non avere la porta 443 aperta causa problemi nella comunicazione tra diversi container o problemi con telnet.
cosa restituisce .\launcher logs app? (puoi usare MS Word per censurare il tuo nome di dominio, ecc.)
accedi al tuo server tramite PuTTy o un altro client SSH? apri la porta 22?
Sto riscontrando questo problema anche su un’istanza self-hosted dopo una recente ricostruzione. Nessuna modifica alla configurazione tranne la ricostruzione stessa. Posso accedere al server tramite SSH e questo è l’output di ./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
Il container Docker è in esecuzione come dimostrato dall’output di docker ps. (ID container oscurato)
local_discourse/app “/sbin/boot” 16 minuti fa Su 16 minuti 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
Una nota importante da evidenziare, non utilizziamo openSSL per i nostri certificati, a causa della necessità di un emittente specifico. Tuttavia, questo certificato non è cambiato e funzionava correttamente prima della ricostruzione.
Sembra esserci una discrepanza tra l’IP che nginx si aspetta (IP locale) e quello trovato assegnato al container. Sembra che il container possa essere in esecuzione in modalità bridge? Ecco le impostazioni di rete dal container.
"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
}
}
}
Sembra che una nuova PR abbia introdotto un nuovo requisito di variabile in app.yml. Questo non sembra essere ancora documentato, ma è necessario aggiungere ENABLE_SSL: true al file app.yml.
Sembra un bug. SSL è attivo per impostazione predefinita da alcuni anni. Puoi collegarti al commit?
Lo vedo nel codice nel template SSL. Potrei perdermi qualcosa dato che sono sul mio telefono e GitHub ha problemi, ma sembra che romperà ogni sito self-hosted.
È questo qui, decisamente un bug non intenzionale durante l’unione della configurazione ssl-on-boot:
Ho aggiornato ENABLE_SSL a 1 per impostazione predefinita qui:
Grazie per averlo notato @tanya_byrne
Ottimo salvataggio, Jeff! Grazie!
Grazie per la correzione @featheredtoast
Grazie ragazzi. Abbiamo risolto anche il problema.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.