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