Está en la página 1de 16

LTSP 5 – HOWTO

Autor: Luis Roberto Romano luisromano(at)gmail.com

Procedimiento de instalación.

En este caso en particular, se instalará el servidor LTSP y el DHCP en un mismo equipo. Para ello se procede a instalar los paquetes ltsp-standalone-server, openssh-server y ldm-server.

# aptitude install ltsp­server­standalone openssh­server \ ldm­server openbsd­inetd

Luego, se procede a construir el entorno del cliente

#

ltsp­build­client

Si

el servidor corre sobre una arquitectura diferente que los clientes (ej: amd64 vs i386),

debemos agregar el parámetro ­­arch=i386.

# ltsp­build­client ­­arch=i386

Esto descargará un sistema Debian completo en /opt/ltsp/i386 (o en otra ubicación específica mediante el parametro '­­base') e instalará los paquetes ltsp-client y ldm (LTSP Display Manager). Para que los clientes puedan acceder a un entorno gráfico, será necesario que en el servidor esté instalado alguno como gnome o xfce. Éste último es recomendable por ser particularmente liviano, pero no por ello menos usable.

Si queremos que los paquetes se descarguen desde un repositorio en particular, hacemos uso

del parámetro ­­mirror

# ltsp­build­client ­­arch=i386 ­­mirror=<url_del_mirror> \ ­­security­mirror=none ­­accept­unsigned­packages

A continuación, se procede a configurar el servicio DHCP. Éste es necesario para que, al

momento del booteo, cada cliente obtenga una dirección IP que lo identifique dentro de la red. EL paquete LTSP incluye un archivo de configuración para dicho servicio, el mismo se encuentra en

/etc/ltsp/dhcpd.conf

Es recomendable colocar los terminales en una red separada (para no introducir una innecesaria sobrecarga en la red). Para ello, el servidor LTSP deberá contar con 2 interfaces de red:

Una de cara a los clientes y la otra de cara al “mundo exterior”.

Supongamos un escenario dentro de una red privada 192.168.2.0/24. Podemos definir dentro de ella otra subred dedicada al entorno LTSP. Configuraremos una de las interfaces del servidor con alguna dirección de la red anteriormente mencionada. Pondremos en este ejemplo 192.168.2.10

Confguraremos una red aparte para el entorno LTSP. Utilizaremos la dirección

192.168.15.0/24. En este ejemplo, pondremos en la otra interfaz del servidor la dirección

192.168.15.1

El archivo de configuración /etc/network/interfaces quedaría de la siguiente manera:

# The loopback network interface auto lo iface lo inet loopback

# The primary network interface

# allow­hotplug eth1 auto eth1 iface eth1 inet static address 192.168.2.10 netmask 255.255.255.0 gateway 192.168.2.1

auto eth0 iface eth0 inet static address 192.168.15.1 netmask 255.255.255.0

Como vemos, la interfaz del lado “de afuera” es la eth1 y la que da de cara a los clientes es la

eth0.

Procedemos a editar el archivo /etc/ltsp/dhcpd.conf manera:

#

#

Default LTSP dhcpd.conf config file.

#

authoritative;

para que quede de la siguiente

subnet 192.168.15.0 netmask 255.255.255.0 { range 192.168.15.100 192.168.15.200; option domain­name "fl.unc.edu.ar";

 

#

option domain­name­servers 192.168.0.1; option broadcast­address 192.168.15.255;

#

option routers 192.168.0.1; next­server 192.168.15.1;

#

get­lease­hostnames true; option subnet­mask 255.255.255.0; option root­path "/opt/ltsp/i386"; if substring( option vendor­class­identifier, 0, 9 ) = "PXEClient"

{

 

filename "/ltsp/i386/pxelinux.0"; } else { filename "/ltsp/i386/nbi.img";

}

 

}

Hay que tener en cuenta aquí que la opción next-server debe apuntar al servidor LTSP. En este caso, es el propio servidor DHCP (como se mencionó antes). El dominio fl.unc.edu.ar se provee como ejemplo.

Para que tome control el archivo que se editó anteriormente, se debe editar el fichero /etc/dhcp3/dhcpd.conf y agregar al principio del mismo la siguiente línea:

include "/etc/ltsp/dhcpd.conf";

Se reinicia el servicio DHCP

# /etc/init.d/isc­dhcp­server restart

Se procede a configurar el archivo /etc/exports, agregando la siguiente línea:

