After Discourse installation can’t reach it in browser

Hello,

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 :slight_smile:

Thanks a lot in advance.
Cheers, Daniel

If you can access via ip but not the desired domain name then it’s a dns problem. If you share the domain name and ip then someone could confirm.

Hi Jay,

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.

Perhaps you need to make sure that port 80 (and 443 if you’re going to want https) is accessible to the outside. Check with your provider.

I have another stupid question, really stupid :slight_smile:
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 :frowning:

The server is complete fresh, minimal installation of ubuntu, so nothing more is installed.

No. You don’t want to install anything else.

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 :frowning:(

Docker Status:

root@crazy-geek:~# service docker status
● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-01-17 12:45:06 CET; 1 day 9h ago
     Docs: https://docs.docker.com
 Main PID: 3857 (dockerd)
    Tasks: 22
   CGroup: /system.slice/docker.service
           ├─ 3857 /usr/bin/dockerd -H fd://
           ├─14119 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 443 -container-ip 172.17.0.2 -container-port 443
           └─14130 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 80 -container-ip 172.17.0.2 -container-port 80

Jan 17 12:58:49 crazy-geek dockerd[3857]: time="2019-01-17T12:58:49.450467881+01:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jan 17 12:58:50 crazy-geek dockerd[3857]: time="2019-01-17T12:58:50.171181280+01:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jan 17 12:58:51 crazy-geek dockerd[3857]: time="2019-01-17T12:58:51.054211198+01:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jan 17 12:58:51 crazy-geek dockerd[3857]: time="2019-01-17T12:58:51.862330252+01:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jan 17 12:58:52 crazy-geek dockerd[3857]: time="2019-01-17T12:58:52.565811076+01:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jan 17 12:58:53 crazy-geek dockerd[3857]: time="2019-01-17T12:58:53.283330959+01:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jan 17 12:58:54 crazy-geek dockerd[3857]: time="2019-01-17T12:58:54.011132735+01:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jan 17 12:58:54 crazy-geek dockerd[3857]: time="2019-01-17T12:58:54.695183727+01:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jan 17 12:58:55 crazy-geek dockerd[3857]: time="2019-01-17T12:58:55.437976456+01:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jan 17 12:58:56 crazy-geek dockerd[3857]: time="2019-01-17T12:58:56.063518104+01:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"

I have tried few things now. Let me explain:

  1. complete rebuild of the cloud-server. Installed apache, it´s accessable
  2. afterwards, deactivated apache, installed discourse standard docker install. Not accessable
  3. complete rebuild of the cloud server. Installed discourse standard docker install. Not accessable

I am out of order now :smiley:

You can test it locally on the host with

curl http://localhost/
curl http://172.17.0.2/

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.

Thanks @ssvenn,

I tried curl inside the container both adresses:

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):

2019/01/21 12:42:09 [emerg] 16765#16765: PEM_read_bio_X509_AUX("/shared/ssl/crazy-geek.de.cer") failed (SSL: error:0906D06C:PEM routines:PEM_read_bio:no start line:Expecting: TRUSTED CERTIFICATE)

Production Log is empty.

So what does that mean to you?

Perhaps let’s encrypt failed to get the certs? Maybe rebuild again? How did you enable let’s encrypt?

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 :slight_smile:
Sorry for my mistakes and thx a lot for the provided help!

Я сам потратил на это несколько часов. Инструкция по установке по адресу discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub предполагает, что если нажать Enter на строке с Let’s Encrypt, она будет пропущена. Но это не так. Система всё равно настраивает использование SSL-сертификата, который не может быть получен по адресу me@example.com.

Затем нужно зайти в файл app.yml, закомментировать строку с email для Let’s Encrypt и шаблоны SSL, а затем пересобрать launcher. Я считаю, что это следует считать ошибкой в утилите discourse-setup. Кроме того, в discourse-setup должна быть поддержка установки собственного SSL-сертификата от другого удостоверяющего центра сразу на начальном этапе, чтобы не приходилось выполнять пересборку.

Это сделано намеренно: Discourse по умолчанию устанавливается с безопасным HTTPS «из коробки». Поле электронной почты предназначено только для уведомления о проблемах с продлением.

Какая польза от использования сертификата от другого центра сертификации? EV-сертификаты уже не актуальны, а Discourse может автоматически управлять собственным сертификатом.

Discourse setup предназначен только для самой стандартной установки. Если вы можете получить собственный сертификат, то и установка его — ваша ответственность. Согласен, что немного сбивает с толку, что let’s encrypt устанавливается по умолчанию, но это безопаснее, и так уже очень давно, при этом жалоб на проблемы крайне мало.

Тогда в подсказке в разделе Let’s Encrypt не должно быть написано SKIP, поскольку нажатие ENTER на самом деле не пропускает этот шаг. Или же следует дать подсказку о том, что делать, если Let’s Encrypt не используется.

Однако, по моему мнению, поддержка SKIP необходима: если шаг пропускается, Discourse должен быть настроен без SSL и работать только на порту 80, а не находиться в полностью нерабочем состоянии, которое выглядит загадочно и сложно отлаживается, как показано в постах выше.

Вы так и не объяснили, почему нельзя использовать автоматически предоставляемый сертификат или в чём его недостатки.

Звучит так, будто технической проблемы здесь нет, максимум — это просто предпочтение.

Мне нужно изучить вопрос внимательнее, но, думаю, вы правы. Я полагаю, что в идеале система не должна задавать никаких вопросов и просто использовать адрес электронной почты разработчика для Let’s Encrypt. Проблема в том, что включать несколько адресов для разработчика допустимо, а для Let’s Encrypt — нет, так что это будет немного хлопотно, но выполнимо.

@Stephen Как и указано в начале этой ветки, то, что должно было работать «автоматически», не сработало. Система находилась в состоянии, при котором она вообще не отдавала веб-страницы на портах 80 или 443. Как только я закомментировал шаблоны SSL и пересобрал систему, всё заработало на порту 80 без проблем.

Скорее всего, это очень простое решение — тысячи установок прошли без сбоев.

Вы используете Cloudflare?

Сколько раз вы пытались настроить Discourse на этом хосте с включённым Let’s Encrypt?

Нельзя передавать адреса электронной почты третьим лицам без согласия.

Точные слова:

      read -p "Optional email address for Let's Encrypt warnings? ($letsencrypt_status) [$letsencrypt_account_email]: " new_value

Это действительно пропускает ввод вашего адреса электронной почты. Если у вас другие требования, вы можете вручную отредактировать файл yaml, чтобы настроить его под себя.