Alte Multisite-Domains servieren weiterhin Standard-Forum nach Deaktivierung von Multisite

[Abdelrahman_MoHamed]

Wir haben zuvor ein Discourse-Multisite-Setup mit rund 22 verschiedenen Foren betrieben. Kürzlich haben wir uns entschieden, die Multisite-Konfiguration zu entfernen und nur die Standard-Site beizubehalten:

Standard-Site jetzt: forum.mamapedia.com
Entfernte alte Multisite-Domain: forum.employ.com (und 21 weitere)

Das Problem:

Selbst nach der Deaktivierung des Multisite-Setups können die alten Multisite-Domains immer noch das Standardforum (forum.mamapedia.com) bereitstellen. Zum Beispiel:

• Der Besuch von forum.mamapedia.com funktioniert wie erwartet.
• Aber der Besuch von forum.employ.com lädt immer noch das Mamapedia-Forum.

Wir hatten erwartet, dass alte Domains wie forum.employ.com entweder:

1. Einen Fehler anzeigen (da sie nicht mehr konfiguriert sind).
2. Korrekt weiterleiten oder vollständig inaktiv sein würden.

Setup-Hinweise:

• Wir verwenden SSL-Zertifikate von Cloudflare mit aktivierter Proxy-Option (der Traffic geht nicht direkt an unseren Server).
• Wir können die A-Records für die alten Domains entfernen, aber wir möchten die Grundursache identifizieren und beheben, anstatt uns auf eine DNS-basierte Umgehung zu verlassen.

Bisherige Schritte:

1. Multisite-Einstellungen aus discourse.conf und der Datenbank entfernt.
2. Discourse neu gestartet und die app.yml-Einstellungen überprüft.
3. Cache geleert und im Inkognito-Modus getestet.

Erwartetes Verhalten:

• forum.mamapedia.com sollte weiterhin funktionieren.
• forum.employ.com und andere alte Domains sollten das Mamapedia-Forum nicht bereitstellen.

Fragen:

1. Wie können wir die alten Domains ordnungsgemäß entfernen, damit sie nicht das Standardforum bereitstellen?
2. Müssen wir Nginx/Traefik-Einstellungen, Cloudflare-Einstellungen anpassen oder gibt es eine Discourse-spezifische Konfiguration, die wir übersehen haben?

Nginx-Konfiguration

[pfaffman (Jay Pfaffman)]

Sie müssen auf eine Standardinstallation umstellen. Die Änderungen, die Sie vorgenommen haben, um es multisite-fähig zu machen, ermöglichen es dem Server, mehrere Domains zu bedienen.

Wenn Sie einen neuen Server erstellen und das Backup wiederherstellen, können Sie nichts kaputt machen, da Sie einfach wieder zum alten Server wechseln können.

Der einzige Haken ist, dass Sie die DNS auf den neuen Server verweisen müssen, während Sie ihn neu aufbauen, damit ein Zertifikat ausgestellt werden kann. Und machen Sie DNS nur über Cloudflare.

[Abdelrahman_MoHamed]

Danke @pfaffman , wir haben versucht, von einer Multisite-Einrichtung auf eine Standardinstallation umzusteigen, aber das Problem besteht weiterhin.

Was wir getan haben:

1. Discourse-Installation entfernt:
   • Das gesamte Verzeichnis /var/discourse gelöscht.
2. Discourse neu installiert:
   • Das Discourse-Repository erneut geklont.
   • app.yml mit den notwendigen Konfigurationen neu erstellt.
3. App neu erstellt:
   • ./launcher rebuild app ausgeführt.
4. DNS aktualisiert:
   • Die Domain auf den neuen Server verweisen lassen.
   • Cloudflare in den nur DNS-Modus versetzt, um die Ausstellung von SSL-Zertifikaten zu ermöglichen.

Zusätzliches Problem mit SSL:

• Als wir SSL in app.yml aktivierten und Cloudflare-Proxy deaktivierten, traten selbst nach der Aktivierung von SSL die folgenden Probleme auf:

Fragen:

1. Könnte das Problem damit zusammenhängen, dass kein Datenbank-Backup wiederhergestellt wurde?
2. Sind zusätzliche Schritte erforderlich, um alte Multisite-Konfigurationen zu bereinigen?
3. Wie aktiviert man SSL in dieser Einrichtung richtig, ohne auf Probleme zu stoßen?

Wir würden uns über jede Anleitung von denen freuen, die dies bereits getan haben!

[pfaffman (Jay Pfaffman)]

@Abdelrahman_MoHamed

app.yml mit den notwendigen Konfigurationen neu erstellt.

Haben Sie discourse setup ausgeführt oder es manuell gemacht?

Haben Sie die SSL- und Let’s Encrypt-Vorlagen?

Wenn Sie eine Menge Male mit der orangefarbenen Wolke neu aufgebaut haben, könnten Sie eine Ratenbegrenzung haben.

