Checklist para comenzar explotación de siguclean

[tonin]

Tras muchas pruebas espero que esté todo en regla y no haya ningún bug gordo.

La documentación actualizada la teneis aquí:

​https://github.com/popoff1998/SiguClean/blob/master/README.md

Antes de comenzar la explotación hay que realizar un checklist y tomar una serie de desiciones, a saber:

1.- Asegurarse de que los montajes necesarios están presentes y accesibles en ibmblade14, comprobar que los labels de la tabla mounts se corresponden.

2.- Asegurarse de que los enlaces alternativos con prefijo 0_ existen en todos los FS, que apuntan al lugar correcto y que están realizados los montajes alternativos.

3.- Decidir que vamos a hacer con los usuarios presentes en people.deleted de ldap. Estos fallan por sistema al hacer solo la busqueda en people. O bien se mueven a la rama people o puedo poner que siguclean busque ramas alternativas a la people.

4.- Decidir el tamaño del FS donde almacenaremos las sesiones de siguclean. Hay que tener en cuenta que tras cada archivado haremos un backup de la sesión (preferentemente a 2 cintas separadas). Hay que decidir también por tanto si usaremos bácula o arcserve para hacerlo (yo voto por bácula).

5.- Crear el FS anterior en la NAS antigua, exportarlo y montarlo en ibmblade14.

Creo que en principio con estas 5 cosas podriamos lanzar una primera prueba real sobre unos 2000 usuarios, los que caducaron antes, a ver como va.

[tonin]

Corregida la documentación del programa.

[tonin]

Algunos cambios en siguclean:

• Añadida rotación de logs
• Añadida opción --restore para restaurar una sesión anterior.
• Las escrituras en la BBDD de los storages archivados se han hecho transaccionales. Solo se hacen cuando se ha archivado el usuario completamente.

La documentación se ha corregido para incluir los cambios:

​https://github.com/popoff1998/SiguClean

[tonin]

Primera prueba real

Lanzo la prueba sobre 488 usuarios con esta línea de comando:

./siguclean.py -vvvvv --sigu-password mysigu --win-password c100cpb -f 1900-01-01 -t 2004-10-30 -n PRUEBABETA --debug --maxsize auto --confirm --sessiondir /nfs/SIGUCLEAN -x /nfs/ -p 0_

El sumario es este:

Tamaño de tars de la session PRUEBABETA es 4G
-------------------------------
ESTADISTICAS DE LA SESION
-------------------------------
Total:		488
Correctos:	474
Incorrectos:	14

--- Detalles de fallos ---

Failed:		0
Rollback:	9
Norollback:	1
Excluded:	4
Skip:		0
Suma:		14

--- Razones del fallo/exclusion ---

NOTINLDAP:	3
NOMANDATORY:	0
FAILARCHIVE:	0
FAILDELETE:	1
FAILARCHIVEDN:	0
FAILDELETEDN:	0
UNKNOWN:	9
ISARCHIVED:	1
UNKNOWNARCHIVED:	0
NODNINAD:	0

--- Rendimiento ---

Inicio:		08-11-13 13:30:03
Fin		08-11-13 14:59:27
Elapsed:	1:29:24.475830
Rendimiento:	0 users/sec

[tonin]

Las razones de fallo son:

sh2schwe	NOTINLDAP	----
l02beguc	NOTINLDAP	----
sh2moral	NOTINLDAP	----
qf1rovaa	UNKNOWN	----
m72roroc	UNKNOWN	----
bb1roara	UNKNOWN	----
i42gumaj	ISARCHIVED	---
i72gumaj	UNKNOWN	----
l82sacaj	FAILDELETE	homecifs
a92mamom	UNKNOWN	----
f32sitoj	UNKNOWN	----
fm1silva	UNKNOWN	----
qa1ricaa	UNKNOWN	----
ig2demin	UNKNOWN	----

[tonin]

Analizando el resultado tenemos:

• Los 3 NOTINLDAP eran esperables, son usuarios en People.deleted
• Todos los UNKNOWN corresponden a problemas al insertar el registro en la bbdd, debido a que el tamaño del campo NSIZE es pequeño:

[2013-11-08 14:53:22.110416]    EXTRADEBUG-INFO: (user-bbddInsert) self.state: DELETED key: homemail
[2013-11-08 14:53:22.112835]    DEBUG-ERROR: (storage.bbddInsert) Error: ORA-01438: valor mayor que el que permite la precision especificada para esta columna

Corrijo de una parte esto (​https://github.com/popoff1998/SiguClean/issues/4) y creo una nueva failreason para problemas con la inserción en la BBDD (​https://github.com/popoff1998/SiguClean/issues/5).

• El NOROLLBACK es l82sacaj. Es muy extraño porque el error es este:

[2013-11-08 14:05:52.992839]    DEBUG-INFO: (storage.delete) homecifs en /nfsro/HOMESCIF/l82sacaj

Y el path existe y parece correcto. Abro el ticket ​https://github.com/popoff1998/SiguClean/issues/6.

• El ISARCHIVED de i42gumaj, tratándose de la primera ejecución donde la BBDD estaba vacía, tampoco debería haberse producido. Llamando a la función desde TORA directamente obtengo el mismo resultado, 0 que indica que no es necesario archivarse. Abro el ticket ​https://github.com/popoff1998/SiguClean/issues/7 al respecto y le lanzo la consulta a José Angel para que vea porqué puede ser, ya que yo no lo veo.

[cc0luism]

He mirado lo de i42gumaj. Su última operación en ut_hist_cuentas en que ha sido bloqueada, con lo que estado=5. En el código de la función dice que con eso no hay que archivar.

[tonin]

Replying to cc0luism:

He mirado lo de i42gumaj. Su última operación en ut_hist_cuentas en que ha sido bloqueada, con lo que estado=5. En el código de la función dice que con eso no hay que archivar.

Pues en ese caso hay algo que no cuadra ... Si un usuario ha sido cancelado o ha caducado, este debería ser su último estado.

Supongo que este usuario se bloqueó cuando estaba aún activo y después por algún procedimiento automático caducó. La explicación sería que la caducidad o cancelación no genere una entrada en ut_hist_cuentas sino solo un cambio de atributo en ut_cuentas, lo cual alteraría la lógica de sigu si se entiende que cualquier actividad sobre el usuario debe de generar una entrada en la primera tabla.

Pongo en copia a José Angel para que esté al tanto.