Discourseインストール後、ブラウザからアクセスできません

こんにちは、

Ubuntu 18 の新しいクラウドサーバーをセットアップし、これまでと同様に Discourse をインストールしました。標準的な 30 分以内のセットアップです。しかし、最初に管理者アカウントを作成しようとしてブラウザからインストールページにアクセスすると、「サーバーに接続できません」というエラーが表示されます。他のサーバーと異なる点は 2 つあります。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.

「いいね!」 2

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.

「いいね!」 2

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!

「いいね!」 4

自分もこれで何時間も無駄にしました。discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub のインストール手順では、Let’s Encrypt の行で Enter を押せばスキップされると示唆されていますが、実際にはそうではありません。それでも、me@example.com というメールアドレスにアクセスできない SSL 証明書の設定が行われてしまいます。

その後、app.yml を編集して Let’s Encrypt のメールアドレス行と SSL テンプレートをコメントアウトし、launcher を再構築する必要があります。これは discourse-setup のバグと見なすべきだと思います。また、discourse-setup には、最初から他の認証局から取得した独自の SSL 証明書をインストールする機能があるべきで、再構築する必要がないようにすべきです。

これは意図的なもので、Discourse は最初から HTTPS による安全な設定がデフォルトで適用されます。そのメールフィールドは、更新に関する問題について通知するためだけに使用されます。

別の CA からの証明書を使用することによるメリットは何でしょうか?EV 証明書はもはや一般的ではなく、Discourse は独自に証明書を自動的に管理できます。

Discourse setup は最も標準的なインストールのみを対象としています。ご自身で証明書を取得できるのであれば、そのインストールもご自身で行う必要があります。Let’s Encrypt がデフォルトでインストールされることに少し混乱を覚える点は同意しますが、より安全であり、また非常に長い間、問題の報告がほとんどない状態で運用されています。

そのため、Let’s Encrypt のセクションにあるプロンプトに「SKIP」と表示されるべきではありません。ENTER キーを押しても実際にはスキップされないためです。あるいは、Let’s Encrypt を使用しない場合の対処法を示すヒントを表示するべきです。

しかし、私の意見では「SKIP」はサポートされるべきです。スキップされた場合、Discourse は SSL なしで設定され、ポート 80 のみで動作するべきです。上記の投稿が示すように、謎めいてデバッグが困難な状態で動作しないのではなく、ポート 80 のみで動作するべきです。

自動で提供される証明書が使用できない理由、またはなぜそれが劣っているのかについて、まだ十分に説明されていません。

ここには技術的な問題はないように思われます。せいぜい好みの問題です。

「いいね!」 1

もう少し詳しく確認する必要がありますが、おっしゃる通りだと思います。おそらく、何も質問せず、開発者用メールアドレスを Let’s Encrypt にそのまま使用するべきなのでしょう。問題点は、開発者用メールアドレスには複数のアドレスを含めることが合法ですが、Let’s Encrypt についてはそうではないことです。そのため、少し手間がかかりますが、不可能ではありません。

@Stephen まあ、このスレッドの冒頭にもある通り、何が「自動的」に行われていたとしても、それは機能しませんでした。システムはポート 80 または 443 でまったく Web ページを提供できない状態に陥っていました。SSL テンプレートをコメントアウトして再構築したところ、ポート 80 では問題なく動作するようになりました。

おそらく非常に簡単な修正で済むはずです。何千ものインストールで問題なくセットアップされています。

Cloudflare を使用していますか?

そのホスト名で Let’s Encrypt を有効にして Discourse のセットアップを何回試みましたか?

同意なしに第三者とメールを共有することはできません。

実際の表示文言は以下の通りです。

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

これはメールアドレスの入力をスキップします。異なる要件がある場合は、yaml ファイルを手動で編集して対応してください。

「いいね!」 2