J’essaie d’installer Discourse sur un serveur cloud de Hetzner, mais lorsque j’exécute ./discourse-setup, j’obtiens le message que les ports sont bloqués (discourse.domain.de n’est évidemment pas le vrai domaine) :
WARNING: Port 443 of computer does not appear to be accessible using hostname: discourse.domain.de.
WARNING: Connection to http://discourse.domain.de (port 80) also fails.
Comme suggéré par l’outil de configuration, je veux maintenant vérifier si discourse.domain.de résout l’adresse IP du serveur cloud. Lorsque je fais dig discourse.domain.de, j’obtiens la sortie suivante :
; <<>> DiG 9.16.1-Ubuntu <<>> discourse.domain.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28839
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;discourse.domain.de. IN A
;; ANSWER SECTION:
discourse.domain.de. 4134 IN A XXX.XXX.XXX.XXX (adresse IP correcte)
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sun Apr 24 10:14:44 UTC 2022
;; MSG SIZE rcvd: 70
Ce qui me semble bien. La chose suivante suggérée est qu’il pourrait s’agir d’un problème de pare-feu. J’ai un pare-feu avec les ports suivants ouverts :
Je pense donc que le pare-feu n’est pas la raison du message ci-dessus. Est-il possible que quelque chose d’autre bloque les ports ? J’ai lu qu’Apache pouvait causer un tel problème, mais il n’est pas installé sur le serveur cloud.
J’ai essayé telnet discourse.domain.de 443 pour voir si les ports étaient ouverts et j’ai obtenu :
telnet: Unable to connect to remote host: Network is unreachable
Quelqu’un a-t-il une idée pour résoudre ce problème ?
Merci !
Malheureusement, les spammeurs et les escrocs par e-mail aiment utiliser les fournisseurs d’hébergement cloud. Et chez Hetzner, nous voulons naturellement l’empêcher. C’est pourquoi nous bloquons les ports 25 et 465 par défaut sur tous les serveurs cloud. C’est une pratique très courante dans l’industrie de l’hébergement cloud car elle empêche les abus. Nous voulons établir la confiance avec nos nouveaux clients avant de débloquer ces ports de messagerie. Une fois que vous êtes avec nous depuis un mois et que vous avez payé votre première facture, vous pouvez créer une demande de limite pour débloquer ces ports pour un cas d’utilisation valide. Dans votre demande, vous pouvez nous donner des détails sur votre cas d’utilisation. Nous prenons des décisions au cas par cas.
En alternative, vous pouvez également utiliser le port 587 pour envoyer des e-mails via des services externes de livraison de messagerie. Le port 587 n’est pas bloqué et peut être utilisé sans envoyer de demande de limite.
J’ai effectué une recherche sur le forum pour voir si d’autres personnes avaient rencontré un problème similaire et j’ai trouvé ceci, bien que malheureusement pas une « vraie solution » en soi :
La configuration manuelle du fichier app.yml pourrait-elle être une option pour vous ?
Je suis toujours confus, mais chez Digital Ocean, le pare-feu doit être configuré. Une installation propre n’a aucun port ouvert (sauf SSH, mais c’est une autre chose). Je ne sais pas comment fonctionne Hetzner. Et si le VPS est derrière des ports fermés, peu importe ce que nous avons dans app.yml.
La configuration manuelle de app.yml est également la solution au problème pour moi. Merci !
J’ai aussi trouvé ce fil, mais je suppose que je ne l’ai pas lu assez attentivement…
Je pense que oui. Lorsque je démarre un VPS (Ubuntu 20), nginx n’est pas installé par défaut : discourse-setup l’installe.
J’ai installé Discourse de nombreuses fois sur un VPS Hetzner sans aucun problème pendant des années (la dernière fois, c’était en février).
C’est pourquoi ce sujet me laisse perplexe.
edit : pour certaines raisons, mon cerveau a confondu docker et nginx
Il y a deux options : utiliser le pare-feu de Digital Ocean ou installer UFW (ou similaire) après la création du VPS. Aucune de mes installations n’utilise le leur, donc tous les ports sont fermés jusqu’à ce que je les ouvre depuis UFW.
Quoi qu’il en soit, nous savons maintenant quand, où et comment Nginx est installé. Chaque jour apporte son lot de nouveautés (quand on ne comprend pas comment fonctionne Docker )
)