D’abord, les louanges sont de mise : le nouvel installateur est une grande amélioration. Lorsqu’il fonctionne, ce qui est le cas la plupart du temps, il offre une expérience bien plus conviviale que l’ancien processus manuel, et j’ai pu effectuer des installations propres grâce à lui. Lancez l’installateur, complétez l’enregistrement/l’activation comme d’habitude, puis ajustez app.yml selon vos spécifications. Facile comme tout. Un grand merci à @Falco et à l’équipe ! Quelle différence avec les vieilles installations Discourse d’antan.
Je poste ceci car j’ai également rencontré un nom d’hôte qui m’a donné du fil à retordre, et je pense que cette expérience peut mettre en lumière quelques endroits où l’installateur pourrait fournir des informations plus claires aux auto-hébergeurs.
Ce qui a fonctionné
J’ai installé Discourse avec succès sur un serveur frais en utilisant :
- mon propre domaine : oui
- SMTP : oui
- le flux d’installation actuel
L’installation a atteint :
Tallyho !
Félicitations, vous avez installé Discourse !
Inscrivez un nouveau compte pour commencer.
Il ne s’agit donc pas d’un post disant « le nouvel installateur est cassé ». L’installateur peut fonctionner très bien.
Le nom d’hôte difficile
Lors d’une autre installation, en suivant le même processus général, le nom d’hôte cible était :
forum.domain.tld
La commande d’installation était :
wget -qO- https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse | sudo bash
Les choix étaient approximativement :
- créer un fichier swap de 2 Go : oui
- utiliser mon propre domaine : oui
- nom d’hôte :
forum.domain.tld - configurer SMTP : oui
- fournisseur SMTP : SendGrid
- port SMTP : 587
L’installateur a atteint :
[4/5] Vérification de la configuration du domaine
? Vérification de votre nom de domaine...
? La connexion à forum.domain.tld a réussi.
Il a ensuite écrit la configuration et reconstruit l’application.
Mais le site n’a pas démarré proprement dans le navigateur. Le symptôme est finalement devenu :
forum.domain.tld a refusé la connexion
Les tentatives répétées de reconstruction/réessai n’ont pas résolu le problème.
Résultat de Discourse Doctor
./discourse-doctor a trouvé le conteneur d’application et les valeurs de configuration attendues. Le conteneur était en cours d’exécution et les ports 80/443 semblaient être liés.
Mais il a rapporté :
Version Discourse à forum.domain.tld : NON TROUVÉE
et plus tard :
Version Discourse à localhost : NON TROUVÉE
Cela a donné au problème une apparence différente d’une simple propagation DNS publique ordinaire.
Limite de taux ACME
Plus tôt dans le processus de dépannage, j’ai également tenté des installations en utilisant les chemins assistés par le service Discourse :
- DiscourseID
- le flux
yoursite.discourse.diy
C’est là que le comportement de martelage du serveur/réessai répété s’est produit, et où le journal ACME a montré une limite de taux Let’s Encrypt :
type: urn:ietf:params:acme:error:rateLimited
status: 429
detail: trop de certificats (5) déjà émis pour cet ensemble exact d'identifiants...
Le chemin de journal utile était :
/shared/letsencrypt/acme.sh.log
C’était une grande leçon. Depuis le navigateur, l’échec ressemblait à un problème de connectivité générique. Mais le véritable blocage à ce moment-là était l’émission du certificat.
La partie la plus confuse était que le bloc de statut final/installation terminée n’indiquait pas cela comme une erreur actionnable. Le symptôme final visible par l’utilisateur était simplement que le site refusait la connexion du navigateur.
Une vérification ultérieure a montré la chaîne d’échec plus clairement :
Limite de taux ACME 429
-> fichiers .cer de zéro octet sous /shared/ssl
-> nginx tente de charger le certificat de zéro octet
-> nginx échoue au démarrage
-> les ports 80/443 refusent
-> le navigateur dit connexion refusée
Demande de fonctionnalité enterrée dans l’expérience :
Il serait très utile si la routine d’installation/reconstruction vérifiait /shared/letsencrypt/acme.sh.log après l’étape du certificat et signalait les erreurs de limite de taux telles que :
rateLimited
trop de certificats
status: 429
Par exemple :
Limite de taux Let's Encrypt atteinte pour ce nom d'hôte.
Attendez jusqu'à l'heure de réessai indiquée dans /shared/letsencrypt/acme.sh.log avant de réessayer.
Les reconstructions répétées peuvent ne pas aider.
Cela épargnerait aux utilisateurs de traquer les problèmes DNS, SMTP, de citation app.yml, Docker ou de pare-feu lorsque le problème réel est ACME.
Après le déblocage de la limite de taux
Après que la fenêtre de limite de taux Let’s Encrypt se soit dissipée, j’ai toujours vu une situation de validation de domaine confuse.
L’installateur a rapporté :
[4/5] Vérification de la configuration du domaine
? Vérification de votre nom de domaine...
? La connexion à forum.domain.tld a réussi.
Mais une recherche DNS locale montrait toujours :
Resolve-DnsName -Name "forum.domain.tld"
avec :
Resolve-DnsName : forum.domain.tld : le nom DNS n'existe pas.
Comment ces deux choses peuvent-elles coexister ?
Je peux imaginer plusieurs possibilités :
- le serveur et la station de travail utilisaient des résolveurs récursifs différents
- un résolveur avait mis en cache un NXDOMAIN périmé
- la propagation DNS était partielle à ce moment-là
- l’installateur vérifie autre chose qu’une recherche DNS simple
- l’installateur ou un service associé avait mis en cache l’état de validation
Je ne prétends pas laquelle est vraie. Je note principalement que depuis la perspective de l’utilisateur, l’installateur disant « connexion réussie » peut rendre les erreurs DNS ou de connectivité ultérieures plus difficiles à interpréter.
Vérification d’isolation DNS
test pour voir si c’était juste une propagation Cloudflare lente, j’ai ajouté un autre enregistrement dans la même zone :
test.domain.tld
En quelques instants, les résultats du vérificateur DNS public étaient verts.
Cela m’a rendu moins confiant quant au fait que la propagation Cloudflare générale était le seul problème. Cela ressemblait davantage à un problème spécifique à forum.domain.tld.
Installations comparatives
J’ai également eu une installation réussie sur un autre nom d’hôte :
discourse.domain2.tld
en utilisant le même chemin d’installation général.
Un autre nom d’hôte de test, pour les diagnostics DNS, était :
forum.domain3.tld
Les installations comparatives sont ce qui m’a éloigné de « le nouvel installateur est cassé » et vers « quelque chose de spécifique au nom d’hôte s’est produit ici. »
Théorie actuelle
Ma théorie actuelle, non prouvée, est que forum.domain.tld a peut-être eu un état spécifique au nom d’hôte mis en cache/réservé/mémorisé quelque part en dehors du serveur lui-même.
Les endroits sur lesquels je me suis interrogé :
- DiscourseID
- le flux
yoursite.discourse.diy - validation de domaine côté installateur
- une relation mise en cache entre une tentative de configuration précédente et le nom d’hôte
La raison pour laquelle je me pose des questions sur ces chemins assistés par service est que je les avais précédemment essayés avec le même nom d’hôte problématique, et c’était aussi le chemin où les tentatives répétées ont finalement atteint la limite de taux Let’s Encrypt.
Encore une fois, c’est une hypothèse, pas une conclusion.
Questions
- Le nouvel installateur contacte-t-il un service contrôlé par Discourse lors des installations de domaine propre ?
- DiscourseID ou le flux
discourse.diyréserve-t-il, se souvient-il ou met-il en cache les noms d’hôte ? - Existe-t-il un chemin de libération/réinitialisation pour un nom d’hôte qui a été utilisé ou tenté précédemment lors de la configuration ?
- Que vérifie exactement
[4/5] Vérification de la configuration du domaine? - L’installateur pourrait-il signaler plus clairement les échecs de limite de taux ACME avant le bloc de statut/résultat final ?
Ce qui aurait aidé
Trois choses auraient rendu le processus de dépannage beaucoup plus clair :
- Un avertissement clair de l’installateur lorsque
/shared/letsencrypt/acme.sh.logcontient une erreur de limite de taux. - Une brève explication de ce que l’étape de vérification de domaine vérifie réellement.
- Si un cache ou une réservation de nom d’hôte côté DiscourseID /
discourse.diy/ installateur existe, un moyen visible d’inspecter ou de libérer cet état.
Merci encore pour le travail sur le nouvel installateur. Il se sent vraiment comme la bonne direction. Je poste ceci dans cet esprit : il fonctionnait magnifiquement lorsqu’il fonctionnait, et l’aspérité ici semble être le genre de chose que de meilleurs messages de l’installateur pourraient rendre beaucoup plus facile à diagnostiquer.
Rédigé avec mes entrées par mon nouveau meilleur ami Codex.