De nieuwste upgrade vereiste het opnieuw opbouwen van de app in de launcher, maar dit mislukte.
Het lijkt erop dat het mislukte bij het proberen te migreren van de second-site database:
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 migratie is mislukt!
Mislukt om second-site te migreren
Checkout the discussion on the same Still an issue: ERROR: must be owner of extension vector - #2 by Falco
Dat heeft het opgelost.
Het probleem met nginx en secondsites dat ik meer dan een jaar geleden meldde, is echter nog steeds aanwezig,
in de nginx-configuratiebestanden binnen de container wordt gecontroleerd of de URL niet voor de eerste site is en wordt deze daarin gewijzigd. Ik heb die code opnieuw uitgecommentarieerd.
There have been big changes in how the nginx config is handled.
Do you have a multisite setup with no reverse proxy?
Well, it’s been nearly 2 years since I’ve looked at nginx much, but this problem existed when I first moved over to Discourse 2 years ago, so it is not new.
Here’s an excerpt from the nginx.conf file:
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
}
Apparently every time it set up a new container (such as during a reboot) it rewrites the
/etc/nginx/conf.d/outlets/server/20-https.conf file, and these lines cause a redirect to the default discourse system:
if ($https_host != huskerlist.tssi.com) {
rewrite (.$) https://huskerlist.tssi.com
}
Is there a way to avoid this? What purpose does this code serve?
That’s right. Are you editing that file inside of the container? Building a new container builds a new container. It’s not rewriting that file, but all files.
You can add stuff to your app.yml to change the file after it’s rewritten.
What changes are you making to that file? Why?
Oh. Wait.
You didn’t answer this question, but I think the answer is yes.
It forces the site since you mostly never want your site to be available by more than one hostname.
So you’ll need to add some code to your app.yml to un-do that.
A long time ago, I had a solution for this in Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy
So you’ll need to add a sed in an exec or maybe use some replace stanza(s) to remove or modify that bit. You probably still need to follow the stuff in that topic (that I think may still work) to get multiple You can now use the DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org to get certs for the additional hostnames.
I suppose the most clever solution might be to contrive to add the other hostname aliases into that if ($http_host != code somehow. I don’t have any sites set up that way right now, so I’m not likely to want to spend time figuring it out for fun.
But yeah, the web ssl template has this:
if (\$http_host != ${DISCOURSE_HOSTNAME}) {
rewrite (.*) https://${DISCOURSE_HOSTNAME}\$1 permanent;
}
so you could either delete it or find a way to make it also check for your other hostnames.
Dus, in wezen zeg je dat de ‘secondsite’-methode om twee onafhankelijke forums op één server te hosten kapot is en niet op de lijst staat om op te lossen.
dus je zou het kunnen verwijderen of een manier vinden om ook je andere hostnamen te controleren.
Het verwijderen ervan in de container is wat ik heb gedaan, maar elke keer dat een container opstart of een nieuwe container-image wordt gegenereerd, wordt die code teruggeplaatst, dus het moet ergens in de bron worden gewijzigd, zodat wanneer het een nieuwe container bouwt, het correct bouwt en meerdere domeinen controleert in app.yml. (Dat is waarschijnlijk beter dan alleen die 3 regels code te verwijderen.)
Als de code die de web ssl-sjabloon bouwt niet wordt bijgewerkt om app.yml te controleren op een tweede site (en derde site en…), klinkt het alsof dit in app.yml moet gebeuren, wat het een aangepaste oplossing voor mij maakt in plaats van een oplossing voor alle gebruikers die meerdere forums op een enkele server draaien met behulp van de blijkbaar kapotte secondsite-methode.
Op dit moment ben ik midden in een grootschalig systeem migratieproject voor een klant, en deze sites zijn sowieso het meest actief tijdens het voetbalseizoen, dus ik moet mijn testomgeving opzetten om het schrijven van app.yml-correcties te testen in plaats van het live systeem on-the-fly te proberen te repareren.
Kort overwogen is het aanpassen van de ssl-template enigszins uitdagend.
De huidige logica zegt: Als de site geen A is, maak het A.
Het introduceren van een tweede site compliceert de zaken, want als het geen A is en het is ook geen B, dan is het ook niet duidelijk dat het veranderen naar A of B het juiste is om te doen. (Dat is misschien waarom dit niet is aangepakt door Discourse.)
Misschien is het verwijderen van die regels code toch het juiste om te doen als er meerdere sites zijn, omdat de externe ngingx-server alleen https-pakketten mag doorsturen die overeenkomen met A of B. Forceren van HTTP naar HTTPS zou al moeten gebeuren in de externe nginx-server.
It was never on the list of things to support. The recommended was was always to use a reverse proxy. I contrived a way to do it without a reverse proxy. And my hack broke a couple years ago.
Doing multisite without a reverse proxy was always a parlor trick. If you’re a pro, you should remove the ssl and let’s encrypt templates and use a reverse proxy that handles ssl. Cdck uses haproxy. I’ve been using traefik. Caddy is pretty easy to manage. I quit using it because if someone removed the cname for their site it would cause all cert renewals to fail (that may no longer be the case, it’s been years).
Aangezien ik nginx met proxy_pass gebruik om verkeer door te geven aan de container, heb ik het dan correct dat ik de reverse proxy-methode voor multisite gebruik?
Ja. Dat was ik vergeten!
Laat het de https doen en verwijder de ssl- en let’s encrypt-sjablonen uit uw yml-bestand.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.