警告:ホスト名を使用してコンピュータのポート443にアクセスできないようです

Discourse のセットアップのために ./discourse-setup を実行していますが、画像に表示されているエラーが発生しています。
このエラーをどのように修正すればよいでしょうか?使用している OS は Ubuntu 18.04 です。

私の DNS レコード:

私の sudo ufw status verbose の出力:

入力したホスト名に印刷不可能な文字が含まれています:

image

もう一度お試しください。ただし、入力をきれに行ってください。コピー&ペーストの場合は、ソースがクリーンであることを確認してください。

「いいね!」 1

変更はありませんでした。

その IP には既に WordPress が動作しているようです。

はい、WordPress はインストール済みです。同じサーバー上で両方を使用することはできませんか?

可能です。ただし、簡単ではありません。また、discourse-setup は使用できません。まずは、他のサービスが動作していないサーバーで試すことをお勧めします。

Discourse と同じマシン上で他の Web サイトを動作させる

「いいね!」 1

これらの手順に従いましたが、結果が得られませんでした。私は現在 WEBMIN を使用しています。

ほかにアイデアはありますか?

以前リンクしたトピックの指示がうまくいかない場合は、Discourse を専用サーバーで実行するのが最も簡単です。

Webmin との連携は非常に困難になるでしょう。

難しいことは承知していますが、私はアマチュアだとは思っていません。あなたがリンクした手順を試してみました。他に読むべきリンクはありますか?

この問題については、いくつかの howto トピックがあります。

「いいね!」 1

@Murto さん、こんにちは

余談ですが、Discourse をバックエンドの Rails アプリケーションとして扱う場合、TCP/IP ポートではなく Unix ドメインソケットを Rails で設定し、さらにリバースプロキシの背後に Discourse アプリケーションを配置すると、セットアップがはるかに簡単になります。

この方法であれば、TCP/IP ポートはリバースプロキシ経由でのみ公開され、Discourse アプリケーション(およびコンテナ)は Unix ドメインソケット経由で接続されます。その結果、必要なだけ多くの Discourse コンテナインスタンスを実行しても、TCP/IP ソケットの競合を気にする必要がなくなります。私見ですが、これは Discourse を運用する非常にクリーンな方法です。

もし行き詰まって方向転換を検討したい場合は、このサイトに多数の HOWTO やチュートリアルが用意されており、設定を導いてくれます。Discourse の配布パッケージには「socket」テンプレートがあり、これを使って「Discourse 側の設定」を構築できます。その後、リバースプロキシを設定するだけです(その方法については無数のチュートリアルが存在します)。「これで完了!」です。

参考になれば幸いです。

「いいね!」 4

まだ問題を解決できませんでした。詳しく説明できる方はいますか? :roll_eyes:

お試しください:

netstat -lnptu | grep :443

次に:

kill -9 PID(PID を上記コマンドの出力番号に置き換えてください)

「いいね!」 1

インターネットに公開されるサーバーにはリバースプロキシを配置し、ホストに応じてリバースプロキシが WordPress または Discourse へリダイレクトするように設定することをお勧めします。

例えば、ホスト上でポート 80 と 443 を使用する nginx サービスを実行し、blog.yourdomain へのリクエストを WordPress サービスへプロキシします(Apache + WordPress の場合、ホスト内の内部ポート(例:8080)へのリダイレクトが可能ですが、FastCGI を使用することもできます)。

同じサーバー上で Discourse を実行する際は、app.yml 内のポート番号をホストの未使用ポート(例:8081)に変更するか、@neounix が述べたように Unix ソケットを使用します。その後、forum.yourdomain へのリクエストをそのポートまたはソケットへプロキシします。Discourse を実行するには、Discourse ディレクトリ(通常は /var/discourse)で ./launch rebuild app を実行する必要があります。

この場合、アップグレード時により多くのメモリが必要となる可能性があるため主に使用される 2GB のスワップファイルの作成(サーバーに十分なメモリがある場合は不要な場合もあります)や app.yml ファイルの作成を行う discourse-setup は実行せず、それらを自分で設定してください。app.yml ファイルに何を記述すべきか分からない場合は、別サーバーで推奨されるインストールを実行し、Discourse に慣れ、生成された app.yml を確認することをお勧めします。その後、そのファイルを共有サーバーで使用できます(ポートを変更するか、ソケット方式を使用する場合はポートを削除することを忘れないでください)。

