Defekte Bilder und ihre S3-URLs

Unterstützung
23

@schleifer Hey, könnten wir danach bitte eine Anleitung bekommen?

24

OK, damit können wir arbeiten. Verschiebe zunächst alle Dateien aus /default/* nach /original/1X/*.

Das ist uns bekannt, aber nicht der Datenbank. Der nächste Schritt wird den Pfad für alle in der Datenbank gespeicherten Hochladungen anpassen. Bevor wir jedoch etwas anderes ändern, lass uns eine Plausibilitätsprüfung durchführen.

Starte eine Datenbankkonsole:

cd /var/discourse
./launcher enter
rails db

Führe diese Abfrage aus, um einen Blick darauf zu werfen:

select id,url from uploads where id > 0 and url not like '//PREFIX/original/%'

Du musst PREFIX durch BUCKET + ‘.s3.dualstack.’ + REGION + ‘.amazonaws.com’ ersetzen, was beispielsweise //pesioforum.s3.dualstack.us-west-2.amazonaws.com/original/% ergeben würde.

Das sollte (0 rows) ausgeben. Falls nicht, gibt es zusätzliche Schritte.

25

Es gibt 7 hochgeladene Dateien für Ihre Abfrage, und keine davon stammt aus S3.
Also zeigen alle S3-Links nur auf das Original, oder? Die 7 Uploads stammen aus der Zeit vor der Einführung von S3 für Uploads (Oktober 2018).

image
image963×182 31.7 KB

Von den S3-Links (2614):
2368 verwenden //pesioforum.s3.dualstack.ap-south-1.amazonaws.com
246 verwenden //pesioforum.s3.ap-south-1.amazonaws.com

Beide Links funktionieren, ich erwähne es hier nur, falls es Regex-Ausdrücke betrifft, die wir eventuell verwenden.

26

@schleifer Bitte hilf uns, das zu Ende zu bringen. :smiling_face:

27

OK, du solltest also problemlos Dateien von /default/ nach /original/1X verschieben können.

28

Du kannst diese in S3 migrieren, indem du rake s3:upload_assets ausführst.

Der Dualstack-Endpunkt funktioniert sowohl für IPv6 als auch für IPv4. Der andere ist nur für IPv4 verfügbar.

Im Image befindet sich ein Skript zum Umschreiben von Zeichenketten in der Datenbank. Führe vor der Ausführung IMMER ein BACKUP über /admin/backups durch (Hamburger-Menü → Admin → Backups).

Dies sollte die 246-Einträge beheben:

discourse remap '//pesioforum.s3.ap-south-1.amazonaws.com/original/' '//pesioforum.s3.dualstack.ap-south-1.amazonaws.com/original/'

Nachdem alle Dateien von /default/ nach /original/1X/ verschoben wurden, können wir diese Dateien in der Datenbank ummappen. Zuvor sollten wir jedoch sicherstellen, dass sich alle Dateien in /original/2X/ tatsächlich an ihrem Platz befinden.

Gibt diese Abfrage die gleiche Anzahl von Zeilen zurück wie die tatsächliche Anzahl der Objekte unter diesem Pfad im Bucket?:
select url from uploads where url like '//pesioforum.s3.dualstack.us-west-2.amazonaws.com/original/2X/%'

29

Hey @schleifer

Du kannst diese mit rake s3:upload_assets nach S3 migrieren.

Ich habe das ausgeführt, und es wurden Assets (JS, CSS usw.) für die Website hochgeladen. Die 7 Dateien wurden jedoch nicht hochgeladen.
Ich habe rake uploads:migrate_to_s3 gefunden, wollte aber sicherstellen, dass dies die richtige Aufgabe dafür ist.

Es gibt ein Skript im Image zum Umsetzen von Strings in der Datenbank.

Das hat gut funktioniert, und in der Tabelle uploads gibt es keine alten nicht-dualstack-Links mehr.

Aber vorher sollten wir sicherstellen, dass alles in /original/2X tatsächlich vorhanden ist.

Leider ist das nicht der Fall. Im S3-Bucket befinden sich 521 Dateien, aber in der Tabelle uploads gibt es 2186 Datensätze.
Ich habe einige Dateien getestet, die nicht wie erwartet in /original/2X/ liegen, und sie befinden sich alle in /default/.

Beispiel: Aus der Tabelle uploads
https://pesioforum.s3.dualstack.ap-south-1.amazonaws.com/original/2X/8/806a660beb158e9f06d07ffcd2370b389bbd250b.jpeg existiert nicht, aber dieselbe Datei befindet sich unter
https://pesioforum.s3.dualstack.ap-south-1.amazonaws.com/default/806a660beb158e9f06d07ffcd2370b389bbd250b.jpeg

An diesem Punkt sind wir mit einem einmaligen Hack einverstanden, bei dem wir einfach alle Dateien von /original/2X/{}/ nach /original/1X/ verschieben und die Beiträge usw. mit den neuen Links aktualisieren.
Neue Uploads werden ohnehin ordnungsgemäß in 2X abgelegt.

30

Aha, ja, das war die, die ich eigentlich gemeint habe. Damit sollten diese letzten sieben hochgeladen werden.

Tatsächlich ist das derzeit die beste Option. Kopieren Sie alle Dateien aus ihrem /2X/-Unterpräfix und verschieben Sie alles nach /1X/.

Sobald alles bereitsteht, gibt es hier einen Befehl, der alle Datenbankeinträge aktualisieren sollte:

discourse remap --regex "//pesioforum\.doublestack\.s3\.ap-south-1\.amazonaws\.com/original/[1234]X/([0-9a-f]/){0,}" "//pesioforum.doublestack.s3.ap-south-1.amazonaws.com/original/1X/"

(Vergessen Sie nicht die vorherige Warnung über die Erstellung eines Backups.)

Danach müssen möglicherweise einige Beiträge die HTML-Version über das Schraubenschlüssel-Menü neu erstellen. Wenn es mehr als nur wenige sind, können Sie alles mit rake posts:rebake neu erstellen.

31

@schleifer Das hat funktioniert! Mit einer angepassten Regex und einem Neuberechnen aller Beiträge funktionieren die meisten Bilder und Uploads einwandfrei.
Es gibt noch ein paar Bilder (keine Beiträge), die immer noch auf /optimized/ verlinken, aber das können wir manuell beheben. Beispiel: Logos in verschiedenen Themes usw.

Vielen Dank für deine Hilfe!

32

Hallo,

wir haben in unserer Umgebung ein ähnliches Problem wie hier beschrieben und hoffen ebenfalls auf Unterstützung bei der Lösung.

Unser Problem ist dem hier in vielerlei Hinsicht ähnlich:

  1. Wir haben denselben Wert unter s3 upload bucket und s3 backup bucket aufgeführt.
  2. Das Problem trat auf, als wir Discourse aktualisiert haben:
Alte Version: v2.3.0.beta3
Neue Version: v2.5.0.beta6
  1. Ich habe mich in den Discourse-Container eingeloggt und die Datenbank abgefragt:
SELECT id,url FROM uploads where id > 0 and url not like '//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/%';

 id |                                                url
----+----------------------------------------------------------------------------------------------------
  1 | /uploads/default/original/1X/eb17xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxc33.png
  2 | /uploads/default/original/1X/b87fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxv21.png
 78 | //acme-forum.s3-us-west-2.amazonaws.com/original/1X/1205xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxv045.png
(3 rows)
  1. Ich habe mich erneut in den Discourse-Container eingeloggt und die Datenbank abgefragt:
select url from uploads where url like '//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/%';

 //acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/6/2/6267xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxf607c.jpeg
(7953 rows)
  1. Ich habe geprüft, wie viele Dateien sich in ./original/3X/ befinden. Die Antwort lautet: 251 Dateien.

Fragen:

  1. Wir verwenden dualstack und möchten unsere URLs nicht so umkonfigurieren, dass dualstack nicht mehr verwendet wird.
  2. Unsere Ordnerstruktur sieht anders aus; wir haben beispielsweise 3X/X/Y (z. B. 3X/7/a). Wie können wir also alles von default nach 3X/* verschieben, wenn die Zuordnung trotzdem nicht korrekt funktioniert?

Mein aktueller Ansatz ist es, ein Skript zu schreiben, das die Ausgabe aus Schritt 4 verwendet, um herauszufinden, wohin die Dateien zurück in den Ordner ./original/3X/X/Y verschoben werden müssen.

Das einzige Problem ist, dass dualstack diese Datei noch nicht bereitgestellt hat, als ich das versucht habe. Was ich damit meine: Wenn ich die Datei nach original/3X/X/Y verschiebe, kann ich sie unter folgender Adresse sehen:
Fehlerhaft https://acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/6/b/6b6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxa001.png

Funktioniert https://acme-forum.s3-us-west-2.amazonaws.com/original/3X/6/b/6b6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxa001.png

Update: Es stellt sich heraus, dass der dualstack-Endpunkt nicht wie gedacht defekt war. Ich habe einen Fehler gemacht, als ich die Bilddatei ursprünglich nach ./original/3X/6/b kopiert habe, und dabei vergessen, Lesezugriff für alle zu ermöglichen.

Meine Frage lautet also:
Wäre es eine gangbare Option, die Bilddateien von ./default zurück nach ./original/3X/x/y zu verschieben und die Datenbank überhaupt nicht zu ändern?

33

Ok, ich habe ein Update.
Es sieht so aus, als könnte ich vorhersagen, wohin die ./original-Bilder gehören, aber ich weiß nicht, wie ich die ./optimized-Bilder beheben soll.

In unserem Forum versucht es, das ./optimized-Bild anzuzeigen, wenn man einen unserer Beiträge aufruft.

Gibt es eine Möglichkeit zu erkennen, ob es sich um ein optimiertes Bild handelt?

Meine Überlegung ist, dass optimierte Bilder auf _2_10x10.png enden. Wäre das eine vernünftige Annahme? Falls ja, wäre es eine machbare Lösung, ein Skript zu verwenden, das alles, was so etwas wie _2_10x10.png enthält, in den Ordner optimized kopiert und alles andere direkt in den Ordner ./original?

Beispiel:

GET https://acme-forum.s3.dualstack.us-west-2.amazonaws.com/optimized/3X/c/c/ccaxxxxxxxxxxxxxxxxxxxxxxxxxxxx85_2_690x268.png
[HTTP/1.1 403 Forbidden 0ms]

Danke!

34

@41821 Wenn die URLs in der Tabelle uploads korrekt und funktionsfähig sind, die Beiträge aber dennoch versuchen, die optimierten Bilder zu laden, sollte das Leeren der Tabelle optimized_images und das Neuaufbereiten aller Beiträge helfen: discourse=> delete from optimized_images;

35

Vielen Dank für das Feedback! Tatsächlich habe ich das Problem (wenn man es so nennen kann) gelöst, indem ich ein Skript geschrieben habe, das das Bild basierend auf dem Dateinamen vom Verzeichnis /default zurück nach /optimized verschiebt. Das hat funktioniert und ich habe keine Probleme mehr.

Sollte das in Zukunft jedoch wieder passieren, werde ich das tun, was du vorgeschlagen hast: alles aus optimized_images löschen und neu baken.

Danke!