Por desgracia, da la impresión que el soporte para thinclients está cada vez mas dejado y nos cuesta trabajito tenerlo operativo.
Durante el todo el curso me han venido advirtiendo de un problema recurrente: cuando un thinclient en el que estaba trabajando un alumno quedaba colgado o se apagaba (el hardware sobre el que corren tiene sus achaques), el alumno ya no podía iniciar sesión en ese u otro thinclient con sus credenciales hasta pasado un tiempo, ya que era expulsado de la sesión a cada intento de entrada. Tenía que usar las de otro usuario para entrar. En los últimos tiempos este problema se había convertido en una manera de interrumpir el desarrollo de la clase para un grupito de alumnos graciosetes.
Mirando lo que pasaba advertimos que se habían quedado un montón de procesos a nombre del usuario abiertos y alguno de ellos bloqueaba el nuevo inicio de sesión. Esto se mantenía así hasta que esos procesos morían (pasado un tiempo o con el reinicio del LTSP).
Una manera rápida de liberar esos procesos es matarlos con uno de los varios comandos que hay para ello, por ejemplo:
# killall -9 -u usuario
Vamos a repasar como se inicia sesión en un thinclient y dilucidar que está fallando.
1. Proceso de inicio de sesión en thinclients.
Los thinclients usan como display manager ldm, que a diferencia de lightdm y similares, establece una conexión ssh con el servidor de aula para iniciar la sesión en él.
Toda la imagen de disco con el que funcionan los thinclients cuelga de la ruta /opt/ltsp/i386 de los servidores de aula. En esa ruta está el fichero /usr/share/ldm/ldm-script, que se ejecuta desde ldm y que lanza los scripts que hay en /usr/share/ldm/rc.d/.
ldm-script recibe un parámetro en $1 que puede tener los valores init/pressh/start/xsession/stop, tal como se ve en este "case", donde se indica en los comentarios a que evento del inicio de sesión está ligado cada valor:
case "${ACTION}" in
init)
# From ldm.c: LDM has just started, X is running, the greeter isn't.
SCRIPTS="I*"
;;
pressh)
# From ssh.c: a username/password was provided, no connection yet.
SCRIPTS="P*"
;;
start)
# From ssh.c: an ssh connection was established.
SCRIPTS="S*"
;;
xsession)
# From plugin.c: an xsession was started (maybe even rdp).
SCRIPTS="X*"
;;
stop)
# From screen.d/ldm.c: the xsession has ended.
SCRIPTS="K*"
;;
esac
I00-localapps-cleanup
I01-halt-check
I01-nbd-checkupdate
K99-ltsp-cluster
K99_seguimiento_usuario
P00-ltsp-cluster
S01-setup-xauth
S15-userLoginCheck
S20-restrictUser
S99-debug-terminal
S99-ltsp-cluster
S99_seguimiento_usuario
X01-localapps
X01-remoteapps
X02-genmenu
X10-delayed-mounter
X50-dmrc-processing
X50-generate-env
X50-printers
X51-localapps
X51-opengl
X51-remoteapps
X52-xcompmgr
X95-run-x-session
X98-delayed-mounter
X99-ltsp-logout-action
2. Inicio de sesión de usuario.
Los scripts comenzados por "S" son los que se ejecutan una vez el usuario ha tecleado usuario y contraseña, se ha establecido conexión ssh y se va a iniciar sesión gráfica.
Entre estos script hay uno llamado /usr/share/ldm/rc.d/S15-userLoginCheck cuya función es comprobar si LDM_LIMIT_ONE_SESSION es true y en caso afirmativo, matar todos los procesos previos del usuario. LDM_LIMIT_ONE_SESSION es una variable definida en /etc/lts.conf y tiene como función "Only allow a given user to log into one thin-client at a time", es decir, solo se permite que un usuario haga login en único thinclient al mismo tiempo. Para ello el script S15-userLoginCheck mata todos los procesos y sesiones previas del usuario.
Bien, pues esto que ha venido funcionando durante años, ahora con Ubuntu 18 ha dejado de funcionar. Y como consecuencia de ello tenemos el problema que estamos comentando en esta entrada.
Si miramos en todos los scripts de rc.d vemos que en muchos de ellos se usan las variables LDM_SOCKET, LDM_SERVER y LDM_USERNAME, que deberían contener respectivamente el socket de la conexión ssh entre thinclient y LTSP, la IP del LTSP y el nombre del usuario que está iniciando sesión. Bien, pues aunque antaño estas variables tenían valores correctos, hace ya tiempo que vienen vacías. Esto hace que muchos de los scripts de rc.d no hagan nada.
Podemos solucionar esto dando los valores adecuados a esas variables en cada script, que tras un proceso de investigación averiguamos que consiste en añadir las líneas:
LDM_SOCKET=$(ls -1 /var/run/ldm_socket* | head -1)
LDM_SERVER=192.168.0.254
LDM_USERNAME=$(ssh -S $LDM_SOCKET $LDM_SERVER "id -un")
Pero es que incluso después de poner las líneas arriba indicadas dentro de S15-userLoginCheck con la esperanza de que volviese a funcionar la matanza de procesos previos del usuario pude comprobar que seguía sin funcionar, y que por desgracia no se podía iniciar sesión por segunda vez. Podría haberme puesto a depurar el código de S15-userLoginCheck, pero antes se me han cruzado un par de asuntos que han solucionado el problema por otra vía.
3. Solución.
Recordé que en /etc/lts.conf había una variable llamada LDM_DIRECTX, que tradicionalmente habíamos tenido con valor False, que es el valor que trae por defecto. Cuando vale False toda la sesión entre thinclient y LTSP se hace cifrada por el túnel ssh, lo cual aporta de seguridad a costa de hacer mas lento el escritorio por sobrecarga de trabajo del thinclient. Un compañero sugirió probar con LDM_DIRECTX = True, que evita el uso de este tunel ssh y lo cierto es que el escritorio de los thinclients iba sensiblemente mas rápido, así que la dejamos con True.
Haciendo caso a un pálpito cambié LDM_DIRECTX = False y regeneré la imagen de thinclients...y ¡voilá!, volvía a funcionar S15-userLoginCheck y un alumno podía iniciar sesión en cualquier lado sin problema, provocando el cierre de la sesión previa. Como contrapartida tenemos que el escritorio de los thinclients quedaba un poco mas lento. ¿Causa de que se arreglase el desaguisado? Je ne sais pas.
No todo queda aquí, en una sincronicidad al poco tiempo otro compañero nos reveló un método para que se liquidasen los procesos de los usuarios que han cerrado sesión, consistente en añadir a /etc/systemd/logind.conf (en nuestro caso, del servidor LTSP) la línea:
KillUserProcesses=yes
No tenía mucha confianza de que funcionase con los thinclients, pero probé a realizar estos pasos:
- Añadir KillUserProcesses=yes a logind.conf.
- Reiniciar el servicio systemd-logind.
- Poner LDM_DIRECTX = True en lts.conf.
- Regenerar imagen de thinclients con ltsp-update-image
He podido verificar con alegría que ahora si funcionaba todo bien como antiguamente. Al final el truco para arreglar todo no estaba en nada relacionado con LTSP, sino con logind.conf.
En conclusión: larga vida a los thinclients.
El 22 de febrero pasado la sonda japonesa Hayabusa 2 le dió un piquito al asteoride Ryugu para recoger muestras antes de traerlas a casa:
No es Bruce Willis y su equipo de perforadores de Armageddon, pero la hazaña de llegar hasta un pedrolo de 435 metros, orbitarlo, aterrizar con éxito 2 rovers del tamaño de una Roomba y acercarse a la superficie para chocar suavemente con ella y recoger muestras no es moco de pavo.
En la primera temporada de True Detective el detective Rust observa un grupo de fanáticos religiosos baptistas y sentencia "míralos: estos nunca fisionarán el átomo". Ni aterrizarán en un asteroide.
