Estou tentando instalar o Discourse em um servidor na nuvem da Hetzner, mas ao executar ./discourse-setup recebo a mensagem de que as portas estão bloqueadas (discourse.domain.de, obviamente, não é o domínio real):
AVISO: A porta 443 do computador não parece acessível usando o nome do host: discourse.domain.de.
AVISO: A conexão com http://discourse.domain.de (porta 80) também falha.
Conforme sugerido pela ferramenta de configuração, agora quero verificar se discourse.domain.de resolve para o endereço IP do servidor na nuvem. Ao executar dig discourse.domain.de, obtenho a seguinte saída:
; <<>> DiG 9.16.1-Ubuntu <<>> discourse.domain.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28839
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;discourse.domain.de. IN A
;; ANSWER SECTION:
discourse.domain.de. 4134 IN A XXX.XXX.XXX.XXX (endereço IP correto)
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sun Apr 24 10:14:44 UTC 2022
;; MSG SIZE rcvd: 70
O que me parece bom.
A próxima sugestão é que pode ser um problema de firewall. Tenho um firewall com as seguintes portas abertas:
Portanto, acho que o firewall não é o motivo da mensagem acima. É possível que haja algo mais bloqueando as portas? Li que o Apache poderia causar tal problema, mas ele não está instalado no servidor na nuvem.
Tentei telnet discourse.domain.de 443 para ver se as portas estavam abertas e recebi:
telnet: Unable to connect to remote host: Network is unreachable
Alguém tem alguma ideia de como resolver este problema?
Obrigado!
Infelizmente, spammers e golpistas de e-mail gostam de usar provedores de hospedagem em nuvem. E nós, na Hetzner, naturalmente queremos evitar isso. É por isso que bloqueamos as portas 25 e 465 por padrão em todos os servidores em nuvem. Esta é uma prática muito comum na indústria de hospedagem em nuvem porque evita abusos. Queremos construir confiança com nossos novos clientes antes de desbloquear essas portas de e-mail. Assim que você estiver conosco há um mês e tiver pago sua primeira fatura, poderá criar uma solicitação de limite para desbloquear essas portas para um caso de uso válido. Em sua solicitação, você pode nos contar detalhes sobre seu caso de uso. Tomamos decisões caso a caso.
Como alternativa, você também pode usar a porta 587 para enviar e-mails por meio de serviços externos de entrega de e-mail. A porta 587 não é bloqueada e pode ser usada sem enviar uma solicitação de limite.
Tive uma pesquisa no fórum para ver se mais alguém havia encontrado um problema semelhante e encontrei isto, embora infelizmente não seja uma “solução real” como tal:
Configurar o app.yml manualmente poderia ser uma opção para você?
Ainda estou confuso, mas no Digital Ocean o firewall deve ser configurado. Uma instalação limpa não tem nenhuma porta aberta (exceto SSH, mas isso é outra coisa). Não sei como o Hetzner funciona. E se o VPS estiver atrás de portas fechadas, não importa o que tenhamos no app.yml.
A configuração manual do app.yml é a solução para o problema para mim também. Obrigado!
Também encontrei este tópico, mas acho que não o li com atenção suficiente…
Eu acho que sim. Quando eu inicio um VPS (Ubuntu 20), o nginx não é instalado por padrão: o discourse-setup o instala.
Eu instalei o Discourse inúmeras vezes em VPS da Hetzner sem nenhum problema por anos (a última vez foi em fevereiro).
É por isso que estou intrigado com este tópico.
edit: por algumas razões meu cérebro misturou docker e nginx
Existem duas opções: usar o firewall do Digital Ocean ou instalar o UFW (ou similar) após a criação do VPS. Nenhuma das minhas instalações usa o deles, então todas as portas estão fechadas até que eu as abra pelo UFW.
De qualquer forma, agora sabemos quando, onde e como o Nginx é instalado. Todo dia algo novo (quando você/eu/alguém não entende como o docker funciona )
)