Acho que isso não é mais o caso.
Exatamente @jomaxro. É por isso que eu disse:
Ah. Desculpe. Perdi essa mudança.
Então, se o usuário não fornecer um endereço de e-mail para notificações do Let’s Encrypt, o discourse-setup agora habilita o Let’s Encrypt cegamente, sem verificar se o domínio resolve para o servidor atual. Mas, se você fornecer um endereço de e-mail, a verificação é feita. Isso não parece ser uma boa ideia.
Por que forçar HTTPS quando eles não têm um nome de domínio válido? Se o plano é forçar todos a usar HTTPS o tempo todo, então deveríamos testar se o nome de domínio é válido e, em seguida, recusar a execução, em vez de entregar uma instalação quebrada.
Como funciona agora: se você não fornecer um endereço de e-mail do Let’s Encrypt e o domínio não resolver para o servidor, o discourse-setup parece ter sucesso, e ele inicia um servidor web que não aceitará conexões porque o nginx não consegue encontrar um certificado. Acredito que uma abordagem melhor seria não solicitar um endereço de e-mail do Let’s Encrypt, usar o e-mail do (primeiro?) desenvolvedor para o Let’s Encrypt e ainda realizar o teste de DNS, mas isso não deve mais ser discutido neste tópico.
Não, não é assim que o Let’s Encrypt funciona. O e-mail não tem nada a ver com a validação do domínio. Ele é usado para alertar o usuário se o certificado estiver prestes a expirar e não puder ser renovado. A validação é sempre feita via DNS.
O Let’s Encrypt não pode emitir um certificado para um endereço que não atenda aos requisitos de validação. Se isso acontecesse, todo o esquema do LE entraria em colapso da noite para o dia.
Não. É assim que o discourse-setup funciona, ou funcionava. Antigamente, ele protegia os usuários de solicitar um certificado quando tinha certeza de que a solicitação falharia. Agora, ele avança, solicita um certificado mesmo quando é impossível que tenha sucesso, e não tem nenhuma maneira de informar ao usuário que não funcionou. Assim, ele agora falha silenciosamente, sem nenhum aviso.
Novamente, por que falharia? O e-mail não é um requisito para a verificação do domínio.
A falha também nunca gerou um e-mail.
O e-mail só existe para informar o usuário posteriormente se o Let’s Encrypt falhar na renovação e um certificado estiver prestes a expirar. Se o certificado for renovado sem problemas, eles nunca receberão um e-mail.
Acho que essa não era a intenção da mudança. A intenção era habilitar o SSL independentemente de um e-mail ser fornecido. Ainda devemos verificar a resolução do domínio cc @Falco
Isso falhará se o nome de domínio não for resolvido para o host. O endereço de e-mail não importa, mas, se houver um, a configuração do Discourse avisará o usuário se o endereço não for resolvido.
A resolução de domínio deve passar por @falco; caso contrário, a configuração deve ser interrompida. Essa é uma mudança ruim.
Então, fiz algumas alterações em uma branch. É assim que vai funcionar:
Usando um nome de host incorreto:
root@droplet:/var/discourse# ./discourse-setup
Nome de host para o seu Discourse?: bad-domain.com
Verificando o nome do seu domínio . . .
AVISO:: Este servidor não parece estar acessível em bad-domain.com:443.
Uma conexão para http://bad-domain.com (porta 80) também falha.
Isso sugere que bad-domain.com resolve para o endereço IP incorreto
ou que o tráfego não está sendo roteado para o seu servidor.
Pesquise no Google: "abrir portas SEU SERVIÇO DE NUVEM" para obter informações sobre como resolver esse problema.
Se quiser prosseguir mesmo assim, será necessário executar cp samples/standalone.yml containers/app.yml
e editar manualmente o arquivo containers/app.yml.
Usando um nome de host correto:
root@droplet:/var/discourse# ./discourse-setup
Nome de host para o seu Discourse?: good-domain.com
Verificando o nome do seu domínio . . .
Conexão com good-domain.com bem-sucedida.
Endereço de e-mail para conta(s) de administrador? :
As alterações estão pendentes em
Parece bom para vocês, @pfaffman @codinghorror?
Comentário sobre por que essa mudança foi necessária desde o início
Primeiro, estou surpreso de que, nos quase 3 meses desde que isso foi implementado dessa forma, não tenha havido muitas reclamações. Além disso, o tópico que trouxe isso à minha atenção não estava tendo problemas devido a essa mudança, então talvez isso importe menos do que eu penso.
A primeira coisa que não entendo muito bem é: vocês realmente querem tornar impossível configurar um site apenas com HTTP usando o discourse-setup? Suponho que eles já tenham feito várias configurações de DNS para que o e-mail funcione, então talvez não seja um problema tão grande exigir que eles criem também o registro A.
Feedback sobre a mudança
A menos que tenha havido uma mudança que eu não tenha notado, o script cria o app.yml antes de começar a fazer perguntas. Portanto, vocês poderiam simplesmente dizer algo como: “A instalação do Discourse sem configuração de DNS não é suportada. Para continuar sem configuração de DNS, edite o app.yml conforme necessário e execute ./launcher rebuild app” e, em seguida, encerrar sem realizar o bootstrap.
Além disso, se vocês vão obrigar todos a usar o Let’s Encrypt e HTTPS, talvez faça sentido alterar o standalone.yml e o web_only.yml de acordo, e assim essas complicadas instruções sed poderiam ser removidas.
Mais reflexões
Da seção “este é o meu problema”, meu script de instalação atual é executado antes que as pessoas possam configurar o DNS, pois eu crio o droplet para elas, configuro o Discourse, envio um e-mail com instruções de DNS, aguardo que o DNS seja configurado e, em seguida, modifico o app.yml para habilitar os modelos e definir o endereço do Let’s Encrypt. Mas acho que isso é apenas por motivos históricos. O que eu deveria fazer, em vez disso, é criar o droplet, configurar o Mailgun, aguardar o DNS e então realizar a instalação. Isso ainda permitiria que meu script usasse o discourse-setup, o que gosto de fazer como um teste frequente para verificar se ainda está funcionando (acho que vocês não estão fazendo um teste automatizado do discourse-setup, certo?)
Sim.
Não recebi nenhuma reclamação sobre essa mudança e, desde que foi implementada, não vejo muitos instâncias do Discourse apenas com HTTP. Quando você diz que algo é OPCIONAL, todos pulam essa etapa sem considerar as implicações. Isso é, na minha opinião, uma ótima mudança para ter configurações padrão seguras para o Discourse, que é exatamente o foco do guia de 30 minutos.
Ah, isso é ainda melhor, menos instruções necessárias!
Ah, agora entendo sua reação forte a essa mudança, já que ela quebrou sua configuração. Peço desculpas por isso.
Recomendo fortemente usar o arquivo yml direto para qualquer automação, em vez de mirar no script interativo.
tl;dr: Sim, com a pequena alteração de linguagem que recomendei, isso parece bom para mim.
Concordo. Zero reclamações! Parece que foi uma vitória.
Não! Não quebrou. (!) Eu apenas percebi de forma vaga que os sites não estavam acessíveis antes de executar a segunda etapa da instalação, que habilita o HTTPS. E minha configuração não é de sua responsabilidade. (Ah, AGORA isso vai quebrar meu script, mas não fazer a instalação antes de configurar o DNS será melhor de qualquer forma. Não fiz uma instalação sem HTTPS há pelo menos um ano.)
O motivo pelo qual gostava de usar discourse-setup no meu script é que isso garante de forma extra-especial que meus clientes de instalação estejam recebendo uma Instalação Padrão. Assim, quando alguém diz “Fiz uma instalação e não funcionou”, posso executar meu script, fazer exatamente o que eles deveriam ter feito e dizer: “Bem, acabei de fazer uma instalação e funcionou.” Mas não me lembro de ter encontrado algum problema nos últimos 3 anos, então talvez meu “teste” não esteja ajudando ninguém.
Legal, obrigado pela análise e revisão!
Fizemos o merge do PR, então agora sempre validaremos o DNS.