La dernière mise à niveau a nécessité la reconstruction de l’application dans le lanceur, mais cela a échoué.
Il semble que la migration de la base de données secondsite ait échoué :
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 migration a échoué !
Échec de la migration de secondsite
Consultez la discussion à ce sujet sur Still an issue: ERROR: must be owner of extension vector - #2 by Falco
Cela a résolu le problème.
Cependant, le problème avec nginx et secondsites que j’ai signalé il y a plus d’un an est toujours là,
dans les fichiers de configuration nginx dans le conteneur, il vérifie si l’URL n’est pas pour le premier site et la change pour celui-là. J’ai commenté ce code – encore une fois.
Il y a eu de grands changements dans la façon dont la configuration nginx est gérée.
Avez-vous une configuration multisite sans proxy inverse ?
Eh bien, cela fait près de 2 ans que je n’ai pas beaucoup regardé nginx, mais ce problème existait déjà lorsque je suis passé à Discourse il y a 2 ans, donc ce n’est pas nouveau.
Voici un extrait du fichier 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
}
Apparemment, chaque fois qu’il configurait un nouveau conteneur (par exemple, lors d’un redémarrage), il réécrivait le fichier /etc/nginx/conf.d/outlets/server/20-https.conf, et ces lignes redirigeaient vers le système Discourse par défaut :
if ($https_host != huskerlist.tssi.com) {
rewrite (.$) https://huskerlist.tssi.com
}
Y a-t-il un moyen d’éviter cela ? À quoi sert ce code ?
C’est exact. Modifiez-vous ce fichier à l’intérieur du conteneur ? La création d’un nouveau conteneur crée un nouveau conteneur. Il ne réécrit pas ce fichier, mais tous les fichiers.
Vous pouvez ajouter des éléments à votre app.yml pour modifier le fichier après sa réécriture.
Quelles modifications apportez-vous à ce fichier ? Pourquoi ?
Oh. Attendez.
Vous n’avez pas répondu à cette question, mais je pense que la réponse est oui.
Cela force le site car vous ne voulez presque jamais que votre site soit accessible par plus d’un nom d’hôte.
Vous devrez donc ajouter du code à votre app.yml pour annuler cela.
Il y a longtemps, j’avais une solution pour cela dans Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy
Vous devrez donc ajouter un sed dans un exec ou peut-être utiliser une ou plusieurs sections replace pour supprimer ou modifier cette partie. Vous devez probablement toujours suivre les instructions de ce sujet (qui, je pense, fonctionnent toujours) pour obtenir plusieurs Vous pouvez maintenant utiliser le DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org pour obtenir des certificats pour les noms d’hôtes supplémentaires.
Je suppose que la solution la plus astucieuse serait de trouver un moyen d’ajouter les autres alias d’hôtes dans ce code if ($http_host != d’une manière ou d’une autre. Je n’ai pas de sites configurés de cette façon pour le moment, donc il est peu probable que je veuille passer du temps à le découvrir pour le plaisir.
Mais oui, le web ssl template a ceci :
if (\\$http_host != ${DISCOURSE_HOSTNAME}) {
rewrite (.*) https://${DISCOURSE_HOSTNAME}\\$1 permanent;
}
vous pourriez donc soit le supprimer, soit trouver un moyen de faire en sorte qu’il vérifie également vos autres noms d’hôtes.
Donc, en gros, ce que vous dites, c’est que la méthode « secondsite » pour héberger deux forums indépendants sur un serveur est cassée et ne figure pas sur la liste des choses à corriger.
vous pourriez donc soit le supprimer, soit trouver un moyen de faire en sorte qu’il vérifie également vos autres noms d’hôte.
Le supprimer dans le conteneur est ce que j’ai fait, mais à chaque fois qu’un conteneur démarre ou qu’une nouvelle image de conteneur est générée, ce code est remis en place. Il doit donc être modifié à la source quelque part afin que, lorsqu’il crée un nouveau conteneur, il le crée correctement en vérifiant plusieurs domaines dans app.yml. (C’est probablement préférable à la simple suppression de ces 3 lignes de code.)
Si le code qui génère le modèle SSL Web ne sera pas mis à jour pour vérifier app.yml pour un secondsite (et un thirdsite et…), il semble que cela doive se faire dans app.yml, ce qui en fait une correction personnalisée pour moi plutôt qu’une correction pour tous les utilisateurs exécutant plusieurs forums sur un seul serveur en utilisant la méthode secondsite apparemment cassée.
Pour le moment, je suis au milieu d’un projet majeur de migration de système pour un client, et ces sites sont les plus actifs pendant la saison de football de toute façon, donc j’ai besoin de configurer mon serveur de test pour tester l’écriture de corrections app.yml plutôt que d’essayer de corriger le système en direct à la volée.
En y réfléchissant brièvement, la correction du modèle ssl est quelque peu difficile.
La logique actuelle dit : Si le site n’est pas A, faites-en A.
L’introduction d’un second site complique les choses, car s’il n’est ni A ni B, il n’est pas non plus clair que le changer en A ou en B soit la bonne chose à faire. (C’est peut-être pourquoi cela n’a pas été abordé par Discourse.)
Peut-être que supprimer ces lignes de code est la bonne chose à faire lorsqu’il y a plusieurs sites, car le serveur nginx externe ne devrait envoyer que des paquets https qui correspondent à A ou B. La redirection de HTTP vers HTTPS devrait déjà se produire dans le serveur nginx externe.
Cela n’a jamais été sur la liste des choses à supporter. Il était toujours recommandé d’utiliser un proxy inverse. J’ai trouvé un moyen de le faire sans proxy inverse. Et mon piratage a cassé il y a quelques années.
Faire du multisite sans proxy inverse a toujours été un tour de passe-passe. Si vous êtes un pro, vous devriez supprimer les modèles ssl et let’s encrypt et utiliser un proxy inverse qui gère le ssl. Cdck utilise haproxy. J’ai utilisé traefik. Caddy est assez facile à gérer. J’ai arrêté de l’utiliser car si quelqu’un supprimait le cname de son site, tous les renouvellements de certificats échoueraient (cela peut ne plus être le cas, cela fait des années).
Puisque j’utilise nginx avec proxy_pass pour transmettre le trafic au conteneur, est-ce que je fais correctement en supposant que j’utilise la méthode de proxy inverse pour le multisite ?
Oui. J’avais oublié celui-là !
Faites-le pour le https et supprimez les modèles ssl et let’s encrypt de votre fichier yml.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.