/opt/ltsp *(ro,no_root_squash,async,no_subtree_check)

Se reinicia el servidor NFS

# invoke­rc.d nfs­kernel­server restart

Se reinicia el servicio tftpd (el cual es utilizado para transferir el kernel desde el servidor hacia el cliente):

# invoke­rc.d openbsd­inetd restart

En este momento, el servidor está listo para recibir conexiones de parte de los clientes delgados.

Preparación de los clientes.

Para el booteo de los clientes, utilizaremos gPXE en diskettes floppy de 1.44 MB. El mismo se aloja en un repositorio git, por lo cual deberemos instalar el paquete necesario:

# aptitude install git

Luego, procedemos a descargar gPXE

# git clone git://git.etherboot.org/scm/gpxe.git

Para poder compilarlo, son necesarios un par de paquetes extra:

# aptitude install syslinux mtools

Una vez

compilación:

instalados,

# cd gpxe/src

# make

se debe

ingresar al directorio

generado (gpxe),

y proceder a

la

Ahora, se procede a escribir la imagen gPXE a un diskette:

# mformat a:

# cat bin/gpxe.dsk > /dev/fd0

Este último comando escribe la imagen al diskette. Esto puede hacerse tambien mediante el siguiente comando

# dd if=bin/gpxe.dsk of=/dev/fd0

Ahora el cliente está en condiciones de bootear y establecer la conexión con el servidor. Se inserta el diskette en la unidad floppy del cliente y se configura el mismo para que bootee desde dicha unidad.

En el servidor, antes de que cualquier cliente botee por primera vez, se debe ejecutar este comando:

# ltsp­update­sshkeys

Creando cuentas de usuario para los clientes.

Las cuentas de usuario se crean mediante el comando adduser:

# adduser <nombre_de_usuario>

A partir de allí el sistema creará el usuario, incuyendo un directorio personal en /home/<nombre_de_usuario>. Tambien se solicitarán datos del mismo (el más importante de ellos es la contraseña). Por defecto, el directorio personal se crea con permisos totales para el propietario del mismo, y permisos de lectura para el resto de los usuarios. Si se desea restringir el acceso al mismo sólo al propietario, se deben modificar los permisos mediante el siguiente comando:

chmod 700 /home/<nombre_de_usuario>

El entorno chroot

Se denomina entorno chroot a una versión minimalista de GNU/Linux, diseñada para optimizar el booteo por red que tiene que efectuar el cliente.

Puede encontrarse en /opt/ltsp, con subdirectorios

para cada arquitectura. En este caso

particular, como se está instalando sobre una arquitectura i386, se encontrará en /opt/ltsp/i386.

Para actualizar el entorno chroot, se deberá abrir una consola con privilegios de root, y ejecutar los siguientes comandos:

En primer lugar, se debe copiar la lista de repositorios hacia el entorno chroot:

# cp /etc/apt/sources.list /opt/ltsp/i386/etc/apt/

Luego, se procede a cambiar el directorio raíz hacia el entorno chroot LTSP

# chroot /opt/ltsp/i386/

Una vez allí, se efectúa la actualización de la lista de paquetes

# apt­get update

Luego, se monta el directorio /proc

# mount ­t proc /proc /proc

Luego, se actualiza el software en el entorno chroot

# apt­get upgrade.

Una vez hecho esto, se sale del entorno chroot mediante el comando exit, o la combinación de teclas Ctrl+D. Si el kernel ha sido actualizado, se deberá registrar dicha actualización

# ltsp­update­kernels

Configurando el comportamiento de los clientes

La mayoría de los clientes se autoconfigurará automáticamente en forma correcta. Sin embargo, algunas veces puede ser necesario personalizar los parámetros que están en el archivo de

configuración /opt/ltsp/i386/etc/lts.conf

Formato del archivo lts.conf

El formato del archivo lts.conf admite una configuración por defecto, así como también configuraciones individuales. Si se cuenta con máquinas cliente idénticas, se puede especificar todos los ajustes de configuración en la sección [default] (como se explicará posteriormente).

Encabezados de sección.

Los encabezados de sección comienzan con un identificador de la forma [default], el cual es utilizado por todas las computadoras (como se mencionó anteriormente), y [Direccion MAC] para estaciones en particular, de la forma [XX:XX:XX:XX:XX:XX], donde X es un valor hexadecimal q va de 0 a F.

Asignación de variables.

