Certo! Eu apliquei estupidamente a configuração na página listada acima, em comparação com outros arquivos de configuração do nginx e não consegui entender por que o proxy não estava escutando em 80:443 para o discourse…
É o que eu esperava ver:
server {
listen 80;
server_name discourse.mydomain.com;
return 301 https://$host$request_uri; # roteamento para https
}
server {
listen 443 ssl
listen [::]:443 ssl;
server_name discourse.mydomain.com;
ssl_certificate /etc/letsencrypt/live/discourse.mydomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/discourse.mydomain.com/privkey.pem;
root /var/www/html;
# Adicione index.php à lista se você estiver usando PHP
index index.html index.htm index.nginx-debian.html;
location / {
proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:; # usando socket
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
}
Desculpe Stephen pela confusão, eu apenas usei o nome da ferramenta que é referenciada no artigo. Entendo que NPM e nginx (como) proxy manager são coisas diferentes, é por isso que usei letras maiúsculas…
É exatamente isso que estou tentando fazer e entendo que você não pode dar suporte nisso. No entanto, qualquer dica / link seria apreciado!
Eu simplesmente não posso, Jay: estou tentando ajudar um amigo a implantar o aplicativo e não posso modificar a configuração do servidor dele. É por isso que tenho que consertar o problema do nginx…
A propósito, meu entendimento é:
O Discourse está escutando nas portas 80/443.
O nginx está desempenhando o papel de um switch, despachando requisições para diferentes aplicações, com base em seus nomes de domínio:
netxcloud.mydomain.com tentando alcançar a porta 80 → a requisição é roteada para server_IP:8000
crm.mydomain.com tentando alcançar a porta 80 → a requisição é roteada para server_IP:9000
discourse.mydomain.com tentando alcançar a porta 80 → a requisição é roteada para http://unix:/var/discourse/shared/standalone/nginx.http.sock: (espero que os dois pontos finais não sejam um erro de digitação) pois o script de configuração configurou o Discourse para escutar nesse socket.
Tentarei configurar o nginx novamente esta tarde. Alguém pode confirmar a sintaxe exata para o socket: http://unix:/var/discourse/shared/standalone/nginx.http.sock:? Quero ter certeza de que os dois pontos finais não são um erro de digitação…
De fato… Apliquei no discourse.conf as modificações que propus na sexta-feira passada e o Discourse agora funciona bem! Pelo menos consigo acessar a página de boas-vindas, mas não recebo o e-mail de ativação, o que não está relacionado ao Discourse (suspeito que meu amigo não criou a conta de e-mail solicitada ).
Devo um agradecimento caloroso pela ajuda que você forneceu e espero não voltar a este fórum tão cedo!
Finalmente, de volta mais cedo do que o esperado, mas você provavelmente será capaz de me dar um pontapé inicial com suas ótimas sugestões!
A situação é:
Discourse configurado e funcionando, Docker (ou Portainer) indica que o contêiner está saudável e eu consigo acessar a página de boas-vindas forums.mydomain.com.
Não recebo nenhum e-mail de ativação, apesar da conta de e-mail técnica ter sido criada corretamente (provedor de hospedagem = OVH).
Testei o envio de um e-mail desta conta técnica (com a configuração abaixo) = OK.
A primeira coisa que verificarei é se forums@mydomain.com foi configurado para enviar em nome de noreply-forums@mydomain.com. Isso precisa ser verificado no seu provedor de e-mail.
========================================
Discourse 2.9.0.beta9
Versão do Discourse em forums.mydomain.com: Discourse 2.9.0.beta9
Versão do Discourse em localhost: NÃO ENCONTRADA
==================== PROBLEMA DE DNS ====================
Este servidor relata NÃO ENCONTRADO, mas forums.mydomain.com relata Discourse 2.9.0.beta9.
Isso sugere que você tem um problema de DNS ou que um proxy intermediário é o culpado.
[...]
Testando o envio para myprivatemail@yahoo.fr usando ssl0.ovh.net:465, nome de usuário: forums@mydomain.com com autenticação simples.
======================================== ERRO ========================================
ERRO INESPERADO
Net::ReadTimeout
====================================== SOLUÇÃO =======================================
O problema de e-mail pode estar ligado ao suposto problema de DNS? Eu não tenho um “proxy intermediário”, apenas estou executando o nginx como servidor proxy web…
Este é provavelmente o seu problema. Você pode tentar uma porta diferente? Eu tive os melhores resultados com a porta 587, se ela for suportada pelo seu provedor de e-mail.
Você precisará comentar esta linha ou defini-la como true se mudar a porta para 587.
Não, meu provedor de e-mail (o mesmo que meu provedor de hospedagem) só permite a porta 465. Aliás, li que preciso configurar o registro SPF e DKIM para o domínio (é este subdomínio?) e ainda não configurei nenhum deles: isso pode ter algum impacto?
Estou navegando no post, mas esqueci algumas informações:
O DNS é gerenciado pelo nosso provedor de hospedagem (para alguns serviços), digamos no ServerA.
O Discourse está rodando em outro servidor (ServerB) que é hospedado por um provedor diferente.
Meu entendimento é então: O Discourse no ServerB se conecta ao servidor de e-mail no ServerA, autenticando-se com e-mail/senha para usar o serviço SMTP fornecido pelo provedor de hospedagem do ServerA.
Esta é uma configuração anormal ou ainda posso usar a configuração normal de e-mail do app.yml aqui?
).
