Discourse 安装后无法在浏览器中访问

你好,

我新搭建了一台 Ubuntu 18 云服务器,并像往常一样安装了 Discourse,采用的是标准的 30 分钟内完成安装流程。现在当我首次尝试创建管理员账户时,在浏览器中访问安装页面却收到“服务器无法访问”的错误提示。与其他服务器相比,有两点不同:1. 我切换到了 Hetzner Cloud;2. 目前只能通过 IP 地址访问安装页面,因为我打算将另一台现有服务器迁移到这台新服务器上。

Hetzner 的 Ubuntu 镜像非常精简,似乎没有预装任何内容。我现在有些束手无策,希望有人能指点我正确的方向 :slight_smile:

提前非常感谢!
祝好,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 中的安装说明暗示,如果在 Let’s Encrypt 行直接按回车键,该步骤会被跳过。但事实并非如此。它仍然会配置使用 SSL 证书,却无法获取到以 me@example.com 为地址的证书。

之后必须进入 app.yml 文件,注释掉 Let’s Encrypt 邮箱行和 SSL 模板行,然后重新运行 launcher 进行重建。我认为这应被视为 discourse-setup 中的一个 bug。此外,discourse-setup 应该在初始阶段就支持安装从其他权威机构获取的自有 SSL 证书,这样就不必重新构建了。

这是有意为之,Discourse 默认开箱即用,已安装并启用安全的 HTTPS。该电子邮件字段仅用于通知您续订问题。

使用来自不同证书颁发机构(CA)的证书有何好处?扩展验证(EV)证书如今已不再常见,而 Discourse 可以自动管理其自己的证书。

Discourse setup 仅适用于最标准的安装。如果您有能力获取自己的证书,那么您也需负责安装它。我同意默认安装 Let’s Encrypt 确实有点令人困惑,但这样更安全,而且长期以来一直如此,收到有关问题的报告也极少。

那么,Let’s Encrypt 部分的提示就不应显示“SKIP”,因为按下回车键实际上并不会跳过该步骤。或者,如果您不使用 Let’s Encrypt,应提供一些操作提示。

但在我看来,应当支持“SKIP”选项。如果跳过,Discourse 应配置为完全不使用 SSL,仅通过 80 端口运行,而不是像上文帖子中展示的那样,陷入一种神秘且难以调试的无法运行状态。

你并没有真正解释为什么不能使用自动提供的证书,或者它为何更差。

这里听起来没有任何技术问题,充其量只是一种偏好。

我需要再仔细看看,但我觉得你说得对。我怀疑正确的做法是不询问任何内容,直接使用开发者邮箱地址来配置 Let’s Encrypt。棘手之处在于,虽然允许在开发者邮箱中包含多个地址,但 Let’s Encrypt 不允许这样做,所以实现起来会有点繁琐,但并非不可行。

@Stephen 正如本线程开头所述,任何“自动”操作都未能奏效。系统当时处于一种状态,完全无法在 80 或 443 端口提供网页服务。一旦我注释掉 SSL 模板并重新构建,80 端口就正常工作了。

这很可能是一个非常简单的修复,已有成千上万的安装顺利部署,毫无问题。

您是否使用了 Cloudflare?

您尝试在该主机名上启用 Let’s Encrypt 并部署 Discourse 多少次了?

未经同意无法与第三方共享电子邮件。

确切措辞如下

      read -p "Let's Encrypt 警告的可选邮箱地址?($letsencrypt_status) [$letsencrypt_account_email]: " new_value

它确实会跳过输入邮箱的步骤。如果您有其他需求,可以手动编辑 yaml 文件以适应您的情况。