Ahora, después de restaurar (la clave fue deshabilitar las cargas de S3), todos los enlaces a los archivos adjuntos en las publicaciones están rotos (error 404). He buscado en el foro y no encuentro una solución, y espero que alguien pueda orientarme.
Tengo dos opciones:
¿Puedo arreglar estos enlaces short-url rotos que apuntan a archivos adjuntos incrustados en las publicaciones (todos los enlaces rotos son de archivos adjuntos en publicaciones; las imágenes incrustadas se renderizan bien, otros enlaces internos funcionan bien)?
Por ejemplo, la URL del archivo adjunto en una publicación del foro se muestra como https://XYZ.com/uploads/short-url/phu1HOLvkE8LWpkKYfnMPSWsvHh.zip Esto es lo que veo en los registros cuando hago clic en un enlace de archivo adjunto en una publicación (que conduce a un 404).
Mensaje (se informaron 5 copias)
Error al procesar la respuesta secuestrada correctamente: Errno::ENOENT: No such file or directory @ rb_sysopen - /XXXXX.s3.dualstack.us-east-1.amazonaws.com/optimized/1X/46728e07f9819907d1b18387bf02ea7fc25c7981_2_32x32.ico
Backtrace
/var/www/discourse/app/controllers/static_controller.rb:160:in read' /var/www/discourse/app/controllers/static_controller.rb:160:in block (2 levels) in favicon’
/var/www/discourse/lib/distributed_memoizer.rb:16:in block in memoize' /var/www/discourse/lib/distributed_mutex.rb:33:in block in synchronize’
/var/www/discourse/lib/distributed_mutex.rb:29:in synchronize' /var/www/discourse/lib/distributed_mutex.rb:29:in synchronize’
/var/www/discourse/lib/distributed_mutex.rb:14:in synchronize' /var/www/discourse/lib/distributed_memoizer.rb:12:in memoize’
/var/www/discourse/app/controllers/static_controller.rb:138:in block in favicon' /var/www/discourse/lib/hijack.rb:56:in instance_eval’
Realmente espero que haya una manera de arreglar estos enlaces short-url después de deshabilitar la opción de carga S3 al restaurar el servidor desde una copia de seguridad. Un re-bake de la publicación no lo arregló.
Si por alguna razón esto es un callejón sin salida y no se puede arreglar en masa, ahora tengo miles de archivos adjuntos huérfanos en la nube S3, ¿hay alguna manera de limpiarlos y liberar espacio? ¿Hay alguna manera de que Discourse revise su bucket de cargas S3 y elimine todos los activos huérfanos?
Es posible, o podría haber sido posible, averiguar cómo arreglar esos enlaces, pero averiguar cómo está fuera del alcance de lo que es factible en un foro.
Comprueba si tienes un archivo llamado b13050bdcd2d58924ba6ab3e7608b16bfc3cd1b7.zip en algún lugar de tus subidas y/o en tu bucket de s3. Si es así, entonces debería ser posible, aunque no fácil, arreglar las cosas.
Dado que no incluiste los nombres reales del foro o del bucket, no podemos decirlo aquí.
Entonces todo está ahí, solo necesitas reescribir las publicaciones de alguna manera. No estoy seguro de por qué no funciona, pero los archivos están ahí.
Creo que sí, pero creo que alguien familiarizado con Discourse y Rails tendrá que escribirlo. No conozco ninguna solución existente para tu problema. Hay algunos temas sobre la migración entre buckets de S3 que podrían ofrecer algunas pistas, pero no creo que tu problema en particular se haya resuelto antes.
Bueno, sí, es lo que te recomendé hacer en primer lugar…
Si no vuelves a habilitar las cargas de S3, la función short-url buscará esas cargas localmente, pero están en S3.
Lo intentaré, pero por otro lado, cuando lo habilité, rompió la restauración (ver mi otro tema). Con la ayuda de Jay, tuve que averiguar cómo deshabilitar la carga para poder restaurarlo. ¿Has podido restaurar un servidor con la opción habilitada?