ich habe kürzlich unsere Testforen auf 3.3.0beta1 aktualisiert. Das Testforum ist im Grunde eine etwas veraltete Kopie (inhaltlich) unserer Live-Foren. Wir nutzen es, um Updates und neue Funktionen zu testen. Es verwendet die gleiche Amazon S3-Verbindung für Uploads wie die Live-Foren.
Nachdem ich das Host-Betriebssystem auf das neueste Ubuntu 24.04 LTS aktualisiert und die Foren auf 3.3.0beta1 aktualisiert habe, sind alle benutzerdefinierten Avatare verschwunden und stattdessen wird der weiße/graue Kopf angezeigt.
Nachdem ich mir die Protokolle angesehen habe, finde ich Meldungen wie:
Could not find file in the store located at url: //ourbucket.s3.dualstack.eu-central-1.amazonaws.com/original/3X/6/9/69ca9110f27d91561axyz52a9cd9485a970fe9.jpeg
Obwohl das Bild tatsächlich unter dieser URL existiert und gut funktioniert. Ich habe versucht, die Datei vom Server mit wget herunterzuladen, um zu sehen, ob es DNS-Probleme oder andere Dinge gibt, die den lokalen Avatar-Proxy daran hindern könnten, sie abzurufen – aber das ist auch nicht der Fall.
Es scheint, dass dies nicht nur in den Testforen passiert, sondern auch in den Live-Foren verschwinden Avatare Stück für Stück mit denselben Fehlern im Protokoll.
Ich frage mich, ob das Testforum Dinge bereinigt, die es nicht im S3-Bucket erwartet, aber Sie sagen, dass die Dinge im Bucket sind, also ist es das nicht. Stellen Sie vielleicht eine Datenbank zum Testen wieder her und sehen Sie sich an, was sich im Uploads-Modell befindet.
Die Sache ist die - die Fehlermeldung im Log besagt, dass ein bestimmtes Bild nicht geladen werden kann, aber genau dieses Bild ist tatsächlich verfügbar. Ich vermute also, dass etwas den Forum-/Avatar-Proxy daran hindert, das Bild abzurufen.
Ich habe gerade einen neuen Avatar auf dem Testserver (mit 3.3.0beta1) hochgeladen. Er wurde hochgeladen, im Vorschaubild angezeigt, aber dann wieder nicht geladen.
/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'
Das ist aus dem Log.
Die Log-Meldung dazu lautet:
Could not find file in the store located at url: //ourbucket.s3.dualstack.eu-central-1.amazonaws.com/original/3X/0/2/02832e36e27bbad791fda46e2290df31e5ee2dda.jpeg
(Die URL wurde modifiziert, damit sie nicht funktioniert, obwohl die echte funktioniert)
‘block in hijack’ ist das, was mich stutzig macht.
Wir laufen hinter Cloudflare im Live-System. Das Testsystem ist “nur DNS”, also offensichtlich nicht durch Cloudflare gefiltert. Wir hatten kürzlich einige Probleme mit Bots auf der Hauptseite, bei denen wir die Cloudflare-Filter ziemlich stark angepasst haben.
Aber warum sollte das Abrufen von einer amazonaws.com-URL ein Problem für das sein – und das Testsystem läuft ja gar nicht über Cloudflare.
Ich stecke hier wirklich fest. Es scheint sowohl das Live- als auch das Testforum zu betreffen – das Live-Forum ist noch auf einer älteren Version und das Problem scheint gar nicht mit dem Update begonnen zu haben, sondern vor ein paar Tagen aufgetreten zu sein, ohne dass nennenswerte Änderungen vorgenommen wurden.
Es passiert also, dass Discourse neue benutzerdefinierte Avatare korrekt nach S3 hochlädt, ihnen, soweit ich sehen kann, korrekt ACLs zuweist und die Dateien auch öffentlich über die URL zugänglich sind, die Discourse zum Abrufen in den Avatar-Proxy zu verwenden versucht – trotzdem schlägt dies fehl (siehe Stacktrace oben).
Hat jemand mit guten Kenntnissen darüber, wie der Avatar-Proxy funktioniert, eine Idee oder kann etwas aus diesem Stacktrace entnehmen?
Ich habe einen wget der Bild-URL von den Servern durchgeführt und sie funktionieren alle einwandfrei – es gibt also nichts, was den Zugriff auf diese URL blockieren sollte.
Ah ja, Entschuldigung, falls das unklar war. Ich kann sie vom Browser aus abrufen (daher ging ich von öffentlicher Verfügbarkeit aus) und auch vom Server aus (um auszuschließen, dass es sich um ein Problem handelt, das der Server hat, um sie abzurufen. Es ist wirklich nur Discourse, das sie aus irgendeinem Grund nicht abruft (siehe oben genannter Stacktrace).
Haben Sie eine Lösung für Ihr Problem gefunden? Wir haben genau das gleiche Problem mit Version 3.2.1. Der Bucket hat den gesamten öffentlichen Zugriff blockiert, funktionierte jedoch immer noch über Presigned URLs. Jetzt erhalte ich genau die gleiche Fehlermeldung: