⚠ このコンピュータのポート 443 は、ホスト名 metabolism.logophilia.eu を使用してアクセスできないようです ----

サポート
8

フィードバックをありがとうございます。お時間をいただき、本当に感謝しています。少し生意気なことを言うようですが：

[2/5] 設定の準備中
✓ ポート 80 と 443 は使用可能です

確かに最初は「使用可能です」と表示されます。とはいえ、私は Gemini の助けを借りて（主に Docker の使い方についてですが、笑）、インスタンスを起動して運用できるようになりました。他の Virtualmin ユーザーのために私の「ランブック」を提供したいと考えています。なぜなら、「443 ポートを解放する」ことがここでの解決策ではないからです。以降の投稿はその内容になります。もし別の場所（新しいスレッドなど）に投稿すべきであれば、どこに投稿すべきか教えてください。この設定で困っているのは私だけではないと思いますし、他の人にも役立つかもしれません。改めてありがとうございます！

Webmin/Virtualmin で管理されている VPS を使用し、サブドメインを利用している場合：

Virtualmin + Discourse 究極のランブック *

  • (1) 残骸のクリーンアップ（再試行する場合、私のように）：

    rm -rf /var/discourse/shared/standalone/ssl/*

    rm -rf /var/discourse/shared/standalone/letsencrypt

    rm -rf /var/discourse/shared/standalone/state

  • (2) テンプレートの削除：

    app.yml から templates/web.ssl.template.yml と templates/web.letsencrypt.ssl.template.yml の行を完全に削除してください。カスタムランチャーパーサーは、# でプレフィックスされていてもそれらを評価します。

  • (3) メール設定と変数：

    DISCOURSE_SKIP_EMAIL_SETUP を '1' から '0' に変更してください。Discourse が接続して DiscordID を確認できないためです。

    DISCOURSE_FORCE_HTTPS: true を追加して、バックエンドが安全な URL を生成できるようにします。

    親切なメモ： DISCOURSE_SMTP_USER_NAME をフルメールアドレス（例：'logophilia@logophilia.eu'）ではなく、生メールボックスアカウント名（例：'logophilia'）に設定し、潜在的な YAML 文字列解析バグを回避するために資格情報をシングルクォート（'）で囲んでください。

  • (4) Expose ブロックの設定：

    app.yml の expose: ブロックに HTTP マッピングが含まれていることを確認してください。443=>8443 のマッピングはオプション/冗長です。Virtualmin が SSL ロジックを終了してから転送するためです。

    expose:
  - 8080:80

    これで再構築を開始できます：

    cd /var/discourse
./launcher rebuild app

  • (5) サブドメインとプロキシパスの設定：

    • Virtualmin で通常通りサブドメインを作成し、Let’s Encrypt SSL 証明書で保護してください（自動的に完了しますが、何らかの無関係な理由でエラーが出ないことを確認してください）。
    • Proxy Paths（Virtualmin → サブドメイン → Web 設定 → Proxy Paths）に移動し、/ から http://localhost:8080/ への新しいマッピングを作成します。「serve locally」はチェックを外したままにしますが、リアルタイム更新と通知ストリームを許可するために Proxy WebSocket を Yes に切り替えてください。

  • (6) CSRF ヘッダーディレクティブ：

    • Webmin ➔ サーバー ➔ Apache Webserver ➔ [サブドメインの設定を見つけて 443 の設定をクリック] ➔ ディレクティブの編集で、以下の行を Virtualmin 独自の Let’s Encrypt プロキシブロック（通常は「ProxyPass /.well-known !」）の直上に配置して、CSRF トークンの転送を可能にします。
    ProxyPreserveHost On
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-For %{REMOTE_ADDR}s

    ProxyPreserveHost On: Discourse に「localhost」ではなく実際のドメイン名を伝えます。
    RequestHeader set X-Forwarded-Proto "https": ユーザーが安全な接続を使用していることを明示的に Discourse に伝え、DISCOURSE_FORCE_HTTPS: true の設定と一致させます。
    RequestHeader set X-Forwarded-For: 訪問者の実際の IP アドレスをコンテナに渡して、セキュリティログが機能するようにします。

  • (7) クリーンなコンテナハンドシェイク：

    長い（申し訳ありません…でも本当です;-）再構築プロセスが完了する間に、潜在的に停止しているコンテナのブループリントを docker rm -f app で消去してください。その後、./launcher start app を実行すると、ポート 8080 にバインドされた完全に新しいインスタンスが起動します。docker ps で「ports」に以下のような表示があることを確認してください。

    # docker ps
CONTAINER ID   IMAGE                 COMMAND        CREATED          STATUS          PORTS                                                                                NAMES
d21772a21e36   local_discourse/app   "/sbin/boot"   45 minutes ago   Up 45 minutes   0.0.0.0:8080->80/tcp, [::]:8080->80/tcp, 0.0.0.0:8443->443/tcp, [::]:8443->443/tcp   app

    （ご覧の通り、私は app.yml に 443=>8443 ディレクティブを残していますが、どちらでも動作します。）

  • (8) 監視と起動：

    データベースのマイグレーションが完了し、ワーカーがリクエストの処理を開始するまで、docker logs -f app でブートストリームをトレースしてください。基本的には、一連の「INFO」行が素早く表示されます。

  • (9) 完了：

    ブラウザでサブドメインを開き、登録をクリックして、システムがメールボックスに検証メールを送信するようにします。

*) 反証されるまで :wink: