Primeiro, reconhecimento onde é devido: o novo instalador é uma grande melhoria. Quando funciona, o que é na maioria das vezes, é um caminho muito mais amigável do que o fluxo manual antigo, e consigo realizar instalações limpas através dele. Execute o instalador, complete o registro/ativação como sempre, e então ajuste o app.yml às minhas especificações. Fácil como bolo. Muitos agradecimentos ao @Falco e à equipe! Que diferença enorme em relação aos velhos tempos de instalação do Discourse.
Estou postando isso porque também encontrei um nome de host que me deu trabalho, e acho que a experiência pode apontar para alguns lugares onde o instalador poderia apresentar informações mais claras para auto-hospedadores.
O que funcionou
Instalei o Discourse com sucesso em um servidor novo usando:
- domínio próprio: sim
- SMTP: sim
- o fluxo de instalação atual
A instalação chegou a:
Tallyho!
Parabéns, você instalou o Discourse!
Registre uma nova conta para começar.
Então, este não é um post sobre “o novo instalador está quebrado”. O instalador pode funcionar muito bem.
O nome de host difícil
Em outra instalação, usando o mesmo caminho geral, o nome de host alvo era:
forum.domain.tld
O comando do instalador foi:
wget -qO- https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse | sudo bash
As escolhas foram aproximadamente:
- criar arquivo de swap de 2 GB: sim
- usar meu próprio domínio: sim
- nome de host:
forum.domain.tld - configurar SMTP: sim
- provedor SMTP: SendGrid
- porta SMTP: 587
O instalador chegou a:
[4/5] Verificando configuração do domínio
? Verificando seu nome de domínio...
? Conexão com forum.domain.tld bem-sucedida.
Ele então escreveu a configuração e reconstruiu o aplicativo.
Mas o site não apareceu corretamente no navegador. O sintoma eventualmente se tornou:
forum.domain.tld recusou a conexão
Tentativas repetidas de reconstrução/reinício não resolveram o problema.
Resultado do Discourse Doctor
./discourse-doctor encontrou o container do aplicativo e os valores de configuração esperados. O container estava em execução e as portas 80/443 pareciam estar vinculadas.
Mas ele relatou:
Versão do Discourse em forum.domain.tld: NÃO ENCONTRADA
e depois:
Versão do Discourse em localhost: NÃO ENCONTRADA
Isso fez o problema parecer diferente da simples propagação de DNS pública comum.
Limite de taxa do ACME
Mais cedo no caminho de solução de problemas, também tentei instalações usando os caminhos assistidos pelo serviço Discourse:
- DiscourseID
- o fluxo
yoursite.discourse.diy
Foi aí que o comportamento de martelamento/reinício repetido do servidor aconteceu, e onde o log do ACME mostrou um limite de taxa do Let’s Encrypt:
type: urn:ietf:params:acme:error:rateLimited
status: 429
detail: muitos certificados (5) já emitidos para este conjunto exato de identificadores...
O caminho do log útil foi:
/shared/letsencrypt/acme.sh.log
Esta foi uma grande lição. Do navegador, a falha parecia ser um problema genérico de acessibilidade. Mas o verdadeiro bloqueador naquele momento era a emissão de certificados.
A parte mais confusa foi que o bloco de status final/completo da instalação não apresentou isso como um erro acionável. O sintoma final voltado ao usuário era apenas que o site recusava a conexão do navegador.
Verificações posteriores mostraram a cadeia de falhas mais claramente:
Limite de taxa ACME 429
-> arquivos .cer de zero bytes em /shared/ssl
-> nginx tenta carregar o certificado de zero bytes
-> nginx falha na inicialização
-> portas 80/443 recusam
-> navegador diz que a conexão foi recusada
Solicitação de recurso enterrada na experiência:
Seria muito útil se a rotina de instalação/reconstrução verificasse /shared/letsencrypt/acme.sh.log após a etapa de certificado e apresentasse erros de limite de taxa como:
rateLimited
too many certificates
status: 429
Por exemplo:
Limite de taxa do Let's Encrypt atingido para este nome de host.
Aguarde até o tempo de retry-after mostrado em /shared/letsencrypt/acme.sh.log antes de tentar novamente.
Reconstruções repetidas podem não ajudar.
Isso economizaria aos usuários a perseguição de problemas de DNS, SMTP, citações em app.yml, Docker ou firewall quando o problema real é o ACME.
Após o limite de taxa ser limpo
Após a janela de limite de taxa do Let’s Encrypt ter sido limpa, ainda vi uma situação de validação de domínio confusa.
O instalador relatou:
[4/5] Verificando configuração do domínio
? Verificando seu nome de domínio...
? Conexão com forum.domain.tld bem-sucedida.
Mas uma consulta de DNS local ainda mostrava:
Resolve-DnsName -Name "forum.domain.tld"
com:
Resolve-DnsName: forum.domain.tld : nome DNS não existe.
Como essas duas coisas podem coexistir?
Posso imaginar várias possibilidades:
- o servidor e a estação de trabalho estavam usando resolvedores recursivos diferentes
- um resolvedor tinha NXDOMAIN obsoleto em cache
- a propagação de DNS era parcial naquele momento
- o instalador verifica algo diferente de uma consulta DNS simples
- o instalador ou um serviço relacionado tinha estado de validação em cache
Não estou afirmando qual é verdadeira. Estou principalmente observando que, do ponto de vista do usuário, o instalador dizendo “conexão bem-sucedida” pode tornar erros posteriores de DNS ou acessibilidade mais difíceis de interpretar.
Verificação de isolamento de DNS
Para testar se isso era apenas propagação lenta do Cloudflare, adicionei outro registro na mesma zona:
test.domain.tld
Dentro de alguns momentos, os resultados do verificador de DNS público estavam verdes.
Isso me deixou menos confiante de que a propagação geral do Cloudflare era o problema inteiro. Pareceu mais como se o problema fosse específico para forum.domain.tld.
Instalações de comparação
Também tive uma instalação bem-sucedida em outro nome de host:
discourse.domain2.tld
usando o mesmo caminho geral do instalador.
Outro nome de host de teste, para diagnósticos de DNS, foi:
forum.domain3.tld
As instalações de comparação são o que me afastaram de “o novo instalador está quebrado” e em direção a “algo específico do nome de host aconteceu aqui.”
Teoria atual
Minha teoria atual, não comprovada, é que forum.domain.tld pode ter tido algum estado em cache/reservado/lembrado específico do nome de host em algum lugar fora do próprio servidor.
Lugares que me perguntei:
- DiscourseID
- o fluxo
yoursite.discourse.diy - validação de domínio do lado do instalador
- algum relacionamento em cache entre uma tentativa de configuração anterior e o nome de host
A razão pela qual estou me perguntando sobre esses caminhos assistidos pelo serviço é que eu os tinha tentado anteriormente com o mesmo nome de host problemático, e esse também foi o caminho onde as tentativas repetidas eventualmente atingiram o limite de taxa do Let’s Encrypt.
Novamente, esta é uma hipótese, não uma conclusão.
Perguntas
- O novo instalador entra em contato com um serviço controlado pelo Discourse durante instalações de domínio próprio?
- O DiscourseID ou o fluxo
discourse.diyreserva, lembra ou armazena em cache nomes de host? - Existe algum caminho de liberação/reset para um nome de host que foi usado ou tentado anteriormente durante a configuração?
- O que exatamente
[4/5] Verificando configuração do domínioverifica? - O instalador poderia apresentar falhas de limite de taxa do ACME mais claramente antes do bloco de status/resultado final?
O que teria ajudado
Três coisas teriam tornado o caminho de solução de problemas muito mais claro:
- Um aviso claro do instalador quando
/shared/letsencrypt/acme.sh.logcontém uma falha de limite de taxa. - Uma breve explicação do que a etapa de verificação de domínio realmente verifica.
- Se existir algum cache ou reserva de nome de host do lado do DiscourseID /
discourse.diy/ instalador, uma maneira visível de inspecionar ou liberar esse estado.
Obrigado novamente pelo trabalho no novo instalador. Realmente parece ser a direção certa. Estou postando isso nesse espírito: funcionou lindamente quando funcionou, e a aspereza aqui parece ser o tipo de coisa que uma melhor mensagem do instalador poderia tornar muito mais fácil de diagnosticar.
Escrito com minhas entradas pelo meu novo melhor amigo, o Codex.