Después del encabezado de sección, se pueden definir variables. Éstas son valores booleanos que se setean con los valores True / False, Yes / No, o bien Y / N. Tambien hay variables no boobleanas de la forma

VARIABLE = valor

Se puede insertar comentarios utilizando el caracter #. Todo lo que esté a continuación de dicho caracter en el resto de la línea se considerará un comentario.

La palabra clave LIKE

La palabra clave LIKE permite definir un conjunto general de parámetros bajo un identificador único, y luego asignar a estaciones particulares ese conjunto de parámetros. Se ilustrará el uso mediante un ejemplo.

Suponer que se tienen 3 tipos de clientes delgados en la red. Un grupo, el cual será utilizado en el laboratorio tiene placas de video viejas y deben usar color en 16 bit a 1024 x 768. Otro grupo necesita tener su memoria RAM de video seteada a 8 megas. Y un tercer grupo autodetecta todo en forma correcta. No es necesario especificar nada para este último grupo, pero para los otros puede utilizarse algunos nombres simbólicos como se muestra a continuación:

[Lab] X_COLOR_DEPTH = 16 X_MODE_0 = 1024x768

[Lowram] X_VIDEO_RAM = 8096

[00:40:32:71:77:A1]

LIKE = Lab

[00:70:84:BB:27:52]

LIKE = Lowram

Como se puede ver, usando la palabra clave LIKE se puede confeccionar un archivo lts.conf más prolijo, agrupando parámetros relacionados dentro de un único nombre simbólico.

A continuación, se transcribe un ejemplo del archivo lts.conf

################ [default]

#X_COLOR_DEPTH=16

LOCALDEV=True SOUND=True NBD_SWAP=True SYSLOG_HOST=server #XKBLAYOUT=de

SCREEN_02=shell

SCREEN_03=shell

SCREEN_04=shell

SCREEN_05=shell

SCREEN_06=shell

SCREEN_07=ldm

# LDM_DIRECTX=True allows greater scalability and performance

# Turn this off if you want greater security instead. LDM_DIRECTX=True

# LDM_SYSLOG=True writes to server’s syslog LDM_SYSLOG=True

################

# A setting stanza for an old machine ################

[oldmachine]

X_COLOR_DEPTH=8

X_MODE_0=800x600

################

# Example of the LIKE variable ################

[01:23:DE:AD:BE:EF]

LIKE=oldmachine

SCREEN_02=shell

################ #[MAC ADDRESS]: Per thin client settings ################

[00:11:25:84:CE:BA]

XSERVER = vesa

X_MOUSE_DEVICE=/dev/ttyS0

X_MOUSE_PROTOCOL=intellimouse

###############

# A Thin Client Print server

# (switch off X by pointing tty7 to shell,

# to save ressources) ###############

[00:11:25:93:CF:00]

PRINTER_0_DEVICE=/dev/usblp0

SCREEN_07=shell

###############

# A workstation that executes a specific

# command after login ###############

[00:11:25:93:CF:02]

LDM_SESSION=/usr/bin/myloginscript

Parámetros de configuración general.

(Nota: Para una explicación más detallada, revisar la documentación oficial del proyecto LTSP.)

LOCALDEV Booleano. Habilita los dispositivos de almacenamiento local en el cliente.

SOUND Booleano. Habilita el sonido en el cliente delgado.

SOUND_DAEMON Servicio de Sonido. Valores posibles: esd, nasd, pulse.

SCREEN_01

SCREEN_12

Script de inicio de sesion. Se pueden configurar hasta un máximo de 12, siendo accesibles mediante la combinacion ctrl+alt+F1 hasta ctrl+alt+F12. Por defecto, no es necesario configurar este parámetro. Valores posibles: rdesktop, shell, ldm, startx, telnet.

MODULE_01

Modulos a cargar en el booteo. Por defecto no deberia ser necesario.

MODULE_10

CONFIGURE_X Booleano. Permite configurar los parámetros de video en el cliente delgado.

X_RAMPERC Valor entero. Define el porcentaje de memoria libre en el cliente que será utilizado por el servidor Xorg. Valor por defecto: 100. Si la estación comienza a experimentar cuelgues, se recomienda setear este valor a 80 o 90.

X_MOUSE_DEVICE Device node al cual está conectado el mouse. Necesario en caso de utilizar un mouse serial. Será /dev/ttyS0 o /dev/ttyS1. No es necesario en caso de mouse PS/2.

