A atualização mais recente exigiu a reconstrução do aplicativo no launcher, mas falhou.
Parece que falhou ao tentar migrar o banco de dados 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 migração falhou!
Falha ao migrar secondsite
Confira a discussão sobre o mesmo em Still an issue: ERROR: must be owner of extension vector - #2 by Falco
Isso resolveu.
No entanto, o problema com nginx e secondsites que relatei há mais de um ano ainda persiste,
nos arquivos de configuração do nginx dentro do contêiner, ele verifica se a URL não é para o primeiro site e a altera para este. Comentei esse código novamente.
Houve grandes mudanças na forma como a configuração do nginx é tratada.
Você tem uma configuração multissite sem proxy reverso?
Bem, já se passaram quase 2 anos desde que mexi muito com o nginx, mas esse problema existia quando me mudei para o Discourse há 2 anos, então não é novo.
Aqui está um trecho do arquivo 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
}
Aparentemente, toda vez que ele configura um novo contêiner (como durante uma reinicialização), ele reescreve o arquivo /etc/nginx/conf.d/outlets/server/20-https.conf, e essas linhas causam um redirecionamento para o sistema padrão do Discourse:
if ($https_host != huskerlist.tssi.com) {
rewrite (.$) https://huskerlist.tssi.com
}
Existe uma maneira de evitar isso? Qual o propósito desse código?
Correto. Você está editando esse arquivo dentro do contêiner? Construir um novo contêiner constrói um novo contêiner. Ele não está reescrevendo esse arquivo, mas todos os arquivos.
Você pode adicionar coisas ao seu app.yml para alterar o arquivo depois que ele for reescrito.
Que alterações você está fazendo nesse arquivo? Por quê?
Oh. Espere.
Você não respondeu a essa pergunta, mas acho que a resposta é sim.
Ele força o site, pois você quase nunca quer que seu site seja acessível por mais de um nome de host.
Portanto, você precisará adicionar algum código ao seu app.yml para desfazer isso.
Há muito tempo, eu tinha uma solução para isso em Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy
Portanto, você precisará adicionar um sed em um exec ou talvez usar alguma(s) seção(ões) replace para remover ou modificar essa parte. Você provavelmente ainda precisa seguir as instruções desse tópico (que acho que ainda funcionam) para obter vários Agora você pode usar o DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org para obter certificados para os nomes de host adicionais.
Suponho que a solução mais inteligente seria criar uma forma de adicionar os outros aliases de nome de host a esse código if ($http_host != de alguma forma. Não tenho nenhum site configurado dessa forma no momento, então não é provável que eu queira gastar tempo descobrindo isso por diversão.
Mas sim, o web ssl template tem isso:
if (\\$http_host != ${DISCOURSE_HOSTNAME}) {
rewrite (.*) https://${DISCOURSE_HOSTNAME}\\$1 permanent;
}
então você poderia excluí-lo ou encontrar uma maneira de fazer com que ele também verifique seus outros nomes de host.
Então, essencialmente o que você está dizendo é que o método ‘secondsite’ para hospedar dois fóruns independentes em um servidor está quebrado e não está na lista de coisas para consertar.
então você poderia excluí-lo ou encontrar uma maneira de fazer com que ele também verifique seus outros nomes de host.
Excluí-lo no contêiner é o que tenho feito, mas toda vez que um contêiner inicia ou uma nova imagem de contêiner é gerada, ele recoloca esse código, então ele precisa ser alterado na origem em algum lugar para que, quando ele crie um novo contêiner, ele o crie corretamente verificando vários domínios em app.yml. (Isso provavelmente é preferível a apenas excluir essas 3 linhas de código.)
Se o código que cria o template web ssl não for atualizado para verificar app.yml para um secondsite (e thirdsite e…) parece que isso precisa acontecer em app.yml, o que o torna uma correção personalizada para mim em vez de uma correção para todos os usuários que executam vários fóruns em um único servidor usando o método aparentemente quebrado secondsite.
No momento, estou no meio de um grande projeto de migração de sistema para um cliente, e esses sites são mais ativos durante a temporada de futebol de qualquer maneira, então preciso configurar meu servidor de teste para testar a escrita de correções em app.yml em vez de tentar corrigir o sistema ao vivo na hora.
Pensando um pouco sobre isso, corrigir o template ssl é um tanto desafiador.
A lógica atual diz: Se o site não é A, torne-o A.
Introduzir um segundo site complica as coisas, porque se ele não é A e não é B, também não fica claro que mudá-lo para A ou B é a coisa certa a fazer. (Talvez seja por isso que isso não foi abordado pelo Discourse.)
Talvez excluir essas linhas de código seja a coisa certa a fazer quando existem vários sites, afinal, o servidor nginx externo deve estar enviando apenas pacotes https que correspondam a A ou B. Forçar HTTP para HTTPS já deve estar acontecendo no servidor nginx externo.
Nunca esteve na lista de coisas para dar suporte. A forma recomendada sempre foi usar um proxy reverso. Eu criei uma maneira de fazer isso sem um proxy reverso. E meu hack quebrou há alguns anos.
Fazer multisite sem um proxy reverso sempre foi um truque de salão. Se você é um profissional, deve remover os modelos ssl e let’s encrypt e usar um proxy reverso que lida com ssl. Cdck usa haproxy. Eu tenho usado traefik. Caddy é bem fácil de gerenciar. Parei de usá-lo porque se alguém removesse o cname para o site, isso faria com que todas as renovações de certificado falhassem (isso pode não ser mais o caso, já se passaram anos).
Como estou usando o nginx com proxy_pass para passar tráfego para o container, estou correto em dizer que estou usando o método de proxy reverso para multisite?
Sim. Eu me esqueci desse!
Faça o https e remova os modelos ssl e let’s encrypt do seu arquivo yml.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.