La última actualización requirió reconstruir la aplicación en el lanzador, pero falló.
Parece que falló al intentar migrar la base de datos de 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’;
¡Fallaron 1 migraciones!
No se pudo migrar secondsite
Consulte la discusión sobre lo mismo en Still an issue: ERROR: must be owner of extension vector - #2 by Falco
Eso lo solucionó.
Sin embargo, el problema con nginx y secondsites que reporté hace más de un año todavía está ahí,
en los archivos de configuración de nginx dentro del contenedor, verifica si la URL no es para el primer sitio y la cambia a ese. Comenté ese código, de nuevo.
Ha habido grandes cambios en la forma en que se maneja la configuración de nginx.
¿Tienes una configuración multisitio sin proxy inverso?
Bueno, han pasado casi 2 años desde que miré mucho nginx, pero este problema existía cuando me cambié a Discourse hace 2 años, así que no es nuevo.
Aquí hay un extracto del archivo 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
}
Al parecer, cada vez que se configura un nuevo contenedor (como durante un reinicio), se reescribe el archivo /etc/nginx/conf.d/outlets/server/20-https.conf, y estas líneas provocan una redirección al sistema de discurso predeterminado:
if ($https_host != huskerlist.tssi.com) {
rewrite (.$) https://huskerlist.tssi.com
}
¿Hay alguna forma de evitar esto? ¿Qué propósito tiene este código?
Correcto. ¿Estás editando ese archivo dentro del contenedor? Construir un nuevo contenedor crea un nuevo contenedor. No está reescribiendo ese archivo, sino todos los archivos.
Puedes añadir cosas a tu app.yml para cambiar el archivo después de que se reescriba.
¿Qué cambios estás haciendo en ese archivo? ¿Por qué?
Oh. Espera.
No respondiste a esta pregunta, pero creo que la respuesta es sí.
Obliga al sitio, ya que la mayoría de las veces no querrás que tu sitio sea accesible por más de un nombre de host.
Así que necesitarás añadir algo de código a tu app.yml para deshacer eso.
Hace mucho tiempo, tenía una solución para esto en Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy
Así que necesitarás añadir un sed en un exec o quizás usar alguna sección replace para eliminar o modificar esa parte. Probablemente todavía necesites seguir las cosas de ese tema (que creo que todavía funcionan) para obtener múltiples Ahora puedes usar DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org para obtener certificados para los nombres de host adicionales.
Supongo que la solución más ingeniosa sería idear cómo añadir los otros alias de nombres de host a ese código if ($http_host !=. No tengo ningún sitio configurado de esa manera en este momento, así que no es probable que quiera pasar tiempo resolviéndolo por diversión.
Pero sí, la web ssl template tiene esto:
if (\\$http_host != ${DISCOURSE_HOSTNAME}) {
rewrite (.*) https://${DISCOURSE_HOSTNAME}\\$1 permanent;
}
así que podrías eliminarlo o encontrar una manera de que también compruebe tus otros nombres de host.
Entonces, esencialmente lo que estás diciendo es que el método ‘secondsite’ para alojar dos foros independientes en un servidor está roto y no está en la lista de cosas por arreglar.
así que podrías eliminarlo o encontrar una manera de hacer que también verifique tus otros nombres de host.
Eliminarlo en el contenedor es lo que he estado haciendo, pero cada vez que se inicia un contenedor o se genera una nueva imagen de contenedor, ese código vuelve a aparecer, por lo que debe cambiarse en el código fuente en algún lugar para que, cuando cree un nuevo contenedor, lo cree correctamente verificando múltiples dominios en app.yml. (Eso es probablemente preferible a simplemente eliminar esas 3 líneas de código).
Si el código que crea la plantilla SSL web no se va a actualizar para verificar app.yml para un segundo sitio (y un tercer sitio y…) suena a que esto necesita suceder en app.yml, lo que lo convierte en una solución personalizada para mí en lugar de una solución para todos los usuarios que ejecutan múltiples foros en un solo servidor utilizando el método aparentemente roto ‘secondsite’.
Ahora mismo estoy en medio de un importante proyecto de migración de sistemas para un cliente, y estos sitios están más activos durante la temporada de fútbol de todos modos, así que necesito configurar mi entorno de prueba para probar la escritura de correcciones en app.yml en lugar de intentar arreglar el sistema en vivo sobre la marcha.
Pensándolo brevemente, arreglar la plantilla ssl es algo desafiante.
La lógica actual dice: Si el sitio no es A, hazlo A.
Introducir un segundo sitio complica las cosas, porque si no es A y tampoco es B, tampoco está claro que cambiarlo a A o B sea lo correcto. (Puede que por eso Discourse no lo haya abordado).
Quizás eliminar esas líneas de código sea lo correcto cuando hay varios sitios, porque el servidor nginx externo solo debería estar enviando paquetes https que coincidan con A o B. Forzar HTTP a HTTPS ya debería estar ocurriendo en el servidor nginx externo.
Nunca estuvo en la lista de cosas que soportar. La forma recomendada siempre fue usar un proxy inverso. Ideé una forma de hacerlo sin un proxy inverso. Y mi truco se rompió hace un par de años.
Hacer multisitio sin un proxy inverso siempre fue un truco de salón. Si eres un profesional, deberías eliminar las plantillas ssl y lets encrypt y usar un proxy inverso que maneje ssl. Cdck usa haproxy. Yo he estado usando traefik. Caddy es bastante fácil de manejar. Dejé de usarlo porque si alguien eliminaba el cname de su sitio, todas las renovaciones de certificados fallarían (eso puede que ya no sea el caso, han pasado años).
Dado que estoy usando nginx con proxy_pass para pasar tráfico al contenedor, ¿es correcto que significa que estoy usando el método de proxy inverso para multisitio?
Sí. ¡Me olvidé de ese!
Haz que haga https y elimina las plantillas ssl y let’s encrypt de tu archivo yml.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.