Non credo che sia più così.
Esattamente @jomaxro. Per questo ho detto:
Oh. Scusa, ho perso quella modifica.
Quindi, se l’utente non fornisce un indirizzo email per le notifiche di Let’s Encrypt, discourse-setup abilita ora Let’s Encrypt senza verificare che il dominio risolve al server corrente. Ma se si fornisce un indirizzo email, allora viene eseguita la verifica. Questa non sembra una buona idea.
Perché forzare HTTPS se non si dispone di un nome di dominio valido? Se l’obiettivo è costringere tutti a utilizzare HTTPS in ogni momento, dovremmo verificare che il nome di dominio sia valido e poi rifiutarsi di eseguire, piuttosto che fornire un’installazione non funzionante.
Nel modo in cui funziona ora, se non si fornisce un indirizzo email per Let’s Encrypt e il dominio non risolve al server, discourse-setup sembra avere successo, ma avvia un server web che non accetta connessioni perché nginx non riesce a trovare un certificato. Penso che sarebbe meglio non richiedere un indirizzo email per Let’s Encrypt, utilizzare l’indirizzo email del (primo?) sviluppatore per Let’s Encrypt ed eseguire comunque il test DNS, ma ora questo non appartiene a questo argomento.
No, non è così che funziona Let’s Encrypt. L’email non ha nulla a che fare con la validazione del dominio. Viene utilizzata per avvisare l’utente se il certificato sta per scadere e non può essere rinnovato. La validazione viene sempre effettuata tramite DNS.
Let’s Encrypt non può emettere un certificato per un indirizzo che non soddisfa i requisiti di validazione. Se lo facesse, l’intero sistema di LE collasserebbe in una notte.
No. È così che funziona discourse-setup, o almeno così funzionava. In passato proteggeva gli utenti da richieste di certificati quando era quasi certo che sarebbero fallite. Ora, invece, procede comunque, richiede un certificato anche quando è impossibile che abbia successo e non ha alcun modo di segnalare all’utente che non ha funzionato, così ora fallisce silenziosamente senza alcun avviso.
Di nuovo, perché dovrebbe fallire? L’email non è un requisito per la verifica del dominio.
Il fallimento non ha mai generato un’email.
L’email serve solo per informare l’utente in un secondo momento se Let’s Encrypt non riesce a rinnovare e un certificato sta per scadere. Se il rinnovo avviene senza problemi, l’utente non riceverà mai un’email.
Non credo che questo fosse lo scopo della modifica. L’intenzione era abilitare SSL indipendentemente dalla presenza di un indirizzo email. Dovremmo comunque verificare la risoluzione del dominio, @Falco.
Fallirà se il nome di dominio non risolve l’host. L’indirizzo email non è rilevante, ma se è presente, la configurazione di Discourse avviserà l’utente se l’indirizzo non risolve.
La risoluzione del dominio deve passare per @falco, altrimenti l’installazione deve fermarsi. Questo è un cambiamento negativo.
Quindi ho apportato alcune modifiche in un branch. Ecco come funzionerà:
Utilizzo di un nome host errato:
root@droplet:/var/discourse# ./discourse-setup
Nome host per il tuo Discourse?: bad-domain.com
Verifica del nome di dominio . . .
AVVISO:: Questo server non sembra essere accessibile su bad-domain.com:443.
Anche una connessione a http://bad-domain.com (porta 80) fallisce.
Ciò suggerisce che bad-domain.com risolve all'indirizzo IP sbagliato
o che il traffico non viene instradato al tuo server.
Google: "apri le porte IL TUO SERVIZIO CLOUD" per informazioni su come risolvere questo problema.
Se vuoi procedere comunque, dovrai eseguire cp samples/standalone.yml containers/app.yml
e modificare manualmente il file containers/app.yml.
Utilizzo di un nome host corretto:
root@droplet:/var/discourse# ./discourse-setup
Nome host per il tuo Discourse?: good-domain.com
Verifica del nome di dominio . . .
Connessione a good-domain.com riuscita.
Indirizzo email per gli account amministratore? :
Le modifiche sono in sospeso su
Sembra tutto a posto @pfaffman @codinghorror?
Commento sul perché questa modifica fosse necessaria
Innanzitutto, sono sorpreso che in quasi 3 mesi da quando è stato introdotto questo cambiamento non ci siano state molte lamentele, e persino l’argomento che ha attirato la mia attenzione non stava avendo problemi a causa di questa modifica, quindi forse è meno importante di quanto penso.
La prima cosa che non capisco davvero è: volete davvero rendere impossibile configurare un sito solo HTTP con discourse-setup? Immagino che abbiano già dovuto fare una serie di configurazioni DNS per far funzionare la posta, quindi forse non è un problema così grande dover creare anche il record A.
Feedback sulla modifica
A meno che non abbiate apportato una modifica che non ho notato, lo script crea app.yml prima di iniziare a porre domande, quindi potreste semplicemente dire qualcosa come: “L’installazione di Discourse senza configurazione DNS non è supportata. Per continuare senza configurazione DNS, modificate app.yml secondo le vostre esigenze ed eseguite ./launcher rebuild app” e poi uscire senza avviare il processo di bootstrap.
Inoltre, se intendete imporre che tutti debbano utilizzare Let’s Encrypt e HTTPS, potrebbe avere senso modificare di conseguenza standalone.yml e web_only.yml, eliminando così quelle complicate istruzioni sed.
Altre riflessioni
Dal dipartimento “questo è il mio problema”, il mio script di installazione attuale viene eseguito prima che gli utenti possano configurare il DNS, poiché creo il droplet per loro, configuro Discourse, invio loro un’email con le istruzioni DNS, attendo che il DNS sia configurato e poi modifico app.yml per abilitare i template e impostare l’indirizzo di Let’s Encrypt. Ma immagino che sia solo per motivi storici; ciò che dovrei fare invece è creare il droplet, configurare Mailgun, attendere il DNS e poi procedere con l’installazione. Questo permetterebbe comunque al mio script di utilizzare discourse-setup, cosa che mi piace fare come test frequente per verificare che funzioni ancora (non credo che voi abbiate un test automatizzato per discourse-setup, vero?)
Sì.
Non ho ricevuto alcuna lamentela su questa modifica e da quando è stata attivata non vedo più molte istanze Discourse configurate solo con HTTP, perché quando dici che qualcosa è OPZIONALE, tutti lo saltano senza pensarci. A mio avviso, questo è un ottimo cambiamento per avere impostazioni predefinite sicure per Discourse, che è esattamente l’obiettivo della guida di 30 minuti.
Ah, questa è ancora meglio, servono meno istruzioni!
Ah, ora capisco la tua forte reazione a questa modifica, dato che ha rotto la tua configurazione, mi dispiace per questo.
Consiglierei vivamente di utilizzare direttamente il file yml per qualsiasi automazione invece di puntare allo script interattivo.
tl;dr: Sì, con la piccola modifica linguistica che ho consigliato, mi sembra tutto a posto.
Concordo. Zero reclami! Sembra una vittoria.
No! Non l’ha fatto. (!) Ho solo notato in modo approssimativo che i siti non si caricavano prima di completare la seconda fase dell’installazione che abilita HTTPS. E la mia configurazione non è tua responsabilità. (Oh, ORA romperà il mio script, ma non eseguire l’installazione prima che il DNS sia configurato sarà comunque meglio. Non eseguo un’installazione non HTTPS da almeno un anno.)
Il motivo per cui mi piaceva che il mio script utilizzasse discourse-setup è che si assicura in modo extra-speciale che i clienti della mia installazione ricevano un’installazione Standard, e che quando qualcuno dice “Ho fatto un’installazione e non ha funzionato” posso eseguire il mio script e fare esattamente quello che avrebbero dovuto fare, dicendo “Beh, ho appena fatto un’installazione e ha funzionato.” Ma non credo di ricordare un momento negli ultimi 3 anni in cui abbia trovato un problema, quindi forse il mio “test” non sta facendo bene a nessuno.
Bene, grazie per l’analisi e la recensione!
Ho unito la PR, quindi ora convalidiamo sempre il DNS.