Migration von gehostet zu selbst gehostet: frühere Uploads verweisen noch auf discourse infra

Unterstützung
1

Überprüft: Images lost when migrating to self-hosting, posts:rebake tut nichts Gutes.

Problem
Wir folgten den offiziellen Anweisungen und erstellten eine Lightsail-Instanz. Von dort luden wir eine Datenbank über die Discourse-UI herunter und wendeten sie an, um zu 80 % fertig zu sein. Die Idee war, zur selbst gehosteten Instanz zu wechseln, während die vorherige Variante am Laufen blieb.

Sobald wir eine Live-Kopie des alten Forums hatten, begannen wir mit der Migration der Bilder. Dazu kündigten wir zunächst unser Abonnement, um unsere Bilder zu erhalten und zu migrieren.

Da neue Bilder auf die selbst gehostete Instanz hochgeladen würden, müssten wir nur von der gehosteten Instanz vor dem Übergangsdatum hochladen. Das bedeutet, dass wir nie den Datenbank-Dump verwendet haben, der mit unseren Bildern und der Kündigung geliefert wurde, da wir die Migration bereits durchgeführt hatten und diese nun abgelaufen war.

Ich beobachte drei Verhaltensweisen, die sich auf diesen Zeitpunkt beziehen.

  1. Referenzierte Ressourcen im Backup (insbesondere SQL-Dump) verweisen auf die Discourse-Infrastruktur.
  2. Referenzierte Ressourcen*, die seitdem im Backup erstellt wurden, z. B. Bilder neuer Beiträge, sind korrekt referenziert und auf unserer Infrastruktur zu finden.

Folglich, wenn ich eine Ressource neu hochlade, die zum gleichen Hash ausgewertet wird, wird sie auf die Discourse-Infrastruktur verlinken. Zum Beispiel: Der Versuch, das Favicon zu reparieren, indem dasselbe hochgeladen wird, funktioniert nicht. Ich kann jedoch jedes andere zufällige Bild hochladen, und es wird funktionieren.

Aktueller Stand
Soweit ich weiß, durchläuft upload://<X> eine b62-Dekodierung (und SHA1?) von Bits, um sie für den Ordner public/uploads zuzuordnen. Wir haben jedes dieser Bilder:

Der von den Discourse-Team bereitgestellte Dump enthält einen Zip mit default/original/1X und dieser ist derzeit unter /var/www/discourse/public/uploads/default/original/1X zu sehen. Der letztere Ordner enthält jetzt 329 Elemente, der gegebene Dump enthielt 249 Elemente – das klingt für mich gut.

Das bedeutet, dass die Daten auffindbar sein sollten, auch wenn ich den Upload nicht direkt im Ordner finden kann. Ich möchte diese Beziehung verstehen, um die Zuordnung irgendwie reparieren zu können. Anfangs schien es nur eine einfache String-Substitution zu sein, und das funktionierte für einige Bilder. Einige wurden jedoch inzwischen durch ein transparent.png ersetzt, wo vorher nur ein unzugängliches Bild war.

4

Wenn das erneute Backen fehlschlug, sollten Sie versuchen, mit remap alle Verweise auf die Discourse-Infrastruktur zu suchen/ersetzen und sie durch relative Links zu ersetzen.

5

Danke Richard!

Zur Klärung, mit: Replace a string in all posts

Verwendung von

rake posts:remap["find","replace","string",true]

tun

rake posts:remap[
  "https://cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/",
  "/uploads/default/"
]

Der alternative Ersetzer für relativ wäre "https://forum.everviz.com/uploads/default/"

Ist der relative Link das, was Sie denken?
e: Korrektur der relativen URL mit /

Einzeiler:

rake posts:remap["https://cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/", "/uploads/default/"]
6

sieht gut aus! Sie müssen einen Schrägstrich davor einfügen

/uploads/default/

7

