Iconos y logos "rotos" luego de actualizar

Hola. Hemos actualizado la solucion de expedientes en un servidor de produccion desde la version 1.7.5 a la version 1.8.3, y si bien el funcionamiento de las operaciones esta intacto, notamos que los iconos de avatar de usuario, y los iconos de los sistemas (aplicaciones cargadas en arai usuarios), aparecen como imagenes rotas o inaccesibles en el navegador al acceder al portal huarpe y a arai usuarios.
Hemos probado ir a la seccion de aplicaciones en arai usuarios, cargando nuevamente el logo de sistema para huarpe y arai usuarios y guardando los cambios, pero continuan rotos.

A alguien mas le ha pasado?

Buen día, han reportado esta situación desde algunas instituciones. Normalmente el inconveniente se produce porque no se ejecuta correctamente el script que cambia los permisos, sobre todo si utilizan NFS.
Dejo unos pasos que ayudaron a resolver el inconveniente en estos casos:

  1. si utilizan NFS cambiar la sección “volumes” en prod/arai/util/usuarios_cambia_permisos.yml y adaptarla según tengan configurado en usuarios.yml
volumes:
  usuarios_assets:
# usuarios_assets: # ejemplo con nfs
#   driver: local
#   driver_opts:
#     type: nfs
#     o: nfsvers=4,addr=170.210.46.29,rw
#     device: ":/var/nfsroot/usuarios"
  1. cambiar permisos del volumen “usuarios_assets” y ver logs con este comando:

docker stack deploy --with-registry-auth --compose-file prod/arai/util/usuarios_cambia_permisos.yml usuarios_cambia_permisos &&
docker service logs usuarios_cambia_permisos_idm -f

  1. cuando termine, eliminar el stack

docker stack rm usuarios_cambia_permisos

  1. en caso de utilizar varios nodos, el volumen usuarios_usuarios_assets debe estar referenciando al volumen compartido y no al local

Saludos!

Gracias por esa informacion. En nuestro caso, no utilizamos NFS. Tenemos todo en un solo servidor. Estuvimos volviendo a hacer los pasos de la guia Exportar → Cambiar Permisos → Actualizar la base de datos.
En el paso de la exportacion, al ejecutar el docker usuarios_export_idm y ver el progreso con los logs, nos indica al principio:

cat: can’t open ‘/run/secrets/usuarios_conexion_personas’: No such file or directory

Y luego de eso, el proceso ocurre normalmente y con exito segun los logs. Pero me llama la atencion eso del principio ya que ese secret lo tenemos creado.

Aun asi, suponiendo que mas alla de eso, se hizo correctamente el proceso de exportacion procedemos al docker de cambio de permisos. Pero al ejecutarlo junto con el comando para ver los logs, dichos logs no muestran nada a lo largo del tiempo. Como si en realidad por algun fallo no se esta ejecutando el cambio de los permisos, y queda ahi, sin mostrar los logs indefinidamente.

Hola!
el log debería mostrar algo asi:

Creating service usuarios_cambia_permisos_idm
usuarios_cambia_permisos_idm.1.r2Wrz2Z3one3@eei-dev    | changed ownership of '/tmp/config_exportada/.gitkeep' to 222:1011
usuarios_cambia_permisos_idm.1.r2Wrz2Z3one3@eei-dev    | changed ownership of '/tmp/config_exportada/arai_usuarios-v3.2.4/instalacion/openssl.ini' to 222:0
usuarios_cambia_permisos_idm.1.r2Wrz2Z3one3@eei-dev    | changed ownership of '/tmp/config_exportada/arai_usuarios-v3.2.4/instalacion/VERSION' to 222:0
usuarios_cambia_permisos_idm.1.r2Wrz2Z3one3@eei-dev    | changed ownership of '/tmp/config_exportada/arai_usuarios-v3.2.4/instalacion/openid.ini' to 222:0
usuarios_cambia_permisos_idm.1.r2Wrz2Z3one3@eei-dev    | changed ownership of '/tmp/config_exportada/arai_usuarios-v3.2.4/instalacion/bases.ini' to 222:0
usuarios_cambia_permisos_idm.1.r2Wrz2Z3one3@eei-dev    | changed ownership of '/tmp/config_exportada/arai_usuarios-v3.2.4/instalacion/web_server.ini' to 222:0
...

en el volumen se vería algo como esto:

ls -l /var/lib/docker/volumes/usuarios_usuarios_assets/_data/resources/img/aplicaciones_iconos/
total 292
-rw-r--r-- 1 222 systemd-journal   1492 sep 27  2023 _5b118fc38007d474057f03490e6fe299ed3a51e40f.png
-rw-r--r-- 1 222 systemd-journal  32712 sep 27  2023 _814f1d1ada63a8e66a6528257f82a57c7c9ec5c4e6.png
-rw-r--r-- 1 222 systemd-journal  29744 sep 27  2023 _968bbd4eb6eae18ae48040be0ceb7ca4dff17dd054.png
-rw-r--r-- 1 222 systemd-journal  24245 sep 27  2023 _b5405f76d1004626181efb157e539758ac0f0a8e51.png
-rw-r--r-- 1 222 systemd-journal   1492 sep 27  2023 _be7c76bd3d358233781669f3e760cf3aa9656ea74d.png
-rw-r--r-- 1 222 systemd-journal  33289 sep 27  2023 _df88fc24ab479419c4f4a29ea015f73d0040d05af8.png
-rw-r--r-- 1 222 systemd-journal 114481 sep 27  2023 _f4c60d41e9730ce1c89262a12bfb60b7abe6b2951f.png
-rw-r--r-- 1 222 systemd-journal  45588 sep 27  2023 idm-core.png

intenta ingresar como root al contenedor y ver si los permisos corresponden al usuario siu:

docker exec -u root -it usuarios_idm.1.gqfyp8wzy0r5adheba692zsrg bash
ls -l /usr/local/app/resources

en caso de que el id de usuario no sea 222 se puede aplicar manualmente

chown -cR 222 /usr/local/app/resources

Comentame si esto resuelve el problema. Saludos

Muchas gracias. No me había dado cuenta de hacerlo de esa manera manual. Quedo solucionado.