Olá @pfaffman, a edição na postagem original tem um + errôneo na linha to:, quebrando a regex. Ele deve ser removido.
Separadamente, o parágrafo a seguir precisa ser editado, pois não faz mais sentido:
Existem dois padrões que precisam ser substituídos, um terminando em --keylength e outro terminando em --fullchainpath (no arquivo real, seu domínio original está antes de cada uma dessas opções). Insira seu (sub)domínio (e quaisquer subdomínios adicionais precedidos por -d ) e, em seguida, adicione o seguinte à seção hooks do seu app.yml (no final do arquivo):
Eu sugiro:
Use domain1 e domain2 nesta postagem para gerar o código que você precisará. domain1 é o seu domínio original e domain2 é o domínio adicional que você deseja adicionar. Adicione o bloco after_ssl: resultante à seção hooks do seu app.yml e execute um launcher rebuild app.
está faltando no contêiner docker. Portanto, ele não será compilado. Solução alternativa: https://www.forcewww.com/
Portanto, isso parou de funcionar:
## Adiciona certificado Let's Encrypt para nome de domínio não-www e www
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.de -d www.example.de --keylength"
Antes de remover tais ferramentas/binários do contêiner Docker, seria bom receber uma notificação…
Esta é uma alteração na forma como o Discourse lida com o LetsEncrypt ou uma alteração no próprio LetsEncrypt?
Tenho um servidor que está atualmente sendo afetado por este problema. Por enquanto, minha solução alternativa é comentar essa parte do app.yml, mas sinto que precisamos de alguma forma de adicionar esses certificados adicionais à configuração no futuro.
O Discourse moveu isso para outro arquivo. Atualmente está em andamento. Tentarei dar uma olhada nos próximos dias para ver o que é necessário para possibilitar o suporte a múltiplos subdomínios.
Errno::ENOENT: No such file or directory @ rb_sysopen - /usr/local/bin/letsencrypt
Localização da falha: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/replace_command.rb:11:in `read’
a substituição falhou com os parâmetros {“filename”=>“/usr/local/bin/letsencrypt”, “from”=>“/-d spokes.nz/”, “to”=>“-d spokes.nz -d www.spokes.nz”}
a inicialização falhou com o código de saída 1
** FALHA AO INICIALIZAR ** por favor, role para cima e procure por mensagens de erro anteriores, pode haver mais de uma.
Estou imaginando, mas me pergunto se o erro que você está recebendo pode estar relacionado a um espaço ausente antes da barra final e da aspa final nas respectivas linhas da estrofe sugerida no seu arquivo app.yml?
Eu infiro da mensagem de erro que suas respectivas linhas são (verbatim)
from: /-d spokes.nz/
to: “-d spokes.nz -d www.spokes.nz”
Eu digo isso porque, no meu caso, as linhas são
from: /-d nzarchitecture.net.nz /
to: "-d nzarchitecture.net.nz -d www.nzarchitecture.net.nz "
E com espaços logo antes do final de cada linha, como mostrado, agora posso reconstruir o Discourse sem gerar esse erro. (se você olhar atentamente, verá que a estrofe atualizada de @pfaffman postada no início deste tópico mostrava esses espaços extras).
Eu não tenho nenhum arquivo no diretório usr/local/bin/ (como observado na sua mensagem de erro), o que me fez suspeitar que a falta desse arquivo letsencrypt não é o que aciona o erro.
Dito isso, para mim, embora o Discourse funcione bem em sua URL nzarchitecture.net.nz, infelizmente ainda recebo um erro de certificado se digitar www.nzarchitecture.net.nz em um navegador - se isso se deve à falta desse arquivo, eu não sei.
Apenas observando que estou atualmente tentando incorporar isso em variáveis de ambiente para lidar diretamente com o discourse_docker, algo como uma lista separada por vírgulas de aliases de hostname. Parece um caso de uso comum o suficiente para ser tratado diretamente.
Isso tornará a configuração mais fácil para este caso, para que ninguém precise fazer modificações em seus app.ymls.
Meu plano atual é com DISCOURSE_HOSTNAMEwww.domain.com
Permitir env como: DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com puxaria o certificado, válido para todos os hostnames.
(Enquanto estou nisso, as renovações automáticas do let’s encrypt também não parecem estar funcionando corretamente, então estou corrigindo isso também)
Perdi isso! Fiz como você sugeriu, mas ainda falha na inicialização:
FALHA
Errno::ENOENT: No such file or directory @ rb_sysopen - /usr/local/bin/letsencrypt
Localização da falha: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/replace_command.rb:11:in `read’
A substituição falhou com os parâmetros {“filename”=>“/usr/local/bin/letsencrypt”, “from”=>“/-d spokes.nz /”, “to”=>"-d spokes.nz -d www.spokes.nz "}
A inicialização falhou com o código de saída 1
** FALHA NA INICIALIZAÇÃO ** por favor, role para cima e procure por mensagens de erro anteriores, pode haver mais de uma.
Provavelmente não é o problema central aqui, mas em minhas tentativas, também atualizei a versão do Docker em execução no Digital Ocean de 20.0.4 (acho) para 28.3.3 - possivelmente isso ajudou, pelo menos com este erro. Se não for nada mais, isso eliminou os avisos de ‘depreciado’ do Docker que eu estava recebendo no início do processo de reconstrução.
Olá a todos, apenas para acompanhar, múltiplos domínios foram mesclados - na versão mais recente do discourse_docker, você pode incluir os templates ssl e letsencrypt e configurar variáveis de ambiente do tipo DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com para configurar nomes de host alternativos.
Seu site também puxará os nomes de host configurados com a solicitação de certificado sem alterações de configuração adicionais.
[quote=“featheredtoast, post:172, topic:56685”]você pode incluir os templates ssl e letsencrypt e configurar variáveis de ambiente do tipo DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com para configurar nomes de host alternativos.
[/quote]
Perdoe minha ignorância, mas isso é editável em alguma configuração do site ou algo precisa ser editado no app.yml?
Se for o primeiro, não tive sorte em encontrá-lo após atualizar para a versão mais recente e, se for o último, o que especificamente deve ser ajustado no app.yml?
Seria ainda melhor se houvesse alguma maneira inteligente para o Discourse escrever os aliases fornecidos pelo administrador no próprio app.yml ao atualizar, ou deixar as informações onde uma instrução do app.yml possa lê-las.