X_MOUSE_PROTOCOL Protocolo del mouse. Debería ser autodetectado. En caso de no serlo, los posibles valores son:

sunkbd, lkkbd, vsxxxaa, spaceorb, spaceball, magellan, warrior, stinger, mousesystems, sunmouse, microsoft, mshack, mouseman, intellimouse, mmwheel, iforce, h3600ts, stowawaykbd, ps2serkbd, twiddler, twiddlerjoy

X_COLOR_DEPTH Valor entero. Indica la profundidad de color en bits para el video. Valores posibles: 8, 16, 24,

32.

LDM_DIRECTX Booleano. Seteado a True, deshabilita el cifrado SSH en la conexión entre el cliente y el servidor. Recomendado en caso de necesitar incremento de rendimiento en el cliente (si se puede sacrificar el aspecto de la seguridad).

LDM_AUTOLOGIN Booleano. Permite el autologueo en el servidor, tomando como usuario y contraseña los siguientes 2 parámetros, mencionados a continuación.

LDM_USERNAME Nombre de usuario usado por autologin.

LDM_PASSWORD Password del usuario usado por autologin.

Habilitando el almacenamiento local.

Puede ser útil para el usuario, disponer de los dispositivos de almacenamiento local, sobre todo el caso de pendrives. Para ello se deberá seguir los siguientes pasos:

Agregar el siguiente parámetro en /opt/ltsp/i386/etc/lts.conf

LOCALDEV = True

El almacenamiento en dispositivos locales para los clientes es manejado por el paquete fuse. Por lo tanto, cada usuario asociado a un cliente delgado deberá ser miembro del grupo fuse.

Agregamos cada usuario al grupo fuse:

# adduser <usuario_ltsp> fuse

Si la configuración se deja así, sin ninguna otra modificación, se podrá notar que en cada acceso a alguna unidad de almacenamiento local en el cliente, la unidad floppy efectuará una lectura, causando una demora innecesaria y un ruido que puede llegar a ser muy molesto. Para solucionar este problema, se debe proceder a editar el archivo

/opt/ltsp/i386/lib/udev/rules.d/60­ltspfsd.rules

Se procede a buscar las siguientes líneas

# legacy floppy drives:

ACTION=="add", KERNEL=="fd[0­9]", RUN+="ltspfs_entry add %k auto"

