Configurer Let's Encrypt avec plusieurs domaines / redirections

Wiki de la communauté Adminsys
,
94

Oh, wow, ça a finalement fonctionné :

true | openssl s_client -connect www.starzen.space:443 2>/dev/null \
| openssl x509 -noout -text \
| perl -l -0777 -ne '@names=/\\bDNS:([^\\s,]+)/g; print join("\\n", sort @names);'
starzen.space
www.starzen.space

J’ai commenté les instructions if dans le script letsencrypt pour forcer une réémission. Ce n’est pas une solution « d’usine », bien sûr.

Cependant, cela suggère qu’il y avait un problème avec « l’état » plutôt qu’avec les options fournies.

Il semble que le script actuel puisse être bloqué en fonction de l’état antérieur, mais si vous forcez une réémission, vous pouvez le corriger.

Mais maintenant, j’ai un domaine apex fonctionnel ! :tada:

4 « J'aime »
95

Cela fait partie de l’installation standard. Voir User Guide — Certbot 5.1.0 documentation et faire défiler jusqu’à Managing Certificates et juste en dessous, Re-creating and Updating Existing Certificates.

Ces commandes seraient exécutées à partir de l’endroit où vous avez exécuté Certbot initialement.

1 « J'aime »
96

Je dispose d’une installation standard et certbot n’est pas utilisé. Ni au niveau du serveur « normal », ni si je tape d’abord ./launcher enter app.

Je suppose qu’il manque à cause de acme.sh.

3 « J'aime »
97

