Problemas con el login de Huarpe

Resulta que este semana no pude loguearme mas en huarpe (arai-usuarios),no se que pasa, me andubo un tiempo tiro el error, luego volvio a andar y ahora otra vez me tira el mismo error.
Mirando los log del contenedor usuarios-idp me sale esto para cualquier usuario, admin, admisudocu, etc:

[Tue Jul 14 16:30:10.987992 2020] [php7:notice] [pid 16] [client 10.0.1.5:33482] simplesamlphp ERR [230aef0b25] arai:usuarios_arai: El usuario ‘login=admin’ no existe, referer: https://expedientes.uncoma.edu.ar/idp/module.php/arai/loginuserpass.php?AuthState=_a3a96831e4a7802ec87cad42148289f5021092e632:https://expedientes.uncoma.edu.ar/idp/saml2/idp/SSOService.php?spentityid=https%3A%2F%2Fexpedientes···%2Fdefault-sp&RelayState=http%3A%2F%2Fexpedientes.uncoma.edu.ar%2Fusuarios%2F&cookieTime=1594754983

sera algo del LDAP?.
yo use el ldap que viene junto con la solución integral que esta en expedientes/dev/servicios/ldap.yml.
Sera algo de en que nodo del cluster se levanta?
Esta parte me confunde ---->El usuario ‘login=admin’ no existe, referer:
no debería aparece solo admin?
Gracias!!

Hola Cristian,

El usuario 'login=admin' no existe,

Este error significa que en la base OpenLDAP, no existe ninguna entidad (dentro de la rama donde se almacenan usuarios claro) que tenga el valor admin en el atributo “login”. Es decir, para buscar, se intenta matchear contra un usuario creado en ldap que coincida “login=admin” básicamente. No se usa ni el campo uid ni uniqueIdentifier.

El ambiente LDAP que despliegan con el sistema de expedientes imagino que no permite conexiones externas al servicio LDAP (con justa causa). Podrían probar configurar el servicio swarm de ldap para sí se pueda y conectarse con un cliente externo (por ejemplo Apache Active Directory) y explorar la estructura en forma visual. Para evitar todo esto, podrían usar sin mayor inconveniente el cliente de consola “ldapsearch” dentro del contenedor del ldap y realizar búsquedas para analizar los datos de las entidades…

Respecto al error de que antes NO funcionaba, lueogo SI y ahora NO, probablemente están pisando la instancia LDAP que utilizan? se está perdiendo los datos? les diría que revisen por ese lado.

Saludos!

El LDAP es el que viene de prueba en expedientes/dev/servicios al mirar el log me sale esto:
5f206875 conn=1012 fd=12 ACCEPT from IP=10.0.4.8:54770 (IP=0.0.0.0:389)
5f206875 conn=1012 op=0 BIND dn=“cn=admin,dc=siu,dc=cin,dc=edu” method=128
5f206875 conn=1012 op=0 BIND dn=“cn=admin,dc=siu,dc=cin,dc=edu” mech=SIMPLE ssf=0
5f206875 conn=1012 op=0 RESULT tag=97 err=0 text=
5f206875 conn=1012 op=1 SRCH base=“dc=siu,dc=cin,dc=edu” scope=2 deref=0 filter=“(&(&(login=admin)(objectClass=top)(objectClass=person)(objectClass=organizationalPerson)(objectClass=inetOrgPerson)(objectClass=eduPerson)(objectClass=labeledURIObject)(objectClass=inetOrgPersonArai)))”
5f206875 conn=1012 op=1 SRCH attr=* +
5f206875 <= mdb_equality_candidates: (login) not indexed
5f206875 conn=1012 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
5f206875 conn=1012 op=2 UNBIND
5f206875 conn=1012 fd=12 closed

Y si corro dentro del contenedor por ejemplo ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=schema,cn=config “(objectClass=olcSchemaConfig)” dn el resultado es:
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
dn: cn={4}ppolicy,cn=schema,cn=config
dn: cn={5}01-arai-usuarios,cn=schema,cn=config
dn: cn={6}edu-org,cn=schema,cn=config
dn: cn={7}edu-person,cn=schema,cn=config
dn: cn={8}dhcp,cn=schema,cn=config
dn: cn={9}dnszone,cn=schema,cn=config
dn: cn={10}mail,cn=schema,cn=config
dn: cn={11}mmc,cn=schema,cn=config
dn: cn={12}openssh-lpk,cn=schema,cn=config
dn: cn={13}quota,cn=schema,cn=config
dn: cn={14}radius,cn=schema,cn=config
dn: cn={15}samba,cn=schema,cn=config
dn: cn={16}zarafa,cn=schema,cn=config
Si ejecuto ldapsearch -x -W -D “cn=admin,dc=siu,dc=cin,dc=edu” -b “dc=siu,dc=cin,dc=edu” se devuelve

extended LDIF

LDAPv3

base <dc=siu,dc=cin,dc=edu> with scope subtree

filter: (objectclass=*)

requesting: ALL

siu.cin.edu

dn: dc=siu,dc=cin,dc=edu
objectClass: top
objectClass: dcObject
objectClass: organization
o: CIN
dc: siu

