⚠ Le port 443 de cet ordinateur ne semble pas accessible via le nom d'hôte : metabolism.logophilia.eu ----

[Idoru_Toei]

Bonjour, je rencontre l’erreur mentionnée dans l’objet (voir également ci-dessous) après avoir obtenu le message « ✓ Les ports 80 et 443 sont libres pour utilisation » lors de l’initialisation. Le DNS est configuré, SSL est configuré, le site web est accessible depuis l’extérieur (faites le test vous-même), et la sortie de curl (tronquée) est ajoutée ci-dessous, ce qui signifie qu’il est accessible depuis la machine elle-même. Je n’ai plus d’idées sur ce qui manque. Merci pour tout éclairage.

PS. AlmaLinux 10.2 - 6.12.0-211.7.4.el10_2.x86_64

# ./discourse-setup  
→ Vérification des mises à jour de l'image de l'assistant de configuration... 
→ Démarrage de l'assistant de configuration Discourse... 
 
 
 ___  _ 
|   \(_)___ __ ___ _  _ _ _ ___ ___ 
| |) | (_-< / _/ _ \ || | '_(-< / -_) 
|___/|_/__/\__\___/\_,_|_| /__/\___| 
                       Assistant de configuration 
 
 
→ Cet assistant vous aidera à configurer votre installation Discourse. 
→ Appuyez sur Ctrl+C à tout moment pour annuler. 
 
── Vérifications système ── 
 
[1/5] Vérification des exigences système 
✓ Exécuté en tant que root 
✓ Docker est disponible 
✓ Mémoire : 8 Go, CPU : 4 cœurs 
 
── Configuration ── 
 
[2/5] Préparation de la configuration 
✓ Les ports 80 et 443 sont libres pour utilisation 
→ Création d'une nouvelle configuration... 
→ Création d'une nouvelle configuration à partir du modèle... 
 
── Paramètres du site ── 
 
[3/5] Saisissez les détails de votre site 
 
Adresse e-mail pour le(s) compte(s) administrateur ? 
eduard.pech@logophilia.eu▌ 
 
Avez-vous un nom de domaine pour votre Discourse ? 
▸ Oui      Non 
 
Nom d'hôte pour votre Discourse ? 
metabolism.logophilia.eu▌ 
 
Configurer SMTP pour l'envoi d'e-mails ? (Nécessite des identifiants SMTP) 
  Oui    ▸ Non 
 
 
── Révision de la configuration ── 
 
 
╭────────────────────────────────────────────╮ 
│                                            │ 
│  Nom d'hôte       metabolism.logophilia.eu   │ 
│  E-mail admin    eduard.pech@logophilia.eu  │ 
│  SMTP           (non configuré)           │ 
│  Let's Encrypt  Activé                    │ 
│                                            │ 
╰────────────────────────────────────────────╯ 
 
 
Est-ce que cela semble correct ? 
▸ Oui      Non 
→ 8 Go de mémoire et 4 cœurs CPU détectés 
→ Définition de db_shared_buffers = 2048 Mo 
→ Définition de UNICORN_WORKERS = 8 
 
── Validation réseau ── 
 
[4/5] Vérification de la configuration du domaine 
→ Vérification de votre nom de domaine... 
⚠ Le port 443 de cet ordinateur ne semble pas être accessible via le nom d'hôte : metabolism.logophilia.eu 
⚠ La connexion à http://metabolism.logophilia.eu (port 80) échoue également. 
 
Cela suggère que metabolism.logophilia.eu se résout vers une adresse IP qui ne permet pas d'atteindre 
cette machine où vous installez Discourse. 
 
La première chose à faire est de confirmer que metabolism.logophilia.eu se résout vers l'adresse IP de ce serveur. 
Vous le faites généralement au même endroit où vous avez acheté le domaine. 
 
Si vous êtes certain que l'adresse IP se résout correctement, il pourrait s'agir d'un problème de pare-feu. 
Une recherche web sur « ouvrir les ports VOTRE SERVICE CLOUD » pourrait aider. 
 
Cet outil est conçu uniquement pour les installations les plus standard. Si vous ne parvenez pas à résoudre 
le problème ci-dessus, vous devrez modifier vous-même containers/app.yml puis taper : 
 
    ./launcher rebuild app 
 
 
✗ Vérification DNS échouée pour metabolism.logophilia.eu 
[root@logophilia discourse]# dig metabolism.logophilia.eu 
 
; <<>> DiG 9.18.33 <<>> metabolism.logophilia.eu 
;; options globales : +cmd 
;; Réponse reçue : 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36726 
;; drapeaux: qr rd ra; REQUÊTE: 1, RÉPONSE: 1, AUTORITÉ: 0, SUPPLÉMENTAIRE: 1 
 
;; SECTION PSEUDO OPT : 
; EDNS: version: 0, drapeaux:; udp: 512 
;; SECTION QUESTION : 
;metabolism.logophilia.eu.      IN      A 
 
;; SECTION RÉPONSE : 
metabolism.logophilia.eu. 300   IN      A       75.119.134.68 
 
;; Temps de requête : 8 msec 
;; SERVEUR : 213.136.95.10#53(213.136.95.10) (UDP) 
;; QUAND : Sam 06 juin 04:52:23 CEST 2026 
;; TAILLE MSG reçue : 69 
 
[root@logophilia discourse]# curl -v https://metabolism.logophilia.eu 
* Hôte metabolism.logophilia.eu:443 résolu. 
* IPv6 : (aucun) 
* IPv4 : 75.119.134.68 
*   Tentative de connexion à 75.119.134.68:443... 
* ALPN : curl propose h2,http/1.1 
* TLSv1.3 (SORTIE), poignée de main TLS, Client hello (1) : 
*  CAfile : /etc/pki/tls/certs/ca-bundle.crt 
*  CApath : aucun 
* TLSv1.3 (ENTRÉE), poignée de main TLS, Server hello (2) : 
* TLSv1.3 (ENTRÉE), changement de chiffrement TLS, Change cipher spec (1) : 
* TLSv1.3 (ENTRÉE), poignée de main TLS, Encrypted Extensions (8) : 
* TLSv1.3 (ENTRÉE), poignée de main TLS, Certificate (11) : 
* TLSv1.3 (ENTRÉE), poignée de main TLS, CERT verify (15) : 
* TLSv1.3 (ENTRÉE), poignée de main TLS, Finished (20) : 
* TLSv1.3 (SORTIE), changement de chiffrement TLS, Change cipher spec (1) : 
* TLSv1.3 (SORTIE), poignée de main TLS, Finished (20) : 
* Connexion SSL utilisant TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / RSASSA-PSS 
* ALPN : le serveur a accepté http/1.1 
* Certificat du serveur : 
*  sujet : CN=metabolism.logophilia.eu 
*  date de début : 6 juin 00:26:43 2026 GMT 
*  date d'expiration : 4 sept. 00:26:42 2026 GMT 
*  subjectAltName : l'hôte « metabolism.logophilia.eu » correspond au certificat « metabolism.logophilia.eu » 
*  émetteur : C=US; O=Let's Encrypt; CN=YR2 
*  Vérification du certificat SSL OK. 
*   Niveau de certificat 0 : Type de clé publique RSA (2048/112 Bits/secBits), signé avec sha256WithRSAEncryption 
*   Niveau de certificat 1 : Type de clé publique RSA (2048/112 Bits/secBits), signé avec sha256WithRSAEncryption 
*   Niveau de certificat 2 : Type de clé publique RSA (4096/152 Bits/secBits), signé avec sha256WithRSAEncryption 
*   Niveau de certificat 3 : Type de clé publique RSA (4096/152 Bits/secBits), signé avec sha256WithRSAEncryption 
* Connecté à metabolism.logophilia.eu (75.119.134.68) port 443 
* utilisation de HTTP/1.x 
> GET / HTTP/1.1 
> Hôte : metabolism.logophilia.eu 
> User-Agent : curl/8.12.1 
> Accept : */* 
>  
* Requête complètement envoyée 
* TLSv1.3 (ENTRÉE), poignée de main TLS, Newsession Ticket (4) : 
* TLSv1.3 (ENTRÉE), poignée de main TLS, Newsession Ticket (4) : 
< HTTP/1.1 200 OK 
< Date : Sam, 06 juin 2026 02:52:36 GMT 
< Serveur : Apache 
< Dernière-modification : Sam, 06 juin 2026 01:25:19 GMT 
< ETag : "1325f-6538ba67ff892" 
< Accept-Ranges : octets 
< Content-Length : 78431 
< Content-Type : text/html; charset=UTF-8 
<  
<!doctype html> 
<html lang="en" data-bs-theme="auto"> 
<head> 
  <title> 
    metabolism.logophilia.eu &mdash;  Page de bienvenue du domaine pour  </title> 
  <meta charset="utf-8">
……

[darkpixlz (Pyx)]

Bonjour,

J’ai vérifié votre site web moi-même. Il semble que votre hébergeur utilise le port 443 pour afficher cette page de bienvenue. Vous devrez trouver comment libérer entièrement les ports 443 et 80 afin que Discourse puisse les contrôler.

[Idoru_Toei]

Je l’ai déjà fait. Le VPS est géré avec Virtualmin, et il s’agit simplement d’une case à cocher. Malheureusement, lorsque je décoche « site web activé », je ne peux plus faire de requête curl sur les ports 443/80 depuis l’hôte, et la configuration de Discourse continue de signaler la même erreur. J’ai donc pensé réactiver le site web, afin de pouvoir au moins montrer que la poignée de main SSL fonctionne.
Comme vous pouvez le voir dans mon message initial, la configuration de Discourse indique en réalité (au départ) que le port 443 est disponible. C’est ma première installation, et j’interpréterais cela comme : tout est au vert. Alors pourquoi la configuration « change-t-elle d’avis » ?
Quoi qu’il en soit, je n’ai pas vraiment besoin de comprendre chaque détail. Je précise simplement : avec Apache désactivé sur le sous-domaine, le résultat de la configuration de Discourse reste le même.

Merci de prendre le temps de répondre. Si je peux fournir d’autres éléments pour clarifier la situation, je ferai (presque) n’importe quoi.

[darkpixlz (Pyx)]

@Idoru_Toei

et la configuration de Discourse signale toujours la même erreur

J’ai rencontré le même problème ici (sur mon propre serveur à la maison) :

SKIP_CONNECTION_TEST does not work on install-discourse script

I’ve tried basically everything I can imagine and nothing is working so I can only infer that this is a bug. Things I’ve tried: SKIP_CONNECTION_TEST=1 ./install-discourse export SKIP_CONNECTION_TEST=1; ./install-discourse Commenting out the line in my local discourse-setup copy yet it still whines that there is no port 443 (which is not an issue because I am under a reverse proxy): root@discourse:~/discourse_docker# ./install-discourse Discourse One-Line Installer → Docker is already ins…

Je pense que la solution consiste simplement à faire ceci si vous êtes absolument certain que le DNS est correct et que vos ports fonctionnent comme prévu.

./install-discourse --skip-connection-test

[Idoru_Toei]

Merci, cela semble avoir fonctionné !

Le script va au-delà de 5/5 maintenant et semble télécharger / installer beaucoup d’éléments supplémentaires. Le certificat SSL est désormais erroné ; je suppose qu’il attend soit l’expiration du TTL, soit que tout soit correct une fois la configuration terminée.

Bien que je n’aie vraiment aucune idée de Discours, de Docker, ou même de Ruby… la partie DNS ne pose jamais de problème Merci encore !

[Idoru_Toei]

Je vois que cela a déjà été marqué comme solution. Mais j’ai une dernière question, si je puis.

Je sais que Postgres est nécessaire, mais cela n’est pas mentionné sur

https://github.com/discourse/discourse/blob/main/docs/INSTALL-cloud.md

J’ai donc pensé que l’image Docker incluait Postgres déjà installé. Pourriez-vous s’il vous plaît préciser si je dois installer Postgres sur le VPS ? Parce que les instructions d’installation ne le mentionnent pas.

… ou peut-être que Docker inclut Postgres, mais que le script a échoué d’une manière ou d’une autre ? Parce qu’il s’arrête à la fin :

........
I, [2026-06-06T04:23:49.114769 #1]  INFO -- : File > /etc/runit/1.d/install-ssl  chmod: +x  chown: 
I, [2026-06-06T04:23:49.114999 #1]  INFO -- : Remplacement de # après ssl par if [ -z "$DISABLE_LETSENCRYPT" ] || [ -n "$ENABLE_LETSENCRYPT" ]; then
  /usr/local/bin/configure-ssl
  exec /usr/local/bin/configure-letsencrypt
fi
# après ssl dans /etc/runit/1.d/install-ssl
I, [2026-06-06T04:23:49.125964 #1]  INFO -- : File > /usr/local/bin/configure-ssl  chmod: +x  chown: 
I, [2026-06-06T04:23:49.127031 #1]  INFO -- : > curl https://raw.githubusercontent.com/acmesh-official/acme.sh/3.0.6/acme.sh > /opt/acme.sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  215k  100  215k    0     0   635k      0 --:--:-- --:--:-- --:--:--  637k
I, [2026-06-06T04:23:49.514883 #1]  INFO -- : > chmod +x /opt/acme.sh
I, [2026-06-06T04:23:49.554670 #1]  INFO -- : File > /usr/local/bin/configure-letsencrypt  chmod: +x  chown: 
I, [2026-06-06T04:23:49.596808 #1]  INFO -- : File > /usr/local/bin/letsencrypt  chmod: +x  chown: 
I, [2026-06-06T04:23:49.598926 #1]  INFO -- : > echo "Beginning of custom commands"
Beginning of custom commands
I, [2026-06-06T04:23:49.605809 #1]  INFO -- : > echo "End of custom commands"
End of custom commands
I, [2026-06-06T04:23:49.608842 #1]  INFO -- : Terminating async processes
I, [2026-06-06T04:23:49.609015 #1]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main pid: 44
I, [2026-06-06T04:23:49.609157 #1]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 111
2026-06-06 04:23:49.609 UTC [44] LOG:  received fast shutdown request
111:signal-handler (1780719829) Received SIGTERM scheduling shutdown...
2026-06-06 04:23:49.612 UTC [44] LOG:  aborting any active transactions
2026-06-06 04:23:49.619 UTC [44] LOG:  background worker "logical replication launcher" (PID 58) exited with exit code 1
2026-06-06 04:23:49.623 UTC [53] LOG:  shutting down
2026-06-06 04:23:49.634 UTC [53] LOG:  checkpoint starting: shutdown immediate
111:M 06 Jun 2026 04:23:49.683 * User requested shutdown...
111:M 06 Jun 2026 04:23:49.683 * Saving the final RDB snapshot before exiting.
111:M 06 Jun 2026 04:23:49.698 * DB saved on disk
111:M 06 Jun 2026 04:23:49.700 # Redis is now ready to exit, bye bye...
2026-06-06 04:23:49.711 UTC [53] LOG:  checkpoint complete: wrote 87 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.041 s, sync=0.022 s, total=0.088 s; sync files=52, longest=0.008 s, average=0.001 s; distance=86 kB, estimate=86 kB
2026-06-06 04:23:49.735 UTC [44] LOG:  database system is shut down

[pfaffman (Jay Pfaffman)]

@Idoru_Toei

Alors, j’ai cru comprendre que l’image Docker incluait déjà Postgres. Pourriez-vous préciser si je dois installer Postgres sur le VPS ?

N’installez pas Postgres.

@Idoru_Toei

Malheureusement, lorsque je décoche « site web activé », je ne peux pas faire de requête curl vers les ports 443/80 depuis l’hôte,

C’est normal, car vous n’avez pas installé Discourse en tant que serveur web.

@Idoru_Toei

et la configuration de Discourse signale toujours la même erreur.

Alors vous avez (presque certainement) toujours le problème que les ports de votre VM ne sont pas exposés à Internet.

@Idoru_Toei

Et comme vous pouvez le voir dans mon message initial, la configuration de Discourse indique (initialement) que le port 443 est disponible.

Non, ce n’est pas le cas. Il est clairement indiqué que Discourse n’a pas accès au port. Votre commande curl montre en outre que quelque chose d’autre contrôle le port 443.

@Idoru_Toei

⚠ Le port 443 de cet ordinateur ne semble pas accessible en utilisant le nom d'hôte : metabolism.logophilia.eu
⚠ La connexion à http://metabolism.logophilia.eu (port 80) échoue également.

Je pense que le conteneur a été construit avec succès, mais qu’il ne peut pas démarrer car quelque chose d’autre utilise le port 443, ou qu’il ne fait rien car le port 443 est redirigé ailleurs.

Vous pouvez essayer

docker ps

pour voir si des conteneurs sont en cours d’exécution et

docker logs app

pour voir ce que Discourse a enregistré via Docker.

[Idoru_Toei]

Merci pour vos retours, j’apprécie vraiment le temps que vous y avez consacré. Pour ne pas passer pour un rabat-joie, mais :

[2/5] Préparation de la configuration
✓ Les ports 80 et 443 sont libres

Cela dit, mon instance est maintenant opérationnelle, avec l’aide de Gemini (surtout pour tout ce qui concerne Docker, lol). Je souhaiterais partager mon « runbook » avec les autres utilisateurs de Virtualmin, car : « libérer le port 443 » n’est pas la solution ici. Le reste de mon message sera consacré à cela. Si je devais plutôt publier cela ailleurs, par exemple dans un nouveau sujet, merci de m’indiquer où aller ; je pense que je ne suis pas le seul avec cette configuration, et cela pourrait être utile à d’autres. Merci encore !

Si vous êtes sur un VPS géré par Webmin/Virtualmin et que vous utilisez un sous-domaine :

Le Runbook Définitif Virtualmin + Discourse *

• (1) Nettoyage des restes (si vous réessayez, comme moi) :

  rm -rf /var/discourse/shared/standalone/ssl/*

  rm -rf /var/discourse/shared/standalone/letsencrypt

  rm -rf /var/discourse/shared/standalone/state

• (2) Suppression des modèles :

  Vous devez supprimer complètement les lignes templates/web.ssl.template.yml et templates/web.letsencrypt.ssl.template.yml de app.yml. Le解析eur de lancement personnalisé les évaluera même si elles sont précédées de #.

• (3) Configuration de l’email et variables :

  Modifiez DISCOURSE_SKIP_EMAIL_SETUP de '1' à '0', car votre Discourse ne pourra pas se connecter et vérifier DiscordID ;

  Ajoutez DISCOURSE_FORCE_HTTPS: true afin que le backend génère des URL sécurisées.

  Rappel amical : Assurez-vous que DISCOURSE_SMTP_USER_NAME est défini avec le nom brut de votre compte de boîte aux lettres (par exemple, 'logophilia'), pas l’adresse email complète (par exemple, 'logophilia@logophilia.eu'), et entourez les identifiants de guillemets simples (') pour contourner d’éventuels bogues d’analyse de caractères YAML.

• (4) Configuration du bloc expose :

  Assurez-vous que votre bloc expose: dans app.yml contient une mappage HTTP ; mapper 443=>8443 est optionnel / redondant, car Virtualmin termine la logique SSL avant de la transmettre :

  expose:
    - 8080:80
  

  Vous pouvez maintenant reconstruire :

  cd /var/discourse
  ./launcher rebuild app
  

• (5) Configuration du sous-domaine et du chemin du proxy :

  • Créez votre sous-domaine dans Virtualmin comme d’habitude et sécurisez-le avec un certificat SSL Let’s Encrypt (fait automatiquement, je le précise juste : assurez-vous qu’il ne génère pas d’erreur pour une raison sans rapport).
  • Accédez à Proxy Paths (Virtualmin → votre sous-domaine → Configuration Web → Proxy Paths), créez une nouvelle mappage / vers http://localhost:8080/, laissez « serve locally » décoché, mais activez Proxy WebSocket sur Oui pour permettre les mises à jour en temps réel et les flux de notifications.

• (6) Directives d’en-tête CSRF :

  • Dans Webmin ➔ Serveurs ➔ Serveur Web Apache ➔ [trouvez la configuration de votre sous-domaine ici et cliquez sur la configuration pour 443] ➔ Éditer les directives, placez les lignes suivantes juste au-dessus du bloc proxy de Virtualmin pour Let’s Encrypt (généralement « ProxyPass /.well-known ! ») pour faciliter la transmission du jeton CSRF :

  ProxyPreserveHost On
  RequestHeader set X-Forwarded-Proto "https"
  RequestHeader set X-Forwarded-For %{REMOTE_ADDR}s
  

  ProxyPreserveHost On : Indique à Discourse votre nom de domaine réel au lieu de « localhost ».
  RequestHeader set X-Forwarded-Proto "https" : Indique explicitement à Discourse que l’utilisateur utilise une connexion sécurisée, ce qui correspond à votre paramètre DISCOURSE_FORCE_HTTPS: true.
  RequestHeader set X-Forwarded-For : Transmet la véritable adresse IP du visiteur au conteneur afin que les journaux de sécurité fonctionnent.

• (7) Poignée de main propre du conteneur :

  Pendant que le processus de reconstruction (désolé… c’est vrai pourtant se termine, assurez-vous que tout modèle de conteneur potentiellement bloqué est effacé avec docker rm -f app afin que l’exécution de ./launcher start app lance une instance complètement nouvelle liée au port 8080. Vérifiez que docker ps affiche quelque chose sous « ports » similaire à :

  # docker ps
  CONTAINER ID   IMAGE                 COMMAND        CREATED          STATUS          PORTS                                                                                NAMES
  d21772a21e36   local_discourse/app   "/sbin/boot"   45 minutes ago   Up 45 minutes   0.0.0.0:8080->80/tcp, [::]:8080->80/tcp, 0.0.0.0:8443->443/tcp, [::]:8443->443/tcp   app
  

  (Comme vous pouvez le voir, j’ai laissé la directive 443=>8443 dans mon app.yml, cela fonctionne dans les deux cas.)

• (8) Surveillance et lancement :

  Suivez le flux de démarrage avec docker logs -f app jusqu’à ce que les migrations de base de données se terminent et que les workers commencent à traiter les requêtes. Une série de lignes « INFO » en rapide succession, essentiellement.

• (9) Finalisation :

  Chargez votre sous-domaine dans un navigateur, cliquez sur S’inscrire, et laissez le système envoyer un email de validation à votre boîte aux lettres.

*) Jusqu’à preuve du contraire

[satonotdead]

J’ai dû arrêter mon serveur Nginx avant l’installation. C’est bien de voir qu’il existe un drapeau pour sauter ce test, bien que