Innanzitutto, un plauso dove è dovuto: il nuovo installer è un grande miglioramento. Quando funziona, che è la maggior parte delle volte, offre un percorso molto più user-friendly rispetto al vecchio flusso manuale, e riesco a completare installazioni pulite grazie ad esso. Esegui l’installer, completa la registrazione/attivazione come di consueto, poi procedi a regolare app.yml secondo le mie specifiche. Facile come bere un bicchiere d’acqua. Un enorme grazie a @Falco e al Team! Che differenza enorme rispetto ai vecchi tempi dell’installazione di Discourse.
Pubblico questo post perché ho anche incontrato un hostname che mi ha dato non pochi grattacapi, e credo che questa esperienza possa evidenziare alcuni punti in cui l’installer potrebbe fornire informazioni più chiare per gli auto-hosters.
Cosa ha funzionato
Ho installato Discourse con successo su un server nuovo usando:
- dominio personale: sì
- SMTP: sì
- il flusso dell’installer attuale
L’installazione ha raggiunto:
Tallyho!
Congratulazioni, hai installato Discourse!
Registra un nuovo account per iniziare.
Quindi questo non è un post del tipo “il nuovo installer è rotto”. L’installer può funzionare molto bene.
L’hostname problematico
In un’altra installazione, seguendo lo stesso percorso generale, l’hostname di destinazione era:
forum.domain.tld
Il comando dell’installer era:
wget -qO- https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse | sudo bash
Le scelte erano approssimativamente:
- crea file swap da 2 GB: sì
- usa il mio dominio personale: sì
- hostname:
forum.domain.tld - configura SMTP: sì
- provider SMTP: SendGrid
- porta SMTP: 587
L’installer ha raggiunto:
[4/5] Verifica configurazione dominio
? Verifica del nome del dominio...
? Connessione a forum.domain.tld riuscita.
Ha quindi scritto la configurazione e ricostruito l’applicazione.
Ma il sito non si è caricato correttamente nel browser. Il sintomo alla fine è diventato:
forum.domain.tld ha rifiutato la connessione
Tentativi ripetuti di ricostruzione/ritentativo non hanno risolto il problema.
Risultato di Discourse Doctor
./discourse-doctor ha trovato il contenitore dell’applicazione e i valori di configurazione previsti. Il contenitore era in esecuzione e le porte 80/443 sembravano essere assegnate.
Ma ha segnalato:
Versione Discourse su forum.domain.tld: NON TROVATA
e in seguito:
Versione Discourse su localhost: NON TROVATA
Questo ha fatto sembrare il problema diverso dalla semplice propagazione DNS pubblica.
Limite di frequenza ACME
In una fase precedente del troubleshooting, ho anche tentato installazioni usando i percorsi assistiti dal servizio Discourse:
- DiscourseID
- il flusso
yoursite.discourse.diy
È lì che si è verificato il comportamento di ripetuti tentativi sul server, e dove il log ACME mostrava un limite di frequenza di Let’s Encrypt:
tipo: urn:ietf:params:acme:error:rateLimited
stato: 429
dettagli: troppi certificati (5) già emessi per questo esatto set di identificatori...
Il percorso del log utile era:
/shared/letsencrypt/acme.sh.log
Questa è stata una grande lezione. Dal browser, il fallimento sembrava un generico problema di raggiungibilità. Ma il vero ostacolo in quel momento era l’emissione del certificato.
La parte più confusa era che il blocco di stato finale/completamento dell’installazione non segnalava questo come un errore risolvibile. Il sintomo finale visibile all’utente era semplicemente che il sito rifiutava la connessione del browser.
Controlli successivi hanno mostrato più chiaramente la catena di fallimenti:
Limite di frequenza ACME 429
-> file .cer di zero byte sotto /shared/ssl
-> nginx tenta di caricare il certificato di zero byte
-> avvio di nginx fallito
-> porte 80/443 rifiutate
-> browser dice connessione rifiutata
Richiesta di funzionalità nascosta nell’esperienza:
Sarebbe molto utile se la routine dell’installer/ricostruzione controllasse /shared/letsencrypt/acme.sh.log dopo il passaggio del certificato e segnalasse errori di limite di frequenza come:
rateLimited
troppi certificati
stato: 429
Per esempio:
Raggiunto il limite di frequenza di Let's Encrypt per questo hostname.
Attendi fino all'ora di retry-after mostrata in /shared/letsencrypt/acme.sh.log prima di ritentare.
Ricostruzioni ripetute potrebbero non aiutare.
Ciò risparmierebbe agli utenti di inseguire problemi DNS, SMTP, quotazione di app.yml, Docker o firewall quando il problema reale è ACME.
Dopo la scadenza del limite di frequenza
Dopo che la finestra del limite di frequenza di Let’s Encrypt si è esaurita, ho ancora visto una situazione di validazione del dominio confusa.
L’installer ha segnalato:
[4/5] Verifica configurazione dominio
? Verifica del nome del dominio...
? Connessione a forum.domain.tld riuscita.
Ma una ricerca DNS locale mostrava ancora:
Resolve-DnsName -Name "forum.domain.tld"
con:
Resolve-DnsName: forum.domain.tld : nome DNS non esiste.
Come possono coesistere queste due cose?
Posso immaginare diverse possibilità:
- il server e la workstation usavano resolver ricorsivi diversi
- un resolver aveva in cache NXDOMAIN obsoleto
- la propagazione DNS era parziale in quel momento
- l’installer controllava qualcosa di diverso da una semplice ricerca DNS
- l’installer o un servizio correlato aveva in cache lo stato di validazione
Non affermo quale sia vera. Segnalo principalmente che dal punto di vista dell’utente, l’installer che dice “connessione riuscita” può rendere più difficili da interpretare gli errori DNS o di raggiungibilità successivi.
Controllo isolamento DNS
Per testare se si trattava solo di una lenta propagazione di Cloudflare, ho aggiunto un altro record nella stessa zona:
test.domain.tld
Dentro pochi momenti, i risultati del controllore DNS pubblico erano verdi.
Ciò mi ha reso meno sicuro che la propagazione generale di Cloudflare fosse l’unico problema. Sembrava più che il problema fosse specifico per forum.domain.tld.
Installazioni di confronto
Ho anche avuto un’installazione riuscita su un altro hostname:
discourse.domain2.tld
usando lo stesso percorso generale dell’installer.
Un altro hostname di test, per le diagnostiche DNS, era:
forum.domain3.tld
Le installazioni di confronto sono ciò che mi ha allontanato dall’idea “il nuovo installer è rotto” verso “qualcosa di specifico per l’hostname è accaduto qui.”
Teoria attuale
La mia teoria attuale, non provata, è che forum.domain.tld possa aver avuto qualche stato memorizzato/cache/reservato specifico per l’hostname da qualche parte al di fuori del server stesso.
Posti su cui ho riflettuto:
- DiscourseID
- il flusso
yoursite.discourse.diy - validazione del dominio lato installer
- qualche relazione in cache tra un tentativo di configurazione precedente e l’hostname
Il motivo per cui rifletto su questi percorsi assistiti dal servizio è che li avevo precedentemente provati con lo stesso hostname problematico, e questo era anche il percorso in cui i tentativi ripetuti alla fine hanno raggiunto il limite di frequenza di Let’s Encrypt.
Ancora una volta, questa è un’ipotesi, non una conclusione.
Domande
- Il nuovo installer contatta un servizio controllato da Discourse durante le installazioni con dominio personale?
- DiscourseID o il flusso
discourse.diyriservano, memorizzano o mettono in cache gli hostnames? - Esiste un percorso di rilascio/reset per un hostname che è stato precedentemente usato o tentato durante la configurazione?
- Cosa controlla esattamente
[4/5] Verifica configurazione dominio? - L’installer potrebbe segnalare più chiaramente i fallimenti del limite di frequenza ACME prima del blocco di stato/risultato finale?
Cosa avrebbe aiutato
Tre cose avrebbero reso il percorso di troubleshooting molto più chiaro:
- Un chiaro avviso dell’installer quando
/shared/letsencrypt/acme.sh.logcontiene un fallimento di limite di frequenza. - Una breve spiegazione di cosa controlla effettivamente il passaggio di verifica del dominio.
- Se esiste una cache o riserva di hostname lato DiscourseID /
discourse.diy/ installer, un modo visibile per ispezionare o rilasciare quello stato.
Grazie ancora per il lavoro sul nuovo installer. Si sente davvero come la direzione giusta. Pubblico questo in quello spirito: ha funzionato magnificamente quando ha funzionato, e l’aspérité qui sembra essere il tipo di cosa che una migliore comunicazione dell’installer potrebbe rendere molto più facile da diagnosticare.
Scritto con i miei input dal mio nuovo migliore amico Codex.