Hola a todos,

Podemos implementarlo cuando me digáis, ya he terminado con las evaluaciones así que cualquier tarde puedo probarlo.
Esto que funcionará a través de una etiqueta?

El miércoles trabajo de mañana y tarde, lo digo por si queréis que lo pruebe una mañana para poder hablar por teléfono por si fuera necesario.

Ya me decís.
Un saludo,

Adrián

Hola Adrián...como y cuando me digas. La solución la podemos desplegar en algunos equipos, en una o varias etiquetas o en todo el centro. Creo que lo mejor es ir poco a poco para ir probando y que lo testeis (si os va bien, si funciona bien, si da algún problema con algo....). Así pues, si me dices CID's o una etiqueta, damos la orden de instalación y lo probáis.

-- nacho

Si podemos crear una etiqueta nueva mejor que mejor, por ejemplo "ldap-google"
Si tiene que ser alguna de las que ya tenemos podria ser la de "minis"

Hola Adrián. Por no liar creando mas etiquetas os lo dejaré disponible en Vitalinux Play para que lo puedas instalar donde lo quieras probar (y que pida credenciales para que solo lo pueda instalar un administrador ). Así, una vez que lo pruebes lo podemos ir desplegando en las etiquetas donde me digas (no tienes que ir instalándolo a mano equipo por equipo con Play...solo es para que lo pruebes donde quieras).

Pero antes de nada, veo que hay un problema con los permisos de los usuarios y en NFS (carpetas compartidas). Como los usuarios de ldap no tienen como grupo principal alumno (1200) son capaces de ver las carpetas compartidas de docente y estudiante, pero no pueden escribir en estudiante. No se si es algo que usáis en vuestro centro (las carpetas compartidas de estudiante), pero tengo que revisar a ver si se puede meter. Si no lo usáis no me doy mas mal, si lo usáis igual hay que buscar un plan B, no se, te iré contando.
Por otro lado a veces falla la autenticación y no entra (falla la comunicación con google), pero ya te habrá comentado Teo....

-- nacho

Hola Nacho,

Me parece perfecta la solución que propones.

Lo de las carpetas compartidas de alumno: la verdad que no pasa nada ya que creo que no lo utilizan, además todos tienen Google drive. No hace falta que des mal por hacer que funcione.

Si, Teo ya me comento lo que la primera vez que se inicia en un equipo entra a la segunda.

Muchas gracias Nacho,

Mañana probaré a ver que tal va y os comento.

Que vaya bien,

Adrián

Teo...hay un error con la asignación de grupos al usuario cuando entra. La primera vez que el usuario entra se le asignan los usuarios indicados en /etc/security/group.conf, pero no así en los siguientes inicios de sesión que haga en la máquina. Habría que revisar éso, ya que no se porqué es (el tema de que los usuarios puedan entrar con perfil de alumno lo tengo controlado y mañana lo despliego en los servidores)

-- nacho

Hola chicos,

Probado y funciona, pero le cuesta un rato identificarse. Del orden de 1 minuto o 2, aun habiéndome identificado previamente.
Pero vamos funciona.
Habría que ver como funciona si se conectan muchos a la vez. La semana que viene hago una prueba con muchos usuarios a la vez.
La terminal va rara, no me deja hacer nada, supongo porque no tengo permisos.
Programas del escritorio funcionaban correctamente.

Por cierto, muy guay lo del vitalinux play!

Un saludo,

Adrián

Se me acaba de ocurrir, hay alguna forma de eliminar todos los usuarios creados de forma telemática?
O tendré que ir equipo por equipo eliminándolos? Lo digo ya pensado en la puesta a punto para un futuro.

Hola Adrián, a que te refieres con eliminar los usuarios? No quieres que se cree un directorio home para el usuario en cada equipo? No entiendo

-- nacho

Hola Nacho,

Si, si que quiero que crees carpetas para cada usuario.
Si de hecho lo ideal es que tanto profesores como alumnos, se les creen carpetas y no tengan permisos de root.
Pero me estaba planteando como hacer el mantenimiento de los equipos vitalinux al final de curso o principio, es decir, en algún momento deberé eliminar los usuarios creados, entonces me estaba planteando si se podía enviar alguna orden de forma remota que eliminará todos los usuarios creados a través del ldap de google, así no tendré que ir equipo por equipo eliminándolos.
Si la hay estupendo, sino cuando llegué el momento ya me pondré en modo macro humana.

