Salut. J’ai mis à jour Discourse Image et Discourse il y a quelques heures en utilisant ./launcher rebuild app. Pendant le processus, j’ai rencontré des erreurs qui ont été corrigées en supprimant les lignes d’installation de plugins obsolètes de app.yml. Aucune autre modification de configuration n’a été apportée. Maintenant, j’ai un conteneur Docker en cours d’exécution qui écoute sur les ports TCP 80 et 443, mais nginx dans le conteneur refuse d’accepter les connexions SSL/TLS. Le fichier error.log à l’intérieur du conteneur ne montre aucune erreur avec les certificats, access.log ne montre aucune requête, telnet sur le port 443 montre un refus de connexion, l’accès HTTP sur le port TCP 80 fonctionne, mais nous avons des problèmes d’authentification SSO (probablement un problème avec les cookies sécurisés uniquement). Le redémarrage du lanceur (launcher) et discourse-doctor n’aident pas. Le redémarrage de nginx à l’intérieur du conteneur n’aide pas non plus. Où chercher maintenant et quoi faire ?
cela se produira si ufw est activé et non configuré pour autoriser les connexions sur le port https 443
Modifier : vous aurez besoin que ce port soit ouvert pour que mail-receiver fonctionne correctement
Je n’ai rien fait avec la configuration de ufw, iptables, etc. Le port était exactement ouvert avant la mise à jour. La configuration pourrait-elle être modifiée avec le processus de mise à jour de Discourse ?
Absolument, le conteneur Docker de Discourse devrait se placer devant ufw. Cependant, ne pas avoir le port 443 ouvert cause des problèmes de communication entre différents conteneurs ou des problèmes avec telnet.
Que renvoie .\launcher logs app ? (vous pouvez utiliser Word pour masquer votre nom de domaine, etc.)
Accédez-vous à votre serveur via PuTTy ou un autre client SSH ? ouvrez-vous le port 22 ?
Je constate également ce problème sur une instance auto-hébergée après une récente reconstruction. Aucune modification de configuration, à l’exception de la reconstruction elle-même. Je peux accéder au serveur via SSH et voici la sortie de ./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
Le conteneur Docker est en cours d’exécution, comme en témoigne ma sortie de docker ps. (ID du conteneur masqué)
local_discourse/app “/sbin/boot” 16 minutes ago Up 16 minutes 0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:443->443/tcp, [::]:443->443/tcp, 0.0.0.0:5432->5432/tcp, [::]:5432->5432/tcp app
Une note importante à souligner, nous n’utilisons pas openSSL pour nos certificats, en raison de la nécessité d’un émetteur spécifique. Cependant, ce certificat n’a pas changé et fonctionnait correctement avant la reconstruction.
Il semble y avoir une inadéquation entre l’IP attendue par nginx (IP locale) et celle trouvée attribuée au conteneur. Il semble que le conteneur puisse fonctionner en mode bridge ? Voici les paramètres réseau du conteneur.
"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
}
}
}
Il semble qu’une nouvelle PR ait introduit une nouvelle exigence de variable dans app.yml. Cela ne semble pas encore documenté, mais vous devez ajouter ENABLE_SSL: true à votre fichier app.yml.
Cela ressemble à un bug. Le SSL est activé par défaut depuis quelques années. Pouvez-vous lier au commit ?
Je le vois dans le code du modèle SSL. Je manque peut-être quelque chose car je suis sur mon téléphone et GitHub a des problèmes, mais il semble que cela va casser tous les sites auto-hébergés.
C’est celui-ci, certainement un bug involontaire lors de la fusion de la configuration ssl-on-boot :
J’ai mis à jour ENABLE_SSL à 1 par défaut ici :
Merci d’avoir repéré ça @tanya_byrne
Bien sauvé, Jeff ! Merci !
Merci pour la correction @featheredtoast
Merci, les gars. Nous avons également résolu le problème.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.