Non è probabile. È il tipo di cosa che probabilmente farai una sola volta, e la farai quando starai già armeggiando con app.yml.
Vedrò di fare una PR che la aggiunga a standalone.yml, però.
E con questo in atto, è molto più semplice!
4 Mi Piace
Grazie per questo, stavo modificando localmente templates/web.letsencrypt.ssl.template.yml ma questo mi rende la vita molto più facile!
1 Mi Piace
Dobbiamo includere l’hostname (OG) in questo, o solo gli alias?
Solo gli alias. L’hostname è l’hostname.
1 Mi Piace
Quindi così?
env:
DISCOURSE_HOSTNAME: domain.com
DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org
1 Mi Piace
Riflettendo filosoficamente sul significato di ‘alias’, ho incluso entrambi gli URL che voglio rimandino al mio sito: nzarchitecure.net.nz e www.nzarchitecture.net.nz senza effetti negativi evidenti (e presumibilmente nessun beneficio).
1 Mi Piace
È possibile modificare standalone.yml o incaricarlo di leggere le impostazioni dell’amministratore all’interno di un’istanza in esecuzione di Discourse?
Se sì, sarebbe di grande aiuto per i nuovi utenti e per coloro che desiderano migrare domini o aggiungere alias, eliminando un problema in meno da ricercare e risolvere.
No. Sarebbe davvero negativo se i processi in esecuzione nel container potessero modificare cose come app.yml. In effetti, una buona pratica di sicurezza è inserire cose come le chiavi S3 nel file yml in modo che siano nascoste dall’interfaccia di Discourse.
Anche in questo caso, è molto raro apportare modifiche come quali domini devono essere reindirizzati, e richiedono altre cose, come le impostazioni DNS. Il momento giusto per farlo è quando si configura Discourse, e quando si configura Discourse, si modifica il file yml.
1 Mi Piace
Questo è stato chiesto e risolto, ma sembra che DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com sia richiesto e non solo l’alias come in DISCOURSE_HOSTNAME_ALIASES: other.domain.com
Qualcuno può confermare per favore?
Inoltre, sembra che la PR di @pfaffman non sia stata unita, quindi i modelli di esempio necessitano di una modifica manuale, giusto?
1 Mi Piace
No. L’esempio è confuso. Solo i nomi EXTRA devono essere in DISCOURSE_HOSTNAME_ALIASES.
Non hai bisogno di DISCOURSE_HOSTNAME_ALIASES a meno che tu non abbia bisogno che il tuo sito abbia un certificato per un altro nome (come ieri quando ho spostato qualcuno da forum.example.com a fancyword.example.com).
Quindi ho fatto
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: forum.example.com
E ho eseguito il backup del forum prima di apportare le modifiche, ho apportato le modifiche, ricostruito, ripristinato il backup (il ripristino gestisce la correzione dei riferimenti all’hostname) e ora se vai su forum.example.com ottieni un certificato valido e vieni reindirizzato al nuovo sottodominio.
Sì, sembra che nessuno abbia notato la PR. Devo sempre andare a cercarla. Certo, DISCOURSE_HOSTNAME_ALIASES è “ovvio” ma solo quando lo sto guardando. 
2 Mi Piace
Grazie per questo @pfaffman
Nel mio caso ho bisogno di questo per far funzionare correttamente la cache di AWS CDN e AWS S3 CDN
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: cloudfront.example.com
Creare più certificati è esattamente ciò di cui avevamo bisogno. Purtroppo ieri abbiamo bombardato l’account con certbot troppe volte, quindi è il momento di mettere in prigione quel sito. Proverò con un sito diverso ora che hai confermato il corretto utilizzo di DISCOURSE_HOSTNAME_ALIASES
1 Mi Piace
Allora devi farlo su AWS.
Se aggiungi un altro alias, ti permetterà di richiederne uno nuovo (a meno che tu non abbia fatto qualcosa per bloccare l’intero dominio).
2 Mi Piace
Sembra che questo potrebbe non essere necessario dopo tutto. La cache sembra funzionare. Aggiornerò con i dettagli su Issues with AWS CDN and S3
1 Mi Piace