Vérification de votre nom de domaine . . .
AVERTISSEMENT : Le port 443 de l’ordinateur ne semble pas accessible en utilisant le nom d’hôte : ***.com.
AVERTISSEMENT : La connexion à http://shoutam.com (port 80) échoue également.
Cela suggère que ***.com se résout en une adresse IP qui n’atteint pas cette machine où vous installez discourse.
La première chose à faire est de confirmer que ***.com se résout en 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 sûr que l’adresse IP se résout correctement, il pourrait s’agir d’un problème de pare-feu.
Une recherche sur le web pour « 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
Quelqu’un peut-il m’aider à résoudre ce problème ? J’utilise Cloudflare.
[quote=“Bhanu Sharma, post:2, topic:281990, username:itsbhanusharma”]vous devrez configurer discourse pour utiliser le modèle cloudflare.
[/quote]
Mais vous ne pourrez toujours pas installer, car let’s encrypt nécessite un accès direct aux ports 80 et 443 pour émettre un certificat.
Une fois que vous aurez obtenu votre certificat et que Discourse sera installé, vous pourrez rechercher des sujets sur la façon de le faire fonctionner avec cloudflare au milieu (ce qui inclut l’utilisation du modèle cloudflare).
Bonne remarque, ce n’est pas Let’s Encrypt mais le client acme.sh utilisé dans Discourse qui a besoin d’un accès direct (certbot a des plugins DNS qui nécessitent des travaux supplémentaires mais éliminent cette exigence). Je n’y avais pas pensé car pratiquement toutes les installations de Discourse que j’ai déployées ces dernières années ont nécessité l’utilisation d’un proxy inverse, d’où le fait que le modèle SSL interne soit désactivé par défaut.
Je ne suis pas sûr de ce que vous entendez par supprimé, mais il faut généralement quelques heures pour que la propagation du DNS se fasse. Cela vaut peut-être la peine d’attendre un peu, puis de réessayer.
Il manque beaucoup d’informations ici pour que nous puissions vraiment vous aider davantage.
De nos jours, Cloudflare ne échoue pas en mode proxy (nuage orange) tant que HTTPS n’est pas défini sur strict, car les ports :80 (HTTP) et :443 (HTTPS) sont directement transmis au serveur.
Strict force le trafic sur le port :80 à être redirigé vers SSL, et donc le défi échouerait.
Il est tout à fait possible que vous ayez manqué un ou plusieurs des fondamentaux, mais sans nous dire où se trouve le VPS et ce que vous avez configuré dans le DNS, nous ne ferons que deviner au mieux ce qui se passe ici.
Certains fournisseurs exigent que des ACL soient définies entre leur VPS et le monde extérieur - avez-vous vérifié que ces ports sont ouverts extérieurement ? Êtes-vous sûr que l’enregistrement ‘a’ que vous avez ajouté au DNS pointe vers l’adresse IP publique qui a été allouée ? Y a-t-il des pare-feux présents ?
C’est vrai avec certains fournisseurs de DNS, certes, mais Cloudflare impose une TTL de 300 secondes à toute adresse qu’ils proxy. Cela signifie que tous les serveurs DNS en amont auront expiré les anciens enregistrements dans les cinq minutes suivant la modification.
Tout ce que fait le modèle, c’est de s’assurer que les bonnes adresses IP client sont extraites des informations d’en-tête supplémentaires que Cloudflare ajoute lorsque le mode proxy est activé, ce n’est pas vraiment pertinent pour le processus d’installation.
Si vous avez effectué plusieurs reconstructions avec le nuage orange, vous avez probablement atteint les limites de débit avec Let’s Encrypt. Les solutions faciles sont d’utiliser un sous-domaine différent ou d’attendre une semaine.
Est-ce que cela fonctionnera si je détruis le droplet et en crée un nouveau ?
Veuillez noter que j’ai réussi à installer Discourse avant ce problème, mais j’ai détruit ce droplet car il y avait une erreur dans l’e-mail de l’administrateur. Maintenant, je n’arrive pas à installer Discourse en utilisant le même processus qu’auparavant.
Je déterre ce fil dans l’espoir que les commentateurs compétents pourront également m’aider.
Je rencontre la même erreur que l’OP d’origine.
J’utilise actuellement Unraid et j’ai un conteneur exécutant Nginix Proxy Manager. Les ports du pare-feu sont configurés pour envoyer tout le trafic des ports 80/443 vers mon conteneur NPM. J’ai configuré avec succès de nombreux conteneurs Docker avec mon conteneur NPM et tout a bien fonctionné.
J’ai installé une VM Ubuntu Server, j’ai suivi la configuration initiale, j’ai configuré une IP statique pour la VM, j’ai installé Docker, puis j’ai téléchargé Discourse, mais j’ai échoué lors du script de configuration, tout comme l’OP.
Si vous souhaitez utiliser Nginx Proxy Manager, vous devrez configurer votre fichier app.yml manuellement. Vous pouvez soit désactiver votre proxy assez longtemps pour laisser discourse-setup s’exécuter la première fois (vous devrez toujours modifier certaines choses manuellement), soit copier à partir de samples/standalone.yml.
Oui, d’après ce que je comprends, les fichiers yml se remplissent après l’exécution et la fin de discourse-setup. Pour y parvenir, peut-être puis-je diriger le trafic WAN sur mon pare-feu vers ma VM Ubuntu sur laquelle j’installe discourse, puis, une fois celle-ci configurée, rediriger mon trafic vers le proxy inverse, puis configurer mon fichier app.yml.
J’ai oublié ceci. Vous pouvez utiliser l’option --skip-connection-test pour qu’elle ignore ce test et s’exécute. Vous devrez toujours modifier les ports manuellement, mais cela vous permettra d’utiliser le script pour créer le fichier et saisir vos informations d’identification SMTP.