Quando apro /admin/backups.json ottengo solo un errore generico Accesso negato.
Quello che non capisco è che l’utilizzo dei seguenti comandi nella mia istanza EC2 funziona correttamente:
aws s3 ls s3://my-bucket-name
e quando entro nel container di discourse con ./launcher enter app posso eseguirlo anche con successo dopo aver installato s3cmd:
s3cmd ls s3://my-bucket-name
Posso anche caricare elementi nel mio bucket usando questi comandi, quindi la policy IAM dovrebbe andare bene e non riesco a capire perché Discourse non possa accedere al bucket. Ho anche provato ad aggiungere “AdministratorAccess” al ruolo IAM per escludere eventuali problemi di permessi troppo restrittivi.
Configurazione in Discourse:
backup location: S3
s3 backup bucket: my-bucket-name
s3 use iam profile: true
s3 region: the correct one. tripple checked.
Le restanti opzioni s3 sono lasciate intatte → Pertanto per lo più vuote/disabilitate.
Non sono sicuro che questo abbia a che fare con le tue impostazioni S3, sembra un messaggio interno sulle autorizzazioni di Discourse. Riesci a caricare /admin/backups come pagina (invece di aggiungere .json alla fine)?
Questo è stato un ottimo suggerimento. Sono riuscito a risalire all’errore di autorizzazione e ho potuto vedere che Discourse stava utilizzando un utente diverso. Ora arriviamo al grande perché e perché nessuno ha mai avuto questo errore prima.
Abbiamo un plugin personalizzato per l’invio di notifiche push tramite AWS SNS che impostava le credenziali tramite Aws.config.update globalmente e quindi anche S3 Backup sembrava utilizzare le credenziali errate che ovviamente non avevano le autorizzazioni richieste.
Ora correggeremo il nostro plugin per fornire localmente le credenziali/regione e supportare i ruoli IAM di EC2 che preferisco a questo punto
