サブドメインなしでのインストールが機能しない

インストール
1

こんにちは。テスト環境のクリーンなUbuntu 20.04 VMにDiscourseをインストールしようとしています（CentOS Stream 9、Ubuntu 22.04、openSUSE MicroOSでも試しました）。プロジェクトの初期の頃からDiscourseの経験があり、現在、移行を評価しています。その場合、mydomain.tld になります（本番ドメインはフォーラムのみで、「forum」という名前が含まれており、そのように広く認識されているため、discourse.mydomain.tld は絶対に避けたいです）。サブドメインなしでDiscourseをインストールしようとした最近の試みはすべて失敗しました。6年ほど前にサブドメインなしでDiscourseフォーラムを実行していたので、可能だったと記憶しています。現在、インストールは正常に完了するように見えますが、サイトはロードされません。Ubuntuでは、http:// を明示的に指定しても、自動的に https:// に切り替わり、まったくロードされません。CentOSとMicroOSでは、http:// のNginxウェルカムページがロードされ、https:// では何もロードされません。

上記のオペレーティングシステムでの私の試みはすべて、Discourseをサブドメイン discourse.mydomain.tld にインストールした場合、Let’s Encryptの自動設定を含め、正常に機能します。DNSレコードはドメインレジストラで正しく設定されており、適切なrDNS解決も行われているようです。サーバーのホスト名は /etc/hosts で 127.0.1.1 mydomain.tld mydomain と表示され、discourse-install スクリプトはドメイン名の解決チェックで成功します。

以下は discourse-doctor の出力です。必要であれば、完全な discourse-install ログもあります。

DISCOURSE DOCTOR Sun Oct 9 13:32:47 UTC 2022
OS: Linux mydomain 5.4.0-125-generic #141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux


Found containers/app.yml

==================== YML SETTINGS ====================
DISCOURSE_HOSTNAME=mydomain.tld
SMTP_ADDRESS=mail.mydomain.tld
DEVELOPER_EMAILS=REDACTED
SMTP_PASSWORD=REDACTED
SMTP_PORT=587
SMTP_USER_NAME=admin@mydomain.tld
LETSENCRYPT_ACCOUNT_EMAIL=REDACTED

==================== DOCKER INFO ====================
DOCKER VERSION: Docker version 20.10.12, build 20.10.12-0ubuntu2~20.04.1

DOCKER PROCESSES (docker ps -a)

CONTAINER ID   IMAGE                 COMMAND        CREATED          STATUS         PORTS                                                                      NAMES
d6f7f53a81db   local_discourse/app   \"/sbin/boot\"   10 minutes ago   Up 4 minutes   0.0.0.0:80-\u003e80/tcp, :::80-\u003e80/tcp, 0.0.0.0:443-\u003e443/tcp, :::443-\u003e443/tcp   app


Discourse container app is running


==================== PLUGINS ====================
          - git clone https://github.com/discourse/docker_manager.git

No non-official plugins detected.

See https://github.com/discourse/discourse/blob/main/lib/plugin/metadata.rb for the official list.

========================================
Discourse version at mydomain.tld: NOT FOUND
Discourse version at localhost: NOT FOUND


==================== MEMORY INFORMATION ====================
OS: Linux
RAM (MB): 2029

              total        used        free      shared  buff/cache   available
Mem:           1935         823         547          30         564         934
Swap:          2047           0        2047

==================== DISK SPACE CHECK ====================
---------- OS Disk Space ----------
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        38G  8.0G   28G  23% /

==================== DISK INFORMATION ====================
Disk /dev/sda: 38.15 GiB, 40961572864 bytes, 80003072 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6643DB1B-E542-4DE1-A04C-C8EB4DAAD77E

Device      Start      End  Sectors  Size Type
/dev/sda1  528384 80003038 79474655 37.9G Linux filesystem
/dev/sda14   2048     4095     2048    1M BIOS boot
/dev/sda15   4096   528383   524288  256M EFI System

Partition table entries are not in disk order.

==================== END DISK INFORMATION ====================

==================== MAIL TEST ====================
For a robust test, get an address from http://www.mail-tester.com/
Mail test skipped.

==================== DONE! ====================
「いいね！」 1
2

ドメインがわからないと、助けるのは難しいです。インターネット上の別のマシンからドメインに詳細なcurlを実行するとどうなりますか？

「いいね！」 1
3

返信ありがとうございます。OK、それは良いアイデアですね。接続が受け付けられていないようです。

$ curl -v mydomain.tld
*   Trying 1.2.3.4:80...
* connect to 1.2.3.4 port 80 failed: Connection refused
* Failed to connect to mydomain.tld port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to mydomain.tld port 80: Connection refused

$ curl -v https://mydomain.tld
*   Trying 1.2.3.4:443...
* connect to 1.2.3.4 port 443 failed: Connection refused
* Failed to connect to mydomain.tld port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to mydomain.tld port 443: Connection refused

これは、Discourse のセットアップロジックで、.tld が .com や .org のような一般的なものであることを期待しているための制限によるものでしょうか？私のものは、テスト用に作成した 5 ドルの .tech ドメインです。

