Je ne pense pas que ce soit encore le cas.
Exactement @jomaxro. C’est pourquoi j’ai dit
Oh. Désolé. J’ai manqué ce changement.
Donc, si l’utilisateur ne fournit pas d’adresse e-mail de notification pour Let’s Encrypt, discourse-setup active désormais Let’s Encrypt sans vérifier que le domaine pointe vers le serveur actuel. Mais si vous fournissez une adresse e-mail, la vérification est effectuée. Cela ne semble pas être une très bonne idée.
Pourquoi forcer HTTPS s’ils n’ont pas de nom de domaine valide ? Si le plan est de forcer tout le monde à utiliser HTTPS en permanence, nous devrions vérifier la validité du nom de domaine et refuser l’exécution plutôt que de leur fournir une installation cassée.
Avec le fonctionnement actuel, si vous ne fournissez pas d’adresse e-mail pour Let’s Encrypt et que le domaine ne pointe pas vers le serveur, discourse-setup semble réussir, mais il lance un serveur web qui n’acceptera pas les connexions car nginx ne peut pas trouver de certificat. Je pense qu’il serait préférable de ne pas demander d’adresse e-mail pour Let’s Encrypt, d’utiliser l’adresse e-mail du développeur (la première ?) pour Let’s Encrypt et de toujours effectuer le test DNS, mais cela ne devrait plus être discuté dans ce sujet.
Non, ce n’est pas ainsi que fonctionne Let’s Encrypt. L’e-mail n’a rien à voir avec la validation du domaine. Il sert à alerter l’utilisateur si son certificat est sur le point d’expirer et ne peut pas être renouvelé. La validation est toujours effectuée via DNS.
Let’s Encrypt ne peut pas émettre de certificat pour une adresse qui ne répond pas aux exigences de validation. Si c’était le cas, tout le système LE s’effondrerait du jour au lendemain.
Non. C’est ainsi que fonctionne discourse-setup, ou du moins c’était le cas. Auparavant, il protégeait les utilisateurs en évitant de demander un certificat lorsqu’il était pratiquement certain que la demande échouerait. Désormais, il poursuit la procédure, demande un certificat même lorsqu’il est impossible que cela réussisse, et ne dispose d’aucun moyen d’informer l’utilisateur de l’échec. Il échoue donc silencieusement, sans aucun avertissement.
Encore une fois, pourquoi cela échouerait-il ? L’adresse e-mail n’est pas requise pour la vérification du domaine.
L’échec n’a jamais généré d’e-mail non plus.
L’e-mail sert uniquement à informer l’utilisateur ultérieurement si Let’s Encrypt échoue à renouveler et qu’un certificat est sur le point d’expirer. Si le certificat se renouvelle sans problème, l’utilisateur ne recevra jamais d’e-mail.
Je ne pense pas que ce soit l’intention du changement. L’objectif était d’activer SSL indépendamment de la fourniture d’une adresse e-mail. Nous devrions toujours vérifier la résolution du domaine cc @Falco
Cela échouera si le nom de domaine ne se résout pas vers l’hôte. L’adresse e-mail n’a pas d’importance, mais s’il y en a une, la configuration de Discourse avertira l’utilisateur si l’adresse ne se résout pas.
La résolution de domaine doit passer par @falco, sinon la configuration doit s’arrêter. C’est un mauvais changement.
J’ai donc apporté quelques modifications dans une branche. Voici comment cela va fonctionner :
En utilisant un nom d’hôte incorrect :
root@droplet:/var/discourse# ./discourse-setup
Nom d'hôte pour votre Discourse ? : bad-domain.com
Vérification de votre nom de domaine . . .
ATTENTION :: Ce serveur ne semble pas être accessible à l'adresse bad-domain.com:443.
Une connexion à http://bad-domain.com (port 80) échoue également.
Cela suggère que bad-domain.com résout vers la mauvaise adresse IP
ou que le trafic n'est pas acheminé vers votre serveur.
Google : "ouvrir les ports VOTRE SERVICE CLOUD" pour obtenir des informations sur la résolution de ce problème.
Si vous souhaitez continuer quand même, vous devrez exécuter cp samples/standalone.yml containers/app.yml
et modifier manuellement le fichier containers/app.yml.
En utilisant un nom d’hôte correct :
root@droplet:/var/discourse# ./discourse-setup
Nom d'hôte pour votre Discourse ? : good-domain.com
Vérification de votre nom de domaine . . .
Connexion à good-domain.com réussie.
Adresse e-mail pour le(s) compte(s) administrateur ? :
Les modifications sont en attente à l’adresse :
Est-ce que cela vous semble correct, @pfaffman @codinghorror ?
Commentaire sur la raison pour laquelle ce changement était nécessaire dès le départ
Tout d’abord, je suis surpris que, depuis près de trois mois que cela fonctionne ainsi, il n’y ait pas eu de nombreuses plaintes, et même le sujet qui a attiré mon attention sur ce problème ne rencontrait pas de difficultés à cause de ce changement. Il est donc possible que cela compte beaucoup moins que ce que je pense.
La première chose que je ne comprends pas vraiment est : vous voulez vraiment rendre impossible la configuration d’un site uniquement en HTTP avec discourse-setup ? Je suppose qu’ils ont déjà dû effectuer diverses opérations DNS pour que la messagerie fonctionne, donc peut-être que ce n’est pas un problème majeur de leur demander de créer l’enregistrement A également.
Retour sur le changement
Sauf si vous avez apporté une modification que je n’ai pas remarquée, le script crée app.yml avant de commencer à poser des questions. Vous pourriez donc simplement afficher un message du type : « L’installation de Discourse sans configuration DNS n’est pas prise en charge. Pour continuer sans configuration DNS, modifiez app.yml selon vos besoins et exécutez ./launcher rebuild app », puis quitter sans amorcer le processus.
De plus, si vous comptez imposer l’utilisation obligatoire de Let’s Encrypt et de HTTPS, il pourrait être logique de modifier standalone.yml et web_only.yml en conséquence, ce qui permettrait alors de supprimer ces délicates instructions sed.
Autres réflexions
Du côté de « c’est mon problème », mon script d’installation actuel s’exécute avant que les utilisateurs puissent configurer le DNS, car je crée le droplet pour eux, configure Discourse, leur envoie un email avec les instructions DNS, attends que le DNS soit configuré, puis modifie app.yml pour activer les modèles et définir l’adresse de Let’s Encrypt. Mais je suppose que cela est dû à des raisons historiques. Ce que je devrais faire à la place, c’est créer le droplet, configurer Mailgun, attendre que le DNS soit configuré, ensuite procéder à l’installation. Cela permettrait toujours à mon script d’utiliser discourse-setup, ce que j’aime faire régulièrement pour vérifier que tout fonctionne toujours (je ne pense pas que vous effectuiez un test automatisé de discourse-setup, n’est-ce pas ?)
Oui.
Je n’ai reçu aucune plainte concernant ce changement et, depuis son déploiement, je ne constate plus de nombreuses instances Discourse en HTTP uniquement, car lorsque vous indiquez que quelque chose est OPTIONNEL, tout le monde l’ignore sans y réfléchir. À mon avis, c’est une excellente avancée pour offrir des paramètres par défaut sécurisés pour Discourse, ce qui est l’objectif principal de notre guide de 30 minutes.
Oh, c’est encore mieux, cela nécessite moins d’instructions !
Ah, maintenant je comprends votre réaction vigoureuse face à ce changement, car il a perturbé votre configuration. Désolé pour cela.
Je recommande vivement d’utiliser directement le fichier yml pour toute automatisation plutôt que de cibler le script interactif.
TL;DR : Oui, avec le petit ajustement linguistique que j’ai recommandé, cela me semble bon.
D’accord. Zéro plainte ! Ça ressemble à une victoire.
Non ! Ce n’est pas le cas. (!) Je me suis seulement aperçu que les sites ne se chargeaient pas avant d’avoir effectué la deuxième étape de l’installation qui active HTTPS. Et mon installation n’est pas de ta responsabilité. (Oh, MAINTENANT cela va casser mon script, mais ne pas effectuer l’installation avant que le DNS soit configuré sera de toute façon mieux. Je n’ai pas fait d’installation sans HTTPS depuis au moins un an.)
La raison pour laquelle j’aimais que mon script utilise discourse-setup, c’est que cela garantit de manière tout à fait spéciale que mes clients d’installation reçoivent une installation standard, et que lorsque quelqu’un dit « J’ai fait une installation et cela ne fonctionne pas », je peux exécuter mon script et faire exactement ce qu’ils auraient dû faire, puis dire « Eh bien, je viens de faire une installation et cela a fonctionné. » Mais je ne pense pas me souvenir d’un moment au cours des trois dernières années où j’ai trouvé un problème, donc peut-être que mon « test » n’est utile à personne.
Super, merci pour l’analyse et la revue !
J’ai fusionné la PR, nous allons donc désormais toujours valider le DNS.