Salut @pfaffman, la modification du message d’origine contient un + erroné dans la ligne to:, ce qui casse l’expression régulière. Il devrait être supprimé.
Séparément, le paragraphe suivant doit être modifié car il n’a plus de sens :
Il existe deux modèles qui doivent être remplacés, l’un se terminant par --keylength et l’autre par --fullchainpath (dans le fichier réel, votre domaine d’origine précède chacun de ces commutateurs). Entrez votre (sous-)domaine (et tous les sous-domaines supplémentaires précédés de -d ) puis ajoutez ce qui suit à la section hooks de votre app.yml (vers la fin du fichier) :
Je suggère :
Utilisez domain1 et domain2 dans ce message pour générer le code dont vous aurez besoin. domain1 est votre domaine d’origine et domain2 est le domaine supplémentaire que vous souhaitez ajouter. Ajoutez le bloc after_ssl: résultant à la section hooks de votre app.yml et exécutez launcher rebuild app.
Depuis la dernière mise à jour vers 3.5.0.beta8-dev
/etc/runit/1.d/letsencrypt
est manquant dans le conteneur Docker. Il ne se construira donc pas. Solution de contournement : https://www.forcewww.com/
Donc, ceci a cessé de fonctionner :
## Ajouter le certificat Let's Encrypt pour le nom de domaine non-www et www
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.de -d www.example.de --keylength"
Avant de supprimer de tels outils/binaires du conteneur Docker, il serait agréable de recevoir une notification…
Est-ce un changement dans la façon dont Discourse gère LetsEncrypt ou un changement dans LetsEncrypt lui-même ?
J’ai un serveur qui est actuellement affecté par ce problème. Pour l’instant, ma solution de contournement consiste à commenter cette partie de app.yml, mais je pense que nous avons besoin d’un moyen d’ajouter ces certificats supplémentaires à la configuration à l’avenir.
Discourse a déplacé cela dans un autre fichier. C’est en cours de traitement. J’essaierai de regarder dans les prochains jours pour voir ce qui est nécessaire pour permettre la prise en charge de plusieurs sous-domaines.
Errno::ENOENT : Aucun fichier ou répertoire de ce type @ rb_sysopen - /usr/local/bin/letsencrypt
Emplacement de l’échec : /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/replace_command.rb:11:in `read’
Remplacement échoué avec les paramètres {“filename”=>“/usr/local/bin/letsencrypt”, “from”=>“/-d spokes.nz/”, “to”=>“-d spokes.nz -d www.spokes.nz”}
Amorçage échoué avec le code de sortie 1
** ÉCHEC DE L’AMORÇAGE ** veuillez faire défiler vers le haut et rechercher les messages d’erreur précédents, il peut y en avoir plus d’un.
Peut-être essayer de mettre le remplacement dans la stanza en bas, là où se trouvait le matériel ssh, si cela a du sens (je suis sur mon téléphone, j’essaierai de regarder demain)
Je suppose, mais je me demande si l’erreur que vous recevez pourrait être liée à un espace manquant avant la barre oblique finale et la citation finale dans les lignes respectives de la strophe suggérée dans votre fichier app.yml ?
J’infère du message d’erreur que vos lignes respectives sont (mot pour mot)
from: /-d spokes.nz/
to: “-d spokes.nz -d www.spokes.nz”
Je dis cela parce que dans mon cas, les lignes sont
from: /-d nzarchitecture.net.nz /
to: "-d nzarchitecture.net.nz -d www.nzarchitecture.net.nz "
Et avec des espaces juste avant la fin de chaque ligne comme indiqué, je peux maintenant reconstruire Discourse sans cette erreur. (si vous regardez attentivement, vous verrez que la strophe mise à jour de @pfaffman publiée au début de ce fil montrait ces espaces supplémentaires).
Je n’ai aucun fichier dans le répertoire usr/local/bin/ (comme indiqué dans votre message d’erreur) non plus, ce qui m’a fait suspecter que l’absence de ce fichier letsencrypt n’est pas ce qui déclenche l’erreur.
Cela dit, pour moi, bien que Discourse fonctionne correctement sur son URL nzarchitecture.net.nz, j’obtiens malheureusement toujours une erreur de certificat si je tape www.nzarchitecture.net.nz dans un navigateur - que ce soit dû à l’absence de ce fichier, je ne sais pas.
Je note que je tente actuellement d’intégrer cela dans les variables d’environnement pour les gérer directement dans discourse_docker, quelque chose comme une liste de noms d’hôtes séparés par des virgules. Cela semble être un cas d’utilisation suffisamment courant pour être géré directement.
Cela facilitera la configuration pour ce cas, afin que personne n’ait besoin de modifier ses fichiers app.ymls.
Mon plan actuel est avec DISCOURSE_HOSTNAMEwww.domain.com
Permettre des variables d’environnement comme : DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com permettrait de récupérer le certificat, valide pour tous les noms d’hôtes.
(Pendant que j’y suis, les renouvellements automatiques de Let’s Encrypt ne semblent pas non plus fonctionner correctement, je suis donc en train de les corriger également)
J’ai raté ça ! J’ai fait ce que vous avez suggéré, mais toujours un échec de démarrage :
ÉCHEC
Errno::ENOENT: Aucun fichier ou répertoire de ce type @ rb_sysopen - /usr/local/bin/letsencrypt
Emplacement de l’échec : /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/replace_command.rb:11:in `read’
Remplacement échoué avec les paramètres {“filename”=>“/usr/local/bin/letsencrypt”, “from”=>“/-d spokes.nz /”, “to”=>"-d spokes.nz -d www.spokes.nz "}
Démarrage échoué avec le code de sortie 1 ÉCHEC DU DÉMARRAGE veuillez faire défiler vers le haut et rechercher les messages d’erreur précédents, il peut y en avoir plus d’un.
Probablement pas le problème principal ici, mais dans mes tâtonnements, j’ai également mis à jour la version de Docker exécutée sur Digital Ocean de 20.0.4 (je pense) à 28.3.3 - cela a peut-être aidé, du moins avec cette erreur. Si rien d’autre, cela a permis d’éliminer les avertissements « obsolètes » de Docker que je recevais au début du processus de reconstruction.
Salut à tous, juste pour faire un suivi, les domaines multiples sont maintenant fusionnés - dans la dernière version de discourse_docker, vous pouvez maintenant inclure les modèles ssl et letsencrypt et configurer des variables d’environnement du type DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com pour configurer des noms d’hôtes alternatifs.
Votre site récupérera en plus les noms d’hôtes configurés avec la demande de certificat sans aucune modification de configuration supplémentaire.
[quote=“featheredtoast, post:172, topic:56685”]Vous pouvez maintenant inclure les modèles ssl et letsencrypt et configurer des variables d’environnement de la forme DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com pour configurer des noms d’hôtes alternatifs.
[/quote]
Pardonnez mon ignorance, mais est-ce modifiable via un paramètre du site, ou faut-il modifier quelque chose dans app.yml ?
Si c’est le premier cas, je n’ai pas réussi à le trouver après la mise à jour vers la dernière version, et si c’est le second cas, qu’est-ce qui doit être spécifiquement ajusté dans app.yml ?
Vous n’incluriez que les domaines supplémentaires pour lesquels vous souhaitez que les gens puissent créer des liens et être redirigés vers le nom d’hôte réel de votre site.
Ce serait encore mieux s’il existait un moyen astucieux pour Discourse d’écrire lui-même les alias fournis par l’administrateur dans app.yml lors de la prochaine mise à jour, ou de laisser les informations là où une instruction app.yml peut les lire.