4

可能性は低いです。

サーバーはどこにホストされていますか？サーバーとクライアントの間には何がありますか？

FQDNを教えていただけると、トラブルシューティングに役立ちます。現状では、目隠しをした状態で診断を手伝ってほしいと言っているようなものですので、特定に時間がかかる場合があります。

「いいね！」 2
6

このインスタンスは discourse-setup を使用してインストールされましたか、それとも YML ファイルを手動で作成しましたか？

Hetzner で 80/443 が開いていることを確認しましたか？

Let’s encrypt は最近標準で登録されているため、セキュアポートへのリダイレクトが行われます。

7

discourse-setup を使用しました。はい、ポートは開いています。サブドメインへのインストールは問題なく機能し、同じ VM にメールサーバーの Docker インストールと Web フロントエンドもセットアップしました（ただし、後に再フォーマットしました）。

8

お読みになりましたか？

9

いや、そうではない。レジストラはHoverで、通常はかなり良い。これは奇妙だ。サーバーをセットアップして20年間、ドメインのルートにあるウェブサイトで問題を起こしたことは一度もない…

10

Hoverで持っていたドメインでは機能しなかったと記憶していますが、それはしばらく前のことです。

NSをCloudflareに切り替えて、DNSに問題があるかどうかを無料でテストしてみてはいかがでしょうか。

11

大変参考になりました。

NSをCloudFlareに切り替えて、DNSに問題があるかどうかを無料でテストしてみてはどうでしょうか。

すみません、素朴な質問ですが、ローカルDNSサーバーをCloudflareに設定するという意味でしょうか？（私は現在8.8.8.8を使用しています）それとも、ドメインに別のDNSサービスを使用するということでしょうか？

12

Hoverに問い合わせたところ、こちらを案内されました。

Glueレコードを使ってみるのも一つの方法です。これにより、サーバーがDNSマネージャーとなり、Glueレコードを使って設定できるネームサーバーにドメイン名をルーティングします。基本的に、サーバーがネームサーバーになります。

Connecting your domain using private nameservers (Glue records) : Hover Customer Support

これは私にはまだ的外れな気がします。WordPressやDrupalが動作するのと同じ状況で、なぜDiscourseがドメインのルートで動作しないのか理解できません。

13

いいえ、ドメインをレジストラ間で移動する必要はありませんが、この理論をテストするために、ドメインのNSレコードをHoverで更新して、別のプロバイダーのDNSを指すようにする必要があります。現在は ns1.hover.com と ns2.hover.com に設定されています。

これは非常に迅速で、ほとんど苦痛のないプロセスです。CloudFlareにサインアップしてドメインを追加しようとすると、2つの新しいネームサーバーが提供され、それらをHoverに入力する必要があります。Hover側のガイドはこちらにあります。

「いいね！」 1
14

CloudFlare以外でApexを使用したのはしばらく前のことです。他の落とし穴がないか確認するために、自分でテストしてみます。Apexに関する問題のほとんどはCNAMEに適用されますが、Aレコードを使用していることがわかりました。

「いいね！」 1
16

私の推測では、何か設定を誤ったまま多くの再構築を行ったため、Let’s Encrypt がレート制限のために証明書を発行できなくなったということです。

その場合、1週間待つか、www をサブドメインとして使用してみてください。これは、最近ではどちらにしても良い考えです。

ログは /var/discourse/shared/log/var-log/nginx/access.log またはおそらく

docker logs app

で確認できます。証明書が存在しないか無効であるという問題が見られるはずです。

「いいね！」 1
18

今のところ、app.ymlでSSLを無効にし、再構築を実行したところ、Discourseはサブドメインなしでポート80でロードされるようになりました。

また、Hetzner DNSを権威DNSとして使用しています。これが違いを生んだのか、それともLet’s Encrypt証明書の失敗が原因だったのかは分かりません。Let’s Encrypt証明書を再度作成してSSLを再度有効にできるようになり、再構築後に再度報告します。

19

数回以上再構築を試した場合、letsencrypt によってレート制限されている可能性があります。証明書に別のホスト名を追加することで、この問題を回避できます。

「いいね！」 1
20

はい、しかし、それらの手順はもう機能しないと思います。

Port 443に接続できない理由は、証明書が壊れており、nginxでエラーが発生するためです。

「いいね！」 3
21

迅速なご回答をいただいた皆様、ありがとうございました。Let’s Encrypt のレート制限の問題だったようです。Hover で新しいドメインを作成したところ、今回はサブドメインなしで Discourse のインストールが正常に完了しました。

「いいね！」 1
22

こんにちは、@pfaffman または他の誰か、くだらない質問ですが：Let’s Encrypt の証明書は ./launcher rebuild app を実行するたびに更新されますか？言い換えれば、試行錯誤を繰り返して Discourse インスタンスを何度も再構築した場合（ただし、完全にゼロから始めるわけではない場合）、レート制限にさらに遭遇する可能性はありますか？どうもありがとう。

23

有効な証明書があれば、再構築ごとに要求されることはないと確信しています。

「いいね！」 2