[SOLUCIONADO] Actualizar ldap en arai-usuarios (v2.3 a v3.0.2)

Hola sergio! ahi se soluciono eso arreglando el indentado y sacando el sp:
Estoy tratando de llevar todo a docker.

Te consulto por la linea :
docker run --rm --env-file migrar.env --volume /opt/arai-usuarios/2.3.1/config/sp.yml:/tmp/sp.yml hub.siu.edu.ar:5005/siu-arai/arai-usuarios/idm:$VERSION – idm/bin/instalador migracion:3.0 load-sp /tmp/sp.yml

No logro que conecte a la DB

  1. Utilidades para migración a versión 3.0
    ==========================================

In Db.php line 93:

DB CONNECTION ERROR: ERROR conectandose al motor - SQLSTATE[08006] [7] coul
d not connect to server: Connection refused
Is the server running on host “localhost” (127.0.0.1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Address not available
Is the server running on host “localhost” (::1) and accepting
TCP/IP connections on port 5432?

Por favor, verifique sus parámetros de conexión

Queria ver que parametros de conexion el archivo Db.php esta tomando, donde se encuentra este archivo?, ya que por consola me funciona

root@AraiUsuariosDesarrollo:/opt/arai-usuarios/2.3.1# psql -U postgres -h localhost
Password for user postgres:
psql (9.6.10)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type “help” for help.

postgres=#

En migrar.env tengo:
DB_HOST=localhost
DB_PORT=5432
DB_DBNAME=arai_usuarios
DB_USERNAME=postgres
DB_PASSWORD=xxxx
DB_SCHEMA=usuarios

Muchas gracias! saludos!

Hola Javier!

Connection refused ... Is the server running on host "localhost"
En migrar.env tengo: DB_HOST=localhost DB_PORT=5432 ...

Este es un error que te arroja “adentro” del contenedor (máquina virtual, nuevo servidor, puede estar en japón corriendo…). Los datos de conexión de este contenedor “hacia” la base de datos tienen que ser de tal forma que este contenedor/servidor pueda llegar al servicio en cuestión (la db en este caso).

Hay algo mas básico que tienen que comprender, relativo a Docker, esto representa trabajar con esquemas de redes (no les pide crear ni configurar IP alguna, pero no quiere decir que por detrás Docker no lo haga). Tienen que ver como desde el contenedor que intentas correr se tiene que llegar al servicio de DB que está “de casualidad” en forma local a donde instalaron Docker Engine.

No puede ser “localhost” la IP del servidor PostgreSQL definitivamente. Tendría que ser la IP asignada al servidor donde corre la db, mínimo, junto con configuración de pg_hba.conf para permitir el acceso externo, etc, etc.

Saludos!

Hola!
Continuando con la actualización manual de arai-usuarios v2.3.1 a 3.0.2 te consulto sobre estas dos variables (IDM):

CONFIG ASSETS

ASSETS_DIR=/usr/local/app/resources
ASSETS_URL=http://localhost/assets

Estas variables responden a la versión instalada o a recursos que deberá tener acceso la versión a instalarse (3.0.2)?

Si es en base a mi versión instalada tengo todo en /opt/arai-usuarios/2.3.1.

Gracias!

Javier,

ASSETS_DIR permite configurar donde se almacenan los archivos de assets (imágenes de usuarios, aplicaciones).

ASSETS_URL permite especificar como se accede a estas imágenes de forma pública (desde el perfil del usuario de Huarpe, esa imágen debe ser accesible en forma pública). Puede alojarse en otro server (con filesystem compartido) o puede estar en el mismo. Por eso hay una forma adicional de especificar esta URL, auqnue sea la misma que la del IDP (que suele ser el caso normal).

Esto ya estaba disponible desde la v2.x. Saludos!

Perfecto sergio, comprendido!

Ya en la etapa final de sincronizacion te consulto, al ejecutar ./idp/bin/arai-cli registry:add http://usuarios.unr.edu.ar:80/arai-registry -e mail@unr.edu.ar -m “Mantenedor”
Obtengo:
[ 422 ] - Problemas al registrar la aplicacion. Se quiere proveer ‘service:siu/sso-saml-idp’ que ya existe en el namespace ‘/’

Sabes por que puede venir esto?

Muchas gracias

Hola Javier,

El problema es que, como estas actualizando de una 2.3, ya existe el registro service:siu/sso-saml-idp en el arai-usuarios anterior. El camino ahora sería primero ejecutar el sync en el IDM para que deje de reportar esa provisión.

./idm/bin/arai-cli arai:actualizar-backend --destino /ruta/arai-usuarios/3.0.0/idm/instalacion/arai-sync.key

Luego de eso, podes ir a por el idp y tratar de agregarlo a registry y sincronizarlo. Nos quedó eso al revez en la doc.

Hola!, finalice con la actualizacion de arai usuarios 3.0.2
Debido a que esta esta en php7.3, decidi mover huarpe a otro servidor con php7.1

Para esto, quite el registro de huarpe de arai-registry, y lo volvi a registrar
Sinconizando ambas partes con las siguientes lineas y limpiando caches de huarpe

HUARPE_APP_ID=siu_huarpe-1 bin/arai-cli registry:sync

./idm/bin/arai-cli registry:sync --aceptar-pedidos-acceso
./idp/bin/arai-cli registry:sync --aceptar-pedidos-acceso
./api/bin/arai-cli registry:sync --aceptar-pedidos-acceso

Luego me enconter con este error a la hora de probar el login en huarpe:

simplesamlphp ERR [c7a0e45f67] SimpleSAML\Error\MetadataNotFound: METADATANOTFOUND(‘%’ => ‘\‘https://huarpe.unr.edu.ar/saml/metadata\\’’)
simplesamlphp ERR [c7a0e45f67] Backtrace:
simplesamlphp ERR [c7a0e45f67] 3 /opt/arai-usuarios/3.0.2/idp/vendor/simplesamlphp/simplesamlphp/lib/SimpleSAML/Metadata/MetaDataStorageHandler.php:340 (SimpleSAML\Metadata\MetaDataStorageHandler::getMetaData)
simplesamlphp ERR [c7a0e45f67] 2 /opt/arai-usuarios/3.0.2/idp/vendor/simplesamlphp/simplesamlphp/lib/SimpleSAML/Metadata/MetaDataStorageHandler.php:360 (SimpleSAML\Metadata\MetaDataStorageHandler::getMetaDataConfig)
simplesamlphp ERR [c7a0e45f67] 1 /opt/arai-usuarios/3.0.2/idp/vendor/simplesamlphp/simplesamlphp/modules/saml/lib/IdP/SAML2.php:380 (SimpleSAML\Module\saml\IdP\SAML2::receiveAuthnRequest)
simplesamlphp ERR [c7a0e45f67] 0 /opt/arai-usuarios/3.0.2/idp/vendor/simplesamlphp/simplesamlphp/www/saml2/idp/SSOService.php:21 (N/A)
simplesamlphp ERR [c7a0e45f67] Error report with id 62a76e62 generated.

Busque en el foro y encontre:

“Este error en el IDP significa que un SP se intenta conectar para hacer login pero este SP no se encuentra registrado en el IDP. En tu caso, Huarpe es el SP que se intenta conectar con la URL https://huarpe.local pero probablemente no lo tiene registrado el IDM o Arai-Usuarios. Para que esto suceda, en Arai-Usuarios tienen que ejecutar arai-cli registry:sync luego de haber hecho lo mismo desde Huarpe (como lo detalla la documentación).”

El registro del SP (Huarpe) deberia quedar en /idp/config/sp.yml ?

Tengo opcion manual de arreglarlo?

Muchas gracias, saludos

Hola Javier,

en la version 3.0+ de Arai-Usuarios ya no se usa el archivo sp.yml, sino que dicha informacion queda contenida en la bd de Arai.

Para registrar/actualizar el SP de Huarpe en forma manual, tendrias que seguir este camino… con esos pasos deberia quedar funcionando.

Saludos

Perfecto! quedo funcionando todo.

Muchas gracias, saludos!

Consulta:
Para registrar arai-documentos sigo este mismo procedimiento?

Hola Javier,

El mismo procedimiento te referis a utilizar arai-registry, instalar arai-documentos y que quede ahi registrado. En principio si, lo que quizá pase es que otros sistemas no estén consumiendo arai-documentos y tengas que simplemente configurarlos manualmente (poner la url de arai-documentos en ese sistema, los user/pass del lado de arai-documentos, etc).

Hola sergio! me referia a la respuesta de richard,
que me sugería el uso de este metodo: https://expedientes.siu.edu.ar/docs/arai/#registrar-huarpe-como-service-provider
El cual me anduvo bien para huarpe, pero me dio la duda para el resto de las aplicaciones.
Saludos!

Hola Javier,

Lo que te menciona Richard es para registrar un Service Provider o SP que requiera autenticación centralizada vía SAML u OIDC. Eso es verdadero para Huarpe (Pilagá, Diaguita, Mapuche, Guaraní, desarrollos web/mobile propios) pero NO para un servicio de servidor a servidor como lo és arai-documentos.

Hola! les consulto por el proceso de actualizacion/migracion de usuarios existntes de v2.3 a v3.x

Vemos que se genera el uid de la forma: 0002bd99-2d73-4f8b-afea-02fd25cc25b1
Pero notamos que no a todos los usuarios se les genero el UID de esa forma y conservan el mismo valor que “Identificador” y a los que les sucede eso no podemos hacer que loguee al sistema.

Si bien esto es en test, hay alguna forma de procesar los usuarios que no fueron procesados? o bien hacer algo en el proceso de actualizacion?

Desde ya muchas gracias, saludos!

Hola Javier,

En la versión 3.0 se implementó esta forma de identificar a los usuarios en LDAP, mediante un UID autogenerado no predecible. En la migración, se corre el punto 3 de esta migración de datos. Este comando procesa de a un usuario por vez. Una vez que el usuario tiene un UID en la forma UUIDv4, no se procesa, con lo cual pueden correr este comando N veces hasta que arroje cero resultados procesados.

Una vez aseguren que en LDAP todos los usuarios tienen el UID correctamente generado, avanzamos en evaluar inconvenientes de acceso.

Hola Sergio, ya quedo todo funcionando, le pase unas veces este comando (instalacion manual): idm/bin/instalador migracion:3.0 ldap

Muchas gracias, saludos!

Buenísimo,

Para tomar nota, cuantos usuarios cuentan en LDAP? Es posible que por la cantidad, sea un tema de recursos. De todas formas, es seguro ejecutar y volver a ejecutar el comando. Una vez que modifica un usuario, ya no lo toca.

Hola Sergio!
En test tenemos una base con 10110 registros.
Si, lo ejecute varias veces hasta que proceso todos.

Lo que si te consulto ya que estamos, el buscador de usuarios en arai usuarios funciona con todos los atributos menos el documento (Campo Identificador).
Sera algo que se soluciona en versiones posteriores?

Saludos!

Hola Javier,

El campo “identificador” permite búsqueda exacta únicamente, es una limitación del LDAP básicamente porque se trata de un campo primario.

Gracias Sergio! solucionado!