Configura Let's Encrypt con più domini / reindirizzamenti

Oh, wow, finalmente ha funzionato:

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

Ho commentato le istruzioni if nello script letsencrypt per forzare una riemissione. Questa non è una soluzione ‘di fabbrica’, ovviamente.

Tuttavia, suggerisce che c’era un problema con lo ‘stato’ piuttosto che con le opzioni fornite.

Sembra che lo script attuale possa bloccarsi a seconda dello stato precedente, ma se si forza una riemissione è possibile risolverlo.

Ma ora ho un dominio apex funzionante! :tada:

4 Mi Piace

Fa parte dell’installazione standard. Vedi User Guide — Certbot 5.1.0 documentation e scorri fino a Gestione dei certificati e anche subito sotto, Ricreazione e aggiornamento dei certificati esistenti.

Questi comandi verrebbero eseguiti da dove hai eseguito Certbot inizialmente.

1 Mi Piace

Non sto usando certbot. Non è a livello di server “normale”, né se dico prima ./launcher enter app.

Suppongo che manchi a causa di acme.sh.

3 Mi Piace

Penso di avere lo stesso problema. Pensavo fosse perché usavo un sottodominio secondario (Let's Encrypt with sub-subdomain?) ma ho provato con un sottodominio normale e il certificato non viene ancora generato per il nuovo sito.

Sto cercando di capire come hai fatto a farlo funzionare, ma non riesco a seguirti :grimacing:

Cosa hai fatto per farlo funzionare per te?

Se fosse questo, quali delle istruzioni if hai commentato?

Inoltre, hai idea di cosa potrebbe causare questo nuovo problema?

1 Mi Piace

Il mio problema era correlato a un nome di dominio scaduto nella mia configurazione multisito:

2 Mi Piace

Ciao @Brahn,

Grazie per il recente aggiornamento alle tue istruzioni.

Stavo riscontrando un errore del certificato dopo aver puntato il mio dominio principale a un sottodominio. Ho aggiornato il mio file app.yml con la versione più recente che volevi testare e il problema è risolto. :slightly_smiling_face:

4 Mi Piace

Ho appena dovuto implementare anche questo, dopo aver cambiato dominio e il reindirizzamento non è andato a buon fine.

Ho apportato una piccola modifica alla wiki, rimuovendo le vecchie istruzioni e correggendo gli spazi in quelle nuove.

Tuttavia, finora non sembra aver funzionato. Sospetto di dover forzare l’emissione di un nuovo certificato. Qualcuno può guidarmi su come farlo facilmente?

Sono abbastanza sicuro di aver appena fatto una ricompilazione. Potrebbe essere che qualcosa sia cambiato di nuovo. Hai ancora il vecchio certificato? Qual è il nome host? Puoi mandarmi un messaggio privato se vuoi.

Grazie Jay - forum.hinz.org.nz è il vecchio dominio (e ehealthforum.nz il nuovo).\n\nHo eseguito una ricostruzione, (solo web_only come 2-container) ma ciò non sembra aver risolto il problema.

Hai cambiato anche il nome dell’host? Hai modificato il nome del dominio o rinominato il tuo Discourse?

Consiglio non richiesto: la best practice sembra essere quella di usare il www piuttosto che il dominio apex. I browser che uso rendono quasi impossibile capire che il www sia presente.

La mia unica ipotesi è che lo spazio finale all’interno delle virgolette sia significativo e tu non lo abbia?

Penso che entrerei nel container e darei un’occhiata e proverei a eseguire acme nel modo in cui lo fa e vedrei cosa succede; non riesco mai a ricordare come fare o dove cercare il comando acme; devo scoprirlo ogni volta, quindi non posso dirtelo. Potresti essere in grado di vederlo da docker logs web_only.

Giuro che questo ha funzionato l’ultima volta che ho modificato questo. Ho appena controllato il sito a cui l’ho applicato e sembra che abbia il suo certificato valido aggiuntivo funzionante. Ma è concepibile che abbia un’immagine di base diversa da quella attuale e che si rompa al prossimo rebuild.

Cercherò di controllare di nuovo quando ne avrò la possibilità, forse la prossima settimana.

1 Mi Piace

[quote=“Jay Pfaffman, post:103, topic:56685, username:pfaffman”]
Hai cambiato anche il nome host? Hai Modificato il nome di dominio o rinominato il tuo Discourse?
[/quote]Sì, ho fatto tutto senza problemi.

[quote=“Jay Pfaffman, post:103, topic:56685, username:pfaffman”]
Consiglio non richiesto: la Best Practice sembra essere quella di utilizzare il www piuttosto che il dominio apex. I browser che uso rendono quasi impossibile accorgersi che il www sia presente.
[/quote]Infatti, ma vale la pena farlo solo se si prevede di utilizzare una CDN o sottodomini (io non lo faccio):
https://hostadvice.com/blog/domains/what-is-apex-domain/

[quote=“Jay Pfaffman, post:103, topic:56685, username:pfaffman”]
La mia unica ipotesi è che lo spazio finale tra le virgolette sia significativo e tu non lo abbia?
[/quote]Ho provato ad aggiungerlo, ma non ha fatto differenza.

[details=“Questo è piuttosto illuminante (clicca per rivelare)”]

> 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
[/details]Questo implica che se non riesco a trovare un modo per forzarlo a rinnovarsi, dovrò aspettare fino al 2023-10-26T08:24:00Z prima che il problema si risolva da solo!

Proverò alcune cose, auguratemi buona fortuna.

più tardi…

Successo!

Beh, dopo aver provato e fallito diverse volte ad avviare il rinnovo del certificato, alla fine mi sono spostato su un nuovo server (questo era già pianificato).

Sorprendentemente, questo ha rinnovato perfettamente il certificato con le impostazioni nell’OP. Chi l’avrebbe mai detto.

Non sono sicuro di come fare meglio in futuro. Forse stabilire le impostazioni DNS dal nuovo dominio un mese o due in anticipo e inserire quelle righe nel tuo app.yml allora.

2 Mi Piace

Ho aggiunto questo al mio file app.yml, devo ricostruire? o funziona e basta?
inoltre nel
“from: /-d www.first-domain.com/” devo mettere il dominio a cui voglio reindirizzare o il mio sottodominio?

1 Mi Piace

Sì, qualsiasi modifica in app.yml richiede solitamente una ricompilazione.

3 Mi Piace

Ho ricostruito e ora il mio sito non è raggiungibile. Devo ricostruire di nuovo?
dice questo dopo la ricostruzione

"Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile' fallito con ritorno #<Process::Status: pid 3575 exit 134>
Posizione del fallimento: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec fallito con i parametri {\"cd\"=>\"$home\", \"hook\"=>\"assets_precompile\", \"cmd\"=>[\"su discourse -c 'bundle exec rake themes:update assets:precompile'\"]}
bootstrap fallito con codice di uscita 134
** FALLITO IL BOOTSTRAP ** si prega di scorrere verso l'alto e cercare messaggi di errore precedenti, potrebbero essercene più di uno."
1 Mi Piace

La ricostruzione è andata a buon fine senza errori?

2 Mi Piace

Per favore fallo e condividi i messaggi di errore.

2 Mi Piace
110:M 10 Dec 2023 13:32:18.543 # Server inizializzato
110:M 10 Dec 2023 13:32:18.543 # ATTENZIONE La sovra-allocazione della memoria deve essere abilitata! Senza di essa, un salvataggio in background o la replica potrebbero fallire in condizioni di memoria insufficiente. Se disabilitata, può anche causare fallimenti senza condizioni di memoria insufficiente, vedi https://github.com/jemalloc/jemalloc/issues/1328. Per risolvere questo problema, aggiungi 'vm.overcommit_memory = 1' a /etc/sysctl.conf e quindi riavvia o esegui il comando 'sysctl vm.overcommit_memory=1' affinché abbia effetto.
110:M 10 Dec 2023 13:32:18.544 * Caricamento RDB prodotto dalla versione 7.0.7

Ho ricevuto questi avvisi, non sono sicuro se siano importanti.

warning "@glint/environment-ember-loose@1.1.0" ha dipendenze peer non soddisfatte "@glimmer/component@^1.1.2".
warning "@glint/environment-ember-template-imports@1.1.0" ha dipendenze peer non soddisfatte "ember-template-imports@^3.0.0".
warning Il campo di risoluzione "unset-value@2.0.1" è incompatibile con la versione richiesta "unset-value@^1.0.0"
warning Il pattern ["wrap-ansi@^7.0.0"] sta cercando di decomprimere nella stessa destinazione "/home/discourse/.cache/yarn/v6/npm-wrap-ansi-cjs-7.0.0-67e145cff510a6a6984bdf1152911d69d2eb9e43-integrity/node_modules/wrap-ansi-cjs" del pattern ["wrap-ansi-cjs@npm:wrap-ansi@^7.0.0"]. Ciò potrebbe comportare un comportamento non deterministico, saltando.
warning "> discourse-markdown-it@1.0.0" ha dipendenze peer non soddisfatte "xss@*".
warning "workspace-aggregator-68bace53-129d-4a2d-85c3-4685b91c92ee > discourse > @ember/legacy-built-in-components@0.5.0" ha una dipendenza peer errata "ember-source@>= 4.8".
warning "workspace-aggregator-68bace53-129d-4a2d-85c3-4685b91c92ee > discourse > @uppy/aws-s3@3.0.6" ha una dipendenza peer errata "@uppy/core@^3.1.2".
warning "workspace-aggregator-68bace53-129d-4a2d-85c3-4685b91c92ee > discourse > @uppy/aws-s3-multipart@3.1.3" ha una dipendenza peer errata "@uppy/core@^3.1.2".
warning "workspace-aggregator-68bace53-129d-4a2d-85c3-4685b91c92ee > discourse > @uppy/xhr-upload@3.1.1" ha una dipendenza peer errata "@uppy/core@^3.1.2".
warning "workspace-aggregator-68bace53-129d-4a2d-85c3-4685b91c92ee > discourse-plugins > ember-this-fallback@0.4.0" ha dipendenze peer non soddisfatte "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" ha una dipendenza peer errata "@uppy/core@^3.2.1".
<--- Ultime GC --->

[3710:0x6291170]   681247 ms: Scavenge 942.0 (1034.0) -> 940.8 (1034.0) MB, 62.9 / 0.0 ms  (mu medio = 0.704, mu corrente = 0.878) errore di allocazione;
[3710:0x6291170]   681616 ms: Scavenge 942.4 (1034.0) -> 941.4 (1034.0) MB, 18.3 / 0.0 ms  (mu medio = 0.704, mu corrente = 0.878) errore di allocazione;
[3710:0x6291170]   681911 ms: Scavenge 943.0 (1034.0) -> 942.0 (1038.0) MB, 46.8 / 0.0 ms  (mu medio = 0.704, mu corrente = 0.878) errore di allocazione;
ERRORE FATALE: Raggiunto il limite dell'heap Errore di allocazione - Heap JavaScript esaurito
 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]
Aborted (core dumped)
error Comando fallito con codice di uscita 134.

e il mio sito dice

Questo sito non può essere raggiunto

forum.mysite.ca ha rifiutato la connessione.

Prova:

  • A controllare la connessione
  • [A controllare il proxy e il firewall]

ERR_CONNECTION_REFUSED

questo è il mio 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 "
## Qualsiasi comando personalizzato da eseguire dopo la compilazione
1 Mi Piace

Quanta memoria ha il tuo server e hai lo swap abilitato (free -h per vedere)?

               totale        utilizzato      libero      condiviso  buff/cache   disponibile
Mem:             957         190         371           3         395         613
Swap:           2047          79        1968

Il tuo server ha 1 GB di RAM e 2 GB allocati per lo swap. Stranamente, il processo di ricostruzione fallirebbe con questa capacità di swap.
Puoi provare a ricostruire di nuovo. Se fallisce, potresti dover aumentare la memoria del server, se possibile (solo per il processo di compilazione, puoi ridurre le dimensioni una volta terminato).

1 Mi Piace