Actualización de SUDOCU

Hola,

les escribo para preguntarles sobre la actualización de SUDOCU 1.0.2 a 1.0.3. No encuentro documentación de la metodología de actualización. Los repositorios de hub.siu.edu.ar contienen básicamente recetas que tienen yml apuntando a imagenes de los distintos componentes de SUDOCU y que entiendo que se han actualizado.

Mi comentario apunta a saber qué se han modificado de los yml o miro uno por uno o simplemente levanto los nuevos contenedores a partir de los nuevos yml. Hay que realizar cambios sobre las BD a mano? O simplemente bajo todo lo anterior y levanto todo lo nuevo utilizando los mismos volúmenes persistentes, mismas bases de datos, etc.

Saludos!
Alejandro

Hola Ale, un par cosas.

la versión de SUDOCU actual es la 1.0.9. Se puede dar un poco a confusión ya que el entorno integrado (sudocu + huarpe + docs + usuarios) se versiona por separado y va por la versión 1.0.3.

Para actualizar sudocu quedamos en que se iba a mantener actualizado este link: https://expedientes.siu.edu.ar/docs/sudocu/#actualización-de-versión, fijate si eso te cierra. Desde la versión anterior que había hasta la actual tengo entendido que hay que migrar la db.

También hay que migrar DB en arai-docs este es el link a la guía de actualización. https://documentacion.siu.edu.ar/documentos/docs/actualizacion/ (también lo linkié en el changelog https://expedientes.siu.edu.ar/docs/changelog/)

Para el resto de los componentes, con un pull alcanza xq no hay modificaciones en la DB.

Desde las siguientes versiones que se saquen, toda esta info va a estar linkeada en el CHANGELOG para evitar confusiones.

Saludos

Gracias Andrés.

En realidad la documentación pide actualizar ciertas cosas ahí lo vi. El tema es que obviamente el git pull me pisa todos los archivos personalizados, donde se hicieron los sed del dominio y muchos json que fueron editados y demás y no se si realmente se agregaron más cosas en esos archivos o los descarto y comienzo de cero con todo o miro las diff y demás!

En realidad los json se utilizaron para generar configs pero no se si también tienen más valores que van a requeririr que los vuelva a regenerar

Saludos!
Alejandro

Esta sección de la documentación atiende esa inquietud. Deberían uds contar con un repo local de git, con sus cambios commiteados y configurado el repo de siu/expedientes como origin. Así cada vez que salga una nueva versión, uds pueden rebasar o reaplicar sus commits propios sobre cada nueva versión que tenga el repo en origin.

Quizá no es el esquema perfecto, pero permite tener un control detallado de todo.

Gracias Sergio por la respuesta.

Saludos!
Alejandro

Cómo es el procedimiento de actualización de la BD de Arai para pasar de 3.0.2 a 3.0.3? Cuál es la imagen que debo usar? Eso no lo encontré en la documentación de Arai. Andrés comenta que hay cambios en la BD, por eso mi pregunta.

Saludos
Alejandro

Ahh. Me parece que la actualización es sobre Arai Docs:

https://documentacion.siu.edu.ar/documentos/docs/actualizacion/

Saludos
Alejandro

Buenas,

pude sortear varios problemas. Pero la migración de la DB de SUDOCU tira esto. Esta salida es la 2da, la primera corrió una parte y luego tiró esto.

En el API Server otengo esto