進め方が分からない場合は、関連する howto トピックのいずれかをフォローすることをお勧めします。

「いいね!」 2

リバースプロキシのプロセスをどのように行うか説明してもらえますか?何をするべきかは学びましたが、具体的な方法がわかりません。

私はプロキシを前面に置いていないため、例を持っていませんが、以前に実装した記憶があります。いずれにせよ、秘密はなく、他のリバースプロキシと同じように設定すれば問題ありません。以下は、ソケットではなくポートを使用して行うべきことの概要です。

  1. ポート 80 および 443 以外のポート(例:8443)で動作している WordPress サービスが確実に存在することを確認してください。まずインターネットに公開して動作確認を行うこともできます。

  2. Discourse についても同様に、異なるポートにマッピングしてください。

変更前:

expose:
  - "80:80"   # http
  - "443:443" # https

変更後(例):

expose:
  - "8081:80"   # http
  - "8444:443" # https

app.yml ファイルを確認してください(持っていない場合は、公式ガイドに従ってスタンドアロンマシンで Discourse を実行し、動作を確認した上で、/var/discourse/containers/ に生成された app.yml ファイルを参照することをお勧めします)。以下は app.yml ファイルのサンプルです:discourse_docker/samples/standalone.yml at master · discourse/discourse_docker · GitHub

  1. Nginx をインストールし、設定ファイルにプロキシディレクティブを追加してください。以下はサンプル抜粋です。
upstream blog {
    server localhost:8080;
}

server {
    server_name blog.barinaklar.com;
    server_tokens off;
    listen 80;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        return 301 https://blog.barinaklar.com$request_uri;
    }
}

server {
    server_name blog.barinaklar.com;
    server_tokens off;
    listen 443 ssl;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        proxy_pass           http://blog;
        proxy_redirect       off;
        proxy_set_header     Host $host;
        proxy_set_header     X-Real-IP $remote_addr;
        proxy_set_header     X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header     X-Forwarded-Host $server_name;
        proxy_set_header     X-Forwarded-Proto $scheme;
    }
}

upstream forum {
    server localhost:8081;
}

server {
    server_name forum.barinaklar.com;
    server_tokens off;
    listen 80;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        return 301 https://forum.barinaklar.com$request_uri;
    }
}

server {
    server_name forum.barinaklar.com;
    server_tokens off;
    listen 443 ssl;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        proxy_pass           http://forum;
        proxy_redirect       off;
        proxy_set_header     Host $host;
        proxy_set_header     X-Real-IP $remote_addr;
        proxy_set_header     X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header     X-Forwarded-Host $server_name;
        proxy_set_header     X-Forwarded-Proto $scheme;
    }
}

これは WordPress がポート 8080 で、Discourse がポート 8081 で動作していることを前提としています。これらのポートへのアクセスをブロックするファイアウォールを設定してください(クラウドプロバイダーはデフォルトで 22 番ポート以外のすべてのポートをブロックしていることが多いため、不要な場合もあります)。

この場合、SSL/TLS 証明書の発行はご自身で行う必要があります(certbot を cron ジョブで定期的に実行することで可能です。そのため、Nginx 設定に /.well-known/acme-challenge/ のパスを既に含めています)。


前述の通り、これは概要に過ぎず、見落としがあるかもしれません。ポート変更に伴うベース URL には特に注意してください(ユーザーを https://yourdomain ではなく https://yourdomain:8081 にリダイレクトしようとしていないか確認し、必要に応じて修正してください)。

WordPress がコンテナ内でポート 80 または 443 を使用して実行されている場合は、この手順が不要な場合があります。Discourse についても同様です。問題が発生するとすれば https 関連で、プロキシ側で http ポートを使用しているために https から http へリダイレクトされてしまう可能性があります。そのような場合は、発生を確認して修正してください。

「いいね!」 3

ご協力ありがとうございます。申請し、取引状況をお知らせいたします。