古い Multisite Domains が、マルチサイトを無効にした後もデフォルト Forum を提供し続けている

以前は、約22の異なるフォーラムを持つDiscourseマルチサイト構成を実行していました。最近、マルチサイト構成を削除し、デフォルトサイトのみを維持することにしました。

現在のデフォルトサイト: forum.mamapedia.com
削除された古いマルチサイトドメイン: forum.employ.com(およびその他21件)

問題点:

マルチサイト構成を無効にした後も、古いマルチサイトドメインからデフォルトフォーラムforum.mamapedia.com)にアクセスできてしまいます。例えば:

  • forum.mamapedia.com にアクセスすると、期待どおりに動作します。
  • しかし、forum.employ.com にアクセスすると、Mamapediaフォーラムが読み込まれます。

古いドメイン(例: forum.employ.com)は、以下のいずれかになることを期待していました。

  1. エラーが表示される(設定が解除されているため)
  2. 正しくリダイレクトされるか、完全に無効になる

セットアップに関する注記:

  • CloudflareのSSL証明書を使用しており、プロキシオプションが有効になっています(トラフィックはサーバーに直接流れません)。
  • 古いドメインのAレコードを削除することは可能ですが、DNSベースの回避策に頼るのではなく、根本原因を特定して修正したいと考えています。

これまでに行った手順:

  1. discourse.conf およびデータベースからマルチサイト設定を削除しました。
  2. Discourseを再起動し、app.yml の設定を確認しました。
  3. キャッシュをクリアし、シークレットモードでテストしました。

期待される動作:

  • forum.mamapedia.com は引き続き動作するはずです。
  • forum.employ.com およびその他の古いドメインは、Mamapediaフォーラムを提供すべきではありません。

質問:

  1. 古いドメインを、デフォルトフォーラムを提供しないように適切に削除するにはどうすればよいですか?
  2. Nginx/Traefikの設定、Cloudflareの設定を調整する必要がありますか、それとも見落としているDiscourse固有の設定がありますか?

Nginx設定

標準インストールに切り替える必要があります。マルチサイトにするために行ったことは、サーバーが複数のドメインを提供できるようにすることです。

新しいサーバーを作成してバックアップを復元すれば、何も壊れることはありません。元に戻すだけです。

唯一の注意点は、再構築中にDNSを新しいサーバーに向けて証明書を取得できるようにすることです。そして、CloudflareのDNSは「DNSのみ」にしてください。

「いいね!」 1

@pfaffman さん、ありがとうございます。マルチサイト設定から標準インストールに切り替えようとしましたが、問題は依然として残っています。

私たちが行ったこと:

  1. Discourseのアンインストール:
    • /var/discourse ディレクトリ全体を削除しました。
  2. Discourseの再インストール:
    • Discourseリポジトリを再度クローンしました。
    • 必要な設定で app.yml を再作成しました。
  3. アプリの再構築:
    • ./launcher rebuild app を実行しました。
  4. DNSの更新:
    • ドメインを新しいサーバーに向けました。
    • SSL証明書の発行を許可するために、CloudflareをDNSのみモードに設定しました。

SSLに関する追加の問題:

  • app.ymlSSLを有効にし、Cloudflareプロキシを無効にしたところ、SSLを有効にした後でも以下の問題が発生しました。

質問:

  1. データベースバックアップを復元しなかったことが原因の可能性がありますか?
  2. 古いマルチサイト設定をクリーンアップするために追加の手順が必要ですか?
  3. 問題なくSSLを有効にするための適切な方法はありますか?

以前にこれを経験したことがある方からのガイダンスをいただけると幸いです!

「いいね!」 1

discourse setup を実行しましたか、それとも手動で行いましたか?

SSL および Let’s Encrypt のテンプレートはありますか?

オレンジ色のクラウドで再構築を何度も実行した場合、レート制限されている可能性があります。

「いいね!」 1

その理由を説明します。マルチサイトでは、ホスト名に基づいてフォーラムが選択されます。マルチサイトではないインストールでは、どのホスト名からアクセスしても問題なく動作します。そのため、古いホスト名のすべてをそのインストールに向け直しておけば、残りのサイトはそれらのホスト名すべてで提供されます。

古いレコードがサイトを指していること、それが根本原因です。
古い設定をクリーンアップすることは、回避策ではなく、解決策です。

「いいね!」 2

OMG。私があなたの意見に事実として反対するのは、いつ以来か覚えていません。いつものように、あなたがコメントしたトピックであなたのアイコンを見ると、何かを学べるだろうとわかります!

それは本当です。しかし、彼らは標準インストールに切り替えたと主張しています。私は彼らを信じていません。

