Die AWS SDK-Maintainer haben die Kompatibilität gebrochen. Es liegt an Ihrem S3-Klonanbieter, aufzuholen und eine bessere Kompatibilität zu implementieren, damit Sie die Workarounds entfernen können.
4 „Gefällt mir“
Nur um das klarzustellen, betrifft das nur JS/map/CSS-Dateien in Assets, und hat keinen Einfluss auf Uploads, richtig?
Ich meine, wird es das Löschen von verwaisten Dateien beeinträchtigen?
Übrigens nehme ich an, dass dieses Problem das Aktualisieren von Discourse über das Admin-Panel betreffen könnte?
Tatsächlich ist das Update über das Admin-Panel bei mir fehlgeschlagen, weshalb ich eine Neuerstellung durchgeführt habe.
Ja, es ist nur für Assets.
Diese Rake-Aufgabe? Nein.
Aber die gesamte Änderung des AWS SDK hat dies möglicherweise auch für Personen mit nicht kompatiblen Klonen beeinträchtigt.
1 „Gefällt mir“
[Zitat=“Yt.w, Beitrag:22, Thema:354217”]
und Uploads nicht beeinträchtigt, oder?
[/Zitat]
Ich bin mir ziemlich sicher, dass das falsch ist. Wir müssen wahrscheinlich auch clean up uploads deaktivieren. Das wird nur Fehler verursachen, wenn du es ausführst. Es wird aber nicht dazu führen, dass du nicht neu erstellen kannst.
[Zitat=“Falco, Beitrag:23, Thema:354217, Benutzername:Falco”]
Aber die gesamte AWS SDK-Änderung könnte das auch für Leute auf nicht-kompatiblen Klonen kaputt gemacht haben.
[/Zitat]
Klingt wahrscheinlich. Vielleicht brauchen wir eine “skip_s3_delete”-Einstellung, um das zu lösen, bis die anderen Anbieter aufholen? Und sie vielleicht automatisch für Anbieter setzen, von denen wir wissen, dass sie defekt sind?
Ist diese Rake-Aufgabe die einzige Möglichkeit, abgelaufene Assets zu entfernen?
Ich frage mich nur, warum keine Option hinzugefügt wird, die Assets auf dem Discourse-Core-Server zu belassen (ich meine, ohne sie auf S3 zu speichern)?
Solange dies den Upload oder den Prozess des Löschens verwaister Dateien nicht beeinträchtigt, scheint es eine praktikable Lösung zu sein.
Ja. Es ist nicht so, dass dies eine große Sache wäre. Normale Websites, die sich von Zeit zu Zeit aktualisieren, werden kaum einen Unterschied feststellen.
Leute können ihre eigenen Lebenszyklusregeln einrichten, wenn ihnen diese Dinge wichtig sind.
Ist das Einrichten von clean up uploads = false nicht bereits das?
Lol nein. Discourse unterstützt S3 offiziell. Während ich mich bemüht habe, das Wiki Konfigurieren eines S3-kompatiblen Objektspeichers für Uploads zu starten und ein paar Schalter hinzuzufügen, um die Klonkompatibilität zu erhöhen, haben wir heute keine Pläne, mehr Zeit dafür zu investieren.
Wenn die Community ein paar PRs senden möchte, die die Kompatibilität erhöhen und standardmäßig deaktiviert sind, ist das pr-welcome, aber erwarten Sie nicht, dass es in naher Zukunft offizielle Unterstützung im Kern für jeden Klon gibt.
4 „Gefällt mir“
FWIW, es scheint, dass Digital Ocean keine Probleme hat, Backups zu löschen oder fehlende Assets ablaufen zu lassen.
Bei Anbietern, die defekt sind, würde es lange dauern, bis unnötige Assets ein großes Problem verursachen. Eine ganze Reihe von Backups, einschließlich einer riesigen Datenbank und aller Uploads, aufzubewahren, könnte ein ziemliches Problem darstellen, wenn Sie für den Speicherplatz bezahlen.
1 „Gefällt mir“
Hallo, ich bin Pat Patterson, Chief Technical Evangelist bei Backblaze. Ich bin auf diesen Thread gestoßen, weil ich ein selbst gehostetes Proof-of-Concept-Discourse-Forum habe und heute genau auf dieses Problem gestoßen bin, als ich mein Forum für Backups und Uploads mit Backblaze B2 konfiguriert habe.
Das Setzen von AWS_REQUEST_CHECKSUM_CALCULATION und AWS_RESPONSE_CHECKSUM_CALCULATION auf WHEN_REQUIRED ist eine hilfreiche Problemumgehung für grundlegende Fälle des Hoch- und Herunterladens von Dateien, aber es ist hilfreich zu wissen, dass dies eine Reihe von Szenarien nicht abdeckt, darunter:
- Löschen von Dateien – Discourse verwendet die S3-Operation
DeleteObjects, um mehrere Dateien in einem einzigen API-Aufruf zu löschen, wie es sein sollte. - Hochladen von Dateien in Buckets mit aktivierter Objektsperre.
Das Problem ist, dass eine Prüfsumme (entweder der Content-MD5-Header oder einer der neuen Prüfsummen-Header) für diese Operationen erforderlich ist (und nicht nur unterstützt wird), und dies veranlasst die aktuellen AWS SDKs, den neuen Prüfsummen-Header bereitzustellen. Soweit ich weiß, gibt es keine Möglichkeit, dies zu überschreiben und das SDK dazu zu bringen, Content-MD5 bereitzustellen, wie es früher der Fall war.
Unsere Ingenieure arbeiten daran, all dies zu lösen. In der Zwischenzeit ist die beste Abhilfemaßnahme die Verwendung der Version 1.177.0 oder früher des Gems aws-sdk-s3.
Ich habe versucht, die Versionen des AWS SDK Gems in meiner PoC-Bereitstellung herunterzustufen, indem ich die Gemfile bearbeitet und Folgendes ersetzt habe:
gem "aws-sdk-s3", require: false
gem "aws-sdk-sns", require: false
durch
gem "aws-sdk-core", "~> 3.215.1", require: false
gem "aws-sdk-kms", "~> 1.96.0", require: false
gem "aws-sdk-s3", "~> 1.177.0", require: false
gem "aws-sdk-sns", "~> 1.92.0", require: false
aber mein bundle-fu ist nicht stark, und ich habe meine Bereitstellung nur mit dem Fehler zum Absturz gebracht:
/var/www/discourse/config/initializers/100-sidekiq.rb:69:in `<main>': undefined method `logger=' for module Sidekiq (NoMethodError)
Sidekiq.logger = Logger.new(nil)
^^^^^^^^^
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/engine.rb:689:in `load'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/engine.rb:689:in `block in load_config_initializer'
...
Ich schätze, ich habe einen wichtigen Schritt verpasst.
Ohne unseren Freunden bei DO etwas Böses zu wollen, haben sie dies getan, indem sie ihren Dienst aktualisiert haben, um die neuen Prüfsummen-Header einfach zu ignorieren, anstatt den API-Aufruf aufgrund der nicht unterstützten Prüfsumme abzulehnen.
Ihr Störungsbericht besagt:
Beachten Sie, dass Spaces derzeit keine Datenintegritätsprüfsummen verifiziert, die vom AWS CLI und den AWS SDKs im Rahmen von Upload-Anfragen gesendet werden.
Wir haben entschieden, dass das einfache Akzeptieren und Speichern von Daten, die möglicherweise nicht mit der vom API-Client bereitgestellten Prüfsumme übereinstimmen, schlecht ist.
9 „Gefällt mir“
Danke fürs Posten!
2 „Gefällt mir“
Ja, und die AWS SDK-Maintainer ignorieren uns nur
2 „Gefällt mir“
Ich freue mich zu sehen, dass das B2-Team dieses Problem ebenfalls bemerkt hat.
Hier ist meine temporäre Lösung:
Ich habe alle S3-bezogenen Konfigurationen in app.yml auskommentiert und Discourse erfolgreich neu kompiliert. Dies beeinträchtigt nicht den Zugriff auf zuvor hochgeladene Dateien auf meiner Website, und alle während dieser Zeit hochgeladenen Anhänge werden lokal gespeichert, ohne Probleme zu verursachen.
Übrigens frage ich mich immer noch, warum keine Option hinzugefügt wird, um die Assets auf dem Discourse-Core-Server zu belassen (ich meine, ohne sie auf S3 zu speichern?
???
So funktioniert Discourse standardmäßig, Sie müssen sich explizit dafür entscheiden, Assets an einen Objektspeicherdienst zu versenden.
Ich meine, es könnte gut sein, eine Option zu haben, um Discourse-Kern-Assets (JS, CSS usw.) auf dem lokalen Server zu belassen. Gleichzeitig würden nur vom Benutzer hochgeladene Dateien in S3 gespeichert werden.
1 „Gefällt mir“
Sie können dies tun, indem Sie „use_s3“ nicht aktivieren. Sie sind jedoch klein, ich würde sie einfach hochladen und mir keine Sorgen um den verschwendeten Speicherplatz machen.
1 „Gefällt mir“
Bitte helfen Sie mir, das richtig zu verstehen.
Meinen Sie, DISCOURSE_USE_S3: false in app.yml zu setzen?
Ich möchte dies tun, da sich mein Discourse-Server in Asien befindet und B2 nur Server in den USA hat.
Außerdem hängt das AWS SDK-Problem diesmal mit der Asset-Verwaltung zusammen, richtig?
Wenn ich also Assets auf dem lokalen Server speichere, kann ich das Problem möglicherweise vermeiden (wenn ich die Situation richtig verstehe).
Das Problem hängt mit dem Entfernen von Assets aus S3 zusammen. Wenn Sie nur die Zeile entfernen, die versucht, die ungenutzten Assets zu entfernen, funktioniert es jetzt. Und es klingt so, als würde das Problem bald behoben sein. Das ist die einfachste Lösung. Das ist, was ich empfehle. Das ist meine beste kostenlose Antwort.
1 „Gefällt mir“
Danke, das ist sehr hilfreich für mich!
1 „Gefällt mir“
Das liegt daran, dass in der S3-API-Definition der Vorgang DeleteObjects httpChecksum.requestChecksumRequired auf true gesetzt hat, im Gegensatz zu z.B. PutObject, das es auf false setzt. Das SDK hält sich also an WHEN_REQUIRED, weil die Prüfsumme erforderlich ist.
Alle AWS SDKs werden jetzt aus der API-Definition generiert, mit minimalem zusätzlichem Code, um Ausnahmesituationen abzudecken. Der Code sieht, dass DeleteObjects eine Prüfsumme erfordert, und der Weg dorthin ist jetzt die Verwendung einer der neuen Prüfsummen anstelle von Content-MD5.
Leider hat AWS es nicht für nötig befunden, eine Konfiguration bereitzustellen, mit der man ‘wie früher Content-MD5 verwenden’ kann. Sie berücksichtigen das Ökosystem von Drittanbieter-Objektspeichern bei solchen Änderungen nicht wirklich, da sie es nicht müssen. Das Einzige, was solche Dinge behebt, ist, wenn es versehentlich einen ihrer eigenen Dienste in einer Nischecke trifft.
3 „Gefällt mir“
Das hilft zwar nicht besonders, wenn Sie sich in Asien befinden, aber wir haben auch Rechenzentren in Europa (Amsterdam, Niederlande) und seit Anfang dieses Jahres in Kanada (Toronto).
Ich kann keine Versprechungen machen, aber wir ziehen definitiv einen Standort in Asien in Betracht.
Außerdem spielt es keine große Rolle, wo sich der Ursprungsserver befindet, wenn Sie ein CDN verwenden.
3 „Gefällt mir“
Du hast Recht!
Backblaze unterstützt x-amz-checksum-crc32 nicht, und die neuere Version des AWS SDK von Discourse hat dies möglicherweise standardmäßig aktiviert.
Also bin ich in die App gegangen:
./launcher enter app
und habe die aktuelle Version des AWS SDK deinstalliert:
gem uninstall aws-sdk-s3 aws-sdk-core aws-sdk-kms
und die Version installiert, von der der Backblaze-Mitarbeiter sagte, dass sie funktionieren würde:
gem install aws-sdk-core -v “~> 3.215.1”
gem install aws-sdk-kms -v “~> 1.96.0”
gem install aws-sdk-s3 -v “~> 1.177.0”
Dann habe ich die App neu kompiliert und es hat funktioniert!
2 „Gefällt mir“