Je pense que je rencontre un problème similaire. Je pensais que c’était parce que j’utilisais un sous-sous-domaine (Let's Encrypt with sub-subdomain?), mais j’ai essayé avec un sous-domaine régulier et le certificat ne se génère toujours pas pour le nouveau site.

J’essaie de comprendre comment vous avez réussi à le faire fonctionner, mais je n’arrive pas à suivre :grimacing:

Qu’avez-vous fait pour que cela fonctionne pour vous ?

Si c’était cela, lesquelles des instructions if avez-vous commentées ?

Avez-vous également une idée de ce qui pourrait causer ce nouveau problème ?

1 « J'aime »
98

Mon problème était lié à un nom de domaine expiré dans ma configuration multisite :

2 « J'aime »
99

Salut @Brahn,

Merci pour la récente mise à jour de tes instructions.

Je rencontrais une erreur de certificat après avoir pointé mon domaine racine vers un sous-domaine. J’ai mis à jour mon fichier app.yml avec la version plus récente que tu voulais tester, et le problème est résolu. :slightly_smiling_face:

4 « J'aime »
100

J’ai également dû implémenter cela, après avoir changé de domaine et que la redirection ait échoué.

J’ai apporté une petite modification au wiki, supprimant les anciennes instructions et corrigeant les espaces dans les nouvelles.

Cependant, cela ne semble pas avoir fonctionné jusqu’à présent. Je suspecte que je dois forcer l’émission d’un nouveau certificat. Quelqu’un peut-il me guider sur la façon de le faire facilement ?

101

Je suis presque certain d’avoir fait une reconstruction. Il se pourrait que quelque chose ait encore changé. Avez-vous toujours l’ancien certificat ? Quel est le nom d’hôte ? Vous pouvez m’envoyer un message privé si vous le souhaitez.

102

Merci Jay - forum.hinz.org.nz est l’ancien domaine (et ehealthforum.nz le nouveau).\n\nJ’ai fait une reconstruction, (web_only uniquement en tant que 2-container) mais cela ne semble pas avoir résolu le problème.

103

Vous avez aussi changé le nom d’hôte ? Avez-vous changé le nom de domaine ou renommé votre Discourse ?

Conseil non sollicité : La meilleure pratique semble être d’opter pour le www plutôt que pour le domaine apex. Les navigateurs que j’utilise rendent presque impossible de savoir que le www est là.

Ma seule supposition est que l’espace final à l’intérieur des guillemets est significatif et que vous ne l’avez pas ?

Je pense que j’irais dans le conteneur, j’explorerais et j’essaierais d’exécuter acme comme il le fait et je verrais ce qui se passe ; je ne me souviens jamais comment faire cela ou où chercher la commande acme ; je dois le découvrir à chaque fois, donc je ne peux pas vous le dire. Vous pourriez peut-être le voir à partir de docker logs web_only.

Je jure que cela a fonctionné la dernière fois que j’ai modifié cela. J’ai juste vérifié le site auquel je l’ai appliqué et il semble avoir son certificat valide supplémentaire qui fonctionne. Mais il est concevable qu’il ait une image de base différente de celle qui existe maintenant et qu’il soit cassé lors de la prochaine reconstruction.

J’essaierai de vérifier cela à nouveau quand j’en aurai l’occasion. Peut-être la semaine prochaine.

1 « J'aime »
104

Oui - j’ai fait tout cela sans problème.

En effet - mais cela ne vaut la peine que si vous prévoyez d’utiliser un CDN ou des sous-domaines (ce que je ne fais pas) :
https://hostadvice.com/blog/domains/what-is-apex-domain/

J’ai essayé de l’ajouter, mais cela n’a pas fait de différence.

C'est assez éclairant (cliquez pour révéler)

> root@forumhinz:/var/discourse# docker logs web_only
> run-parts: executing /etc/runit/1.d/00-ensure-links
> run-parts: executing /etc/runit/1.d/00-fix-var-logs
> run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
> run-parts: executing /etc/runit/1.d/anacron
> run-parts: executing /etc/runit/1.d/cleanup-pids
> Cleaning stale PID files
> run-parts: executing /etc/runit/1.d/copy-env
> run-parts: executing /etc/runit/1.d/letsencrypt
> [Sat 9 Sep 08:19:27 UTC 2023] Domains not changed.
> [Sat 9 Sep 08:19:27 UTC 2023] Skip, Next renewal time is: 2023-10-26T08:24:32Z
> [Sat 9 Sep 08:19:27 UTC 2023] Add ‘–force’ to force to renew.
> [Sat 9 Sep 08:19:29 UTC 2023] Installing key to: /shared/ssl/ehealthforum.nz.key
> [Sat 9 Sep 08:19:29 UTC 2023] Installing full chain to: /shared/ssl/ehealthforum.nz.cer
> [Sat 9 Sep 08:19:29 UTC 2023] Run reload cmd: sv reload nginx
> warning: nginx: unable to open supervise/ok: file does not exist
> [Sat 9 Sep 08:19:29 UTC 2023] Reload error for :
> [Sat 9 Sep 08:19:29 UTC 2023] Domains not changed.
> [Sat 9 Sep 08:19:30 UTC 2023] Skip, Next renewal time is: 2023-10-26T08:24:45Z
> [Sat 9 Sep 08:19:30 UTC 2023] Add ‘–force’ to force to renew.
> [Sat 9 Sep 08:19:31 UTC 2023] Installing key to: /shared/ssl/ehealthforum.nz_ecc.key
> [Sat 9 Sep 08:19:31 UTC 2023] Installing full chain to: /shared/ssl/ehealthforum.nz_ecc.cer
> [Sat 9 Sep 08:19:31 UTC 2023] Run reload cmd: sv reload nginx
> warning: nginx: unable to open supervise/ok: file does not exist
> [Sat 9 Sep 08:19:31 UTC 2023] Reload error for :
> Started runsvdir, PID is 570
> supervisor pid: 578 unicorn pid: 590

Cela implique que si je ne trouve pas le moyen de forcer le renouvellement, je devrai attendre le 2023-10-26T08:24:00Z avant que le problème ne se résolve de lui-même !

Je vais essayer quelques choses - souhaitez-moi bonne chance.

plus tard…

Succès !

Eh bien, après avoir essayé plusieurs fois sans succès de relancer le renouvellement du certificat, j’ai finalement déménagé sur un nouveau serveur (ce qui était déjà prévu).

Sans surprise, cela a parfaitement renouvelé le certificat avec les paramètres de l’OP. Allez comprendre.

Je ne sais pas comment faire mieux à l’avenir. Peut-être établir les paramètres de votre DNS à partir de votre nouveau domaine un mois ou deux à l’avance, et ajouter ces lignes à votre app.yml à ce moment-là.

2 « J'aime »
105

J’ai ajouté ceci à mon fichier app.yml, dois-je reconstruire ? ou cela fonctionne-t-il simplement ?
également dans le
“from: /-d www.first-domain.com/” dois-je mettre le domaine vers lequel je veux rediriger ou mon sous-domaine ?

1 « J'aime »
106

Oui, toute modification dans app.yml nécessite généralement une reconstruction.

3 « J'aime »
107

J’ai reconstruit et maintenant mon site n’est plus accessible. Dois-je reconstruire à nouveau ?
il dit ceci après la reconstruction

"Pups::ExecError : cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile' a échoué avec le retour #<Process::Status: pid 3575 exit 134>
Emplacement de l'échec : /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec a échoué avec les paramètres {\"cd\"=>\"$home\", \"hook\"=>\"assets_precompile\", \"cmd\"=>[\"su discourse -c 'bundle exec rake themes:update assets:precompile'\"]}
bootstrap a échoué avec le code de sortie 134
** ÉCHEC DU BOOTSTRAP ** veuillez faire défiler vers le haut et rechercher les messages d'erreur précédents, il peut y en avoir plus d'un."
1 « J'aime »
108

Le processus de reconstruction s’est-il déroulé sans problème et sans erreur ?

2 « J'aime »
109

Veuillez faire cela et partager les messages d’erreur.

2 « J'aime »
110 
110:M 10 déc. 2023 13:32:18.543 # Serveur initialisé
110:M 10 déc. 2023 13:32:18.543 # ATTENTION La pré-allocation de mémoire doit être activée ! Sans elle, une sauvegarde en arrière-plan ou la réplication peut échouer dans des conditions de faible mémoire. Désactivée, elle peut également causer des échecs sans condition de faible mémoire, voir https://github.com/jemalloc/jemalloc/issues/1328. Pour corriger ce problème, ajoutez 'vm.overcommit_memory = 1' à /etc/sysctl.conf puis redémarrez ou exécutez la commande 'sysctl vm.overcommit_memory=1' pour que cela prenne effet.
110:M 10 déc. 2023 13:32:18.544 * Chargement du RDB produit par la version 7.0.7

J’ai reçu ces avertissements, je ne suis pas sûr si c’est important.

warning « > @glint/environment-ember-loose@1.1.0 » a une dépendance pair non satisfaite « @glimmer/component@^1.1.2 ».
warning « > @glint/environment-ember-template-imports@1.1.0 » a une dépendance pair non satisfaite « ember-template-imports@^3.0.0 ».
warning Le champ de résolution « unset-value@2.0.1 » est incompatible avec la version demandée « unset-value@^1.0.0 »
warning Le modèle [« wrap-ansi@^7.0.0 »] essaie de se décompresser dans la même destination « /home/discourse/.cache/yarn/v6/npm-wrap-ansi-cjs-7.0.0-67e145cff510a6a6984bdf1152911d69d2eb9e43-integrity/node_modules/wrap-ansi-cjs » que le modèle [« wrap-ansi-cjs@npm:wrap-ansi@^7.0.0 »]. Cela pourrait entraîner un comportement non déterministe, en cours d'ignorance.
warning « > discourse-markdown-it@1.0.0 » a une dépendance pair non satisfaite « xss@* ».
warning « workspace-aggregator-68bace53-129d-4a2d-85c3-4685b91c92ee > discourse > @ember/legacy-built-in-components@0.5.0 » a une dépendance pair incorrecte « ember-source@>= 4.8 ».
warning « workspace-aggregator-68bace53-129d-4a2d-85c3-4685b91c92ee > discourse > @uppy/aws-s3@3.0.6 » a une dépendance pair incorrecte « @uppy/core@^3.1.2 ».
warning « workspace-aggregator-68bace53-129d-4a2d-85c3-4685b91c92ee > discourse > @uppy/aws-s3-multipart@3.1.3 » a une dépendance pair incorrecte « @uppy/core@^3.1.2 ».
warning « workspace-aggregator-68bace53-129d-4a2d-85c3-4685b91c92ee > discourse > @uppy/xhr-upload@3.1.1 » a une dépendance pair incorrecte « @uppy/core@^3.1.2 ».
warning « workspace-aggregator-68bace53-129d-4a2d-85c3-4685b91c92ee > discourse-plugins > ember-this-fallback@0.4.0 » a une dépendance pair non satisfaite « ember-source@^3.28.11 || ^4.0.0 ».
warning « workspace-aggregator-68bace53-129d-4a2d-85c3-4685b91c92ee > discourse > @uppy/aws-s3 > @uppy/xhr-upload@3.3.0 » a une dépendance pair incorrecte « @uppy/core@^3.2.1 ».

<--- Derniers GC ---

[3710:0x6291170]   681247 ms: Scavenge 942.0 (1034.0) -> 940.8 (1034.0) Mo, 62.9 / 0.0 ms  (mu moyen = 0.704, mu actuel = 0.878) échec d'allocation ;
[3710:0x6291170]   681616 ms: Scavenge 942.4 (1034.0) -> 941.4 (1034.0) Mo, 18.3 / 0.0 ms  (mu moyen = 0.704, mu actuel = 0.878) échec d'allocation ;
[3710:0x6291170]   681911 ms: Scavenge 943.0 (1034.0) -> 942.0 (1038.0) Mo, 46.8 / 0.0 ms  (mu moyen = 0.704, mu actuel = 0.878) échec d'allocation ;

ERREUR FATALE : Limite du tas atteinte Échec d'allocation - Tas JavaScript hors mémoire
 1: 0xb83f50 node::Abort() [ember]
 2: 0xa94834  [ember]
 3: 0xd647c0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [ember]
 4: 0xd64b67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [ember]
 5: 0xf42265  [ember]
 6: 0xf5474d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [ember]
 7: 0xf2ee4e v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [ember]
 8: 0xf30217 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [ember]
 9: 0xf113ea v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [ember]
10: 0x12d674f v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [ember]
11: 0x17035b9  [ember]
Abandonné (noyau vidé)
error La commande a échoué avec le code de sortie 134.

et mon site dit

Ce site est inaccessible

forum.mysite.ca a refusé de se connecter.

Essayez :

  • De vérifier la connexion
  • De vérifier le proxy et le pare-feu

ERR_CONNECTION_REFUSED

voici à quoi ressemble mon app.yml

hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/discourse/discourse-zoom.git
  after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: "-d www.mysite.ca/"
        to: "-d www.mysite.ca -d mysite.ca "
## Toutes les commandes personnalisées à exécuter après la construction
1 « J'aime »
111

Quelle quantité de mémoire votre serveur possède-t-il et avez-vous activé le swap (free -h pour voir) ?

112 
               total        used        free      shared  buff/cache   available
Mem:             957         190         371           3         395         613
Swap:           2047          79        1968
113

Votre serveur dispose de 1 Go de RAM et de 2 Go alloués pour le swap. Étonnamment, le processus de reconstruction échouerait avec cette capacité de swap.
Vous pouvez essayer de reconstruire à nouveau. Si cela échoue, vous devrez peut-être mettre à niveau la mémoire du serveur, si possible (uniquement pour le processus de construction, vous pourrez la réduire une fois terminé).

1 « J'aime »