Y se comenta (mediante el caracter #) la segunda, con lo cual quedaría de la siguiente manera

# legacy floppy drives:

# ACTION=="add", KERNEL=="fd[0­9]", RUN+="ltspfs_entry add %k auto"

Aspectos varios.

Problema con placas realtek 8139.

Un mensaje de advertencia suele ser mostrado en algunos clientes que cuentan con placas de red Realtek 8139. El mismo advierte sobre un problema de compatibilidad de las mismas con el módulo correspondiente del kernel, y sugiere reemplazarlo por otro módulo (8139too).

Para solucionar esto, se deben seguir los siguientes pasos:

Editar el archivo /opt/ltsp/i386/etc/initramfs­tools/modules y agregar el

módulo:

8139too

Editar el archivo /opt/ltsp/i386/usr/share/initramfs­tools/hook­functions y

agregar el módulo “8139too” al final de la siguiente línea:

r8169 s2io sis900 skge slhc smc911x starfire sky2 \

Luego, en el entorno chroot, montar /proc actualizar el initramfs:

# chroot /opt/ltsp/i386 mount ­t proc /proc /proc

# chroot /opt/ltsp/i386 update­initramfs ­u

Actualizar:

# ltsp­update­kernels

Configuracion para clientes con mouse serial.

El siguiente es un ejemplo de configuración del archivo lts.conf para un cliente que utiliza un mouse serial.

[Client_MAC_Address] X_MOUSE_DEVICE = /dev/ttyS0 X_MOUSE_PROTOCOL = Microsoft X_MOUSE_EMULATE3BTN = True X_MOUSE_ZAXISMAPPING = 4 5 6 7

Montar y extraer pendrives en forma segura.

LTSP monta cualquier dispositivo USB unos segundos después de ser conectado. Por ello, resultaría de gran utilidad confeccionar un script que muestre un mensaje al usuario mientras se está produciendo el montaje del dispositivo.

El script podría tener la siguiente forma:

#!/bin/sh

(

echo "10" ; sleep 1 echo "# Montando Pendrive" ; sleep 1 echo "20" ; sleep 1 echo "100" ; sleep 1 echo "# Pendrive listo para usar" ;

|

) zenity ­­progress \ ­­title="Montando pendrive" \

­­text="Montando

­­percentage=0

"

\

if [ "$?" = ­1 ] ; then zenity ­­error \ ­­text="Update canceled."

fi

Thunar /media/$USER/usbdisk­sda1

El mismo hace uso de la utilidad zenity, que sirve para crear cuadros de diálogo GTK usando comandos de consola. En la línea final puede verse una invocación al gestor de archivos Thunar, que es el que viene incluido por defecto en el entorno gráfico xfce. En caso de usar otro entorno, reemplazar dicha llamada por la correspondiente al gestor de archivos asociado a dicho entorno. En gnome, por ejemplo, deberíamos invocar a nautilus.

La llamada apunta al directorio /media/$USER/usbdisk­sda1, ya que es allí donde LTSP monta los dispositivos USB.

La extracción de pendrives puede realizarse en cualquier momento, siempre y cuando el sistema haya terminado de efectuar cualquier operación de lectura/escritura sobre el dispositivo. Por ello, sería deseable contar con alguna herramienta que genere alguna especie de “demora” que evite que el usuario extraiga el medio en forma precipitada y provoque eventualmente algún tipo de fallo en el sistema de archivos de la unidad.

El script puede tener la siguiente forma:

#!/bin/sh

(

echo "10" ; sleep 1 echo "# Espere un momento" ; sleep 1 echo "20" ; sleep 1 echo "# Espere un momento" ; sleep 1 echo "50" ; sleep 1 echo "# Espere un momento" ; sleep 1 echo "75" ; sleep 1 echo "# Espere un momento" ; sleep 1 echo "75" ; sleep 1 echo "# Espere un momento" ; sleep 1 echo "100" ; sleep 1 echo "# Puede desconectar su pendrive" ;

|

) zenity ­­progress \ ­­title="Desconectar Pendrive" \

­­text="Desconectando

"

\

­­percentage=0

if [ "$?" = ­1 ] ; then zenity ­­error \ ­­text="Update canceled."

fi

Podemos ver que es similar al anterior. En este caso, se genera un retardo de 10 segundos, suficiente como para que finalicen todas las operaciones de lectura/escritura.

Instalar aplicaciones en el servidor.

Para este caso en particular, se ha solicitado que los clientes puedan:

Contar con una suite ofimática

Navegación web

Compatibilidad con Java

Suite ofimática.

Para la suite ofimática se ha optado por OpenOffice 3.1, debido a su alta compatibilidad con la suite Office de Microsoft (hay que admitir que la mayoría de los usuarios utilizan ésta última en sus casas).

Para su instalación, se descargan los paquetes correspondientes vía aptitude:

# aptitude install openoffice.org openoffice.org­l10n­es

Navegación web.

Optaremos por Google Chrome, por ser éste un navegador liviano y de muy fácil uso. Lo podemos descargar desde la página oficial www.google.com/chrome. Por tratarse este caso de un sistema Debian, tendremos que bajar el navegador en un paquete .deb

Una vez descargado, procedemos a su instalación:

# cd <directorio_de_la_descarga>

# dpkg ­i google­chrome­stable_current_amd64.deb

Para que se puedan visualizar las páginas con contenido flash, instalamos el plugin:

# aptitude install flashplugin­nonfree

Compatibilidad con aplicaciones Java.

Finalmente, para poder ejecutar aplicaciones escritas en lenguaje Java, instalamos la máquina virtual de Sun

# aptitude install sun­java6­jre sun­java6­plugin

Para asegurarnos de que el sistema use dicha máquina virtual y no otra, tenemos que registrarla de la siguiente manera:

# update­alternatives ­­install "/usr/bin/java" "java" \ "/usr/lib/jvm/java­6­sun/bin/java" 1

# update­alternatives ­­set java /usr/lib/jvm/java­6­sun/bin/java

Algunos aspectos administrativos.

Terminar un proceso.

Para matar un proceso que se está ejecutando por algun usuario en particular, se hace uso de una serie de comandos, detallada a continuación.

Para ver la lista de procesos que está corriendo un determinado usuario se hace uso del comando

# ps w ­u <nombre_de_usuario>

Para matar un proceso en particular se hace

# killall ­u <nombre_de_usuario> <nombre_del_proceso>