Los mantenedores del SDK de AWS rompieron la compatibilidad. Depende de su proveedor de clones de S3 ponerse al día e implementar una mejor compatibilidad para que pueda eliminar las soluciones alternativas.
4 Me gusta
Sólo para aclarar, esto solo afecta a los archivos JS/map/CSS en assets, y no afectará las subidas, ¿verdad?
Me refiero, ¿impactará en la eliminación de archivos huérfanos?
Por cierto, supongo que este problema podría afectar la actualización de Discourse desde el panel de administración.
En realidad, la actualización a través del panel de administración falló para mí, por eso realicé una reconstrucción.
Sí, es solo para los assets.
¿Esta tarea de rake? No.
Pero el cambio completo del SDK de AWS también podría haber roto eso para personas con clones no compatibles.
1 me gusta
Estoy bastante seguro de que eso es incorrecto. Así que probablemente también necesitemos desactivar clean up uploads. Eso solo causará errores cuando estés ejecutando, sin embargo. No hará que no puedas reconstruir.
Suena probable. ¿Quizás necesitamos alguna configuración de “skip_s3_delete” para resolver esto hasta que los otros proveedores se pongan al día? ¿Y tal vez establecerla automáticamente para los proveedores que sabemos que están rotos?
¿Es esa tarea de rake la única forma en que se eliminan los activos caducados?
Solo me pregunto, ¿por qué no añadir una opción para mantener los activos en el servidor principal de Discourse (es decir, sin almacenarlos en S3)?
Mientras no afecte a las cargas o al proceso de limpieza de archivos huérfanos, parece una solución viable.
Sí. No es como si esto fuera un gran problema. Los sitios normales que se actualizan de vez en cuando no verán mucha diferencia.
Las personas pueden configurar sus propias reglas de ciclo de vida si les importa este tipo de cosas.
¿No es eso ya clean up uploads = false?
Jaja, no. Discourse admite oficialmente S3. Si bien me esforcé por iniciar la wiki Configurar un proveedor de almacenamiento de objetos compatible con S3 para cargas y agregar algunos interruptores para aumentar la compatibilidad con clones, no tenemos ningún plan de invertir más tiempo en eso hoy.
Si la comunidad quiere enviar un par de PR que aumenten la compatibilidad y estén desactivados por defecto, son pr-welcome, pero no esperen ver soporte oficial en el núcleo para cada clon en el corto plazo.
4 Me gusta
Para que conste, parece que Digital Ocean no tiene problemas para eliminar copias de seguridad ni para caducar activos faltantes.
Para los proveedores que están rotos, pasaría mucho tiempo antes de que los activos innecesarios causaran muchos problemas. Conservar un montón de copias de seguridad, incluida una base de datos enorme y todas las cargas, podría ser un gran problema si pagas por el almacenamiento.
1 me gusta
Hola, soy Pat Patterson, Evangelista Técnico Jefe en Backblaze; llegué a este hilo porque tengo un foro de prueba de concepto de Discourse autoalojado y me encontré con este problema exacto hoy mientras configuraba mi foro para usar Backblaze B2 para copias de seguridad y cargas.
Establecer AWS_REQUEST_CHECKSUM_CALCULATION y AWS_RESPONSE_CHECKSUM_CALCULATION en WHEN_REQUIRED es una solución útil para casos básicos de carga y descarga de archivos, pero es útil saber que no cubre una serie de escenarios, que incluyen:
- Eliminar archivos: Discourse está utilizando la operación S3
DeleteObjectspara eliminar varios archivos en una sola llamada API, como debe ser. - Cargar archivos en buckets con el bloqueo de objetos habilitado.
El problema es que una suma de verificación (ya sea la cabecera Content-MD5 o una de las nuevas cabeceras de suma de verificación) es requerida (en lugar de solo admitida) para estas operaciones, y esto hace que los SDKs de AWS actuales proporcionen la nueva cabecera de suma de verificación. Por lo que sé, no hay forma de anular esto y hacer que el SDK proporcione Content-MD5 como solía hacerlo.
Nuestros ingenieros están trabajando para resolver todo esto; mientras tanto, la mejor mitigación es usar la versión 1.177.0 o anterior de la gema aws-sdk-s3.
Intenté degradar las versiones de la gema AWS SDK en mi implementación de PoC editando el Gemfile y reemplazando
gem "aws-sdk-s3", require: false
gem "aws-sdk-sns", require: false
con
gem "aws-sdk-core", "~> 3.215.1", require: false
gem "aws-sdk-kms", "~> 1.96.0", require: false
gem "aws-sdk-s3", "~> 1.177.0", require: false
gem "aws-sdk-sns", "~> 1.92.0", require: false
pero mi bundle-fu no es fuerte, y solo logré romper mi implementación con el error:
/var/www/discourse/config/initializers/100-sidekiq.rb:69:in `<main>': undefined method `logger=' for module Sidekiq (NoMethodError)
Sidekiq.logger = Logger.new(nil)
^^^^^^^^^
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/engine.rb:689:in `load'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/engine.rb:689:in `block in load_config_initializer'
...
Supongo que me perdí algún paso vital.
Sin querer arrojar sombra sobre nuestros amigos de DO, lo hicieron actualizando su servicio para simplemente ignorar las nuevas cabeceras de suma de verificación en lugar de rechazar la llamada API debido a la suma de verificación no admitida.
Su informe de incidente dice:
Tenga en cuenta que Spaces no verifica actualmente las sumas de verificación de integridad de datos enviadas por AWS CLI y AWS SDKs como parte de las solicitudes de carga.
Decidimos que simplemente aceptar y almacenar datos que podrían no coincidir con la suma de verificación que proporcionó el cliente de la API era algo malo.
9 Me gusta
¡Gracias por publicar!
2 Me gusta
Sí, y los mantenedores del SDK de AWS solo nos dan la espalda en esto
2 Me gusta
Me alegra ver que el equipo B2 también ha notado este problema.
Aquí está mi solución temporal:
Comenté todas las configuraciones relacionadas con S3 en app.yml y reconstruí Discourse con éxito. Esto no afecta el acceso a los archivos subidos previamente en mi sitio, y cualquier archivo adjunto subido durante este período se almacenará localmente sin causar ningún problema.
Por cierto, todavía me pregunto, ¿por qué no añadir una opción para mantener los activos en el servidor principal de Discourse (es decir, sin almacenarlos en S3)?
???
Así es como funciona Discourse de fábrica, necesitas optar explícitamente por enviar activos a un servicio de almacenamiento de objetos.
Quiero decir, podría ser bueno tener una opción para mantener los recursos principales de Discourse (JS, CSS, etc.) en el servidor local. Al mismo tiempo, solo los archivos subidos por el usuario se almacenarían en S3.
1 me gusta
Puedes hacerlo no habilitando “use_s3”, pero son pequeños, yo los subiría y no me preocuparía por el espacio desperdiciado.
1 me gusta
Por favor, ayúdame a entender correctamente.
¿Quieres decir que configure DISCOURSE_USE_S3: false en app.yml?
Me gustaría hacer esto porque mi servidor de Discourse está en Asia y B2 solo tiene servidores en los Estados Unidos.
Además, esta vez, el problema del SDK de AWS está relacionado con la gestión de activos, ¿verdad?
Entonces, si almaceno los activos en el servidor local, podría evitar el problema (si entiendo la situación correctamente).
El problema está relacionado con la eliminación de activos de S3. Si solo elimina la línea que intenta eliminar los activos no utilizados, funcionará ahora. Y parece que pronto se resolverá el problema. Esta es la solución más fácil. Es lo que recomiendo. Esa es mi mejor respuesta gratuita.
1 me gusta
¡Gracias, eso es muy útil para mí!
1 me gusta
Esto se debe a que, en la definición de la API de S3, la operación DeleteObjects tiene httpChecksum.requestChecksumRequired establecido en true, en contraste con, por ejemplo, PutObject, que lo establece en false. Por lo tanto, el SDK está cumpliendo con WHEN_REQUIRED, porque la suma de verificación es requerida.
Todos los SDK de AWS ahora se generan a partir de la definición de la API, con un código adicional mínimo para cubrir situaciones límite. El código ve que DeleteObjects requiere una suma de verificación, y la forma de hacerlo ahora es usar una de las nuevas sumas de verificación, en lugar de Content-MD5.
Desafortunadamente, AWS no consideró oportuno proporcionar una configuración de ‘usar Content-MD5 como antes’. No suelen considerar el ecosistema de almacenamiento de objetos de terceros cuando realizan este tipo de cambios, ya que realmente no lo necesitan. La única vez que cosas como esta se arreglan es cuando accidentalmente arruinan uno de sus propios servicios en algún caso extremo.
3 Me gusta
No es que ayude particularmente si estás en Asia, pero, para que conste, también tenemos centros de datos en Europa (Ámsterdam, Países Bajos) y, desde principios de este año, en Canadá (Toronto).
No puedo hacer promesas, pero definitivamente estamos considerando una ubicación en Asia.
Además, si usas una CDN, no importa demasiado dónde esté el servidor de origen.
3 Me gusta
¡Tienes razón!
Backblaze no admite x-amz-checksum-crc32, y la versión más reciente del SDK de AWS de Discourse puede haber habilitado esto por defecto.
Así que entré en la aplicación:
> ./launcher enter app
y desinstalé la versión actual del SDK de AWS:
> gem uninstall aws-sdk-s3 aws-sdk-core aws-sdk-kms
e instalé la que el chico de Backblaze dijo que funcionaría:
> gem install aws-sdk-core -v "~> 3.215.1"
> gem install aws-sdk-kms -v "~> 1.96.0"
> gem install aws-sdk-s3 -v "~> 1.177.0"
¡Luego reconstruí la aplicación y funcionó!
2 Me gusta