Cuando abro /admin/backups.json, solo obtengo un error genérico de Acceso denegado.
Lo que no entiendo es que usar los siguientes comandos en mi instancia EC2 funciona correctamente:
aws s3 ls s3://my-bucket-name
Y cuando entro en el contenedor de Discourse con ./launcher enter app, también puedo ejecutar esto con éxito después de instalar s3cmd:
s3cmd ls s3://my-bucket-name
También puedo subir cosas a mi bucket usando estos comandos, por lo tanto, la política de IAM debería estar bien y no entiendo por qué Discourse no puede acceder al bucket. También intenté agregar “AdministratorAccess” al rol de IAM para descartar cualquier problema de permisos demasiado restrictivo.
Configuración en Discourse:
ubicación de copia de seguridad: S3
bucket de copia de seguridad s3: my-bucket-name
s3 usar perfil iam: true
región s3: la correcta. Comprobado tres veces.
Las opciones s3 restantes se dejan sin tocar → Por lo tanto, en su mayoría vacías/deshabilitadas.
No estoy seguro de que esto tenga algo que ver con tu configuración de S3, suena como un mensaje interno de permisos de Discourse. ¿Puedes cargar /admin/backups como una página (en lugar de añadir .json al final)?
Esta fue una pista increíble. Pude rastrear el error de permisos y ver que Discourse estaba usando un usuario diferente. Ahora, la gran pregunta es por qué y por qué nadie tuvo este error antes.
Tenemos un plugin personalizado para enviar notificaciones push a través de AWS SNS que estaba configurando credenciales globalmente a través de Aws.config.update y, por lo tanto, S3 Backup también parecía haber estado usando las credenciales incorrectas que obviamente no tenían los permisos requeridos.
Ahora arreglaremos nuestro plugin para proporcionar localmente las credenciales/región y admitir roles de IAM de EC2, que es lo que prefiero en este momento
