Impossibile trovare il file nello store all'indirizzo: //s3-bucket/prefix/file.jpeg

Installazione
1

Sto attualmente configurando l’immagine Docker ufficiale su AWS ECS.
Mentre è in esecuzione su EC2, l’immagine Docker funziona perfettamente.

Tuttavia, dopo averla avviata su ECS con la stessa configurazione, finisco con immagini avatar corrotte.

Errori correlati:

Impossibile trovare il file nello store situato all'URL: //x-dev-xx-xxx-x.s3.dualstack.eu-central-1.amazonaws.com/original/1X/761c151e2d0ebedff3330dc6ec7a27050fef43f9.jpeg

e

Impossibile elaborare correttamente la risposta dirottata: FinalDestination::SSRFDetector::LookupFailedError: FinalDestination: ricerca fallita

Il file è nel bucket e i diritti di accesso sono gli stessi dell’istanza EC2.

Qualcuno può indicarmi dove posso approfondire e trovare la causa principale?

Grazie

2

Hai creato un’immagine con il launcher e l’hai inviata a un repository? E la stai avviando con lo stesso ambiente che usa il launcher?

3

Sì. Utilizzo le variabili d’ambiente che il comando run-cmd genera. Finora non sono riuscito a individuare alcun errore.
Purtroppo finora non sono riuscito a trovare esempi di ECS per Discourse.

4

Sei sulla strada giusta, ma è complicato migrare lo standee e caricare gli asset. Non sono sicuro di quale possa essere il problema.

5

Ho trovato la causa principale. A causa della mia configurazione del plugin Discourse AI, avevo aggiunto una zona privata alla VPC per rendere disponibili i diversi servizi internamente alla VPC.

Quando si esegue Discourse su un’istanza EC2 in un container Docker, il container ottiene un nome host come 12-34-56-78-app. Tuttavia, quando si esegue come attività ECS, non è possibile impostare il nome host quando si è in modalità awsvpc, né è possibile configurare il dominio di ricerca DNS. Ciò porta al fatto che la risoluzione DNS è diversa su ECS, nel mio caso aggiungendo un dominio di ricerca come xxxx.internal.

Dopo aver scavato, ho scoperto usando tcpdump che Discourse tenta di risolvere il proprio FQDN come parte dei controlli SSRF. Se questo fallisce, il controllo fallisce. Come errore successivo, la chiamata a S3 fallisce con il messaggio di errore errato sopra.

La soluzione nel mio caso è stata aggiungere il record FQDN, che è un alias per la mia distribuzione Cloudfront, alla mia zona DNS privata.

2 Mi Piace
6

Wow. Questo è un ottimo debug! Ed è per questo che si tratta di un’installazione non supportata! Non c’è molto che si possa indovinare da tutto questo!

1 Mi Piace
7

Alla fine è come al solito: se non funziona, è sempre colpa del DNS :joy:

8

Ciao @nodomain,
Ho riscontrato lo stesso errore del tuo post qui sotto. La richiesta all’avatar dell’utente, ad esempio https://example.com/user_avatar/example.com/myself/96/215_2.png, risponde con 500. Nel mio caso, il nome di dominio example.com non è configurato nel DNS pubblico; nella fase di test, ho falsificato example.com nel mio file host localmente. Questo problema non si presenterà quando il nome di dominio example.com sarà configurato nel DNS pubblico?