最新のアップグレードでは、ランチャーでアプリを再構築する必要がありましたが、失敗しました。
secondsite データベースの移行中に失敗したようです。
2025-08-21 06:44:42.493 UTC [867] discourse@discourse_nu ERROR: vector 拡張機能の所有者である必要があります
2025-08-21 06:44:42.493 UTC [867] discourse@discourse_nu STATEMENT: ALTER EXTENSION vector UPDATE TO ‘0.7.0’;
マイグレーションが 1 件失敗しました！
secondsite のマイグレーションに失敗しました
同じ件についての議論はこちらをご覧ください: Still an issue: ERROR: must be owner of extension vector - #2 by Falco
それが解決しました。
しかし、私が1年以上前に報告したnginxとsecondsitesの問題はまだ残っています。
コンテナ内のnginx設定ファイルでは、URLが最初のサイトのものではないかどうかを確認し、そうであればそれに変更します。私はそのコードを（再び）コメントアウトしました。
nginxの設定の処理方法に大きな変更がありました。
リバースプロキシなしのマルチサイト設定を使用していますか？
nginx をあまり見ていないのは約 2 年前ですが、この問題は 2 年前に Discourse に移行したときから存在していたので、新しいものではありません。
nginx.conf ファイルからの抜粋を以下に示します。
server {
server_name huskerlist.tssi.com;
root /var/www/html;
allow 162.210.7.125;
allow 162.210.7.112;
allow 162.210.7.116;
allow 76.84.125.160;
allow 172.17.0.2;
allow 72.250.242.47;
allow all;
if ( $lockdown ) {
set $custom_server_name "lists.tssi.com";
return 300 "site is down for maintenance";
}
client_max_body_size 100M;
# Load configuration files for the default server block.
#include /etc/nginx/default.d/*.conf;
location / {
proxy_pass https://127.0.0.1:8443/;
#proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
error_page 404 /404.html;
location = /usr/share/nginx/html/40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /usr/share/nginx/html/50x.html {
}
listen [::]:443 ssl; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/lists.tssi.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/lists.tssi.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
server_name nu-sports.tssi.com;
root /var/www/html;
allow 162.210.7.125;
allow 162.210.7.112;
allow 162.210.7.116;
allow 76.84.125.160;
allow 172.17.0.2;
allow 72.250.242.47;
allow all;
if ( $lockdown ) {
set $custom_server_name "lists.tssi.com";
rewrite ^ https://lists.tssi.com/n-maint.html;
}
client_max_body_size 100M;
# Load configuration files for the default server block.
#include /etc/nginx/default.d/*.conf;
location / {
proxy_pass https://127.0.0.1:8443/;
#proxy_pass http://unix:/var/discourse/shared/standalone/nginx2.http.sock:;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
error_page 404 /404.html;
location = /usr/share/nginx/html/40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /usr/share/nginx/html/50x.html {
}
listen [::]:443 ssl; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/lists.tssi.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/lists.tssi.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
再起動時などに新しいコンテナがセットアップされるたびに、以下の行を含む /etc/nginx/conf.d/outlets/server/20-https.conf ファイルが書き直されるようです。これらの行は、デフォルトの Discourse システムへのリダイレクトを引き起こします。
if ($https_host != huskerlist.tssi.com) {
rewrite (.$) https://huskerlist.tssi.com
}
これを回避する方法はありますか？このコードの目的は何ですか？
その通りです。コンテナ内でそのファイルを編集していますか？新しいコンテナをビルドすると、新しいコンテナが作成されます。そのファイルを上書きしているのではなく、すべてのファイルを上書きしています。
上書きされた後にファイルを変更するために、app.yml に何かを追加できます。
そのファイルにどのような変更を加えていますか？なぜですか？
ああ。待って。
この質問には答えていませんが、答えは「はい」だと思います。
サイトはほとんどの場合、複数のホスト名で利用できるようにしたくないため、サイトを強制します。
そのため、それを元に戻すために app.yml にコードを追加する必要があります。
ずっと前に、Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy でこの解決策を持っていました。
そのため、exec に sed を追加するか、いくつかの replace ステートメントを使用してその部分を削除または変更する必要があるでしょう。おそらく、複数のサイトを取得するために、そのトピック（まだ機能すると思われる）の手順に従う必要があるでしょう。 追加のホスト名の証明書を取得するために、 DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org を使用できるようになりました。
おそらく最も賢い解決策は、他のホスト名のエイリアスをその if ($http_host != コードに組み込むように工夫することでしょう。現在、そのようなサイトは設定していないため、楽しみのために時間をかけて理解しようとは思わないでしょう。
しかし、web ssl template には次のものが含まれています。
if (\\$http_host != ${DISCOURSE_HOSTNAME}) {
rewrite (.*) https://${DISCOURSE_HOSTNAME}\\$1 permanent;
}
そのため、それを削除するか、他のホスト名もチェックするようにする方法を見つけることができます。
つまり、「secondsite」メソッドを使用して1つのサーバーで2つの独立したフォーラムをホストする方法は壊れており、修正リストにも載っていないということですね。
なので、削除するか、他のホスト名もチェックするようにする方法を見つけるかのどちらかです。
コンテナ内で削除していますが、コンテナが起動するたびに、または新しいコンテナイメージが生成されるたびに、そのコードが元に戻ってしまうため、ソースのどこかを変更して、新しいコンテナをビルドする際にapp.ymlで複数のドメインをチェックするようにビルドする必要があるのです。（おそらく、その3行のコードを削除するよりも望ましいでしょう。）
Web SSLテンプレートをビルドするコードが、2番目のサイト（および3番目のサイトなど）をチェックするためにapp.ymlを更新しないのであれば、これはapp.ymlで行う必要があるようです。これは、明らかに壊れている「secondsite」メソッドを使用して、単一サーバーで複数のフォーラムを実行しているすべてのユーザーの修正ではなく、私にとってのカスタム修正となります。
現在、クライアントのために大規模なシステム移行プロジェクトの途上にあり、これらのサイトはサッカーシーズン中に最も活発になるため、ライブシステムをその場で修正しようとするのではなく、app.ymlの修正をテストするためのテストベッドサーバーをセットアップする必要があります。
少し考えてみましたが、SSLテンプレートの修正はやや困難です。
現在のロジックは、「サイトがAでなければ、Aにする」というものです。
セカンドサイトを導入すると、サイトがAでもBでもない場合、AまたはBのどちらかに変更することが正しいことなのかも不明確になるため、事態は複雑になります。（おそらく、これがDiscourseでこの問題が対処されていない理由でしょう。）
結局のところ、外部のnginxサーバーはAまたはBのいずれかに一致するHTTPSパケットのみを送信するはずなので、複数のサイトがある場合にそれらのコード行を削除することが正しいのかもしれません。HTTPからHTTPSへの強制は、外部のnginxサーバーで既に実行されているはずです。
サポートリストに載ったことは一度もありません。常にリバースプロキシの使用が推奨されていました。リバースプロキシなしで実現する方法を考案しました。そして、そのハックは数年前に壊れました。
リバースプロキシなしでマルチサイトを行うことは、常に手品のようなものでした。プロであれば、SSLとLet’s Encryptのテンプレートを削除し、SSLを処理するリバースプロキシを使用すべきです。Cdckはhaproxyを使用しています。私はtraefikを使用してきました。Caddyは管理が非常に簡単です。使用をやめたのは、誰かがサイトのCNAMEを削除すると、すべての証明書の更新が失敗する原因となったためです（これは現在では当てはまらないかもしれませんが、もう何年も前のことです）。
nginx の proxy_pass を使用してコンテナにトラフィックを渡しているのですが、これはマルチサイトでリバースプロキシ方式を使用しているということになりますか？
はい、それも忘れていました！
https を実行し、yml ファイルから ssl および let’s encrypt テンプレートを削除するようにしてください。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.