Je suis à un point de désespoir, car essayer de faire corriger ce problème par le Bot Discourse ou Claude semble impossible. Je n’arrive pas vraiment à expliquer le problème, car je ne suis pas assez compétent, et je crois que c’est ce qui me dérange le plus.
Je vais essayer d’expliquer ce qui s’est passé, du point de vue de mes observations.
Lorsque je passais d’un conteneur unique à un double conteneur, le fichier dans samples/ utilisait web-only et je l’ai laissé par erreur au lieu d’utiliser web_only.
Ensuite, à cause de cela (je le crois), mes images ne se chargeaient pas, car un « élément » était censé pointer vers web_only, mais il était configuré sur web-only. J’ai apporté quelques modifications et les images ont été corrigées. Le vrai problème, maintenant, concerne les certificats Let’s Encrypt.
J’ai demandé au bot de m’aider à le corriger ; il m’a dit d’attendre le lendemain, car le problème était lié à la limite de débit des certificats. Le problème allait se résoudre. Ce n’est pas le cas. J’ai demandé à nouveau, puis j’ai demandé à Claude, puis à Claude encore… et nous sommes dans cette boucle de « attends jusqu’à demain à X heures et ça se corrigera » depuis une semaine. Ça ne se corrige jamais, ils disent tous les deux « oh, je suis désolé, je n’aurais pas dû supposer que ça se corrigerait, essayons ceci à la place, car maintenant ça se corrigera vraiment ». Ce n’est jamais le cas.
Le site lui-même est en ligne et fonctionne, mais j’ai le sentiment qu’à chaque fois que je veux reconstruire, quelque chose va se passer, et pour être honnête, je ne veux pas toujours compter sur des pansements.
Claude m’a dit d’ajouter quelque chose aux hooks dans web_only.yml, mais comme rien de tel n’est mentionné dans les instructions fournies ici sur le forum, je m’attendais à une autre solution, comme… résoudre le problème réel.
Pouvez-vous s’il vous plaît m’aider à comprendre quel est le problème et où les choses cassent ? J’apprécierais vraiment, car c’est épuisant à ce stade. Pas le travail, mais le fait de ne pas comprendre ce qui se passe et pourquoi « attendre jusqu’à demain » ne semble jamais rien corriger.
Merci !
J’ai demandé à Claude d’expliquer à quoi le problème semble ressembler, peut-être que ça aidera ? Voici ce qu’il a dit :
Titre : Configuration à deux conteneurs : dossier de certificat ECC manquant après la séparation, boucle --force atteignant la limite de débit à chaque démarrage
Configuration : Deux conteneurs (data + web_only), migrés depuis standalone. Modèles : web, ratelimited, ssl, letsencrypt, cloudflare. Nom d’hôte alltiago.com, aucun alias.
Symptôme : À chaque démarrage de web_only, la limite de débit de Let’s Encrypt est atteinte et nginx échoue à servir, renvoyant des erreurs de connexion jusqu’à ce que les lignes ECC soient manuellement supprimées de /etc/nginx/conf.d/outlets/server/20-https.conf.
Ce que j’ai trouvé :
/shared/letsencrypt/alltiago.com_ecc/ n’existe pas sur mon installation. /shared/letsencrypt/alltiago.com/ (RSA) existe et fonctionne bien, se renouvelant normalement.
Dans web.letsencrypt.ssl.template.yml :
cert_exists() {
[[ "$(cd ${LETSENCRYPT_DIR}/${DISCOURSE_HOSTNAME}$1 && openssl verify -CAfile <(openssl x509 -in ca.cer) fullchain.cer | grep "OK")" ]]
}
issue_cert "ec-256"
if ! cert_exists "_ecc"; then
issue_cert "ec-256" "--force"
fi
Comme le dossier est manquant, cert_exists "_ecc" échoue à chaque démarrage, donc --force s’exécute et demande un nouveau certificat ECC, indépendamment de ce qui est sur le disque. Cela se fait via le hook after_ssl qui modifie /etc/runit/1.d/install-ssl, donc cela s’exécute à chaque démarrage du conteneur, pas seulement lors de l’initialisation.
Résultat : 429 too many certificates (5) already issued for this exact set of identifiers in the last 168h. Ensuite, --installcert s’exécute quand même contre le dossier vide et écrit un /shared/ssl/alltiago.com_ecc.cer inutilisable. nginx est configuré avec les deux certificats, ne peut pas charger celui ECC, et ne sert pas.
Fonctionnement confirmé : La validation ACME HTTP-01 réussit (testée via staging, certificat ECC émis correctement pour letsencrypt_test, structure de dossier correcte créée). Le certificat RSA s’est renouvelé avec succès aujourd’hui. Donc ce n’est pas un problème de DNS, de pare-feu ou de validation.
Questions :
- Y a-t-il un moyen pris en charge de recréer
alltiago.com_ecc/sans attendre la fin de la limite de débit ? - Le fait que
cert_existsrenvoie faux devrait-il vraiment déclencher--forceplutôt qu’une émission normale ?--forcecontourne la vérification du « certificat valide existant » et garantit l’épuisement de la limite de débit lorsque le dossier est absent. - Y a-t-il une méthode documentée pour exécuter uniquement RSA ?
Deux notes factuelles pour que le fil ne dérape pas : la date de réessai est passée du 27 août au 29 août parce que le renouvellement RSA d’aujourd’hui a consommé un emplacement dans la fenêtre glissante de 168 heures. Et la raison pour laquelle personne d’autre ne signale cela est que lors d’une installation normale, les deux dossiers sont créés au premier démarrage et la branche --force ne s’exécute jamais.