Problema al restaurar la copia de seguridad: SiteSetting::Upload.s3_base_url está fallando porque enable_s3_uploads se estableció en la base de datos

General
1

Tengo una copia de seguridad del sitio predeterminado en una instancia multisitio. Las subidas están en S3. He creado con éxito una copia de seguridad con include_s3_uploads_in_backups establecido en true.

Cuando intento restaurar esto desde la línea de comandos en otra instancia multisitio (con s3) o en una instalación estándar nueva, obtengo un error: Algo salió mal al reasignar las subidas.

He añadido un montón de puts a lib/backup_restore/uploads_restorer.rb y he determinado que esto causa el error:

  puts "url base #{SiteSetting::Upload.s3_base_url}"

la siguiente línea, que parece ser la que fallaba antes de mi depuración, es:

       current_s3_base_url = SiteSetting::Upload.enable_s3_uploads ? SiteSetting::Upload.s3_base_url : nil

He intentado comentar varias variables de s3 en discourse.conf para ver si hay algún valor incorrecto en la base de datos que esté causando el problema, pero todas están vacías.

Hmm. Y en la instalación limpia, la copia de seguridad falló y ahora el sitio devuelve

{
errors: [
"El ajuste del sitio `s3_upload_bucket` tiene que estar establecido."
]
}

Así que tal vez alguna otra configuración de s3 esté establecida en la base de datos que me perdí. Sí, enable_s3_uploads está establecido en la base de datos. Estoy confundido acerca de la relación entre use_s3 y enable_s3_uploads…

1 me gusta
2

Así que está confirmado que el problema fue que hace algunos años, cuando intenté configurar S3 por primera vez, establecí enable_s3_uploads en la base de datos, lo que provoca que la restauración no funcione porque intenta cargar en S3 pero no tiene suficiente información. (Suspiro. Pero falla al restaurar la instancia multisitio/s3 porque algunos archivos “no se migran a s3”).

Me pregunto si tendría sentido ocultar todas las configuraciones de carga de S3. Estoy bastante seguro de que no puede salir nada bueno de establecerlas en la UX. Pero puede ser útil establecer las cargas de S3 en la base de datos. . . . tal vez.

La que se restauró en la instalación estándar no muestra las cargas porque está haciendo esto:

      Started GET "/uploads/short-url/puhaSNHeEy1S2knGFQIAZ8lprRy.pdf" for 68.11.35.109 at 2022-01-25 19:48:06 +0000
Processing by UploadsController#show_short as PDF
  Parameters: {"base62"=>"puhaSNHeEy1S2knGFQIAZ8lprRy", "extension"=>"pdf"}
Sent file /var/www/discourse/public/default/original/1X/b2a283b9381b837234e7d4830b.pdf (4.4ms)
Completed 500 Internal Server Error in 130ms (ActiveRecord: 0.0ms | Allocations: 10019)
ActionController::MissingFile (Cannot read file /var/www/discourse/public/default/original/1X/b2a283b9381b837234e7d4830.pdf)

La ruta que está buscando es /var/www/discourse/public/default/original/1X/ en lugar de /var/www/discourse/public/uploads/default/original/1X/

… . .

Y eso se debe a que hice una reasignación intentando arreglar las referencias del bucket S3 y eso rompió las rutas en las URL locales.

Creo que tal vez esto sea demasiado detallado para ser útil para alguien. Aunque sigo pensando que ocultar las variables de carga de S3 de la UX es una buena idea.

3 Me gusta