Datei im Speicher unter der URL: //s3-bucket/prefix/file.jpeg nicht gefunden

Installation
1

Ich bin gerade dabei, das offizielle Docker-Image auf AWS ECS einzurichten.
Während der Ausführung auf EC2 funktioniert das Docker-Image einwandfrei.

Nach dem Start auf ECS mit der gleichen Konfiguration enden die Avatar-Bilder jedoch beschädigt.

Zugehörige Fehler:

Could not find file in the store located at url: //x-dev-xx-xxx-x.s3.dualstack.eu-central-1.amazonaws.com/original/1X/761c151e2d0ebedff3330dc6ec7a27050fef43f9.jpeg

und

Failed to process hijacked response correctly : FinalDestination::SSRFDetector::LookupFailedError : FinalDestination: lookup failed

Die Datei befindet sich im Bucket und die Zugriffsrechte sind die gleichen wie für die EC2-Instanz.

Kann mir bitte jemand sagen, wo ich tiefer graben und die Ursache finden kann?

Danke

2

Hast du ein Image mit Launcher erstellt und das Image in ein Repository gepusht? Und startest du es mit derselben Umgebung wie der Launcher?

3

Ja. Ich verwende die Umgebungsvariablen, die der Befehl run-cmd generiert. Ich konnte bisher keinen Fehler feststellen.
Leider konnte ich bisher keine ECS-Beispiele für Discourse finden.

4

Sie sind auf dem richtigen Weg, aber es ist schwierig, den Aufsteller zu migrieren und die Assets hochzuladen. Ich bin mir nicht sicher, was das Problem sein könnte.

5

Ich habe die Grundursache gefunden. Aufgrund meiner Einrichtung des Discourse AI-Plugins hatte ich eine private Zone zur VPC hinzugefügt, um die verschiedenen Dienste intern in der VPC verfügbar zu machen.

Wenn Discourse auf einer EC2-Instanz in einem Docker-Container ausgeführt wird, erhält der Container einen Hostnamen wie 12-34-56-78-app. Wenn er jedoch als ECS-Task ausgeführt wird, können Sie den Hostnamen im awsvpc-Modus nicht festlegen, und Sie können auch keine Suchdomäne für DNS konfigurieren. Dies führt dazu, dass die DNS-Auflösung auf ECS anders ist. In meinem Fall wurde eine Suchdomäne wie xxxx.internal hinzugefügt.

Nachdem ich mich umgesehen hatte, fand ich mit tcpdump, dass Discourse versucht, seinen eigenen FQDN als Teil der SSRF-Prüfungen aufzulösen. Wenn dies fehlschlägt, schlägt die Prüfung fehl. Als nachfolgender Fehler schlägt der Aufruf an S3 mit der fehlerhaften Fehlermeldung oben fehl.

Die Korrektur in meinem Fall bestand darin, den FQDN-Eintrag, der ein Alias für meine Cloudfront-Distribution ist, zu meiner privaten DNS-Zone hinzuzufügen.

2 „Gefällt mir“
6

Wow. Das ist eine gute Fehlersuche! Und deshalb ist dies eine nicht unterstützte Installation! Es gibt kaum eine Möglichkeit, dass so viel von all dem erraten werden könnte!

1 „Gefällt mir“
7

Am Ende ist es wie immer: Wenn es nicht funktioniert, ist es immer DNS :joy:

8

Hallo @nodomain,
Ich habe genau denselben Fehler wie in deinem Beitrag unten erlebt. Die Anfrage an den Benutzeravatar, z. B. https://example.com/user_avatar/example.com/myself/96/215_2.png, wird mit 500 beantwortet. In meinem Fall ist der Domainname example.com nicht im öffentlichen DNS eingerichtet. In der Testphase habe ich example.com in meiner lokalen Host-Datei gespooft. Wird dieses Problem nicht auftreten, wenn der Domainname example.com im öffentlichen DNS eingerichtet ist?