Un saludo,

Adrián

Las carpetas de los usuarios se crean automáticamente, es decir, cuando un usuario entra en un equipo, si no tiene su cuenta se crea. Si lo hace en otro ordenador se crea allí también (pero no es la misma, no es un perfil móvil).
El tema de los privilegios depende del grupo donde esté en el ldap de google, y para eso Teo creo una asignación de grupos locales a grupos de ldap. Éso lo debes revisar con él (quiénes son docentes, alumnos...)
Sobre el borrado, éso lo podemos hacer nosotros como hacemos en otros centros con cuentas locales: limpieza cuando nos digáis. Todo lo que se pueda hacer por software, se puede automatizar con Vitalinux :-)

-- nacho

Por cierto, ya he hecho los cambios pertinetes para que los estudiantes puedan acceder y escribir en estudiantes (servidor caché, el de las carpetas compartidas que aparecen en el escritorio), y los perfiles de usuarios que sean docentes, que puedan escribir en docentes.
Ya me cuentas si te funciona

-- nacho

Por partes:

Asignación de grupos¶

La asignación de grupos está en /etc/security/groups.conf

Allí, si se quiere se puede cambiar el tema de la asignación de grupos al inicio de sesión, ahora mismo la cosa está así:

#Docentes (todos los miembros del grupo claustro@iessierradeguara.com)
*;*;%claustro;Al0000-24000;docentes,adm,profesor,lpadmin

En principio, los profesores tienen todos esos grupos asignados en cuanto inician sesión con su cuenta del iessierradeguara, pero no tienen el grupo sudo ni el grupo admin, así que entiendo que no podrán hacer sudo.
He creado una cuenta test_ldap_profe@ies... con la misma contraseña de los otros test_ldapX@ies... pero la he añadido al grupo claustro@ies... y lo he probado y le otorga bien los grupos, y no puede hacer sudo:

test_ldap_profe@vitalinux:~$ id
uid=883569657(test_ldap_profe) gid=883569657(test_ldap_profe)
grupos=883569657(test_ldap_profe),4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),46(plugdev),122(lpadmin),999(sambashare),1100(profesor),3100(docentes),76294466(profesores_clase),723609588(claustro)
test_ldap_profe@vitalinux:~$ sudo ls
[sudo] contraseña para test_ldap_profe: 
Disculpe, el usuario test_ldap_profe no está autorizado para ejecutar «/usr/bin/ls» como root en vitalinux.aragon.es

No sé si esto debería de ser así o no. Al final el docente que quiera hacer algún comando como sudo, o bien se cambia al usuario docente, o bien le saldrá el diálogo diciéndole que proporcione la contraseña de dga, docente o cau.

Los alumnos están puestos por grupos de 2º nivel, es decir está el grupo alumnado.1eso que comprende alumnado.1esoa, 1esob,... etc. y todos los demás cursos. En principio está configurado para que lea grupos de profundidad 2 en el dominio, aunque puede ser que lea más, si leyendo un grupo se encuentra a un usuario, lo cachea también, aunque ese grupo sea de más profundidad. Las líneas de los grupos de alumno están así.

@#Alumnado
*;*;%alumnado.1eso;Al0000-24000;estudiantes,alumno
....

Eliminación de cuentas:¶

