Fehler bei der Verwendung von benutzerdefiniertem S3-Speicher

Unterstützung
1

Da ich ständig durch die Fehlfunktionen des Azure Blob Storage-Plugins frustriert bin, habe ich einen Flexify.IO-Server eingerichtet, um das Azure-Protokoll in das S3-Protokoll zu übersetzen.

Nach der Einrichtung in Discourse funktioniert es jedoch nicht. Der Fehler lautet:

Failed to open TCP connection to support.xxx.xxx.xxx.xxx:443 (getaddrinfo: Name or service not known)

Dabei ist xx.xx.xx.xx die IP-Adresse des S3-Gateways und support der Bucket-Name.

Das Lustige daran ist: Ich habe den Endpunkt mit S3 Browser getestet, und er funktioniert einwandfrei.

Könnte mir also jemand Gütiges sagen, was ich falsch gemacht habe?

Ich vermute, es könnte am Region-Problem liegen, da die vom Endpunkt angezeigte Region eastasia ist (eine gültige Azure-Region), ich aber in der Liste nur die Standard-AWS-Regionen auswählen kann. Dennoch ist es seltsam, denn der Fehler deutet darauf hin, dass die Verbindung zum Endpunkt selbst nicht hergestellt werden konnte und nicht auf eine Regionsinkonsistenz zurückzuführen ist.

2

Ich habe das Gefühl, dass meine Einstellung für s3_bucket falsch ist, da der Bucket-Name an die Endpunkt-URL angehängt wird.

Sollte ich stattdessen das Format bucket/folder verwenden? Was sollte ich jeweils eingeben?

EDIT: Aus dem Quellcode geht hervor, dass dies hart codiert ist. Was ist, wenn mein Speicheranbieter den Bucket-Namen nicht als Präfix verwendet?

3

Sie sollten für Ihren Anwendungsfall die Dokumentation unter Verwendung von Object Storage für Uploads (S3 & Clones) konsultieren. Das ist deutlich flexibler. Sobald Sie es zum Laufen gebracht haben, können Sie es auch in das Wiki aufnehmen!

2 „Gefällt mir“
4

Angesichts folgendem:

ist dies definitiv falsch:

Die Fehlermeldung sagt genau das aus. getaddrinfo: Name or service not known ist ein Fehler bei der DNS-Auflösung; Es wird niemals einen Hostnamen wie „support.303.303.303.303

2 „Gefällt mir“
5

Oh, sorry. support ist der Bucket-Name. Ich sehe, dass S3 einfach den Bucket-Namen dem Domainnamen voranstellt, und das wird von Discourse angenommen.

Ja, das habe ich mir schon gedacht. Also muss ich die Endpunkte in app.yaml hart codieren, richtig?

6

@Falco @schleifer Alles klar, ich habe es ausprobiert, aber leider bekomme ich immer noch exakt denselben Fehler.

Daher glaube ich nicht, dass es funktioniert, selbst wenn es hart in app.yaml kodiert ist. Sie scheinen in denselben Code-Stream zu gehen.

Dies ist meine app.yaml-Einstellung:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: eastasia
  DISCOURSE_S3_ENDPOINT: https://??.??.??.??
  DISCOURSE_S3_ACCESS_KEY_ID: ???
  DISCOURSE_S3_SECRET_ACCESS_KEY: ???
  DISCOURSE_S3_BUCKET: support

Es versucht immer noch, auf support.??.??.??.??:443 zuzugreifen.

Also nehme ich an, dass der Bucket in Discourse muss eine Subdomain bilden?

EDIT 1

Alles klar, ich habe die app.yaml-Einstellungen verworfen und eine Subdomain mit support erstellt, die auf xx.xx.xx.xx zeigt. Wenn ich jetzt etwas hochlade, dauert es eine Weile, und dann kommt eine generische Fehlermeldung zurück:

Aws::S3::Errors::BadRequest

Gibt es eine Möglichkeit, die genaue Fehlermeldung zu erhalten?

7

Hast du versucht, die Seite /logs zu überprüfen?

8

Ja, aber da ist nichts…

9

Welchen genauen Wert verwenden Sie für die Umgebungsvariable des Endpunkts?

10

OK, ich habe eine Einstellung in Flexify.IO gefunden, um den Subdomain-Modus zu aktivieren. Es funktioniert jetzt. :champagne:

Ich werde das Wiki aktualisieren!

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.