Si recompilaste la aplicación, entonces los cambios realizados en el contenedor se han perdido. Quizás la gente de Backblaze arregló las cosas mientras tú hacías eso.
1 me gusta
Acabo de comentar el S3 y reconstruir. Supongo que me quedaré con el almacenamiento local de ahora en adelante.
1 me gusta
El almacenamiento local funciona bien. Solo la eliminación no funciona.
Gracias por publicar y confirmar que no hay una solución alternativa actual sin degradar los SDK de AWS. Me encontré con problemas con las API de B2 S3 de otro proyecto que utiliza el SDK de AWS de golang, intentando hacer una copia de seguridad de una base de datos VictoriaMetrics.
¿Tiene alguna idea de su equipo de ingeniería sobre cómo o cuándo podrían optar por resolver este problema, o alguna forma de rastrear/obtener actualizaciones sobre una solución alternativa compatible? ¡Estoy tratando de decidir si debería bifurcar y recompilar un proyecto con un cambio de dependencia o simplemente esperar un poco una actualización!
¡Gracias!
El siguiente procedimiento funcionó para mí para degradar las Gems de AWS:
# Para ingresar al contenedor:
./launcher enter app
# Aparentemente necesario para desbloquear el archivo Gemfile.lock:
bundle config set frozen false
# Establecer una versión anterior de la gema sdk-s3:
sed -i 's/gem "aws-sdk-s3", require: false/gem "aws-sdk-s3", "1.177.0", require: false/' Gemfile
# Degradar la gema aws-sdk-s3 para que coincida con la versión ahora en el Gemfile:
bundle update aws-sdk-s3
# También degradar la gema aws-sdk-core:
bundle add aws-sdk-core --version 3.215.
Después de hacer estos cambios, pude guardar con éxito una copia de seguridad en B2. Estoy seguro de que esto es solo una solución temporal que se perderá con la próxima actualización de Discourse, así que espero que @PatPatterson y el equipo de Backblaze puedan proporcionar una solución de compatibilidad más permanente pronto.
2 Me gusta
Esperemos que no necesites hacer esto, pero es posible poner ese comando sed en app.yml para que ocurra automáticamente cuando reconstruyas. Creo que simplemente pegarlo debajo de donde se clonan los plugins sería suficiente. Pero podría ser más complicado de lo que creo.
1 me gusta
Hola AntiMetaman,
He pasado la última semana intentando que las copias de seguridad funcionen con el almacenamiento S3 y finalmente conseguí que la copia de seguridad funcionara con este hilo. Sinceramente, no estoy seguro de qué parte funcionó.
Seguí lo que hiciste con la desinstalación e instalación de gemas, pero ahora obtengo un error al intentar subir imágenes. Mi registro de errores muestra esto:
not entitled /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.219.0/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call’ /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aw
Antes de tener que desechar todo mi servidor y empezar de nuevo (sinceramente, en este punto ni siquiera estoy seguro de querer continuar), ¿sabes cómo puedo revertir la desinstalación e instalación de gemas para poder intentar ver si eso soluciona el problema?
El comportamiento que he observado en nuestra instancia (que utiliza Backblaze para la copia de seguridad) es que las copias de seguridad comenzaron a fallar, sin notificación, en febrero. Justo me di cuenta de ello hoy, ya que verifico nuestras copias de seguridad de vez en cuando. ¿Considerarías esto como un problema bastante serio?
¿Sería posible reducir la versión del AWS-SDK hasta que se pueda encontrar una solución temporal para Backblaze y otros proveedores no-AWS?
Pero lo hice para un sitio que usa Backblaze. Creé una plantilla que puse en /root/aws-revert-template.yml con esto:
# Esta plantilla revierte aws-sdk-s3 a una versión que funciona con backblaze
params:
home: /var/www/discourse
hooks:
after_bundle_exec:
- exec:
cd: $home
cmd:
- bundle config set frozen false
- "sed -i 's/gem \\\"aws-sdk-s3\\\", require: false/gem \\\"aws-sdk-s3\\\", \\\"1.177.0\\\", require: false/' Gemfile"
- bundle update aws-sdk-s3
- bundle add aws-sdk-core --version 3.215
Y luego la agregué a mi app.yml de esta manera:
# IMPORTANTE: ESTABLECE UNA CONTRASEÑA SECRETA en Postgres para el Usuario Discourse
# TODO: cambia SOME_SECRET en esta plantilla
templates:
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Descomenta estas dos líneas si deseas agregar Lets Encrypt (https)
- "templates/web.ssl.template.yml"
- "templates/web.letsencrypt.ssl.template.yml"
- "/root/aws-revert-template.yml"
Y ejecuté una actualización a estable y parece que está funcionando.
También podrías simplemente agregar lo que está en la plantilla a tu app.yml
3 Me gusta
Noté que esta página - S3-Compatible API - ya no enumera las diversas cabeceras checksum-* como no compatibles.
@PatPatterson no estoy seguro de si todavía estás en este hilo o no, pero ¿se agregó soporte oficial para ellos?
2 Me gusta
¿Puede confirmar que su backblaze b2 está funcionando sin la corrección que sugiero?
Gracias por la pronta respuesta, y disculpa, debería haber añadido más detalles. En otro paquete de código abierto (Mastodon) terminamos bloqueando también el gem aws-sdk-core a < 3.216.0 para manejar este problema exacto para las personas que usan Backblaze (y sospecho que otros, pero ahí es donde surgió).
Pero luego, en las últimas semanas, noté:
- Que la página en el sitio de Backblaze ya no enumera esas cabeceras como no admitidas.
- Una versión reciente del gem de AWS menciona la corrección del problema donde
when_requiredno se respetaba completamente anteriormente.
En investigaciones anteriores, había visto este hilo con más o menos el mismo problema y estaba tratando de entender si ahora podemos actualizar el gem de forma segura si Backblaze ha agregado ese soporte, y/o si el gem ahora funciona completamente para solucionar el problema.
2 Me gusta
Hola, sí, Backblaze B2 agregó soporte oficial para las cabeceras de checksum a principios de este año.
2 Me gusta
¡Excelente! Gracias por confirmar.