root@sudocu:/home/soporte/expedientes-2020/prod# docker logs 0d
2020-10-02T16:03:38: PM2 log: Launching in no daemon mode
2020-10-02T16:03:38: PM2 log: App [sudocu-api-server:0] starting in -fork mode-
2020-10-02T16:03:38: PM2 log: App [sudocu-api-server:0] online
Iniciando Sudocu…
Usando secrets
_
| |
___ _ _ | | ___ ___ _ _
/ || | | | / ` | / _ \ / _|| | | |
_
| |
| || (| || () || (
| || |
|
/ _,| _,| _/ _| _,|

Sudocu setup fail version_check_fail_mismatch_{“persisted”:“1.0.7”,“pjson”:“1.0.9”}

y en la migración de la base pasó esto:

root@sudocu:/home/soporte/expedientes-2020/prod/sudocu# cd
root@sudocu:~# docker run --rm --env SUDOCU_DB_HOST=X.X.X.X --env SUDOCU_DB_NAME=sudocu --env SUDOCU_DB_PORT=5432 --env SUDOCU_DB_USER=postgres --env SUDOCU_DB_PASSWORD=XXXXXXXXXXX ungs/sudocu-db-instalador:1.0.9
[ERROR] AssertionError [ERR_ASSERTION]: ifError got unwanted exception: llave duplicada viola restricción de unicidad «documentos_tipos_pkey»
at /usr/local/lib/node_modules/db-migrate/lib/commands/on-complete.js:15:14
at tryCatcher (/usr/local/lib/node_modules/db-migrate-pg/node_modules/bluebird/js/release/util.js:16:23)
at Promise.successAdapter (/usr/local/lib/node_modules/db-migrate-pg/node_modules/bluebird/js/release/nodeify.js:22:30)
at Promise._settlePromise (/usr/local/lib/node_modules/db-migrate-pg/node_modules/bluebird/js/release/promise.js:601:21)
at Promise._settlePromiseCtx (/usr/local/lib/node_modules/db-migrate-pg/node_modules/bluebird/js/release/promise.js:641:10)
at _drainQueueStep (/usr/local/lib/node_modules/db-migrate-pg/node_modules/bluebird/js/release/async.js:97:12)
at _drainQueue (/usr/local/lib/node_modules/db-migrate-pg/node_modules/bluebird/js/release/async.js:86:9)
at Async._drainQueues (/usr/local/lib/node_modules/db-migrate-pg/node_modules/bluebird/js/release/async.js:102:5)
at Immediate.Async.drainQueues [as _onImmediate] (/usr/local/lib/node_modules/db-migrate-pg/node_modules/bluebird/js/release/async.js:15:14)
at runCallback (timers.js:705:18)
at tryOnImmediate (timers.js:676:5)
at processImmediate (timers.js:658:5)
at Parser.parseErrorMessage (/usr/local/lib/node_modules/db-migrate-pg/node_modules/pg-protocol/dist/parser.js:241:15)
at Parser.handlePacket (/usr/local/lib/node_modules/db-migrate-pg/node_modules/pg-protocol/dist/parser.js:89:29)
at Parser.parse (/usr/local/lib/node_modules/db-migrate-pg/node_modules/pg-protocol/dist/parser.js:41:38)
at Socket.stream.on (/usr/local/lib/node_modules/db-migrate-pg/node_modules/pg-protocol/dist/index.js:8:42)
at Socket.emit (events.js:198:13)
at addChunk (_stream_readable.js:288:12)
at readableAddChunk (_stream_readable.js:269:11)
at Socket.Readable.push (_stream_readable.js:224:10)
at TCP.onStreamRead [as onread] (internal/stream_base_commons.js:94:17)

Saludos
Alejandro

Hola Ale,

Te pido por favor si nos podes adjuntar el contenido de la tabla sudocu.migrations y sudocu.documentos_tipos.

Gracias!

Saludos,

Pablo.

Pablo,

pude avanzar más allá del error pero tengo un problema con la API de SUDOCU en el Endpoint /auth/providers. Me da 404 y veo que el JSON está bien formado con SAML en habilitado en true.

Saludos
Alejandro

En el log del api server no dice nada ?

404… Estoy debuggeando src/modules/auth/auth.js pero veo el JSON bien formado y veo que ahí debería devolver SAML…

Hola! Estoy en el mismo punto de actualización y con el mismo error (el de llave duplicada viola restricción de unicidad «documentos_tipos_pkey»

Hay solución para este problema?

Gracias!


sudocu.migrations.zip (1.27 KB)

sudocu.documentos_tipos.zip (3.04 KB)

Pablo,

te adjunto lo de los documentos.

Saludos
Alejandro


salida.sql (12.8 KB)

Pablo puede que sea algo de CORS? En la petición que hace el browser veo que el servidor de API devuelve en el header esto:
access-control-allow-origin: http://expedientes2.testing.unlp.edu.ar:8080

En realidad eso veo que lo forma con los datos del JSON de config, pero debería ser https://expedientes2.testing.unlp.edu.ar que es la URL que yo estoy accediendo en el navegador. En el config lo tengo igual en esa sección que la otra versión, no se si han modificado Uds algo en la API. En el JSON sí figura expedientes2.testing.unlp.edu.ar y port 8080 pero no se para que lo usa.

Saludos,
Alejandro

El problema con la actualización de versión (puntualmente el script de actualizacion de la base a la versión 1.0.8), es que quiere hacer un insert en la tabla documentos_tipos con el ID 36. En nuestro caso, como habíamos creado un par de tipos de documentos de prueba, ese ID ya estaba siendo utilizado por un tipo de documento propio de la universidad. Por eso el error de clave duplicada.

Pregunta: ese insert que quiere hacer el instalador del tipo “providencia_auto” ¿puede llevar otro id? ¿o necesariamente tiene que ser el 36?

Porque en tenemos documentos creados con el tipo de datos que creamos (y que tiene el id 36 actualmente)…

Adjunto el log del postgresql.


logdelerror_postgresql.zip (1012 Bytes)

la solución momentánea es pasar los tipos de documentos creados por la universidad con un ID mayor a 20.000

En nuestro caso, como no teníamos numeradores creados para ese tipo, y tampoco teníamos template creado para ese tipo que creamos, movimos nuestro tipo de documento al ID 20.001 con las siguientes queries:


INSERT INTO sudocu.documentos_tipos (id,id_padre,nombre,nombre_plural,nombre_singular,nombre_abrev,id_nuxeo,visibilidad,esencia,alias_busqueda,tipo_leido,nivel_firma,config,eliminado)
SELECT 20001 AS id,id_padre,nombre,nombre_plural,nombre_singular,nombre_abrev,id_nuxeo,visibilidad,esencia,alias_busqueda,tipo_leido,nivel_firma,config,eliminado
FROM sudocu.documentos_tipos WHERE id = 36;

UPDATE sudocu.documentos SET id_tipo = 20001 WHERE id_tipo = 36;

UPDATE sudocu.documentos_versiones SET id_tipo = 20001 WHERE id_tipo = 36;

UPDATE sudocu.usuarios_permisos_documentos SET id_tipo_documento = 20001 WHERE id_tipo_documento = 36;

Y luego BORRAMOS el el ID 36 (para que funcione el script de actualización)


DELETE FROM sudocu.documentos_tipos WHERE id = 36;

LUEGO DE HACER ESTO EL SCRIPT TERMINÓ DE EJECUTARSE:


docker run --rm   --env SUDOCU_DB_HOST=X.X.X.X   --env SUDOCU_DB_NAME=XXXX  --env SUDOCU_DB_PORT=X   --env SUDOCU_DB_USER=XXXX   --env SUDOCU_DB_PASSWORD=XXXXXX   ungs/sudocu-db-instalador:1.0.9
[INFO] Processed migration 20200803172958-v108
[INFO] Processed migration 20200813191107-v109
[INFO] Done

Gracias Diego por tu análisis. Has podido completar la migración?

Pablo, has podido ver lo que he mandado del endpoint de providers?

Saludos
Alejandro

Pablo,

parece que ahora luego de finalizar la migración acomodando la base con las claves duplicadas parece que quedó andando.

Saludos
Alejandro

Hola a mi me paso lo mismo de llaves duplicadas y en mi caso me comento Mariano de Sarmiento que el error es porque tenia creados tipos de documentos desde el mpc
y el migrador de la versión 1.0.8 esta tratando de agregar uno con el mismo id
Por lo que me sugirió cambiar el id 36 en la tabla documentos_tipos por otro y volver a correr la migración.
A mi eso me anduvo, espero que le sirva a otro.
Saludos