Discourse セットアップスクリプトにおける Let's Encrypt のホスト名検証

それはもう当てはまらないと思います。

まさにその通りです、@jomaxro。だからこそ、私は次のように言いました。

おっと、その変更を見落としていました。

つまり、ユーザーが Let’s Encrypt の通知メールアドレスを提供しない場合、discourse-setup はドメインが現在のサーバーに解決されるかを確認せずに、Let’s Encrypt を無条件で有効化します。しかし、メールアドレスを提供した場合はそのチェックを行います。これはあまり良い考えとは思えません。

有効なドメイン名を持っていないのに、なぜ HTTPS を強制するのでしょうか?全員が常に HTTPS を使用することを強制する方針であれば、ドメイン名が有効か確認した上で、実行を拒否すべきであり、壊れたインストール状態を招くべきではありません。

現在の動作では、Let’s Encrypt のメールアドレスを提供せず、かつドメインがサーバーに解決されない場合、discourse-setup は成功したように見えますが、nginx が証明書を見つけられないため、接続を受け付けない Web サーバーが起動してしまいます。より良い対応としては、Let’s Encrypt のメールアドレスを尋ねず、(最初の) 開発者メールアドレスを使用して Let’s Encrypt を設定し、かつ DNS チェックも実施するべきだと考えます。ただし、この件は今回のトピックには含まれないべきでしょう。

いいえ、Let’s Encrypt の仕組みはそうではありません。メールアドレスはドメインの検証とは無関係です。これは、証明書が期限切れになり更新できない場合にユーザーに通知するために使用されます。検証は常に DNS によって行われます。

Let’s Encrypt は、検証要件を満たしていないアドレスに対して証明書を発行することはできません。もし発行してしまった場合、LE の仕組み全体が一夜にして崩壊してしまいます。

いいえ、それは discourse-setup の仕組み(かつての仕組み)です。以前は、証明書の取得がほぼ確実に失敗すると判断される場合、ユーザーがリクエストするのを防いでいました。現在は、成功のしようがない状況でも証明書の取得を進めてしまい、失敗したことをユーザーに報告する手段がないため、警告もなく静かに失敗するようになりました。

もう一度、なぜ失敗するのでしょうか?ドメインの検証にメールアドレスは必須ではありません。

失敗してもメールは送信されませんでした。

メールは、Let’s Encrypt の更新に失敗して証明書が期限切れになる可能性がある場合に、ユーザーに後で通知するためだけのものです。証明書に問題なく更新されれば、ユーザーがメールを見ることはありません。

それは変更の意図ではなかったと思います。意図は、メールアドレスが提供されていなくても SSL を有効化することでした。ドメインの解決を確認すべきです。cc @Falco

ドメイン名がホストに解決されない場合は失敗します。メールアドレスは問題ありませんが、Discourse のセットアップ中にメールアドレスが解決されない場合、ユーザーに警告が表示されます。

ドメインの解決は必ず @falco を経由する必要があります。それ以外の場合はセットアップを停止してください。これは悪い変更です。

そこで、ブランチ内でいくつか変更を加えました。以下がその仕組みです。

間違ったホスト名を使用した場合:

root@droplet:/var/discourse# ./discourse-setup

Discourse のホスト名を入力してください?: bad-domain.com

ドメイン名を確認中 . . .
WARNING:: このサーバーは bad-domain.com:443 からアクセスできないようです。

http://bad-domain.com(ポート 80)への接続も失敗しました。

これは bad-domain.com が誤った IP アドレスに解決されているか、
トラフィックがサーバーにルーティングされていないことを示唆しています。

この問題を解決するには、Google で「open ports YOUR CLOUD SERVICE」と検索してください。

いずれにせよ続行したい場合は、cp samples/standalone.yml containers/app.yml を実行し、
containers/app.yml ファイルを手動で編集する必要があります。

正しいホスト名を使用した場合:

root@droplet:/var/discourse# ./discourse-setup

Discourse のホスト名を入力してください?: good-domain.com

ドメイン名を確認中 . . .
good-domain.com への接続に成功しました。
管理者アカウントのメールアドレスを入力してください?: 

