Probleme bei der Wiederherstellung des Backups – SiteSetting::Upload.s3_base_url schlägt fehl – da enable_s3_uploads in der Datenbank gesetzt wurde

Allgemein
1

Ich habe ein Backup von der Standardseite in einer Multisite-Instanz. Uploads befinden sich auf S3. Ich habe erfolgreich ein Backup mit include_s3_uploads_in_backups auf true erstellt.

Wenn ich versuche, dies von der Befehlszeile auf einer anderen Multisite-Instanz (mit S3) oder einer frischen Standardinstallation wiederherzustellen, erhalte ich eine Fehlermeldung: Something went wrong while remapping uploads.

Ich habe eine Reihe von puts zu lib/backup_restore/uploads_restorer.rb hinzugefügt und festgestellt, dass dies den Fehler verursacht:

  puts "base url #{SiteSetting::Upload.s3_base_url}"

Die nächste Zeile, die anscheinend zuvor fehlschlug, bevor ich mit dem Debugging begann, lautet:

       current_s3_base_url = SiteSetting::Upload.enable_s3_uploads ? SiteSetting::Upload.s3_base_url : nil

Ich habe versucht, verschiedene S3-Variablen in discourse.conf auszukommentieren, um zu sehen, ob ein ungültiger Wert in der Datenbank das Problem verursacht, aber sie sind alle leer.

Hmm. Und bei der sauberen Installation schlug das Backup fehl und die Seite gibt nun Folgendes zurück:

{
errors: [
"`s3_upload_bucket` site setting has to be set."
]
}

Vielleicht ist eine andere S3-Einstellung in der Datenbank gesetzt, die ich übersehen habe. Ja, enable_s3_uploads ist in der Datenbank gesetzt. Ich bin verwirrt über die Beziehung zwischen use_s3 und enable_s3_uploads…

1 „Gefällt mir“
2

Es ist also bestätigt, dass das Problem darin bestand, dass ich vor einigen Jahren, als ich S3 zum ersten Mal einzurichten versuchte, enable_s3_uploads in der Datenbank gesetzt habe, was dazu führt, dass die Wiederherstellung nicht funktioniert, da versucht wird, nach S3 hochzuladen, aber nicht genügend Informationen vorhanden sind. (Seufz. Aber die Wiederherstellung der Multisite/S3-Instanz schlägt fehl, da einige Dateien „nicht nach S3 migriert wurden“.)

Ich frage mich, ob es sinnvoll wäre, die S3-Upload-Einstellungen komplett auszublenden. Ich bin ziemlich sicher, dass nichts Gutes dabei herauskommen kann, sie im UX zu setzen. Aber es kann praktisch sein, S3-Uploads in der Datenbank einzustellen. . . . vielleicht.

Die auf die Standardinstallation wiederhergestellte Installation zeigt keine Uploads an, da sie Folgendes tut:

      Started GET "/uploads/short-url/puhaSNHeEy1S2knGFQIAZ8lprRy.pdf" for 68.11.35.109 at 2022-01-25 19:48:06 +0000
Processing by UploadsController#show_short as PDF
  Parameters: {"base62"=>"puhaSNHeEy1S2knGFQIAZ8lprRy", "extension"=>"pdf"}
Sent file /var/www/discourse/public/default/original/1X/b2a283b9381b837234e7d4830b.pdf (4.4ms)
Completed 500 Internal Server Error in 130ms (ActiveRecord: 0.0ms | Allocations: 10019)
ActionController::MissingFile (Cannot read file /var/www/discourse/public/default/original/1X/b2a283b9381b837234e7d4830.pdf)

Der Pfad, nach dem gesucht wird, ist /var/www/discourse/public/default/original/1X/ anstelle von /var/www/discourse/public/uploads/default/original/1X/

… . .

Und das liegt daran, dass ich eine Neuzuordnung vorgenommen habe, um die S3-Bucket-Referenzen zu korrigieren, was die Pfade in den lokalen URLs kaputt gemacht hat.

Ich denke, das ist vielleicht zu sehr im Detail, um für irgendjemanden nützlich zu sein. Obwohl ich immer noch denke, dass es eine gute Idee ist, die S3-Upload-Variablen aus dem UX auszublenden.

3 „Gefällt mir“