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
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
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.
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).
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 ‘/’
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.
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
“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 ?
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).
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?
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.
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?