Ancuni domini multisito ancora servono il forum predefinito dopo aver disabilitato Multisite

[Abdelrahman_MoHamed]

In precedenza gestivamo una configurazione multisito di Discourse con circa 22 forum diversi. Recentemente, abbiamo deciso di rimuovere la configurazione multisito mantenendo solo il sito predefinito:

Sito predefinito ora: forum.mamapedia.com
Dominio multisito precedente rimosso: forum.employ.com (e altri 21)

Il Problema:

Anche dopo aver disabilitato la configurazione multisito, i vecchi domini multisito possono ancora servire il forum predefinito (forum.mamapedia.com). Ad esempio:

• Visitare forum.mamapedia.com funziona come previsto
• Ma visitare forum.employ.com carica ancora il forum di Mamapedia

Ci aspettavamo che vecchi domini come forum.employ.com facessero una delle seguenti cose:

1. Mostrassero un errore (poiché non sono più configurati)
2. Reindirizzassero correttamente o fossero completamente inattivi

Note sulla Configurazione:

• Utilizziamo certificati SSL di Cloudflare con l’opzione proxy abilitata (il traffico non va direttamente al nostro server).
• Possiamo rimuovere i record A per i vecchi domini, ma vogliamo davvero identificare e correggere la causa principale invece di fare affidamento su una soluzione alternativa basata sul DNS.

Passaggi Eseguiti Finora:

1. Rimossi i settaggi multisito da discourse.conf e dal database
2. Riavviato Discourse e verificato le impostazioni di app.yml
3. Cancellata la cache e testato in modalità incognito

Comportamento Atteso:

• forum.mamapedia.com dovrebbe continuare a funzionare
• forum.employ.com e gli altri vecchi domini non dovrebbero servire il forum di Mamapedia

Domande:

1. Come possiamo rimuovere correttamente i vecchi domini in modo che non servano il forum predefinito?
2. Dobbiamo modificare le impostazioni di Nginx/Traefik, le impostazioni di Cloudflare, o c’è una configurazione specifica di Discourse che ci è sfuggita?

Configurazione Nginx

[pfaffman (Jay Pfaffman)]

È necessario passare a un’installazione standard. Le cose che hai fatto per renderlo multisite servono a far sì che il server possa gestire diversi domini.

Se crei un nuovo server e ripristini il backup, non puoi far deteriorare nulla, perché puoi semplicemente tornare al vecchio.

L’unica zoppia è che devi puntare il DNS al nuovo server mentre ricostruisci, così può ottenere un certificato. E rendi i DNS di Cloudflare solo DNS.

[Abdelrahman_MoHamed]

Grazie @pfaffman, abbiamo tentato di passare da una configurazione multisito a un’installazione standard, ma il problema persiste.

Cosa abbiamo fatto:

1. Rimozione dell’installazione di Discourse:
   • Eliminata l’intera directory /var/discourse.
2. Reinstallazione di Discourse:
   • Clonato nuovamente il repository di Discourse.
   • Ricreato app.yml con le configurazioni necessarie.
3. Ricostruzione dell’app:
   • Eseguito ./launcher rebuild app.
4. Aggiornamento DNS:
   • Puntato il dominio al nuovo server.
   • Impostata la modalità Solo DNS di Cloudflare per consentire l’emissione del certificato SSL.

Problema aggiuntivo con SSL:

• Quando abbiamo abilitato SSL in app.yml e disabilitato il proxy di Cloudflare, abbiamo riscontrato il seguente problema anche dopo aver abilitato SSL:

  

Domande:

1. Potrebbe il problema essere correlato alla mancata ripristino di un backup del database?
2. Sono necessari passaggi aggiuntivi per ripulire le vecchie configurazioni multisito?
3. Qual è il modo corretto per abilitare SSL in questa configurazione senza riscontrare problemi?

Apprezzerei qualsiasi guida da parte di chi l’ha già fatto!

[pfaffman (Jay Pfaffman)]

@Abdelrahman_MoHamed

Ricreato app.yml con le configurazioni necessarie.

Hai eseguito discourse setup o l’hai fatto manualmente?

Hai i template ssl e let’s encrypt?

Se hai eseguito ricostruzioni un bel po’ di volte con la nuvola arancione potresti essere limitato in frequenza.

