Anteriormente, estávamos executando uma configuração multissite do Discourse com cerca de 22 fóruns diferentes. Recentemente, decidimos remover a configuração multissite e manter apenas o site padrão:
Site padrão agora:forum.mamapedia.com Domínio multissite antigo removido:forum.employ.com (e outros 21)
O Problema:
Mesmo após desabilitar a configuração multissite, os domínios multissite antigos ainda podem servir o fórum padrão (forum.mamapedia.com). Por exemplo:
Visitar forum.mamapedia.com funciona como esperado
Mas visitar forum.employ.com ainda carrega o fórum Mamapedia
Esperávamos que domínios antigos como forum.employ.com fizessem uma das seguintes coisas:
Exibir um erro (já que não estão mais configurados)
Redirecionar corretamente ou estar completamente inativos
Notas de Configuração:
Estamos usando certificados SSL do Cloudflare com a opção de proxy habilitada (o tráfego não vai diretamente para o nosso servidor).
Podemos remover os registros A para os domínios antigos, mas realmente queremos identificar e corrigir a causa raiz em vez de depender de uma solução alternativa baseada em DNS.
Passos Realizados Até Agora:
Removidas as configurações multissite de discourse.conf e do banco de dados
Reiniciado o Discourse e verificado as configurações de app.yml
Limpo o cache e testado em modo anônimo
Comportamento Esperado:
forum.mamapedia.com deve continuar funcionando
forum.employ.com e outros domínios antigos não devem servir o fórum Mamapedia
Perguntas:
Como podemos remover adequadamente os domínios antigos para que eles não sirvam o fórum padrão?
Precisamos ajustar as configurações do Nginx/Traefik, as configurações do Cloudflare, ou há alguma configuração específica do Discourse que perdemos?
Você precisa mudar para uma instalação padrão. O que você fez para torná-la multilocate é para permitir que o servidor sirva vários domínios.
Se você criar um novo servidor e restaurar o backup, não poderá quebrar nada, pois apenas voltará ao antigo.
A única ressalva é que você precisa apontar o DNS para o novo servidor enquanto o reconstrói, para que ele possa obter um certificado. E deixe o DNS do Cloudflare como apenas DNS.
A razão pela qual isso está acontecendo é simples. Multisite selecionará um fórum com base no nome do host. Uma instalação que não seja multisite aceitará feliz qualquer nome de host que você apontar para ela. Então, enquanto você tiver todos os nomes de host antigos direcionados para essa instalação, ela servirá o restante do site em todos esses nomes de host.
[citação=“Abdelrahman MoHamed, post:1, tópico:351365, nome de usuário:Abdelrahman_MoHamed”]
Podemos remover os registros A para os domínios antigos, mas realmente queremos identificar e corrigir a causa raiz ao invés de depender de uma solução alternativa baseada em DNS.
[/citação]
Ter os registros antigos apontando para o seu site, é a causa raiz.
Limpar sua configuração antiga não é uma solução alternativa, é a solução.
Nossa. Não me lembro da última vez que discuti um fato com você. Como regra, quando vejo seu avatar em um tópico em que comentei, sei que vou aprender algo!
Isso é verdade. Eles afirmam, no entanto, que mudaram para uma instalação padrão. Eu não acredito neles.
Há vários anos (mas acho que desde que o let’s encrypt está disponível), em uma instalação padrão, se você acessá-la por qualquer outro nome de host, ela fará um redirecionamento (você pode verificar facilmente usando o número IP e acabei de fazer outro configurando forum.bigmouth.bass em /etc/hosts para uma instalação padrão e ela redirecionou como esperado. Se você acessá-la via https, o que a maioria dos navegadores faz por padrão agora, você receberá um erro de certificado.
Se tudo o que era necessário para acessar seu site por algum outro nome de host era DNS, então qualquer um poderia sequestrar seu site criando um registro DNS apontando para o seu site.
Acho que esta é a mágica:
Minha suposição é que o app.yml ainda tem algo como isto:
Bem, até hoje eu não sabia que deveria atualizar meus fatos com mais frequência! Esse código está lá desde 2014, então acho que estava vivendo bem no passado.
Você está completamente certo, ele irá redirecionar.
Verificamos o app.yml, e não há configurações de redirecionamento personalizadas ou sobrescritas. No entanto, nossa instância ainda não está redirecionando nomes de host desconhecidos para o domínio principal.
Configuração do Nginx: Existe uma maneira de verificar se a lógica de redirecionamento do templates/web.ssl.template.yml está realmente sendo aplicada? Devemos verificar manualmente a configuração gerada do Nginx dentro do container?
Depuração do Discourse: Existem logs ou comandos que podemos executar dentro do container para confirmar se o Discourse está lidando com nomes de host corretamente?
Outras Causas Potenciais: Se o app.yml estiver limpo, o que mais poderia impedir o comportamento de redirecionamento esperado? O Cloudflare ou outra configuração pode estar interferindo?
Agradeceria qualquer orientação para investigar mais a fundo!
Todos os domínios antigos estão com a nuvem laranja ativada? Desativar a nuvem laranja resolve o problema? Se sim, então, como eu esperava o tempo todo, Richard está certo e você precisa organizar sua configuração.
Mas se o uso do Cloudflare permite que um agente mal-intencionado (você, neste caso) sirva o site de outra pessoa em seu domínio, isso parece ser um problema.
Já removemos domínios antigos, mas sim, eles estavam com o botão laranja ativado. O problema agora é que se alguém obtiver nosso IP de servidor e um registro lá com a opção de proxy ativada, ele servirá nosso site com o domínio deles.
Você deve executar discourse-setup para garantir que você realmente tenha uma instalação padrão. Se você colar seu app.yml antigo, pode haver algo nele que não pertence. Ainda não estou totalmente convencido de que você tenha uma configuração padrão.
Ainda não estou convencido de que seja o caso, mas se for, não há nada que você possa fazer a respeito.
Gostaria muito de agradecer a vocês @pfaffman@RGJ, agora está limpo e quase bom
O problema que estamos enfrentando agora é que todas as imagens de marca desapareceram e o mesmo para as imagens de alguns usuários.
Os dados de marca estão ok, posso baixá-los do servidor antigo, mas e quanto às imagens dos usuários e a todas as imagens do site que também estão faltando
\n\n(https://forum.mamapedia.com/user_avatar/forum.mamapedia.com/jakeatgetit/24/5872_2.png)\n\n\nE @pfaffman este era, de facto, o site principal na configuração multisite. \n\nCC: @Abdelrahman_MoHamed
Hmm. Bem, se fosse o site principal, eu esperaria que esse caminho fosse https://forum.mamapedia.com/user_avatar/forum.mamapedia.com/jakeatgetit/24/5872_2.png, mas isso também não funciona.
Se você ainda tiver o site antigo, eu faria um backup deste e o restauraria no novo site.
Obrigado @pfaffman, o que fiz até agora parece estar funcionando.
Entrei no servidor antigo e movi os dados de /var/discourse/shared/standalone/uploads/default para o mesmo caminho no novo servidor e todos os avatares e posts dos usuários voltaram.
O novo problema é que a marca do site não está funcionando, mesmo que eu tente atualizá-la.
Voltando aqui para ver se alguém tem alguma ideia. Estamos muito perto de finalizar isso por aqui, só precisamos de alguma ajuda para solucionar o problema de salvamento ‘sem logo’. Agradeço antecipadamente por qualquer ideia para resolvê-lo!