[RGJ (Richard - Communiteq)]

Der Grund, warum dies passiert, ist ganz einfach. Multisite wählt ein Forum basierend auf dem Hostnamen aus. Eine Nicht-Multisite-Installation akzeptiert gerne jeden Hostnamen, auf den Sie zeigen. Solange Sie also alle alten Hostnamen auf diese Installation umleiten, wird die verbleibende Seite auf all diesen Hostnamen angezeigt.

[Zitat=“Abdelrahman MoHamed, Beitrag: 1, Thema: 351365, Benutzername: Abdelrahman_MoHamed”]
Wir können die A-Datensätze für die alten Domains entfernen, aber wir möchten wirklich die Ursache identifizieren und beheben, anstatt uns auf eine DNS-basierte Zwischenlösung zu verlassen.
[/Zitat]
Dass die alten Einträge auf Ihre Seite verweisen, ist die Ursache.
Das Aufräumen Ihrer alten Konfiguration ist keine Zwischenlösung, sondern die Lösung.

[pfaffman (Jay Pfaffman)]

OMG. Ich kann mich nicht erinnern, wann ich das letzte Mal mit Ihnen in einer Sachfrage nicht einer Meinung war. Normalerweise weiß ich, wenn ich Ihren Avatar in einem Thema sehe, zu dem ich etwas geschrieben habe, dass ich etwas lernen werde!

@RGJ

Der Grund, warum dies geschieht, ist einfach. Multisite wählt ein Forum basierend auf dem Hostnamen aus.

Das stimmt. Sie behaupten jedoch, dass sie zu einer Standardinstallation gewechselt sind. Ich glaube ihnen nicht.

@RGJ

Eine Nicht-Multisite-Installation akzeptiert gerne jeden Hostnamen, auf den Sie sie verweisen.

Seit mehreren Jahren (aber ich glaube, seit Let’s Encrypt verfügbar ist) leitet eine Standardinstallation bei Zugriff über einen anderen Hostnamen weiter (Sie können dies leicht überprüfen, indem Sie die IP-Nummer verwenden, und ich habe gerade eine weitere durchgeführt, indem ich forum.bigmouth.bass in /etc/hosts auf eine Standardinstallation gesetzt habe, und es wurde wie erwartet weitergeleitet. Wenn Sie über HTTPS darauf zugreifen, was die meisten Browser jetzt standardmäßig tun, erhalten Sie einen Zertifikatsfehler.

Wenn alles, was erforderlich war, um auf Ihre Website über einen anderen Hostnamen zuzugreifen, DNS war, dann könnte jeder Ihre Website kapern, indem er einen DNS-Eintrag erstellt, der auf Ihre Website verweist.

Ich glaube, das ist die Magie:

templates/web.ssl.template.yml

Ich vermute, dass app.yml immer noch etwas wie das hier enthält:

@pfaffman

   # do not redirect all hosts back to the main domain name
    - 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)]

@Jay Pfaffman

Ich weiß, dass ich etwas lernen werde!

Nun, TIL, dass ich meine Fakten öfter aktualisieren sollte! Dieser Code ist seit 2014 vorhanden, also lebte ich wohl ziemlich in der Vergangenheit.

Du hast völlig recht, es wird weiterleiten.

[Abdelrahman_MoHamed]

Vielen Dank @RGJ , @pfaffman ,

Wir haben app.yml überprüft, und es gibt keine benutzerdefinierten Weiterleitungskonfigurationen oder Overrides. Unser Instance leitet jedoch immer noch keine unbekannten Hostnamen auf die Hauptdomain um.

1. Nginx-Konfiguration: Gibt es eine Möglichkeit zu überprüfen, ob die Weiterleitungslogik aus templates/web.ssl.template.yml tatsächlich angewendet wird? Sollten wir die generierte Nginx-Konfiguration im Container manuell überprüfen?

2. Discourse-Debugging: Gibt es Logs oder Befehle, die wir im Container ausführen können, um zu bestätigen, dass Discourse Hostnamen korrekt verarbeitet?

3. Andere mögliche Ursachen: Wenn app.yml sauber ist, was könnte sonst den erwarteten Weiterleitungsprozess verhindern? Könnten Cloudflare oder eine andere Einstellung eingreifen?

Wir würden uns über Hinweise freuen, um tiefer zu graben!

[RGJ (Richard - Communiteq)]

@Richard – Communiteq

Das Bereinigen Ihrer alten Konfiguration ist kein Workaround, sondern die Lösung.

Hier ist ein Hinweis.

[pfaffman (Jay Pfaffman)]

Haben alle alten Domains die orangefarbene Wolke aktiviert? Löst das Deaktivieren der orangefarbenen Wolke das Problem? Wenn ja, dann hat Richard, wie ich schon immer erwartet habe, Recht und Sie müssen Ihr Setup bereinigen.