[RGJ (Richard - Communiteq)]

Il motivo per cui ciò accade è semplice. Multisite selezionerà un forum in base al nome host. Un’installazione non multisite accetterà felicemente qualsiasi nome host a cui la punti. Quindi, finché avrai tutti i vecchi nomi host indirizzati a quell’installazione, servirà il sito rimanente su tutti quei nomi host.

@Abdelrahman_MoHamed

Possiamo rimuovere i record A per i vecchi domini, ma vogliamo davvero identificare e correggere la causa principale invece di fare affidamento su una soluzione alternativa basata sul DNS.

Avere i vecchi record puntati al tuo sito è la causa principale.
Pulire la tua vecchia configurazione non è una soluzione alternativa, è la soluzione.

[pfaffman (Jay Pfaffman)]

OMG. Non ricordo l’ultima volta che ho avuto un disaccordo con te su un fatto. Di regola, quando vedo il tuo avatar in un argomento su cui ho commentato, so che imparerò qualcosa!

@RGJ

Il motivo per cui ciò accade è semplice. Multisite selezionerà un forum in base al nome host

È vero. Affermano, però, di essere passati a un’installazione standard. Non gli credo.

@RGJ

Un’installazione non multisite accetterà felicemente qualsiasi nome host a cui la si punti.

Da diversi anni ormai (ma penso da quando Let’s Encrypt è disponibile), su un’installazione standard, se vi si accede tramite qualsiasi altro nome host, verrà eseguito un reindirizzamento (puoi verificarlo facilmente usando il numero IP e ho appena fatto un altro test impostando forum.bigmouth.bass in /etc/hosts su un’installazione standard e ha reindirizzato come previsto. Se vi si accede tramite https, cosa che la maggior parte dei browser fa per impostazione predefinita ora, si otterrà un errore di certificato.

Se tutto ciò che era necessario per accedere al tuo sito tramite un altro nome host era il DNS, allora chiunque potrebbe dirottare il tuo sito creando un record DNS che punta al tuo sito.

Penso che questa sia la magia:

templates/web.ssl.template.yml

La mia ipotesi è che app.yml abbia ancora qualcosa di simile:

@pfaffman

   # non reindirizzare tutti gli host al nome di dominio principale
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /if \\(\\$http_host[^\\}]*\\}/m
        to: ""
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /return 301.*$/
        to: "return 301 https://$host$request_uri;"

[RGJ (Richard - Communiteq)]

@pfaffman

So che imparerò qualcosa!

Beh, TIL che dovrei aggiornare più spesso i miei fatti! Quel codice è lì dal 2014, quindi immagino che vivessi nel passato.

Hai perfettamente ragione, reindirizzerà.

[Abdelrahman_MoHamed]

Grazie @RGJ, @pfaffman,

Abbiamo controllato app.yml e non ci sono configurazioni personalizzate di reindirizzamento o override. Tuttavia, la nostra istanza ancora non reindirizza gli host sconosciuti al dominio principale.

1. Configurazione Nginx: C’è un modo per verificare se la logica di reindirizzamento dai template/web.ssl.template.yml viene effettivamente applicata? Dovremmo controllare manualmente la configurazione generata di Nginx all’interno del container?

2. Debugging di Discourse: Ci sono log o comandi che possiamo eseguire all’interno del container per confermare che Discourse gestisce correttamente gli hostname?

3. Altri possibili motivi: Se app.yml è pulito, cos’altro potrebbe impedire il comportamento di reindirizzamento atteso? Cloudflare o altre impostazioni potrebbero interferire?

Apprezzerei qualsiasi suggerimento per approfondire questa situazione!

[RGJ (Richard - Communiteq)]

@RGJ

Pulire la vecchia configurazione non è una soluzione temporanea, è la soluzione.

Ecco un suggerimento.

[pfaffman (Jay Pfaffman)]

Tutti i vecchi domini hanno la nuvola arancione attivata? Risolvere il problema disattivando la nuvola arancione? Se sì, allora, come ho sempre previsto, Richard ha ragione e devi sistemare la tua configurazione.

Ma se l’uso di Cloudflare permette a un malintenzionato (tu in questo caso) di servire il sito di qualcun altro sul suo dominio, questo sembra un problema.

