Imágenes rotas y sus URLs de S3

[masterakay (Aekansh Dixit)]

@schleifer Hola, ¿podemos recibir orientación después de esto, por favor?

[schleifer (Andrew Schleifer)]

@rithvikvibhu

Las nuevas subidas (que funcionan correctamente) se almacenan en /original/2X/*/.jpg

Bien, eso es algo con lo que podemos trabajar. Primero, mueve todos los archivos de /default/* a /original/1X/*.

@rithvikvibhu

Ya parece que /default/ tiene todas las imágenes.

Eso lo sabemos nosotros, pero la base de datos no. El siguiente paso ajustará la ruta de todas las subidas en la BD. Pero antes de cambiar cualquier otra cosa, hagamos una verificación de coherencia.

Inicia una consola de la base de datos:

cd /var/discourse
./launcher enter
rails db

Ejecuta esta consulta para echar un vistazo:

select id,url from uploads where id > 0 and url not like '//PREFIX/original/%'

Deberás reemplazar PREFIX por BUCKET + ‘.s3.dualstack.’ + REGION + ‘.amazonaws.com’, lo que daría algo como //pesioforum.s3.dualstack.us-west-2.amazonaws.com/original/%.

Eso debería mostrar (0 filas). Si no es así, entonces tendremos pasos adicionales.

[rithvikvibhu]

Hay 7 subidas para tu consulta y ninguna de ellas es de S3.
Así que todos los enlaces de S3 apuntan solo al original, ¿verdad? Las 7 subidas son anteriores a que comenzáramos a usar S3 para las subidas (octubre de 2018).

De los enlaces de S3 (2614),
2368 usan //pesioforum.s3.dualstack.ap-south-1.amazonaws.com
246 usan //pesioforum.s3.ap-south-1.amazonaws.com

Ambos enlaces funcionan, solo lo menciono aquí por si afecta a cualquier expresión regular que podamos usar.

[masterakay (Aekansh Dixit)]

@schleifer Por favor, ayúdanos a terminar esto.

[riking (Kane York)]

OK, así que deberías tener libertad para mover archivos de /default/ a /original/1X.

[schleifer (Andrew Schleifer)]

@rithvikvibhu

Las 7 subidas son anteriores al inicio del uso de S3 para subidas (octubre de 2018).

Puedes migrar esas subidas a S3 ejecutando rake s3:upload_assets

@rithvikvibhu

246 usan //pesioforum.s3.ap-south-1.amazonaws.com

El punto final dualstack funciona para IPv6 e IPv4. El otro es solo para IPv4.

Hay un script en la imagen para reasignar cadenas en la base de datos. Antes de ejecutarlo, SIEMPRE REALIZA UNA COPIA DE SEGURIDAD a través de /admin/backups (Menú hamburguesa → Admin → Copias de seguridad).

Esto debería solucionar los 246:

discourse remap '//pesioforum.s3.ap-south-1.amazonaws.com/original/' '//pesioforum.s3.dualstack.ap-south-1.amazonaws.com/original/'

Después de mover todo desde /default/ a /original/1X/, podemos reasignar esos archivos en la BD. Pero antes de eso, debemos asegurarnos de que todo lo que está en /original/2X realmente exista.

¿Esta consulta devuelve el mismo número de filas que el conteo de objetos reales bajo esa ruta en el bucket?:
select url from uploads where url like '//pesioforum.s3.dualstack.us-west-2.amazonaws.com/original/2X/%'

[rithvikvibhu]

Hola @schleifer

Puedes migrar esos archivos a S3 ejecutando rake s3:upload_assets

Ejecuté esto y se subieron los activos (js, css, etc.) del sitio web. Los 7 archivos no se subieron.
Encontré rake uploads:migrate_to_s3, pero quería confirmar que era la tarea correcta para esto.

Hay un script en la imagen para reasignar cadenas en la base de datos

Esto funcionó bien y ya no hay enlaces antiguos no duales en la tabla uploads.

Pero antes de eso, debemos asegurarnos de que todo en /original/2X esté realmente allí.

Lamentablemente, no es así. Hay 521 archivos en el bucket de S3, pero 2186 registros en la tabla uploads.
Probé varios archivos que no están en /original/2X/ como se requiere y todos están en /default/.

Ejemplo: De la tabla uploads,
https://pesioforum.s3.dualstack.ap-south-1.amazonaws.com/original/2X/8/806a660beb158e9f06d07ffcd2370b389bbd250b.jpeg no existe, pero el mismo archivo está en
https://pesioforum.s3.dualstack.ap-south-1.amazonaws.com/default/806a660beb158e9f06d07ffcd2370b389bbd250b.jpeg

En este punto, como un parche único, estamos de acuerdo con simplemente mover todos los archivos de /original/2X/{}/ a /original/1X/ y actualizar las publicaciones, etc., con los nuevos enlaces.
Las nuevas subas se están colocando correctamente en 2X de todos modos.

[schleifer (Andrew Schleifer)]

@rithvikvibhu

Encontré rake uploads:migrate_to_s3, pero quería confirmar que era la tarea correcta para esto.

¡Ajá, sí, esa era la que realmente pretendía! Debería subir esos últimos siete.

@rithvikvibhu

En este punto, como un truco de una sola vez, nos conformamos con mover todos los archivos de /original/2X/{}/ a /original/1X/ y actualizar las publicaciones, etc., con los nuevos enlaces.
Las nuevas subidas se están colocando correctamente en 2X de todos modos.

Efectivamente, esa es la mejor opción en este momento. Copia todos los archivos fuera de su subprefijo /2X/ y mueve todo a /1X/.

Una vez que todo esté en su lugar, aquí tienes un comando que debería actualizar todas las entradas de la base de datos:

discourse remap --regex "//pesioforum\.doublestack\.s3\.ap-south-1\.amazonaws\.com/original/[1234]X/([0-9a-f]/){0,}" "//pesioforum.doublestack.s3.ap-south-1.amazonaws.com/original/1X/"

(Recuerda la advertencia anterior sobre hacer una copia de seguridad.)

Después de eso, algunas publicaciones pueden necesitar que se reconstruya la versión HTML a través del menú de la llave inglesa. Si hay más de unas pocas, puedes reconstruir todas con rake posts:rebake.

[rithvikvibhu]

@schleifer ¡eso funcionó! Con una expresión regular modificada y una regeneración de todas las publicaciones, la mayoría de las imágenes y archivos subidos funcionan correctamente.
Hay algunas imágenes (que no son publicaciones) que aún enlazan a /optimized/, pero podemos corregir esto manualmente. Por ejemplo: logotipos en diferentes temas, etc.

¡Muchas gracias por tu ayuda!

[41821]

Hola, hemos encontrado un problema similar al descrito en nuestro entorno también, y esperábamos contar con ayuda para resolverlo.

Nuestro problema es similar al de este caso en muchos aspectos:

1. Tenemos el mismo valor listado bajo s3 upload bucket y s3 backup bucket.
2. Encontramos este problema al actualizar Discourse:

Versión anterior: v2.3.0.beta3
Nueva versión: v2.5.0.beta6

3. Accedí mediante exec al contenedor de Discourse y consulté la base de datos:

SELECT id,url FROM uploads where id > 0 and url not like '//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/%';

 id |                                                url
----+----------------------------------------------------------------------------------------------------
  1 | /uploads/default/original/1X/eb17xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxc33.png
  2 | /uploads/default/original/1X/b87fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxv21.png
 78 | //acme-forum.s3-us-west-2.amazonaws.com/original/1X/1205xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxv045.png
(3 filas)

4. Accedí mediante exec al contenedor de Discourse y consulté la base de datos:

select url from uploads where url like '//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/%';

 //acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/6/2/6267xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxf607c.jpeg
(7953 filas)

5. Verifiqué cuántos elementos hay en ./original/3X/; la respuesta fue 251 elementos.

Preguntas:

1. Estamos usando dualstack y no quiero volver a mapear nuestras URL para dejar de usarlo.
2. Nuestra estructura de carpetas es diferente; tenemos cosas como 3X/X/Y (por ejemplo: 3X/7/a), así que, ¿cómo puedo mover todo desde default a 3X/*, si aún así no se mapeará correctamente?

Mi idea actual es escribir un script que utilice la salida del Paso 4 para determinar dónde mover el archivo de vuelta a la carpeta ./original/3X/X/Y.

El único problema es que, cuando lo hice, dualstack aún no había alojado este archivo. Lo que quiero decir es que, al reemplazar el archivo en original/3X/X/Y, puedo verlo al acceder a:
Roto https://acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/6/b/6b6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxa001.png

Funciona https://acme-forum.s3-us-west-2.amazonaws.com/original/3X/6/b/6b6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxa001.png

Actualización: Resulta que el endpoint dualstack nunca estuvo roto como pensé; cometí un error al copiar originalmente el archivo de imagen a ./original/3X/6/b, donde olvidé permitir la lectura para todos.

Entonces, mi pregunta es:
¿Sería una opción viable que yo mueva los archivos de imagen desde ./default de vuelta a ./original/3X/x/y y, en ese caso, no modifique la base de datos en absoluto?

[41821]

Bien, tengo una actualización.

Parece que puedo predecir dónde deberían ir las imágenes ./original, pero no sé cómo solucionar el problema de las imágenes ./optimized.

En nuestro foro, si navegas a una de nuestras publicaciones, intenta mostrar la imagen ./optimized.

¿Hay alguna forma de saber qué imagen es optimized?

Mi idea es que las imágenes optimizadas terminan con _2_10x10.png; ¿sería una suposición razonable? Si es así, ¿sería una solución viable usar un script para copiar todo lo que tenga algo como _2_10x10.png a la carpeta optimized y todo lo que no lo tenga, directamente a la carpeta ./original?

Ejemplo:

GET https://acme-forum.s3.dualstack.us-west-2.amazonaws.com/optimized/3X/c/c/ccaxxxxxxxxxxxxxxxxxxxxxxxxxxxx85_2_690x268.png
[HTTP/1.1 403 Forbidden 0ms]

¡Gracias!

[rithvikvibhu]

@41821 Si las URLs en la tabla uploads son correctas y funcionan, pero las publicaciones aún intentan cargar las imágenes optimizadas, entonces limpiar la tabla optimized_images y rehacer todas las publicaciones debería solucionarlo: discourse=> delete from optimized_images;

[41821]

Muchas gracias por los comentarios. En realidad, terminé resolviéndolo (si es que se puede llamar así) escribiendo un script para mover la imagen desde el directorio /default de nuevo a /optimized basándome en el nombre del archivo. Esto parece haber funcionado y ya no tengo ningún problema.

Si esto vuelve a ocurrir en el futuro, haré lo que sugeriste: eliminaré todo de optimized_images y volveré a generar las imágenes.

¡Gracias!