標準インストールでは、数年前から(ただし、Let’s Encrypt が利用可能になってからだと思いますが)、別のホスト名でアクセスするとリダイレクトされます(IPアドレスを使用すると簡単に確認できます。私は forum.bigmouth.bass/etc/hosts に標準インストールに設定して別のテストを行い、期待どおりにリダイレクトされました。https でアクセスすると(ほとんどのブラウザはデフォルトでそうします)、証明書エラーが発生します。

サイトに別のホスト名でアクセスするために必要なのが DNS だけだとすると、誰でも DNS レコードを作成してあなたのサイトを指すことで、あなたのサイトをハイジャックできます。

これが魔法だと思います:

app.yml にはまだ次のようなものが含まれていると推測します:

「いいね!」 3

さて、もっと頻繁に事実を更新すべきだと知りました!そのコードは2014年からそこにあったので、私はずっと過去に生きていたのだと思います。

あなたは完全に正しいです、それはリダイレクトされます。

「いいね!」 2

ありがとうございます @RGJ@pfaffman

app.ymlを確認しましたが、カスタムのリダイレクト設定やオーバーライドはありませんでした。それでも、私たちのインスタンスは未だに未知のホスト名をメインドメインにリダイレクトしていません。

  1. Nginxの設定: templates/web.ssl.template.ymlからのリダイレクトロジックが実際に適用されているかどうかを確認する方法はありますか?生成されたNginxの設定をコンテナ内で手動で確認すべきでしょうか?

  2. Discourseのデバッグ: コンテナ内で実行できるログやコマンドはありますか?Discourseがホスト名を正しく処理しているかを確認するために。

  3. その他の原因: app.ymlがクリーンであれば、期待されるリダイレクト動作を妨げる他の要因は何でしょうか?Cloudflareや他の設定が干渉している可能性はありますか?

この件について深掘りするための指針をいただけると幸いです!」}# 1. Nginxの設定値を確認するには、コンテナ内で nginx -T コマンドを実行して、現在の設定をすべて出力させると良いでしょう。

2. Discourse の動作確認には、コンテナ内で rails c コマンドを使い、SiteSetting の設定を確認したり、hostname 関連の設定を調べることができます。

3. Cloudflareや他のCDN設定もリダイレクトに影響を与えることがあります。Cloudflareのページルールやページリダイレクト設定、SSL/TLS設定も併せて確認してください。

こちらがポインターです。

古いドメインはすべてオレンジ色のクラウドが有効になっていますか?オレンジ色のクラウドから外れることで問題は解決しますか?もしそうなら、私がずっと予想していたように、リチャードが正しく、セットアップをクリーンアップする必要があります。

しかし、Cloudflare を使用することで、悪意のあるアクター (この場合はあなた) が他人のサイトをそのドメインで提供できるようになるのであれば、それは問題のように思えます。

「いいね!」 1

OK、ダウンロード後に実行すべきですか?

./discourse-setup

それとも、ダウンロード後に古いapp.ymlを貼り付けてから実行すべきですか?

./launcher rebuild app

どちらのパスを選択すべきですか?

「いいね!」 1

古いドメインはすでに削除しましたが、はい、それらはオレンジ色のボタンが有効になっていました。現在、誰かが私たちのサーバーIPを取得し、プロキシオプションを有効にしてそこにAレコードを設定した場合、彼らのドメインで私たちのサイトが提供されてしまいます。

「いいね!」 1

標準的なインストールであることを確認するために discourse-setup を実行する必要があります。古い app.yml を貼り付けると、そこに含まれていないものが含まれている可能性があります。まだ標準的なセットアップではないと確信が持てません。

まだそうであるとは確信していませんが、もしそうであれば、あなたができることは何もありません。

「いいね!」 1

世界のサーバーIPのほとんどは公開されています。それがIPシステムの趣旨です。

「いいね!」 1

@pfaffman @RGJ 本当に感謝します。これでクリーンになり、ほぼ良くなりました。

現在直面している問題は、すべてのブランディング画像が消えてしまい、一部のユーザーの画像も同様です。

ブランディングデータは問題なく、古いサーバーからダウンロードできますが、ユーザーの画像やサイト全体の画像はどうでしょうか。

新しいサーバー

古いサーバー

注:

「いいね!」 1

これがマルチサイトのメインサイトでなかった場合、アップロードのパスはデフォルトではなく、サイト名とサイトになります。

「いいね!」 1

画像が見つからないのですが、「ネストされた」URLのようです。たとえば、こちらです。

(https://forum.mamapedia.com/user_avatar/forum.mamapedia.com/jakeatgetit/24/5872_2.png)

@pfaffman さん、これは実際にはマルチサイト設定のメインサイトでした。

CC: @Abdelrahman_MoHamed

うーん。もしそれがメインサイトだったら、そのパスは https://forum.mamapedia.com/user_avatar/forum.mamapedia.com/jakeatgetit/24/5872_2.png になるはずですが、それも機能しません。

もし古いサイトがまだ残っているなら、このサイトのバックアップを取って、それを新しいサイトに復元することをお勧めします。

@pfaffman さん、ありがとうございます。これまでの作業でうまくいっているようです。

古いサーバーに入り、/var/discourse/shared/standalone/uploads/default から新しいサーバーの同じパスにデータを移動したところ、すべてのユーザーアバターと投稿が戻ってきました。

新しい問題は、サイトのブランディングを更新しようとしても機能しないことです。

1分間の画面録画はこちらです。

「いいね!」 1

こちらに戻って、どなたかアイデアがないか確認しています。こちらはもうすぐ完了しますが、「ロゴなし」の保存問題のトラブルシューティングに少し支援が必要です。何か解決策をご存知でしたら、事前に感謝いたします!