[Abdelrahman_MoHamed]

OK, devo eseguire

./discourse-setup

dopo aver scaricato discourse o devo incollare il mio vecchio app.yml dopo aver scaricato e poi eseguire

./launcher rebuild app

Quale percorso devo seguire?

[Abdelrahman_MoHamed]

Abbiamo già rimosso i vecchi domini ma sì, avevano il pulsante arancione abilitato, il problema ora è se qualcuno ottiene il nostro IP del server e un record lì con l’opzione proxy abilitata, servirà il nostro sito con il loro dominio.

[pfaffman (Jay Pfaffman)]

Dovresti eseguire discourse-setup per assicurarti di avere davvero un’installazione standard. Se incolli il tuo vecchio app.yml potresti avere qualcosa al suo interno che non dovrebbe esserci. Non sono ancora del tutto convinto che tu abbia una configurazione standard.

@Abdelrahman_MoHamed

il problema ora è che se qualcuno ottiene l’IP del nostro server e un record lì con l’opzione proxy abilitata, servirà il nostro sito con il loro dominio

Non sono ancora convinto che sia così, ma se lo fosse, non c’è niente che tu possa fare al riguardo.

[Jagster (Jakke Lehtonen)]

@Abdelrahman_MoHamed

se qualcuno ha ottenuto l’IP del nostro server

La maggior parte degli indirizzi IP dei server mondiali sono pubblici. Questo è un po’ il senso del sistema IP.

[Abdelrahman_MoHamed]

Voglio davvero ringraziarvi @pfaffman @RGJ, ora è pulito e quasi a posto

Il problema che stiamo affrontando ora è che tutte le immagini del marchio sono scomparse e lo stesso vale per le immagini di alcuni utenti.

I dati del marchio sono a posto, posso scaricarli dal vecchio server, ma per quanto riguarda le immagini degli utenti e tutte le immagini del sito, sono anch’esse mancanti

Nuovo Server

Vecchio Server

NOTE:

• abbiamo seguito i passaggi di migrazione eseguendo discourse remap sullo stesso dominio e rake posts:rebake
• Potrebbe essere correlato alla cronologia multisito, quindi abbiamo bisogno di una rimappatura specifica secondo questo link
  Serve Discourse from a subfolder (path prefix) instead of a subdomain - #101 by jtraulle ?

[pfaffman (Jay Pfaffman)]

Se questo non fosse il sito principale per il multisito, il percorso per i caricamenti sarebbe il nome e il sito e non quello predefinito.

[Jacob_Peebles]

Guardando le immagini mancanti, sembrano avere un URL ‘annidato’, eccone una:

(https://forum.mamapedia.com/user_avatar/forum.mamapedia.com/jakeatgetit/24/5872_2.png)

E @pfaffman questo era infatti il sito principale nella configurazione multisito.

CC: @Abdelrahman_MoHamed

[pfaffman (Jay Pfaffman)]

@Jacob_Peebles

/user_avatar/forum.mamapedia.com/

Hmm. Beh, se fosse il sito principale, mi aspetterei che quel percorso fosse https://forum.mamapedia.com/user_avatar/forum.mamapedia.com/jakeatgetit/24/5872_2.png, ma anche quello non funziona.

Se hai ancora il vecchio sito, farei un backup di questo e lo ripristinerei sul nuovo sito.

[Abdelrahman_MoHamed]

Grazie @pfaffman, quello che ho fatto finora sembra funzionare.

Sono entrato nel vecchio server e ho spostato i dati da /var/discourse/shared/standalone/uploads/default allo stesso percorso sul nuovo server e tutti gli avatar e i post degli utenti sono tornati.

Il nuovo problema è che il branding del sito non funziona anche se provo ad aggiornarlo.

Ecco una registrazione dello schermo di un minuto

Screen Recording - Feb 13, 2025

[Jacob_Peebles]

Torno qui per vedere se qualcuno ha qualche idea. Siamo molto vicini a chiudere questa questione da parte nostra, abbiamo solo bisogno di un po’ di assistenza per risolvere il problema del salvataggio ‘senza logo’. Grazie in anticipo per qualsiasi idea per risolverlo!