Nach der Wiederherstellung (der Schlüssel war, S3-Uploads zu deaktivieren) sind nun alle Links zu Anhängen in Beiträgen defekt (404-Fehler). Ich habe das Forum durchsucht und keine Lösung gefunden und hoffe, dass mir jemand in die richtige Richtung weisen kann.
Ich habe zwei Optionen:
Kann ich diese defekten short-url-Links reparieren, die auf in Beiträge eingebettete Anhänge verweisen (alle defekten Links sind für Anhänge in Beiträgen; eingebettete Bilder werden korrekt angezeigt, andere interne Links funktionieren einwandfrei)?
Zum Beispiel wird die URL zum Anhang in einem Beitrag im Forum als https://XYZ.com/uploads/short-url/phu1HOLvkE8LWpkKYfnMPSWsvHh.zip angezeigt. Das ist es, was ich in den Protokollen sehe, wenn ich auf einen Anhangslink in einem Beitrag klicke (was zu einem 404 führt).
Nachricht (5 Kopien gemeldet)
Fehler bei der Verarbeitung der gekaperten Antwort: Errno::ENOENT : No such file or directory @ rb_sysopen - /XXXXX.s3.dualstack.us-east-1.amazonaws.com/optimized/1X/46728e07f9819907d1b18387bf02ea7fc25c7981_2_32x32.ico
Backtrace
/var/www/discourse/app/controllers/static_controller.rb:160:in read' /var/www/discourse/app/controllers/static_controller.rb:160:in block (2 levels) in favicon’
/var/www/discourse/lib/distributed_memoizer.rb:16:in block in memoize' /var/www/discourse/lib/distributed_mutex.rb:33:in block in synchronize’
/var/www/discourse/lib/distributed_mutex.rb:29:in synchronize' /var/www/discourse/lib/distributed_mutex.rb:29:in synchronize’
/var/www/discourse/lib/distributed_mutex.rb:14:in synchronize' /var/www/discourse/lib/distributed_memoizer.rb:12:in memoize’
/var/www/discourse/app/controllers/static_controller.rb:138:in block in favicon' /var/www/discourse/lib/hijack.rb:56:in instance_eval’
Ich hoffe wirklich, dass es eine Möglichkeit gibt, diese short-url-Links zu reparieren, nachdem die S3-Upload-Option deaktiviert wurde, während der Server aus einem Backup wiederhergestellt wurde. Ein erneutes Backen des Beitrags hat es nicht behoben.
Wenn dies aus irgendeinem Grund eine Sackgasse ist und nicht massenhaft behoben werden kann, gibt es jetzt, da ich Tausende von verwaisten Anhängen in der S3-Cloud habe, eine Möglichkeit, diese zu bereinigen und den Speicherplatz freizugeben? Gibt es eine Möglichkeit, dass Discourse seinen S3-Upload-Bucket durchgeht und alle verwaisten Assets löscht?
Es könnte möglich gewesen sein, herauszufinden, wie diese Links repariert werden können, aber die Lösung dafür liegt außerhalb des Rahmens dessen, was in einem Forum machbar ist.
Prüfen Sie, ob Sie eine Datei namens b13050bdcd2d58924ba6ab3e7608b16bfc3cd1b7.zip irgendwo in Ihren Uploads und/oder Ihrem S3-Bucket haben. Wenn ja, dann sollte es möglich sein, wenn auch nicht einfach, die Dinge zu reparieren.
Da Sie die tatsächlichen Foren- oder Bucket-Namen nicht angegeben haben, können wir das hier nicht sagen.
Ich glaube schon, aber ich denke, jemand, der mit Discourse und Rails vertraut ist, muss es schreiben. Mir ist keine bestehende Lösung für Ihr Problem bekannt. Es gibt einige Themen zum Verschieben zwischen S3-Buckets, die Hinweise geben könnten, aber ich glaube nicht, dass Ihr spezielles Problem bereits gelöst wurde.
Ja, das ist es, was ich Ihnen von Anfang an empfohlen habe…
Wenn Sie die S3-Uploads nicht wieder aktivieren, sucht die short-url-Funktion lokal nach diesen Uploads, aber sie befinden sich auf S3.
Ich werde es versuchen, aber andererseits hat es die Wiederherstellung kaputt gemacht, als ich es aktiviert habe (siehe mein anderes Thema). Mit Jays Hilfe musste ich herausfinden, wie ich den Upload deaktivieren kann, um ihn schließlich wiederherzustellen. Konnten Sie einen Server mit aktivierter Option erfolgreich wiederherstellen?