I have set up a new Ubuntu 18 Cloud Server and installed Discourse like I did it all times, the Standard under 30 Min setup. When I now want to first create a admin, I am calling the installation in my browser and getting error that server is not reachable. 2 things are different to my other servers, 1. I changed to Hetzner Cloud, 2. I can only call the installtion with the IP adress at the moment, as I want to switch another existing server to the new one.
The Hetzner Ubuntu Image is minimal I think, nothing installed. I am out of knowledge now and hope that someone could point me the right direction
thx for reply. I think I explained wrong. I tried only to access via IP, the domain name is still not pointed on the new server. The result of trying to access via IP is the error I said before.
Discourse is up and running but the server somehow diesn´t point to the docker container. I don´t have clue.
I have another stupid question, really stupid
Do I need an an apache or any other webserver installed additionally? Or does the mentioned install method supports everything needed for launching? Sorry for that dumb question
The server is complete fresh, minimal installation of ubuntu, so nothing more is installed.
I recommend opening a ticket with the provider and/or checking their settings to see if you need to do something to open up ports. Sometimes all ports are closed by default.
My provider Hetzner doesn´t offers a extern firewall for the cloud server structure. The only I can do is to check up my system configuration, ufw for example.
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00013s latency).
Not shown: 131065 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
6010/tcp open x11
68/udp open|filtered dhcpc
Nmap done: 1 IP address (1 host up) scanned in 4851.83 seconds
root@crazy-geek:~# ufw status
Status: inactive
As I said, its a standard configuration. I am sure I am missing a small thing (
One or both of those should return a bunch of html. If they don’t, go look at the log files in /var/discourse/shared/standalone/log/var-log/nginx/ and /var/discourse/shared/standalone/log/rails/production.log for clues about what could be wrong
You could try ./launcher enter app in the discourse directory and running the top command to verify that nginx, redis, postmaster and ruby are all running. curl is available to test inside the container too.
root@crazy-geek:~# cd /var/discourse
root@crazy-geek:/var/discourse# ./launcher enter app
root@crazy-geek-app:/var/www/discourse# curl http://localhost/
curl: (7) Failed to connect to localhost port 80: Connection refused
root@crazy-geek-app:/var/www/discourse# curl http://172.17.0.2/
curl: (7) Failed to connect to 172.17.0.2 port 80: Connection refused
Outside the container:
root@crazy-geek:/var/discourse# curl http://localhost/
curl: (56) Recv failure: Connection reset by peer
root@crazy-geek:/var/discourse# curl http://172.17.0.2/
curl: (7) Failed to connect to 172.17.0.2 port 80: Connection refused
Error Logs from inside the container:
Nginx (whole error.log is full of the same message):
Thanks a lot. That was a noob mistake actually. I needed to deactivate ssl templates in app.yml and rebuild new. Problem was that letsencrypt couldn´t verify the cert for the domain, as the domain is still pointed to the old server
Sorry for my mistakes and thx a lot for the provided help!
Perdi horas com isso também. As instruções de instalação em discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub sugerem que, se você apenas pressionar Enter na linha do Let’s Encrypt, ela será ignorada. Mas não é isso que acontece. O processo ainda configura tudo para usar um certificado SSL que não pode ser obtido no e-mail me@example.com.
Depois, é necessário editar o app.yml, comentar a linha do e-mail do Let’s Encrypt e os templates SSL, e então reconstruir o launcher. Acho que isso deveria ser considerado um bug no discourse-setup. Além disso, o discourse-setup deveria oferecer suporte para instalar seu próprio certificado SSL obtido de outra autoridade logo no início, para que você não precise reconstruir.
É intencional: o Discourse é instalado com segurança padrão, com HTTPS ativado nativamente. Esse campo de e-mail serve apenas para notificá-lo sobre problemas de renovação.
Qual seria a vantagem de usar um certificado de uma CA diferente? Certificados EV não são mais tão relevantes, e o Discourse pode gerenciar seu próprio certificado automaticamente.
O setup do Discourse é apenas para a instalação mais padrão. Se você é capaz de obter seu próprio certificado, então é responsável por instalá-lo. Concordo que é um pouco confuso que o Let’s Encrypt seja instalado por padrão, mas é mais seguro e tem sido assim há muito tempo, com muito poucos relatos de problemas.
Então, o prompt na parte do Let’s Encrypt não deveria exibir SKIP, pois ao pressionar ENTER ele não realmente ignora. Ou deveria oferecer alguma dica sobre o que fazer se não estiver usando o Let’s Encrypt.
Mas, na minha opinião, SKIP deveria ser suportado e, se for ignorado, o Discourse deveria ser configurado sem SSL naquele momento, funcionando apenas na porta 80, em vez de não funcionar de forma alguma, em um estado muito misterioso e difícil de depurar, como mostram as postagens acima.
Vou precisar analisar com mais cuidado, mas acho que você está certo. Acredito que o que deveria acontecer é não fazer nenhuma pergunta e simplesmente usar o e-mail do desenvolvedor para o Let’s Encrypt. O problema é que é permitido incluir vários endereços de e-mail para desenvolvedores, mas não para o Let’s Encrypt, então seria um pouco trabalhoso, mas factível.
@Stephen Bem, como o início deste tópico afirma, o que era “automático” não funcionou. O sistema estava em um estado em que não servia páginas web de forma alguma nas portas 80 ou 443. Assim que comentei os modelos SSL e reconstruí, funcionou perfeitamente na porta 80.
Não é possível compartilhar e-mails com terceiros sem consentimento.
As palavras exatas são:
read -p "Endereço de e-mail opcional para avisos do Let's Encrypt? ($letsencrypt_status) [$letsencrypt_account_email]: " new_value
Ele realmente pula a solicitação do seu e-mail. Se você tiver necessidades diferentes, pode editar manualmente o arquivo YAML para atender às suas exigências.
(