\u003e Das neueste Upgrade erforderte den Neuerstellung der App im Launcher, aber es schlug fehl.\n\nEs sieht so aus, als ob die Migration der secondsite-Datenbank fehlgeschlagen ist:\n\n2025-08-21 06:44:42.493 UTC \[867\] discourse@discourse_nu ERROR: must be owner of extension vector\n2025-08-21 06:44:42.493 UTC \[867\] discourse@discourse_nu STATEMENT: ALTER EXTENSION vector UPDATE TO ‘0.7.0’;\n\n—\n\n1 Migration fehlgeschlagen!\n\nMigration von secondsite fehlgeschlagen
Ursache
- Die Migration versucht, die „vector“-Erweiterung zu aktualisieren.
- Der PostgreSQL-Benutzer, der die Migration ausführt (z. B. discourse), muss der Eigentümer der Erweiterung sein, aber sie gehört einem anderen Benutzer (oft postgres).
Lösung
- Stellen Sie als Eigentümer eine Verbindung zu Ihrer Datenbank her
- Führen Sie das Update als Eigentümer aus
Lesen Sie die Diskussion dazu unter Still an issue: ERROR: must be owner of extension vector - #2 by Falco
1 „Gefällt mir“
Das hat es behoben.
Das Problem mit nginx und secondsites, das ich vor über einem Jahr gemeldet habe, besteht jedoch weiterhin.
In den nginx-Konfigurationsdateien innerhalb des Containers wird geprüft, ob die URL nicht für die erste Website ist, und sie wird zu dieser geändert. Ich habe diesen Code auskommentiert – erneut.
1 „Gefällt mir“
Es gab große Änderungen daran, wie die nginx-Konfiguration gehandhabt wird.
Haben Sie eine Multisite-Einrichtung ohne Reverse-Proxy?
Nun, es ist fast 2 Jahre her, dass ich mich mit nginx beschäftigt habe, aber dieses Problem bestand schon, als ich vor 2 Jahren zu Discourse wechselte, also ist es nicht neu.
Hier ist ein Auszug aus der Datei 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
}
Anscheinend schreibt es jedes Mal, wenn ein neuer Container eingerichtet wird (z. B. während eines Neustarts), die Datei /etc/nginx/conf.d/outlets/server/20-https.conf neu, und diese Zeilen leiten zum Standard-Discourse-System um:
if ($https_host != huskerlist.tssi.com) {
rewrite (.$) https://huskerlist.tssi.com
}
Gibt es eine Möglichkeit, dies zu vermeiden? Welchen Zweck erfüllt dieser Code?
Das stimmt. Bearbeiten Sie diese Datei innerhalb des Containers? Das Erstellen eines neuen Containers erstellt einen neuen Container. Es überschreibt nicht nur diese Datei, sondern alle Dateien.
Sie können Ihrer app.yml etwas hinzufügen, um die Datei zu ändern, nachdem sie überschrieben wurde.
Welche Änderungen nehmen Sie an dieser Datei vor? Warum?
Oh. Moment.
Diese Frage haben Sie nicht beantwortet, aber ich denke, die Antwort ist ja.
Es erzwingt die Seite, da Sie meist nie möchten, dass Ihre Seite über mehr als einen Hostnamen verfügbar ist.
Sie müssen also etwas Code zu Ihrer app.yml hinzufügen, um dies rückgängig zu machen.
Vor langer Zeit hatte ich eine Lösung dafür in Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy
Sie müssen also ein sed in einem exec hinzufügen oder vielleicht einige replace-Stanzas verwenden, um dieses Bit zu entfernen oder zu ändern. Sie müssen wahrscheinlich immer noch die Dinge in diesem Thema befolgen (von denen ich glaube, dass sie immer noch funktionieren), um mehrere Sie können jetzt DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org verwenden, um Zertifikate für die zusätzlichen Hostnamen zu erhalten.
Ich vermute, die raffinierteste Lösung wäre, die anderen Hostnamen-Aliase irgendwie in diesen if ($http_host != Code einzubauen. Ich habe derzeit keine Websites, die so eingerichtet sind, daher werde ich wahrscheinlich keine Zeit damit verbringen, es zum Spaß herauszufinden.
Aber ja, die web ssl template hat dies:
if (\\$http_host != ${DISCOURSE_HOSTNAME}) {
rewrite (.*) https://${DISCOURSE_HOSTNAME}\\$1 permanent;
}
Sie könnten es also entweder löschen oder einen Weg finden, es auch für Ihre anderen Hostnamen überprüfen zu lassen.
Sie sagen also im Grunde, dass die ‘secondsite’-Methode zum Hosten von zwei unabhängigen Foren auf einem Server kaputt ist und nicht auf der Liste der zu behebenden Probleme steht.
Sie könnten es also entweder löschen oder einen Weg finden, es auch für Ihre anderen Hostnamen überprüfen zu lassen.
Es zu löschen ist das, was ich im Container getan habe, aber jedes Mal, wenn ein Container startet oder ein neues Container-Image generiert wird, wird dieser Code wieder eingefügt. Er muss also irgendwo im Quellcode geändert werden, damit beim Erstellen eines neuen Containers dieser korrekt mehrere Domains in app.yml überprüft. (Das ist wahrscheinlich besser, als nur diese 3 Codezeilen zu löschen.)
Wenn der Code, der die Web-SSL-Vorlage erstellt, nicht aktualisiert wird, um app.yml für eine zweite (und dritte und…) Website zu überprüfen, dann muss dies anscheinend in app.yml geschehen, was eine benutzerdefinierte Lösung für mich darstellt und keine Lösung für alle Benutzer, die mehrere Foren auf einem einzigen Server mit der anscheinend kaputten ‘secondsite’-Methode betreiben.
Im Moment befinde ich mich mitten in einem großen Systemmigrationsprojekt für einen Kunden, und diese Websites sind während der Fußballsaison ohnehin am aktivsten. Daher muss ich meinen Testserver einrichten, um das Schreiben von app.yml-Korrekturen zu testen, anstatt zu versuchen, das Live-System im laufenden Betrieb zu reparieren.
Kurz darüber nachdenkend ist die Korrektur der SSL-Vorlage etwas schwierig.
Die aktuelle Logik besagt: Wenn die Seite nicht A ist, mache sie zu A.
Die Einführung einer zweiten Seite verkompliziert die Dinge, denn wenn sie weder A noch B ist, ist es auch nicht klar, ob die Änderung zu A oder B das Richtige ist. (Das mag der Grund sein, warum dies von Discourse nicht angegangen wurde.)
Vielleicht ist das Löschen dieser Codezeilen doch das Richtige, wenn es mehrere Seiten gibt, denn der externe Nginx-Server sollte nur HTTPS-Pakete durchlassen, die entweder A oder B entsprechen. Das Erzwingen von HTTP zu HTTPS sollte bereits im externen Nginx-Server geschehen.
Es stand nie auf der Liste der zu unterstützenden Dinge. Die empfohlene Methode war immer die Verwendung eines Reverse-Proxys. Ich habe einen Weg gefunden, es ohne Reverse-Proxy zu tun. Und mein Hack ist vor ein paar Jahren kaputt gegangen.
Multisite ohne Reverse-Proxy zu betreiben, war schon immer ein Taschenspielertrick. Wenn Sie ein Profi sind, sollten Sie die SSL- und Let’s-Encrypt-Vorlagen entfernen und einen Reverse-Proxy verwenden, der SSL handhabt. Cdck verwendet haproxy. Ich habe traefik verwendet. Caddy ist ziemlich einfach zu verwalten. Ich habe die Verwendung eingestellt, weil, wenn jemand den CNAME für seine Website entfernt hat, alle Zertifikatserneuerungen fehlschlagen würden (das mag nicht mehr der Fall sein, es ist Jahre her).
Da ich nginx mit proxy_pass verwende, um den Datenverkehr an den Container weiterzuleiten, verwende ich korrekt die Reverse-Proxy-Methode für Multisite?
Ja. Das habe ich vergessen!
Lassen Sie es das HTTPS tun und entfernen Sie die SSL- und Let’s Encrypt-Vorlagen aus Ihrer YML-Datei.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.