admin, siu.cin.edu

dn: cn=admin,dc=siu,dc=cin,dc=edu
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e1NTSEF9cnc2WUtLblFoc1lwa1E1Y2pudC9xT05ScUxPQTNVWHI=

usuarios, siu.cin.edu

dn: ou=usuarios,dc=siu,dc=cin,dc=edu
objectClass: top
objectClass: organizationalUnit
ou: usuarios

usuariosCuentas, siu.cin.edu

dn: ou=usuariosCuentas,dc=siu,dc=cin,dc=edu
objectClass: top
objectClass: organizationalUnit
ou: usuariosCuentas

groups, siu.cin.edu

dn: ou=groups,dc=siu,dc=cin,dc=edu
objectClass: top
objectClass: organizationalUnit
ou: groups

devs, groups, siu.cin.edu

dn: cn=devs,ou=groups,dc=siu,dc=cin,dc=edu
objectClass: groupOfNames
cn: devs
member: cn=admin,dc=siu,dc=cin,dc=edu

search result

search: 2
result: 0 Success

numResponses: 7

numEntries: 6

Como puedo ver si están los usuarios adminsudoco o alguno de los creados.

Hola,

Acá hay una guía donde podes ver como manipular un LDAP en principio.

Ese LDAP que me estas mostrando al parecer está vacio. Tiene la estructura básica :

# siu.cin.edu # admin, siu.cin.edu # usuarios, siu.cin.edu # usuariosCuentas, siu.cin.edu # groups, siu.cin.edu # devs, groups, siu.cin.edu

No tiene ningún usuario (el admin que ahí figura es el admin de config, no es el admin que se requiere crear la primera vez y con el cual se puede ingresar al IDM). En la demo de expedientes, se recomienda este paso para inicializar todo. En particular, si lo querés ver desde el punto de vista de arai-usuarios únicamente, está documentado acá.

Saludos!

Hola el paso que mencionas lo hice cuando desplegue todo y anduvo todo bien por un tiempo, cree usuarios, use sudocu, etc. Luego dejo de andar quiza cuando se corto la luz en la sala de servidores y levanto todo los contenedores nose. Eso paso dos veces. Pero se mantuvieron los usuarios
Ahora volvi a correr ADMIN_PASS=toba1234 docker stack deploy --with-registry-auth -c util/usuarios_crear_admin.yml boot
Pude ingresar pero perdí todos los usuarios creados.
Entonces porque el LDAP (que repito es el de expedientes/dev/servicios ) se vacía?
Saludos

Hola Cristian,

Ahora volvi a correr ADMIN_PASS=toba1234 docker stack deploy --with-registry-auth -c util/usuarios_crear_admin.yml boot

Esto te crea/actualiza el usuario “admin” y crea/actualiza la aplicación idm en el registro de aplicaciones. No hace ningún otro cambio extra.

Pude ingresar pero perdí todos los usuarios creados. Entonces porque el LDAP (que repito es el de expedientes/dev/servicios ) se vacía?

Hay que entender primero que, el LDAP levantado como contenedor docker con la definición dev/servicios es “sólo para pruebas rápidas” y no está configurado para ser persistente entre nodos. Es decir, no tiene nada para preservar los datos entre posibles recreaciones que tenga el contenedor, en ambientes con múltiples nodos.

Acá entra en juego que UDS tienen que comprender como opera el orquestador de contenedores (en este caso docker swarm). Swarm puede tomar la definición del servicio (en este caso “ldap”) y levantar un contenedor para él en cualquier nodo de trabajo, luego si sucede algo puede reiniciarlo en cualquier otro nodo. Si UDS no toman el recaudo de manejar los volumenes en forma distribuida, etc, etc, este LDAP se va a reiniciar siempre vacio (o cada que se reinicie en un nuevo nodo, o no tenga volumenes externos para los datos, etc)!

En la documentación de expedientes (Creo que este tema ya no cae en Huarpe, esta es una consulta más para el foro de expedientes, no?) han puesto referencia y detallan un poco más el tema de almacenamiento.

Saludos!

Hola muchas gracias por tu explicación. Tenemos un servidor NFS para los volumenes e instalamos los plugin para acceder desde los tres nodos del cluster, entonces puede ser que al levantar LDAP en alguno de los nodos, el acceso al servidor NFS desde eso nodo no quedo bien o falla y por eso levanta vacio el LDAP.
Voy a comprobar eso y luego te cuento.
Saludos

Buenísimo!

Comprobé el acceso al NFS desde todos los nodos y esta bien, y comprobé que solo cuando el LDAP se levanta en el manager recupera los usuarios, como vos bien decís no es persistente. Tengo tres opciones mientras sigamos probando,

  1. levantar un LDAP propio fuera del stack…ya lo tengo casi terminado
  2. modificar el LDAP de prueba para que sea persistente ( debo modificar los volumenes, que no se como seria, supongo que similar a como esta configurado usuarios.yml )
  3. forzar que el LDAP levante siempre en el nodo manager, creo esta la opción mas rápida mientras sigamos probando.
    Cualquier otra cosa abro otro hilo para seguir preguntando