Haben Sie beim Sichern Ihrer gehosteten Website die Option alle Uploads einschließen aktiviert? Wenn Sie bei CDCK gehostet haben, gab es früher eine versteckte Einstellung, die sie aktivieren mussten, bevor Sie ein Backup mit allen enthaltenen Uploads erstellen konnten. Ich bin mir nicht sicher, ob sich das jetzt geändert hat, aber Sie sollten sich auf jeden Fall mit Ihrem Hosting-Anbieter abstimmen, bevor Sie den Umzug durchführen, um sicherzustellen, dass Sie ein vollständiges Backup (und nicht nur einen SQL-Dump) erstellen.

8

Mein Hosting-Anbieter war Discourse, wir hatten einen Monatsplan. Die gehostete Benutzeroberfläche besagt, dass man sich an team@discourse.com wenden soll, um hochgeladene Dateien zu erhalten. Ihre Antwort war, dass ich das Abonnement kündigen muss, um die Dateien zu erhalten.

Aber ja, wie erwähnt, habe ich uploads/original/1X erhalten.

9

Es ist ein guter Tipp, aber ich habe ihn vielleicht schon ausgeführt:

root@...:/var/www/discourse$ rake posts:remap[\"//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/\",\"/uploads/default/\"]
Sind Sie sicher, dass Sie alle String-Vorkommen von '//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/' durch '/uploads/default/' ersetzen möchten? (J/n)
J
Remapping
0 Beiträge neu zugeordnet!

Die Links waren früher https://europe1.discourse-cdn.com/standard21/uploads/everviz/ im gehosteten Forum. Das ist natürlich dasselbe, nur über das CDN geleitet. Versuchen wir, die Zuordnung zu ändern.

1 Beitrag neu zugeordnet.

Dieses Bild finde ich merkwürdig:

image
image2272×1242 357 KB

Das war natürlich, bevor ich all diese Befehle heute ausgeführt und hier gepostet habe. Es wurde dem Discourse-Team geschickt, bevor ich einige Rake-Tasks und so weiter ausgeführt habe.

10

Hast du das getan? Sie müssen eine versteckte Einstellung aktivieren, die Bilder von S3 herunterlädt und sie in Ihr Backup aufnimmt. Ein normales Backup enthält nicht die Bilder, sondern nur Links zu ihnen in ihren S3-Buckets. Das Kündigen eines Abonnements löst dies meiner Meinung nach automatisch aus, aber ich hatte Kunden, bei denen die Einstellung einfach durch Nachfragen aktiviert wurde. Sie sollten entweder Ihr Abonnement kündigen oder noch einmal nachfragen.

Wenn Sie es nicht auf diese Weise tun möchten, müssen Sie ein Skript schreiben, das die Bilder von S3 herunterlädt und die Discourse-Datenbank entsprechend aktualisiert.

11

Ich habe die Kündigung vorgenommen und die Dateien erhalten. Es scheint jedoch, dass das ursprüngliche Backup der Discourse-Datenbank den Pfad in S3 referenziert. Im Wesentlichen habe ich alles, was ich brauche, in /var/www/discourse/uploads/original/1X.

Ich habe einen manuell heruntergeladenen SQL-Dump verwendet, um die Instanz zu befüllen, nicht den, der mit den Dateien geliefert wurde. Ich war besorgt, dass letzterer möglicherweise korrigierte Pfade zu Bildern enthielt, was ich nun verifiziert habe, dass dies nicht der Fall ist.

Zur Veranschaulichung:


![](upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif) = 1aec065017da50538fe5866ae91a6396185234e1.gif

https://forum.everviz.com/uploads/default/original/1X/1aec065017da50538fe5866ae91a6396185234e1.gif

http://cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/original/1X/1aec065017da50538fe5866ae91a6396185234e1.gif

<img src="https://forum.everviz.com/images/transparent.png" alt="" data-orig-src="upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif" role="presentation" width="1" height="1" style="aspect-ratio: 1 / 1;" loading="lazy">

Das Obige ist ein Sonderfall, bei dem die vorherige Referenz auf cdck… nur transparent.png ist. Unabhängig davon können Sie den Link öffnen und sehen, dass er existiert.

12

Daher würde ich Probleme erwarten.

In dem, was ich als roten Beitrag annehme, den Sie beigefügt haben, mit der Datenbank, die mit den Dateien geliefert wurde, würde ich erwarten, dass sich das ![](upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif) auf Ihren lokalen Speicher bezieht, aber wenn jemand explizit einen Link zu einem Bild in seinem Bucket eingefügt hat, müsste etwas getan werden, um dies zu beheben. Wenn das Bild existierte und Sie die Einstellung “Download to local” aktiviert haben, würde das Bild aus dem Bucket heruntergeladen werden (vorausgesetzt, es erfüllte die Kriterien der Einstellung).

Ich bin mir nicht ganz sicher, wie das letzte <img> in Ihrem Beispiel generiert werden konnte.

13

Lokaler Download ist aktiviert.

Für die verknüpfte Datei enthält der „offizielle“ Goodbye-Dump keine relativen Pfade.

<img src="https://europe1.discourse-cdn.com/standard21/uploads/everviz/original/1X/1aec065017da50538fe5866ae91a6396185234e1.gif" alt="" data-base62-sha1="3Qa5S9sUTcc42dT4EFAbz5K0iJP" ...

Diese exakte Dateireferenz verweist an einigen Stellen auch auf cdck…

Das klingt für mich ein wenig verrückt, aber ich könnte jetzt ein Backup machen. Und dann die Verweise auf die Discourse-Infrastruktur für den lokalen Pfad im Dump selbst verwerfen und diesen neu hochladen.

Die letzte Datei könnte auf transparent.png verweisen, da ich den Beitrag neu aufbereitet habe und die Quelldatei in der Discourse-Infrastruktur nicht mehr auffindbar war. Ich glaube nicht, dass wir von einem vollständigen Datenverlust sprechen.

14

Wenn Ihre Website live ist, würden Sie einfach in Rails hineingehen und Dinge reparieren, soweit es möglich ist.

Aber dieses <img> ist ein bearbeiteter Beitrag, richtig? Nicht der rohe Beitrag?

15

Das Bild ist aus dem Datenbank-Dump. Ich nehme an, es ist “cooked”. Der rohe Beitrag verweist auf die b62 als upload://

Der aktuelle “cooked”-Inhalt ist:

<img src="https://forum.everviz.com/images/transparent.png" alt="" data-orig-src="upload://3Qa5S9sUTcc42dT4EFAbz5K0iJP.gif" ...

Bisher war ich mit rake zum Finden und Beheben fehlender Uploads, zum Neu-Abbilden und zum erneuten Backen von Beiträgen nicht sehr erfolgreich.

Danke Jay für all deine Hilfe!

16

Die Datei, auf die im aufbereiteten Beitrag verwiesen wird, funktioniert. Es gibt kein Problem damit.

Wenn Sie in der Datenbank-Sicherung in den aufbereiteten Beiträgen suchen, dann suchen Sie an der falschen Stelle.

Sie haben jetzt eine Live-Seite, also müssen Sie von dort aus arbeiten.

Was sehen Sie im Rohbeitrag? Was zeigt der aufbereitete Beitrag nach einer Neubackung dieses Beitrags, was nicht Ihren Erwartungen entspricht?

Ohne genau zu wissen, was Sie getan haben und was in den Beiträgen (roh und aufbereitet) steht, gibt es nicht viele Möglichkeiten zu helfen. Da Sie mit einer Datenbank begonnen haben, die voraussichtlich nicht die richtigen Daten enthält, wird dieses Thema für andere nicht nützlich sein.

17

Ich habe getan, was mir alle verboten haben: mich mit der Datenbank und ihrem Dumpfile zu befassen. Derzeit funktioniert fast alles, außer in einigen Fällen von:

<img src="https://forum.everviz.com/images/transparent.png"
alt="image" data-orig-src="upload://npqpp5O0wbL89nR9OXtP7Btu4hc.png"
width="517" height="90" style="aspect-ratio: 517 / 90;" loading="lazy">

Berechnen wir die b62 und nehmen ihre Hexadezimaldarstellung

npqpp5O0wbL89nR9OXtP7Btu4hc = 0x a411c90267cafca7a1cbcd7c8f4f9b8db17e51ba

Versuchen wir nun, sie aus /var/www/discourse/public/uploads zu finden:

find . -name '*a411c90267cafca7a1cbcd7c8f4f9b8db17e51ba*'
./default/original/1X/a411c90267cafca7a1cbcd7c8f4f9b8db17e51ba.png

Ja!

932×164 18.5 KB

Aber warum ist es im Beitrag transparent.png? Ich habe rake uploads:recover_from_tombstone und rake posts:rebake ausgeführt.

Wie bin ich hierher gekommen?

Die Uploads-Spalte in der Datenbank für die Tabelle url zeigte immer noch cdck als Teil der Quell-URL für Bilder an. Ich bin von innerhalb des Containers in die Datenbank eingestiegen:

postgres psql discourse

Dann

UPDATE uploads
SET url = REPLACE(
           url,
           '//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/',
           '/uploads/default/'
         )
WHERE url LIKE '//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard21/uploads/everviz/%';

Dies zeigte vielversprechende Ergebnisse, bei denen die meisten Originalbilder und Miniaturansichten wieder erschienen.

Ein Schritt weiter: Bearbeiten von Dumpfiles

Die Annahme ist, dass Discourse zustandslos* ist und wir uns nur um das kümmern müssen, was sich in der Datenbank befindet. Ich war nicht begierig darauf, mit Rake-Tasks oder Ruby herumzuspielen, da ich weder damit noch mit den Interna von Discourse sehr vertraut bin. Ich will nur schnelle Ergebnisse.

*Abgesehen vom public-Ordner, der unsere Bilder enthält. Wir können dennoch bestätigen, dass wir alles haben, was wir brauchen.

Also laden wir eine Kopie der Datenbank über die Benutzeroberfläche herunter, öffnen sie in VSCode und ersetzen schrittweise cdck (Bucket)-Referenzen und europe1 (Bucket aus CDN)-Referenzen.

Mit schrittweise meine ich, dass Sie in einigen Fällen ‘//…’ und in anderen Fällen ‘https://’ sehen würden. Daher müssen Sie zuerst ‘//…’ abgleichen und ersetzen, sonst haben Sie am Ende des Files nachgestellte https:.

Laden Sie dann das modifizierte Dumpfile erneut hoch. Ein Teil dessen, was dies alles schwierig machte, ist der Base62-Schritt, der es etwas schwieriger macht, von einer Rohdarstellung zur tatsächlichen Bild-URL zu gelangen.

18

Aufgabe abgeschlossen

Nachdem ich die Größe der Uploads-Tabelle noch einmal überprüft hatte, stellte ich fest, dass einige hundert Einträge fehlten. Ich weiß nicht, bei welchem Schritt sie verloren gegangen sind. Ich habe mit einem einfachen SQL-Join aus einer temporären Tabelle mit dem Datenbank-Backup der Vergangenheit zusammengeführt.

Wie ich oben bereits erwähnt habe, ist die URL, die für ein Bild angefordert wird, diejenige, die in der Uploads-Tabelle in der Spalte „url“ gespeichert ist. Vom Rails-Konsolen aus habe ich diese CDN-Referenzen mit SQL über die Uploads-Tabelle auf unsere lokale Domain umgestellt.

Warum nicht die Rake-Aufgabe verwenden

Es gibt wahrscheinlich ein paar, die in Ordnung sind, und eine Kombination davon würde funktionieren. Wenn Sie jedoch das aktuelle Verhalten beobachten können, wissen Sie, was Sie wollen, und Sie wissen, wie Sie dorthin gelangen – dann empfinde ich die Einschränkung als willkürlich.

Ich möchte dem Discourse-Team und den Freiwilligen hier danken, die mir alle Informationen gegeben haben, die ich benötigte, um die Lösung zu finden, die schließlich aus einigen Schritten bestand.

1 „Gefällt mir“
19

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.