Problème de restauration de sauvegarde - SiteSetting::Upload.s3_base_url échoue - car enable_s3_uploads a été défini dans la base de données

Général
1

J’ai une sauvegarde du site par défaut sur une instance multisite. Les téléchargements sont sur S3. J’ai réussi à créer une sauvegarde avec include_s3_uploads_in_backups défini sur true.

Lorsque j’essaie de restaurer ceci depuis la ligne de commande sur une autre instance multisite (avec s3) ou une installation standard fraîche, j’obtiens une erreur : Something went wrong while remapping uploads.

J’ai ajouté un tas de puts à lib/backup_restore/uploads_restorer.rb et j’ai identifié que cela provoquait l’erreur :

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

La ligne suivante, qui semble être celle qui échouait avant mon débogage, est :

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

J’ai essayé de commenter diverses variables s3 dans discourse.conf pour voir s’il y avait une mauvaise valeur dans la base de données qui causait le problème, mais elles sont toutes vides.

Hmm. Et sur l’installation propre, la sauvegarde a échoué et maintenant le site renvoie

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

Donc, peut-être qu’un autre paramètre s3 est défini dans la base de données que j’ai manqué. Oui, enable_s3_uploads est défini dans la base de données. Je suis confus quant à la relation entre use_s3 et enable_s3_uploads…

1 « J'aime »
2

Il est donc confirmé que le problème venait du fait que, il y a quelques années, lorsque j’ai d’abord essayé de configurer S3, j’avais défini enable_s3_uploads dans la base de données, ce qui empêche la restauration de fonctionner car elle essaie de télécharger vers S3 mais n’a pas assez d’informations. (Soupir. Mais la restauration de l’instance multisite/s3 échoue car certains fichiers « ne sont pas migrés vers S3 ».)

Je me demande s’il serait judicieux de masquer tous les paramètres de téléchargement S3. Je suis à peu près sûr que rien de bon ne peut sortir de leur définition dans l’interface utilisateur. Mais il peut être utile de définir les téléchargements S3 dans la base de données. . . . peut-être.

Celui restauré sur l’installation standard ne parvient pas à afficher les téléchargements car il fait ceci :

      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)

Le chemin qu’il recherche est /var/www/discourse/public/default/original/1X/ au lieu de /var/www/discourse/public/uploads/default/original/1X/

… . .

Et c’est parce que j’ai fait un remappage en essayant de corriger les références du bucket S3 et que cela a cassé les chemins dans les URL locales.

Je pense que c’est peut-être trop technique pour être utile à qui que ce soit. Bien que je pense toujours que masquer les variables de téléchargement S3 de l’interface utilisateur est une bonne idée.

3 « J'aime »