El SysAdmin del 3er Mundo

todo lo que expliqué mientras nadie prestaba atención

ltsp en debian8 y salud

| Comments

Problema

21 de Mayo: La situación de los clientes ligeros en el Calixto no da más. El servidor DHCP del ardence dejó pinchar sin previo aviso. El encargado de los clientes ligeros, reinstaló todo y siguió sin pinchar. Luego determinó que era culpa de un virus. El incha-cojones de Windows vuelve a hacer de la suya. Mientras tanto, el caos se ríe de todos y se frota las manos.

A la novena llamada preguntando “cuando se arreglan los clientes ligeros” determiné que la situación llevaba medidas drásticas, siendo hora de pasar el servidor al lado oscuro de la fuerza.

Plan de migración: El miembro sobre la mesa.

Tiempo estimado: Menos del que te imaginas.

Por un lado, 6 clientes ligeros con un windows XP que se arrastra en los 128 megas de RAM y un servidor dongan de manufactura vietnamita. Por el otro, más de 6 usuarios quejándose porque su sistema funciona lento, cuando le da la gana y además deben reiniciar más de 10 veces al día. Eso sin contar que deben tener la información en memorias flash, porque no se guardan los cambios en las imágenes.

Solución

Linux Terminal Server Project, más conocido como “LTSP”.

Instalar ltsp es un proceso relativamente fácil, sobre todo cuando tienes un tubo de internet a full.

Pero detrás del proxy satánico de infomed; la cosa se vuelve un tanto compleja.

Por suerte, el repo de debian en infomed está bien afinadito y ahora con el tubo de 2 megas, la cosa mejora considerablemente.

Hay dos maneras de hacer esto, la fácil y novel; o la difícil y tediosa. En caso de la fácil, bastará con instalar el paquete “ltsp-server-standalone”; el cual instalará y configurará todo la orquesta de software requerido para pinchar lo que se conoce como ltsp. Entre ellos, el servidor dhcp de ics, el servidor tftp-hpa, la maritrónica que sirve la SWAP por nfs y todo el rebortillo de cosas que requiere NFS.

Corre esto y ponte cómodo, que va pa largo…

“ltsp-build-client”
1
2
3
4
 ltsp-build-client --http-proxy http://127.0.0.1:3128 \
 --mirror http://ftp.sld.cu/debian \
 --security-mirror http://ftp.sld.cu/debian-security \
 --copy-sourceslist --copy-package-cache --accept-unsigned-packages

El comando que corriste, generó un fichero de configuración para el servidor dhcp de isc. Te sugiero que lo uses como DHCP.

1
2
cp /etc/ltsp/dhcpd.conf /etc/dhcp/dhcpd.conf
systemctl restart isc-dhcp-server

Muy importante NFS. En el fichero /etc/exports ponemos esto:

“/etc/exports”
1
/opt/ltsp *(ro,no_root_squash,async,no_subtree_check)

y reiniciamos el servicio de NFS

“reiniciando nfs”
1
systemctl restart nfs-kernel-server

Cuando butees una máquina, el login no te pinchará. Deberás correr esto:

“crear el squash”
1
2
ltsp-update-sshkeys
ltsp-update-image --config-nbd

La imagen que se instaló en /opt no es más que la matriz para crear un squashfs que se le sirve a los clientes. Con ese comando, reflejamos los cambios volviendo a crear la imagen “squashada”.

Con eso te digo que si haces un cambio en la imagen, deberás correr ese comando.

Ahora bien. Para que no queden lagunas mentales:

Todo lo que tendrán los usuarios, ESTÁ EN EL SERVIDOR

Por tanto, hay que instalar una interfaz visual EN EL SERVIDOR. Será lo que los clientes pinchen. Por supuesto, no necesariamente el servidor tiene que correr dicha interfaz. En mi caso yo instalé solo sistema base y luego corrí esto:

“instalar lxde completo”
1
aptitude install task-lxde-desktop

Ahora el servidor está equipado con una interfaz visual, pero no la pincha, ya que no le instalamos ningún “display manager”; por tanto, las X no arrancan. El display manager lo tiene la imagen que levantan los clientes; nada menos que LDM.

