Durante la migrazione (tramite backup) di un Discourse da un hostname a un altro, un amministratore potrebbe voler mantenere il vecchio hostname ma configurare il server web per riscrivere le richieste in modo che utilizzino il nuovo nome canonico, ad esempio:
Sfortunatamente, non è sufficiente modificare semplicemente il record CNAME o A nel DNS; il client del browser genererà un errore o un avviso perché l’hostname non corrisponde al certificato generato dall’installazione di Discourse tramite Let’s Encrypt.
In un’installazione manuale di un server web, utilizzerei lo strumento certbot per generare un certificato con più nomi associati ad esso. Tuttavia, la configurazione di Discourse passa a Let’s Encrypt solo l’hostname di Discourse, e non vedo alcun concetto di alias nella configurazione di Discourse.
Qualcuno ha configurato una tale soluzione o ha un’idea su come realizzarla al meglio? Immagino che ciò richiederà alcune modifiche ai template SSL e Let’s Encrypt.
Non specifico di Discourse, ma quando devo reindirizzare su HTTPS reindirizzo tutto. Cioè, ho un server che gestisce il reindirizzamento dal vecchio indirizzo al nuovo. Alcune opzioni di hosting si occupano di questo in background, a volte chiamate servizio di “reindirizzamento di dominio” o “inoltro”.
Non ci penso nemmeno più, perché è sempre stato un dolore ogni volta che ho provato altro.
Discourse risponderà a un solo nome host. Se desideri più di un nome host – e il tuo caso d’uso, ovvero supportare il nome host precedente, è il più comune – allora dovrai reindirizzare uno all’altro.
Consiglio di farlo al di fuori di Discourse. Basta creare una configurazione nginx che abbia il proprio certificato, un server_name per il nome host vecchio e reindirizzi tutto al nuovo nome host.
In realtà, se stai utilizzando un’installazione basata su Docker con un’unica istanza per server, funziona perfettamente con qualsiasi numero di voci DNS (nginx ascolta le porte 80 e 443 per tutti i nomi host) e riscrive correttamente l’URL al nuovo nome host canonico. Questa parte funziona senza problemi. (Chi fosse incline a testarlo potrebbe provare aggiungendo un nome di dominio finto al file localhost della propria macchina e puntandolo all’indirizzo IP del proprio sito Discourse preferito.)
L’unico problema che riscontro è l’avviso SSL, perché la risposta di riscrittura da nginx proviene da https://old.example.org/foo e invia un reindirizzamento HTTP 302 al nuovo URL.
Preferirei non dover mantenere un server web separato solo per una regola di riscrittura, se possibile.
Aggiornamento: Configurazione riuscita del nome di dominio secondario sull’installazione standalone ed emissione di un certificato Let’s Encrypt per gestire sia il nome vecchio che quello nuovo.
Prerequisito: Non ho ancora modificato il DNS per reindirizzare gli utenti al nuovo sito; volevo essere sicuro che tutto funzionasse in anticipo. Ho quindi utilizzato una voce localhost sulla mia macchina di test. Questo significa che non ho potuto eseguire una verifica normale di Let’s Encrypt e ho dovuto usare invece il metodo “DNS” di acme.sh, generalmente sconsigliato perché non supporta il rinnovo automatico. Per me va bene, poiché effettuerò il passaggio entro il termine di 30 giorni del certificato “iniziale” (nuovamente emesso con 2 nomi).
Nel mio file web_only.yml (potresti usare app.yml), sotto la sezione hooks: e prima dei plugin, ho aggiunto quanto segue:
Nel DNS, imposta un record TXT falso/temporaneo per _acme-challenge.old.example.org con un TTL di 5 minuti (potresti impostarlo anche più breve) e attendi la propagazione per effettuare rapidamente la modifica con la chiave di verifica di acme.sh (Let’s Encrypt).
Ferma il sito ed esegui una validazione di debug (test) per rendere il sistema consapevole del breve TTL della nuova voce:
Esegui la richiesta vera e propria questa volta senza l’impostazione di debug. Riceverai un avviso con il valore da utilizzare nel DNS per la voce creata al passaggio 2:
Una volta che il sito è di nuovo attivo, dovrebbe funzionare con il nuovo certificato. Potresti dover cancellare i certificati memorizzati nel browser, compito che lascio come esercizio al lettore e al tuo motore di ricerca preferito.
Grazie a tutti quelli che mi hanno indicato la direzione giusta!
Questa è un’applicazione perfetta per una regola di Cloudflare: zero configurazione del server. Basta passare gli stessi parametri URL al nuovo dominio.
Per il vecchio nome di dominio sarà necessario attivare la nuvola arancione.
Sì, una situazione di reverse proxy come Cloudflare (o, supponiamo, il tuo reverse proxy preferito davanti al tuo sito Discourse) potrebbe aggirare il problema implementando le regole di riscrittura “un livello più su”. In questo caso, Cloudflare non era un’opzione per motivi di sicurezza e morali.
