Maintenant, après la restauration (la clé a été de désactiver les téléchargements S3), tous les liens vers les pièces jointes dans les messages sont cassés (erreur 404). J’ai cherché sur le forum et je n’ai pas trouvé de solution et j’espère que quelqu’un pourra m’orienter dans la bonne direction.
J’ai deux options :
Puis-je réparer ces liens short-url cassés qui pointent vers des pièces jointes intégrées dans les messages (tous les liens cassés concernent des pièces jointes dans les messages ; les images intégrées s’affichent correctement, les autres liens internes fonctionnent bien) ?
Par exemple, le lien vers la pièce jointe sur un message du forum s’affiche comme https://XYZ.com/uploads/short-url/phu1HOLvkE8LWpkKYfnMPSWsvHh.zip. C’est ce que je vois dans les logs lorsque je clique sur un lien de pièce jointe dans un message (qui mène à un 404).
Message (5 copies signalées)
Échec du traitement correct de la réponse détournée : Errno::ENOENT : No such file or directory @ rb_sysopen - /XXXXX.s3.dualstack.us-east-1.amazonaws.com/optimized/1X/46728e07f9819907d1b18387bf02ea7fc25c7981_2_32x32.ico
Trace
/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’
J’espère vraiment qu’il existe un moyen de réparer ces liens short-url après avoir désactivé l’option de téléchargement S3 tout en restaurant le serveur à partir d’une sauvegarde. Un nouveau “re-bake” des messages n’a pas résolu le problème.
Si pour une raison quelconque c’est une impasse et que cela ne peut pas être corrigé en masse, maintenant que j’ai des milliers de pièces jointes orphelines dans le cloud S3, y a-t-il un moyen de les nettoyer et de libérer de l’espace ? Y a-t-il un moyen pour Discourse de parcourir son bucket de téléchargements S3 et de supprimer tous les actifs orphelins ?
Il était peut-être possible de trouver comment réparer ces liens, mais trouver comment le faire dépasse la portée de ce qui est réalisable dans un forum.
Vérifiez si vous avez un fichier nommé b13050bdcd2d58924ba6ab3e7608b16bfc3cd1b7.zip quelque part dans vos téléchargements et/ou votre bucket S3. Si c’est le cas, il devrait être possible, bien que pas facile, de réparer les choses.
Étant donné que vous n’avez pas inclus les noms réels du forum ou du bucket, nous ne pouvons pas le dire ici.
Alors tout est là, il vous suffit de réécrire les messages d’une manière ou d’une autre. Je ne suis pas sûr pourquoi cela ne fonctionne pas, mais les fichiers sont là.
Je crois bien, mais je pense que quelqu’un qui connaît bien Discourse et Rails devra l’écrire. Je ne connais pas de solution existante à votre problème. Il y a quelques sujets sur le déplacement entre les buckets S3 qui pourraient offrir quelques indices, mais je ne pense pas que votre problème particulier ait déjà été résolu.
Eh bien, oui, c’est ce que je vous ai recommandé de faire en premier lieu…
Si vous ne réactivez pas les téléchargements S3, la fonction short-url recherchera ces téléchargements localement, mais ils sont sur S3.
J’essaierai, mais d’un autre côté, lorsque je l’ai activé, cela a cassé la restauration (voir mon autre sujet). Avec l’aide de Jay, j’ai dû trouver comment désactiver le téléchargement pour pouvoir le restaurer. Avez-vous réussi à restaurer un serveur avec l’option activée ?
Vous devez\n\n* Désactiver le paramètre\n* Restaurer\n* Activer le paramètre\n\nComme je l’ai décrit dans notre échange de messagerie privée la semaine dernière