J’ai récemment mis à jour nos forums de test vers la version 3.3.0beta1. Le forum de test est essentiellement une copie un peu obsolète (en termes de contenu) de nos forums en direct. Nous l’utilisons pour tester les mises à jour et les nouvelles fonctionnalités. Il utilise la même connexion Amazon S3 pour les téléchargements que les forums en direct.
Après avoir mis à jour le système d’exploitation hôte vers la dernière version Ubuntu 24.04 LTS et mis à jour les forums vers la version 3.3.0beta1, tous les avatars personnalisés ont disparu et la tête blanche/grise s’affiche à la place.
Après avoir consulté les journaux, j’ai trouvé des messages tels que :
Impossible de trouver le fichier dans le magasin situé à l'URL : //ourbucket.s3.dualstack.eu-central-1.amazonaws.com/original/3X/6/9/69ca9110f27d91561axyz52a9cd9485a970fe9.jpeg
Même si, en fait, l’image existe à cette URL et fonctionne très bien. J’ai essayé de télécharger le fichier depuis le serveur avec wget pour voir s’il y avait des problèmes de DNS ou d’autres éléments qui pourraient empêcher le proxy d’avatar local de l’obtenir - mais ce n’est pas le cas non plus.
Avez-vous une idée de ce qui pourrait se passer ici ?
Il semble que cela ne se produise pas seulement sur les forums de test, mais aussi sur les forums en direct, les avatars disparaissent petit à petit avec les mêmes erreurs dans le journal.
Je me demande si le forum de test nettoie les éléments qu’il n’attend pas dans le bucket s3, mais vous dites que les éléments sont dans le bucket, donc ce n’est pas ça. Peut-être restaurer une base de données en test et regarder ce qu’il y a dans le modèle d’uploads.
Le problème est que le message d’erreur dans le journal indique qu’il ne peut pas charger une certaine image, mais cette image exacte est en fait disponible. Je suppose donc que quelque chose empêche le proxy de forum/avatar d’extraire l’image.
Je viens de téléverser un nouvel avatar sur le serveur de test (exécutant la version 3.3.0beta1). Il s’est téléversé, s’est affiché dans l’aperçu, mais a ensuite échoué à se charger à nouveau.
/var/www/discourse/app/models/optimized_image.rb:81:in `block in create_for'
/var/www/discourse/app/models/optimized_image.rb:19:in `block (2 levels) in lock'
/var/www/discourse/lib/distributed_mutex.rb:53:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:34:in `synchronize'
/var/www/discourse/app/models/optimized_image.rb:19:in `block in lock'
/var/www/discourse/lib/distributed_mutex.rb:53:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:34:in `synchronize'
/var/www/discourse/app/models/optimized_image.rb:18:in `lock'
/var/www/discourse/app/models/optimized_image.rb:73:in `create_for'
/var/www/discourse/app/models/upload.rb:130:in `get_optimized_image'
/var/www/discourse/app/controllers/user_avatars_controller.rb:218:in `get_optimized_image'
/var/www/discourse/app/controllers/user_avatars_controller.rb:136:in `show_in_site'
/var/www/discourse/app/controllers/user_avatars_controller.rb:89:in `block (2 levels) in show'
/var/www/discourse/lib/hijack.rb:64:in `instance_eval'
/var/www/discourse/lib/hijack.rb:64:in `block in hijack'
concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/promises.rb:911:in `callback_on_resolution'
concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/promises.rb:797:in `call_callback'
concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/promises.rb:803:in `call_callbacks'
concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/promises.rb:692:in `resolve_with'
concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/promises.rb:1325:in `resolve'
/var/www/discourse/lib/scheduler/defer.rb:115:in `block in do_work'
rails_multisite-5.0.1/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
rails_multisite-5.0.1/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/lib/scheduler/defer.rb:109:in `do_work'
/var/www/discourse/lib/scheduler/defer.rb:97:in `block (2 levels) in start_thread'
Ceci provient du journal.
Le message du journal correspondant est :
Impossible de trouver le fichier dans le magasin situé à l'URL : //ourbucket.s3.dualstack.eu-central-1.amazonaws.com/original/3X/0/2/02832e36e27bbad791fda46e2290df31e5ee2dda.jpeg
(J’ai modifié l’URL pour qu’elle ne fonctionne pas, bien que l’original fonctionne)
« block in hijack » est ce qui me pose problème.
Nous fonctionnons derrière Cloudflare sur le système principal. Le système de test est en « DNS uniquement », donc évidemment pas filtré par Cloudflare. Nous avons eu quelques problèmes récemment avec des bots sur le site principal, nous avons donc pas mal joué avec les filtres Cloudflare.
Mais alors, pourquoi la récupération d’une URL amazonaws.com poserait-elle problème pour cela - et encore une fois, le site de test n’est pas du tout géré par Cloudflare.
Je suis vraiment bloqué sur celui-ci. Il semble affecter à la fois les forums en direct et de test - le forum en direct est toujours sur une ancienne version et le problème ne semble même pas avoir commencé avec la mise à jour, mais est apparu il y a quelques jours sans aucun changement notable.
Ce qui se passe, c’est que Discourse télécharge correctement les nouveaux avatars personnalisés vers S3, leur applique les ACL comme je le vois correctement et les fichiers sont également accessibles publiquement via l’URL que Discourse essaie d’utiliser pour les importer dans le proxy d’avatar - malgré cela, il ne parvient pas à le faire (voir la trace de la pile ci-dessus).
Quelqu’un qui connaît bien le fonctionnement du proxy d’avatar a-t-il une idée ou peut-il tirer quelque chose de cette trace de la pile ?
J’ai fait un wget de l’URL de l’image depuis les serveurs et elles fonctionnent toutes bien - donc rien là qui devrait bloquer l’accès à cette URL.
Ah oui, désolé si ce n’était pas clair. Je peux y accéder depuis le navigateur (j’ai donc supposé qu’ils étaient publiquement disponibles) et aussi depuis le serveur (pour exclure qu’il s’agisse d’un problème que le serveur rencontre pour les obtenir. C’est vraiment juste discourse qui ne les obtient pas pour une raison quelconque (voir la trace de la pile ci-dessus).
Avez-vous trouvé une solution à votre problème ? Nous rencontrons exactement le même problème sur la version 3.2.1. Le bucket a tout accès public bloqué, cependant il fonctionnait toujours via des URL pré-signées. Maintenant, j’ai exactement la même erreur :