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!
J’ai moi-même perdu des heures sur ce problème. Les instructions d’installation sur discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub laissent entendre que si vous appuyez simplement sur Entrée à la ligne Let’s Encrypt, cela sera ignoré. Mais ce n’est pas le cas. Cela configure toujours l’utilisation d’un certificat SSL qu’il ne peut pas obtenir à l’adresse email me@example.com.
Il faut ensuite ouvrir app.yml, commenter la ligne de l’email Let’s Encrypt et les modèles SSL, puis relancer le rebuild du launcher. Je pense que cela devrait être considéré comme un bug dans discourse-setup. De plus, discourse-setup devrait prendre en charge l’installation de votre propre certificat SSL obtenu auprès d’une autre autorité dès le début, afin que vous n’ayez pas à reconstruire.
C’est intentionnel : Discourse s’installe de manière sécurisée par défaut avec HTTPS, sans configuration supplémentaire. Ce champ e-mail sert uniquement à vous informer des problèmes de renouvellement.
Quel avantage y a-t-il à utiliser un certificat provenant d’une autre autorité de certification ? Les certificats EV ne sont plus vraiment d’actualité, et Discourse peut gérer automatiquement son propre certificat.
La configuration de Discourse est conçue uniquement pour les installations les plus standard. Si vous êtes capable d’obtenir votre propre certificat, vous êtes responsable de son installation. Je conviens qu’il est un peu déroutant que Let’s Encrypt soit installé par défaut, mais c’est plus sûr et cela fonctionne ainsi depuis très longtemps, avec très peu de signalements de problèmes.
Alors, l’invite dans la section Let’s Encrypt ne devrait pas afficher SKIP, car appuyer sur ENTRÉE ne l’évite pas vraiment. Ou bien, il faudrait donner un indice sur la marche à suivre si vous n’utilisez pas Let’s Encrypt.
Mais à mon avis, SKIP devrait être pris en charge. Si on le saute, Discourse devrait être configuré sans SSL, fonctionnant uniquement sur le port 80, plutôt que de ne pas fonctionner du tout dans un état mystérieux et difficile à déboguer, comme le montrent les messages ci-dessus.
Je devrai examiner cela plus attentivement, mais je pense que vous avez raison. Je soupçonne que ce qu’il faudrait faire, c’est ne rien vous demander et utiliser directement l’adresse e-mail du développeur pour Let’s Encrypt. Le hic, c’est qu’il est légal d’inclure plusieurs adresses pour les e-mails des développeurs, mais pas pour Let’s Encrypt, donc ce serait un peu fastidieux, mais faisable.
@Stephen Comme le mentionne le début de ce fil, ce qui était censé être « automatique » ne fonctionnait pas. Le système était dans un état où il ne servait aucune page web sur les ports 80 ou 443. Une fois que j’ai commenté les modèles SSL et reconstruit, tout a fonctionné parfaitement sur le port 80.
(