Para la eliminiación de cuentas, entiendo lo que dice Adrián, sin meternos en temas de cuotas de disco (que estaría bien y está como líneas futuras que jamás nadie va a implementar, jajaja de trabajo en mi TFM), se podrían llenar los discos. Estoy pensando en los portátiles dynabook, por ejemplo, que tienen 128GB y algunos a están dualizados, pues es fácil que las carpetas /home/*/descargas se llenen de "broza" y terminen llenando el disco duro.

Al final de curso se podría pedir a Nacho o Arturo que lancen un en el siguiente inicio de sesión:

rm -rf /home/*@iessierradeguara.com

y fusilar todas las carpetas de usuario del dominio, al iniciar sesión se volverá a crear y ya está.

He notado, en la máquina virtual que tengo instalado todo que a veces tarda muchísimo en iniciar sesión. A veces va relativamente rápido 5 segundos, pero a veces tarda minutos que se queda ahí como congelado y al final va... creo que se combina la latencia de google con las peticiones que hace por detrás el demonio para escanear los grupos del dominio y demás... sigo investigando :-)

Sobre el archivo security, Teo, lo que se ha desplegado es ésto (es lo que había en el documento y a lo que añadí alumno para la primera línea, que no estaba):

*;*;*;Al0000-2400;audio,alumno,cdrom,dialout,floppy,plugdev,sambashare,dip
*;*;%claustro;Al0000-24000;docentes,adm,profesor,lpadmin
*;*;%vitalinuxsudo;Al0000-24000;sudo

-- nacho

Sí, Nacho, perdonad, fallo mío. En esencia es lo mismo, si asumes que el permiso mínimo es ser alumno. Pero en el TFM lo he puesto así para demostrar que puede haber una granularidad más fina de permisos entre los diferentes grupos de alumnos.

Por cierto, que hay una circunstancia de seguridad asociada al uso de pam_group (aparece en la página del manual) que es interesante de saber y que está relacionada con el setuid y el setgid. Básicamente es que un usuario podría recuperar la pertenencia a un grupo previo, usando el bit setgid en un binario y actuar como tal.
En el manual dicen que todo sistema de archivos que sea escribible por un usuario que ha adquirido un grupo por pam_group, debería estar montado como nosuid.
La solución propuesta en el TFM es separar el /home y poniéndolo como nosuid, pero en el mundo real, no creo que haga falta, ya que no se dará el caso de que alguien pierda su grupo, ni que sepa implementar nada parecido a lo que se dice en el manual, ¿no?

Hola Teo...no entiendo muy bien. El setuid y el setgid te permiten (en cualquier caso) que el proceso del ejecutable que tenga dicho bit activado adquiera la propiedad (o grupo propietario) del propietario/grupo del archivo y no del que lanza el proceso (como ocurre de forma normal)....pero ésto ocurre siempre, independiente de pam, no?

-- nacho

En el manual dice algo así (lo he traducido):

"La utilidad de este módulo (pam_group) confía en los sistemas de archivos accesibles en modo de escritura para el usuario. El caso es que, una vez concedida la pertenencia a un grupo a un usuario, ese usuario podría intentar crear un binario con setgid con pertenencia restringida a ese grupo. Después, si el usuario deja de pertenecer a ese grupo, podría recuperar la membrersía con el binario precompilado. El hecho de que cuando un sistema de archivos se monta con la opción nosuid, el usuario sería incapaz de ejecutar ese binario, es por lo que se especifica que este módulo confía en cómo estén montados los sistemas de archivos. Para que este módulo provea algún nivel de seguridad, todos los sistemas de ficheros a los que el usuario tiene acceso de escritura, deberían estar montados con la opción nosuid."

Lo que yo creo que quiere decir es que un usuario podría utilizar un binario en su carpeta personal y activarle el setgid mientras es propietario del archivo y miembro de un grupo A, para que el binario actuara en nombre de ese grupo A; y después utilizarlo en nombre de ese grupo una vez el usuario ya no perteneciera a ese grupo.

Si lo han puesto en el manual, será que algo hay, no sé.

Bueno...pero en nuestro caso no afectará, ya que como mucho lo podrán correr como grupo alumno, siempre que sin querer no se creen usuarios en el grupo docente y que ése usuario, en ése in-pass, le de por crear los binarios con guid

-- nacho

Ok, genial chicos. Yo por mi parte lo implementaría en cuanto termine el curso, es decir, la última semana de junio. Para comenzar el curso que viene con todo preparado.

Faltaría hacer un par de cambios:
- A poder ser implementar la instalación, mediante una etiqueta.
- Cambiar las contraseñas de docente y estudiante para que no las utilicen el año que viene.
- Añadir una configuración de wifi nueva, aunque aún no sé cuál.

Escribo en breves, con toda la información definitiva.

Gracias majos!
Un saludo,

Ok...
Lo de la etiqueta se puede crear sin problemas, pero igual es mejor aprovechar las que ya tenéis, es decir, lo podemos hacer como con el resto de software, instalar en los equipos con ciertas etiquetas. recuerda que tienes éstas que aparecen en la web. Otra cosa es que quieras instalarlo en equipos que no están definidos por ninguna etiqueta
Las contraseñas de las cuentas locales se pueden cambiar cuando nos digáis con las que no digáis. Se puede hacer para todo el centro o igualmente por etiquetas

-- nacho

Hola a todos:

He descubierto una opción que creo que mejora el tiempo en general de rendimiento del inicio de sesión.

Para evitar que escanee todos los usuarios del grupo por separado, cuando escanea los grupos, habría que añadir en el fichero /etc/sssd/conf.d/01-iessierradeguara.com.conf la opción:

ignore_group_members = true

Creo que aliviaría mucho el número de peticiones LDAP que se producen, ya que los grupos de usuarios pueden tener muchísimos miembros y hace una petición por cada uno de ellos, según he visto revisando los logs.

Edito:

Tiene una contrapartida, y es que si queremos saber los usuarios de un grupo a través de una petición LDAP, no los mostrará y mostrará el grupo vacío, no sé si esto puede tener alguna implicación. Sin embargo, sí funciona bien si buscamos los grupos de un usuario con groups, por ejemplo:

dga@vitalinux-ldap:/home/dga$ groups test_ldap_profe ⏎ 

      test_ldap_profe : test_ldap_profe profesores_clase claustro

Con la opción ignore_group_members = false

dga@vitalinux-ldap:~$ getent group test_ldap_grupo_nivel3 ⏎ 

      test_ldap_grupo_nivel3:*:1836921401:test_ldap9,test_ldap7,test_ldap0

Con la opción ignore_group_members = true

dga@vitalinux-ldap:~$ getent group test_ldap_grupo_nivel3 ⏎ 

      test_ldap_grupo_nivel3:*:1836921401:

Un saludo.

Hola...entiendo que saber los grupos (a nivel de ldap) puede no ser muy interesante o necesario, pero si que sería conveniente que tenga la pertenencia a alumno, profesor u otros grupos locales. Éso se mantiene con la opción indicada? No me queda claro
En cuanto confirmes lo añadimos y actualizo la versión del paquete

--nacho

Te lo confirmo, no afecta a la asignación de grupos en el inicio de sesión.

Al buscar un usuario, sí encuentra sus grupos, y en base a esos grupos del dominio, el módulo pam_group asigna los grupos locales (vitalinuxsudo --> sudo, claustro --> docentes, etc.)

Creo que habría que añadirlo al paquete, porque todas las pruebas que he hecho son positivas, mejora bastante el rendimiento y no he encontrado ningún caso en el que nos perdamos nada.

Saludos.

Hecho y desplegado....

--nacho

Hola majos,

Perdonar mi desconexión. Hemos tenido múltiples dificultades en el instituto y he querido esperar a implementar lo hablado hasta que tuviera el tema más controlado.

Respecto a que etiquetas asociar la instalación de inicio de sesión de ldap podemos comenzar con:

SEC-SIERRADEGUARA.A02
SEC-SIERRADEGUARA.A26

Si veo que funciona todo correctamente, lo desplegaremos en todo el centro.
Si te parece voy a crear otras incidencias para tema wifi y passwords, así dejo este hilo solo para ldap.

Mejor dejar ésta para ldap solo, si :-)
Ya lo he configurado, así que en la próxima actualización se instalará y configurará el inicio de sesión con opción de ldap (también afectará a los equipos de docente, que estaban con arranque automático a docente). Se hará efectivo en el siguiente reinicio después de la actualización.

Ya nos cuentas como va

-- nacho

Lo probé hace ya casi un mes pero no os había podido escribir.

Funciona muy bien. Este ultimo apaño ha mejorado muchísimo la velocidad de inicio de sesión.
Os felicito, porque va de maravilla.

Yo lo desplegaría ya en todo el centro.
Aun no borraría el usuario estudiante, ya que tardarán un tiempo hasta que se acostumbren y se lo aprendan todos los profes.

Yo lo pondría ya en la etiqueta principal del centro. Para que esté en todos los equipos.

Y en un par de mese te aviso para que borréis el usuario estudiante.
Cualquier cosa ya me dices.

Muchas gracias Nacho.

Yo igual no quitaría la cuenta de estudiante. Si algún día falla la conexión con ldap de google, no podrías iniciar sesión en el equipo, no? Por lo menos les quedaría la cuenta de estudiante...no se

-- nacho