Los clientes levantan un LDM e inician sesión remota en el servidor.

¿se entendió?

Toas las instrucciones que cargará esta interfaz gráfica minimalista (el LDM de los clientes ligeros), se declaran en el fichero /opt/ltsp/i386/etc/lts.conf a mi me quedó así la primera versión de este fichero.

“/opt/ltsp/i386/etc/lts.conf”
1
2
3
4
5
6
[default]
    LTSP_CONFIG=True
    SOUND=True
    LOCALDEV=True
    CONFIGURE_X=True
    LDM_SESSION=/usr/bin/startlxde

Dice que está configurado, que tiene sonido, que use dispositivos locales, que configure las X dinámicamente y que arranque lxde como sesión por defecto.

Y ahí empezaron mis problemas. En mi caso, las canchanfletas que usé como clientes ligeros, tenían una tarjeta de video unichrome más extraña que un calsoncillo con tirantes. La pantalla se veía con una capa verde delante. Nunca había visto cosa igual.

Solución. Levanta un cliente ligero, entra en la consola (con Ctrl+Alt+F1) y ejecuta:

“/opt/ltsp/i386/etc/lts.conf”
1
X -configure

Eso te creará el fichero xorg.conf.new EN EL CLIENTE. A ese punto, se habrá generado una configuración de X decente. Pero ese fichero hay que ponerlo EN EL SERVIDOR:

“monta que te queda”
1
scp xorg.conf root@servidor:/opt/ltsp/i386/etc/X11/xorg.conf

Ahora además, al servidor hay que especificarle que las X NO se auto-configuren y que en cambio, usen el fichero dado. Todo eso lo haremos en /opt/ltsp/i386/etc/lts.conf

“/opt/ltsp/i386/etc/lts.conf”
1
2
3
4
5
6
7
8
9
10
[default]
    LTSP_CONFIG=True
    SOUND=True
    LOCALDEV=True
    LDM_SESSION=/usr/bin/startlxde
    CONFIGURE_X=False
    X_CONF=/etc/X11/xorg.conf
    X_MODE_0=1024x768
    MODULE_01 = "usb-storage"
    MODULE_02 = "sd_mod"

Dice ahora que: Está configurado, tiene sonido, dispositivos locales (pa que pinchen las memorias flash), que levante lxde, que NO configure las X, que use el fichero dado, que la resolución de su pantalla 0 (la única) es de 1024x768 y además que meta ese par de módulos, pa que pinchen los puertos USB.

Por supuesto, en el chroot que levanta el cliente, la ruta absoluta /etc/X11/xorg.conf es completamente válida.

¡¡Ah, y no olvides volver a crear la imagen!!

pero de vuelta al servidor

Entre los palos más comunes, vemos uno que al iniciar la sesión dice que el usuario “fulano” no pertenece a netdev y que por tanto, el puñetero data-bus no arranca.

“agregando a netdev”
1
2
adduser fulano netdev
systemctl restart dbus

En el fichero /etc/adduser.conf puedes especificar los parámetros de los nuevos usuarios creados, ahí puedes declarar que se creen con sus pertinentes grupos.

“adduser.conf”
1
2
3
4
5
# Set this if you want the --add_extra_groups option to adduser to add
# new users to other groups.
# This is the list of groups that new non-system users will be added to
# Default:
EXTRA_GROUPS="dialout cdrom audio video plugdev users netdev netdev messagebus pulse lpadmin"

El directorio /etc/skel/ contiene la plantilla para crear el nuevo usuario. Crea un usuario, has la configuración que desees y cópialo pa /etc/skel.

Otro palo común es que las memorias NTFS se montan como solo lectura. Solución, instala ntfs-3g EN EL CHROOT que está en /opt y vuelve a crear la imagen.

Nota para los mentequieta:

Los usuarios se crean EN EL SERVIDOR no en la imagen.

Sugerencias

