Estoy intentando configurar Discourse para usar el almacenamiento de objetos compatible con S3 de Scaleway, pero no logro que funcione y no sé dónde está el problema.
He verificado que ambos buckets funcionan con aws-cli y que la configuración de CORS está correctamente establecida siguiendo la documentación oficial de Scaleway, así que creo que el problema no son los buckets en sí.
Estas son mis configuraciones de S3 en Discourse (parte del nombre del bucket censurada):
Cuando abro la pestaña de copias de seguridad, obtengo el mensaje: «Failed to list backups from S3: Aws::S3::Errors::BadRequest».
Y cuando intento subir una imagen, veo esto en el registro: «Job exception: Failed to open TCP connection to [redacted]-discourse-files.s3.fr-par.amazonaws.com:443 (getaddrinfo: Name or service not known)».
Estoy ejecutando la última versión de Discourse: 2.4.0.beta10 (14ae574bc5).
Pude determinar qué actualización del gem aws-sdk-s3 provocó que los buckets de GCP dejaran de funcionar, aunque la solución que eligió mi cliente fue cambiar a un bucket de AWS.
@Falco sí, yo también estoy atascado.
El error con la URL que contiene amazonaws es específicamente para la carga de archivos, no para las copias de seguridad. Para las copias de seguridad solo obtengo el error genérico, así que supongo que ambas están rotas debido al problema de la URL.
¿Se te ocurre algo más?
@pfaffman gracias por el consejo; veré si cambiar la versión de la gem ayuda.
Hola @FroggyC,
En realidad me quedé sin tiempo para depurar esto, así que al final no experimenté con cambiar las versiones de las gemas. Cambié a usar Amazon S3 siguiendo la documentación oficial y todo funcionó de inmediato.
Lo siento, no son mejores noticias…
Podrías intentar preguntar a Scaleway: la responsabilidad de la compatibilidad recae sobre ellos. Si no son totalmente compatibles con AWS S3, deberían solucionarlo.
Estás insinuando que es culpa de ellos, pero hasta ahora has ignorado el comentario de @dino:
Mientras la URL de s3_endpoint (sin modificaciones) no se utilice tal cual, será difícil convencer a Scaleway de que el error está de su lado. Especialmente porque otros clientes S3 pueden conectarse sin problemas.
De acuerdo, demuéstralo. Muéstrame la documentación y los registros de trazas que demuestren que este es el caso. Si puedes proporcionar evidencia real del problema de nuestro lado, lo revisaré.
Entonces, ¿cómo puedo indicarle a Discourse que registre sus intentos de conexión con S3? Una vez que tengamos la certeza de la URL a la que desea conectarse, podré interceptar el tráfico y compartir los resultados.
El motivo por el que la carga/respaldo de S3 no funciona es que la región debe configurarse en fr-par (o nl-ams), lo cual solo puede hacerse evitando la validación de SiteSetting de Discourse:
Por supuesto, esto es una solución temporal; si restableces o modificas esta configuración del sitio a través del Administrador Web, no podrás volver a un estado funcional (a menos que uses nuevamente la consola de Rails).
Supongo que el cliente de AWS/S3 permite establecer explícitamente una cadena de región (a diferencia del estado actual del administrador web).
También es algo engañoso en el caso del valor desplegable “EU (París)” en Discourse, ya que este se refiere al esquema de nombres de AWS eu-west-3 (o algo similar) y no al valor esperado para Scaleway.
Ajá. ¿Necesitamos un campo especial de configuración del sitio “región compatible con S3” @falco? Eso permitiría a los usuarios ingresar regiones completamente arbitrarias (y por tanto, ‘inventadas’ desde la perspectiva de Amazon).
Las personas que usan clones de S3 deben establecer la variable de entorno S3 Endpoint, lo que sobrescribe la región de S3.
Tengo una guía completa explicando esto con el clon de S3 de Digital Ocean, pero estoy esperando a que Digital Ocean corrija un error en su CDN de S3 antes de publicarla.
Si Scaleway está en mejor estado que Digital Ocean, creo que lo probaré y trataré de basar mi guía en él.
