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!
이후 app.yml 파일에 들어가서 Let’s Encrypt 이메일 줄과 SSL 템플릿을 주석 처리한 뒤 launcher rebuild를 실행해야 합니다. 저는 이것이 discourse-setup의 버그로 간주되어야 한다고 생각합니다. 또한, discourse-setup은 처음부터 다른 인증 기관에서 발급받은 자체 SSL 인증서를 설치할 수 있도록 지원해야 하며, 이렇게 해야 다시 빌드할 필요가 없게 됩니다.
Discourse의 setup은 가장 표준적인 설치에만 해당합니다. 자신의 인증서를 발급받을 수 있을 정도의 능력이 있다면, 해당 인증서를 설치하는 책임도 본인에게 있습니다. Let’s Encrypt가 기본적으로 설치되는 것이 다소 혼란스러울 수 있다는 점에는 동의하지만, 이는 더 안전하며, 아주 오랜 기간 동안 이러한 방식으로 유지되어 왔고 문제 보고도 매우 적었습니다.
더 자세히 살펴봐야겠지만, 말씀이 맞는 것 같습니다. 개발자 이메일 주소를 Let’s Encrypt에 그대로 사용하도록 아무것도 묻지 않는 것이 적절할 것 같습니다. 다만, 개발자 이메일에는 여러 주소를 포함할 수 있지만 Let’s Encrypt에는 그럴 수 없기 때문에 다소 번거롭지만 가능한 작업입니다.
@Stephen 글쎄요, 이 스레드의 시작 부분에서 언급했듯이, "자동"으로 설정된 부분이 제대로 작동하지 않았습니다. 시스템은 80번 포트나 443번 포트에서 웹 페이지를 전혀 제공하지 않는 상태였습니다. ssl 템플릿을 주석 처리하고 다시 빌드한 후에는 80번 포트에서 정상적으로 작동했습니다.