変更は以下のプルリクエストで保留中です。

@pfaffman さん、@codinghorror さん、これで問題ありませんか?

なぜこの変更が必要だったのかについてのコメント

まず、この状態になってからほぼ3ヶ月が経過しているのに、多くの不満が寄せられていないことに驚いています。さらに、この変更を私の注意に引き寄せたトピック自体も、この変更によって問題を抱えていなかったため、私が考えているほど重要ではないのかもしれません。

私があまり理解できない最初の点は、discourse-setupを使ってhttpのみのサイトを構築することが不可能になるように本当にしたいのかということです。おそらく、メールが機能するようにすでにDNSの設定をたくさん行っているはずなので、Aレコードを作成させるのもそれほど大きな問題ではないかもしれません。

変更に関するフィードバック

私が気づいていない変更を加えたとしたら別ですが、スクリプトは質問を始める前にapp.ymlを作成します。そのため、「DNS設定なしのDiscourseインストールはサポートされていません。DNS設定なしで続行する場合は、app.ymlを編集して必要に応じて設定し、./launcher rebuild appを実行してください」といったメッセージを表示し、ブートストラップを実行せずに終了させることができます。

また、すべてのユーザーにLet’s EncryptとHTTPSの使用を強制するつもりなら、standalone.ymlweb_only.ymlをそれに応じて変更し、それらの細かいsedコマンドを削除することも意味があるかもしれません。

その他の考察

「これが私の問題だ」という部門からの話ですが、現在のインストールスクリプトは、DNSを設定する前に実行されます。私はユーザーのためにドロプレットを作成し、Discourseを設定し、DNSの指示を含むメールを送信し、DNSが設定されるのを待ってから、app.ymlを変更してテンプレートを有効にし、Let’s Encryptのアドレスを設定します。しかし、これは単に歴史的な理由によるもので、私がすべきことは、ドロプレットを作成し、Mailgunを設定し、DNSを待ってからその後にインストールを行うことです。それでも、私のスクリプトはdiscourse-setupを使用できます。私はこれを頻繁に動作確認のために使用するのが好きです(あなたがたがdiscourse-setupの自動テストを行っているとは思いませんが)

はい、その通りです。

この変更については一切の不満を受けておらず、実装されてから HTTP のみの Discourse インスタンスが大量に作成されることもありません。なぜなら、「オプション」と書かれていると、誰もが深く考えずにスキップしてしまうからです。これは、Discourse の安全なデフォルト設定を実現するための素晴らしい変更だと個人的には思います。30 分ガイドで目指しているのもこれです。

なるほど、それならさらに優れていますね。必要な指示が少なくて済みます!

ああ、これであなたのこの変更に対する強い反応の理由がわかりました。あなたのセットアップを壊してしまったのですから、申し訳ありません。

対話型スクリプトを対象とするのではなく、自動化された処理には直接 yml ファイルを使用することを強くお勧めします。

tl;dr: はい、私が提案した小さな言語の微調整を加えれば、これで問題ありません。

同意します。苦情ゼロ!勝利ですね。

いいえ、壊していません!(!)私が HTTPS を有効化するインストールの第二段階を行う前に、サイトが起動していないことに気づいただけです。そして、私の環境設定はあなたの責任ではありません。(ああ、なら私のスクリプトが壊れてしまいますが、DNS が設定される前にインストールを行わない方が結局は良いことです。少なくとも1年前から、HTTPS ではないインストールは行っていません。)

私が自分のスクリプトで discourse-setup を使いたがっていた理由は、インストールの顧客が「標準インストール」を確実に受けられるようにするためです。また、誰かが「インストールをしたが動かない」と言った場合、私のスクリプトを実行して、彼らがやるべきことを正確に行い、「さて、今インストールをやってみたが、問題なく動きました」と言えるからです。しかし、過去3年間で問題が見つかったことを覚えているのは一度もありません。おそらく、私の「テスト」は誰の役にも立っていないのでしょう。

素晴らしい、分析とレビューをありがとうございます!

PR をマージしましたので、これからは常に DNS を検証します。