Wenn Cloudflare es jedoch einem böswilligen Akteur (in diesem Fall Ihnen) ermöglicht, die Website eines anderen unter dessen Domain zu hosten, scheint das ein Problem zu sein.

[Abdelrahman_MoHamed]

Soll ich es nach dem Herunterladen von Discourse ausführen?

./discourse-setup

Oder sollte ich meine alte app.yml nach dem Herunterladen einfügen und dann ausführen?

./launcher rebuild app

Welchen Weg soll ich einschlagen?

[Abdelrahman_MoHamed]

Wir haben bereits alte Domains entfernt, aber ja, sie hatten den orangefarbenen Button aktiviert. Das Problem ist jetzt, dass, wenn jemand unsere Server-IP und einen A-Record mit aktivierter Proxy-Option erhält, unsere Website mit deren Domain bedient wird.

[pfaffman (Jay Pfaffman)]

Sie sollten discourse-setup ausführen, um sicherzustellen, dass Sie wirklich eine Standardinstallation haben. Wenn Sie Ihre alte app.yml einfügen, könnten Sie etwas darin haben, das nicht dorthin gehört. Ich bin immer noch nicht ganz davon überzeugt, dass Sie eine Standardkonfiguration haben.

@Abdelrahman_MoHamed

Das Problem ist jetzt, wenn jemand unsere Server-IP und einen Eintrag dort mit aktivierter Proxy-Option erhält, wird er unsere Website mit seiner Domain bedienen.

Ich bin immer noch nicht davon überzeugt, dass dies der Fall ist, aber wenn es so ist, können Sie nichts dagegen tun.

[Jagster (Jakke Lehtonen)]

@Abdelrahman_MoHamed

if anyone got our server IP

Die meisten Server-IPs der Welt sind öffentlich. Das ist irgendwie der Sinn des IP-Systems.

[Abdelrahman_MoHamed]

Ich möchte mich wirklich bei Ihnen @pfaffman @RGJ bedanken, jetzt ist es sauber und fast gut.

Das Problem, mit dem wir jetzt konfrontiert sind, ist, dass alle Branding-Bilder verschwunden sind und dasselbe gilt für einige Benutzerbilder.

Die Branding-Daten sind in Ordnung, ich kann sie vom alten Server herunterladen, aber was ist mit den Benutzerbildern und allen Website-Bildern, die ebenfalls fehlen?

Neuer Server

Alter Server

ANMERKUNGEN:

• Wir haben die Migrationsschritte befolgt, indem wir discourse remap auf dieselbe Domain und rake posts:rebake ausgeführt haben.
• Könnte es mit der Multisite-Historie zusammenhängen, sodass wir eine spezifische Zuordnung gemäß diesem Link benötigen:
  Serve Discourse from a subfolder (path prefix) instead of a subdomain - #101 by jtraulle ?

[pfaffman (Jay Pfaffman)]

Wenn dies nicht die Hauptseite für die Multisite gewesen wäre, dann wäre der Pfad für die Uploads der Name und die Seite und nicht der Standard.

[Jacob_Peebles]

Betrachtet man die fehlenden Bilder, scheinen sie eine ‘verschachtelte’ URL zu haben, hier ist eine:

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

Und @pfaffman, dies war tatsächlich die Hauptseite im Multisite-Setup.

CC: @Abdelrahman_MoHamed

[pfaffman (Jay Pfaffman)]

@Jacob_Peebles

/user_avatar/forum.mamapedia.com/

Hmm. Nun, wenn es die Hauptseite wäre, würde ich erwarten, dass dieser Pfad https://forum.mamapedia.com/user_avatar/forum.mamapedia.com/jakeatgetit/24/5872_2.png lautet, aber das funktioniert auch nicht.

Wenn Sie noch die alte Seite haben, würde ich ein Backup davon erstellen und es auf der neuen Seite wiederherstellen.

[Abdelrahman_MoHamed]

Danke @pfaffman, was ich bisher getan habe, scheint zu funktionieren.

Ich habe mich in den alten Server eingeloggt und die Daten von /var/discourse/shared/standalone/uploads/default auf denselben Pfad auf dem neuen Server verschoben, und alle Benutzeravatare und Beiträge sind zurückgekehrt.

Das neue Problem ist, dass das Branding der Website nicht funktioniert, selbst wenn ich versuche, es zu aktualisieren.

Hier ist eine einminütige Bildschirmaufnahme

Screen Recording - Feb 13, 2025

[Jacob_Peebles]

Ich melde mich hier wieder, um zu sehen, ob jemand Ideen hat. Wir sind kurz davor, dies auf unserer Seite abzuschließen, benötigen nur etwas Hilfe bei der Fehlerbehebung des Problems mit dem Nichtspeichern des Logos. Vielen Dank im Voraus für alle Ideen zur Lösung!