L’ultimo aggiornamento ha richiesto la ricostruzione dell’app nel launcher, ma non è riuscito.
Sembra che non sia riuscito nel tentativo di migrare il database secondsite:
2025-08-21 06:44:42.493 UTC [867] discourse@discourse_nu ERROR: must be owner of extension vector
2025-08-21 06:44:42.493 UTC [867] discourse@discourse_nu STATEMENT: ALTER EXTENSION vector UPDATE TO ‘0.7.0’;
1 migrazione non è riuscita!
Impossibile eseguire la migrazione di secondsite
Dai un’occhiata alla discussione sullo stesso argomento Still an issue: ERROR: must be owner of extension vector - #2 by Falco
Ha risolto il problema.
Tuttavia, il problema con nginx e secondsites che ho segnalato più di un anno fa è ancora presente,
nei file di configurazione di nginx all’interno del container, controlla se l’URL non è per il primo sito e lo modifica in quello. Ho commentato di nuovo quel codice.
Ci sono stati grandi cambiamenti nel modo in cui viene gestita la configurazione di nginx.
Hai una configurazione multisito senza proxy inverso?
Beh, sono passati quasi 2 anni da quando ho guardato molto nginx, ma questo problema esisteva già quando sono passato a Discourse 2 anni fa, quindi non è nuovo.
Ecco un estratto dal file 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
}
Sembra che ogni volta che viene creato un nuovo container (ad esempio, durante un riavvio) riscriva il file
/etc/nginx/conf.d/outlets/server/20-https.conf, e queste righe causano un reindirizzamento al sistema discourse predefinito:
if ($https_host != huskerlist.tssi.com) {
rewrite (.$) https://huskerlist.tssi.com
}
C’è un modo per evitarlo? A cosa serve questo codice?
Esatto. Stai modificando quel file all’interno del container? La creazione di un nuovo container crea un nuovo container. Non sta riscrivendo quel file, ma tutti i file.
Puoi aggiungere elementi al tuo app.yml per modificare il file dopo che è stato riscritto.
Quali modifiche stai apportando a quel file? Perché?
Oh. Aspetta.
Non hai risposto a questa domanda, ma penso che la risposta sia sì.
Forza il sito poiché nella maggior parte dei casi non vorrai che il tuo sito sia disponibile tramite più di un nome host.
Quindi dovrai aggiungere del codice al tuo app.yml per annullare questo.
Tanto tempo fa, ho avuto una soluzione per questo in Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy
Quindi dovrai aggiungere un sed in un exec o forse usare alcune sezioni replace per rimuovere o modificare quella parte. Probabilmente dovrai ancora seguire le indicazioni di quell’argomento (che penso funzionino ancora) per ottenere più Ora puoi usare DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org per ottenere certificati per i nomi host aggiuntivi.
Suppongo che la soluzione più intelligente potrebbe essere quella di creare un modo per aggiungere gli alias degli altri nomi host in quel codice if ($http_host != in qualche modo. Al momento non ho siti configurati in quel modo, quindi non è probabile che voglia dedicare tempo a capirlo per divertimento.
Ma sì, il web ssl template ha questo:
if (\\$http_host != ${DISCOURSE_HOSTNAME}) {
rewrite (.*) https://${DISCOURSE_HOSTNAME}\\$1 permanent;
}
quindi potresti eliminarlo o trovare un modo per farlo controllare anche i tuoi altri nomi host.
Quindi, in sostanza, stai dicendo che il metodo ‘secondsite’ per ospitare due forum indipendenti su un server è rotto e non è nell’elenco delle cose da correggere.
quindi potresti eliminarlo o trovare un modo per farlo controllare anche per i tuoi altri nomi host.
Eliminarlo nel container è quello che ho fatto, ma ogni volta che un container si avvia o viene generata una nuova immagine del container, quel codice viene reinserito, quindi deve essere modificato nella sorgente da qualche parte in modo che quando costruisce un nuovo container, lo costruisca correttamente controllando più domini in app.yml. (Questo è probabilmente preferibile a eliminare semplicemente quelle 3 righe di codice.)
Se il codice che costruisce il template web ssl non verrà aggiornato per controllare app.yml per un secondsite (e un thirdsite e…) sembra che questo debba accadere in app.yml, il che lo rende una correzione personalizzata per me piuttosto che una correzione per tutti gli utenti che eseguono più forum su un singolo server utilizzando il metodo secondsite apparentemente rotto.
Al momento sono nel bel mezzo di un importante progetto di migrazione di sistema per un cliente, e questi siti sono più attivi durante la stagione calcistica, quindi ho bisogno di impostare il mio server di test per testare la scrittura delle correzioni di app.yml piuttosto che cercare di correggere il sistema live al volo.
Pensandoci brevemente, correggere il template ssl è alquanto impegnativo.
La logica attuale dice: se il sito non è A, rendilo A.
Introdurre un secondo sito complica le cose, perché se non è A e non è B, non è nemmeno chiaro che cambiarlo in A o B sia la cosa giusta da fare. (Potrebbe essere per questo che non è stato affrontato da Discourse.)
Forse eliminare quelle righe di codice è la cosa giusta da fare quando ci sono più siti, dopotutto, perché il server nginx esterno dovrebbe inviare solo pacchetti https che corrispondono ad A o B. Il passaggio forzato da HTTP a HTTPS dovrebbe già avvenire nel server nginx esterno.
Non è mai stato nell’elenco delle cose da supportare. La soluzione consigliata è sempre stata quella di utilizzare un reverse proxy. Ho escogitato un modo per farlo senza un reverse proxy. E il mio trucco si è rotto un paio di anni fa.
Fare il multisite senza un reverse proxy è sempre stato un trucco da salotto. Se sei un professionista, dovresti rimuovere i template ssl e let’s encrypt e utilizzare un reverse proxy che gestisca ssl. Cdck usa haproxy. Io ho usato traefik. Caddy è abbastanza facile da gestire. Ho smesso di usarlo perché se qualcuno rimuoveva il cname per il proprio sito, tutti i rinnovi dei certificati fallivano (potrebbe non essere più così, sono passati anni).
Dato che sto usando nginx con proxy_pass per passare il traffico al container, è corretto dire che sto usando il metodo del reverse proxy per il multisite?
Sì. Me ne ero dimenticato!
Fallo fare all’https e rimuovi i template ssl e let’s encrypt dal tuo file yml.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.