Cada cosa que los clientes ejecuten, lo harán en el servidor, y puedes ponerte a mirar con htop que proceso se está metiendo la RAM o el CPU, detener dicho proceso y requerir al usuario. Porque verás los procesos y el usuario que lo ejecuta. Déjame recordarte que Linux, es un sistema multitarea y multiusuarios de verdad.

En mi caso, el servidor (los “dongan” vietnamitas) tiene dos discos duros. Monté uno para el sistema y la swap, el otro lo dejé para el /home.

Mi servidor tiene 512 de RAM y aún con 4 clientes ligeros no ha llenado la mitad de la memoria. ¿Dime tu con 1 Giga de RAM?

Por defecto, los homes de los usuarios se crean con permisos que los hace visibles entre si. Ejecuta: “chmod 770 /home/fulano” cada vez que crees un usuario. Si no, el home de este usuario será visible por los demás usuarios.

¿Has pensando que ahora es más fácil hacerle salvas a las cosas? Todo está en el /home.

No olvides decirle al usuario que ahora pueden hacer y guardar cambios en su “perfil” (como ellos le llaman) pues algunos están acostumbrados a que el cliente ligero No guarda cambios.

Puedes decirle a tus usuarios que su perfil puede ser abierto desde cualquier cliente ligero de la flota. Lo cual les da cierta “movilidad”.

Puedes decirle que si su cliente ligero se rompe no se preocupe, que su información está a salvo. Incluso, le recuerdas además que puede abrir su perfil desde otro cliente ligero que esté en la misma flota.

Puedes hacer configuraciones individuales de cada máquina en el fichero /opt/ltsp/i386/etc/lts.conf

En donde dice [default] puedes poner la MAC del cliente.

“/opt/ltsp/i386/etc/lts.conf”
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# configuración genérica
[default]
    LTSP_CONFIG=True
    SOUND=True
    LOCALDEV=True
    LDM_SESSION=/usr/bin/startlxde
    CONFIGURE_X=False
    X_CONF=/etc/X11/xorg.conf
    X_MODE_0=1024x768
    MODULE_01 = "usb-storage"
    MODULE_02 = "sd_mod"

# configuración de un cliente individual el
# jefe no quiere que oiga música ni use
# memorias flash
[00:90:4b:a2:55:05]
    LTSP_CONFIG=True
    SOUND=False
    LOCALDEV=False
    LDM_SESSION=/usr/bin/startlxde
    CONFIGURE_X=True
    X_MODE_0=1024x768

# EOF

Una buena idea, es usar un dhcp con las MAC e ip fijas para cada usuario, sería una mejor manera de cortar el bacalao. Así el servidor solo le respondería a sus clientes. Además, en caso de tener múltiples servidores de clientes ligeros, no tendrás otra opción, pues si no, cada cliente ligero buteará por donde mejor la parezca y seguro no querrás eso.

En el servidor DHCP central, rechaza las MAC de los clientes si se dirigen al puerto 67, para que no reciban dicho servicio, así lo obligas a bootear por el servidor de clientes ligeros.

“iptables”
1
2
iptables -A INPUT -p tcp --dport 67 -m mac --mac-source 00:90:4b:a2:55:05 -j DROP
iptables -A INPUT -p udp --dport 67 -m mac --mac-source 00:90:4b:a2:55:05 -j DROP

Lo ideal sería que el DHCP central tuviera las direcciones MAC de los clientes y le diera los parámetros de buteo a cada cual, pero eso aún no lo he logrado. Hay algo que tiene que ver con el parámetro “next server”. He logrado que estos den con el tftp adecuado, pero luego tratan de contactar al propio servidor DHCP como servidor NFS.

También podrías tener un firewall en el servidor de clientes ligeros. Que permite el DHCP solo a las MAC de los clientes. Así no le das DHCP a cualquiera. Además, podrías decirle también a ese servidor, que solo permite el tráfico de las MAC de los clientes ligeros. No me parece que un servidor como ese tenga que ser alcanzado por otra máquina.

Si este artículo te resultó interesante, considere donar 0.07 BTC: 1Kg4gu3e7u8HUw8bj5NbBciRg6Y56kuFCU

Comments