DPD Thinstation
De Gleducar, http://www.gleducar.org.ar
Introducción
El siguiente artículo va a intentar explicar como funciona un sistema de Terminal Server y como interactua el ya conocido por Uds GNU/Linux en el escenario. Inicialmente vamos a contestar las siguientes interrogantes: Qué es un Servidor de Terminales? Qué es un ThinClient? Qué ventajas técnicas aporta el modelo de terminales? Para todo esto vamos a basarnos en el proyecto mas conocido: el "Linux Terminal Server Project", LTSP desde ahora y a mencionar otras alternativas. En cuanto a lo técnico vamos a comenzar por explicar que servicios de red están involucrados para la puesta en marcha del sistema, los archivos de configuración y algunos tips para sacar andando la base para luego montar arriba nuestro LTSP. Una vez completado esto vamos a hablar un poco sobre como relacionarlo con plataformas Microsoft, cuales son los problemas mas comunes, el hardware recomendado y muchas experiencias personales de haber puesto en producción un esquema de terminal server con 1000 clientes y 30 servidores de terminales. Les anticipo que vamos a ver como interactuan algunos servicios con el tema del artículo asumiendo que el lector tiene algunos conocimientos de como configurarlos, sólo vamos a abarcar los cambios que hacen falta para relacionarlo el sistema de Terminal Server. El artículo no está orientado a que aprendan de cero a utilizar NFS, DHCP, DNS, sino a que conozcan como se relacionan con el LTSP.
¿Qué es un Servidor de Terminales?
Es un servidor con mucha pontencia de procesamiento donde corren localmente aplicaciones. Es un "servidor de aplicaciones". Servidor donde podemos ofrecer a N cantidad de clientes conectarse por red con aplicativos como el VNC, citrix, remote desktop, X, entre otros y así utilizar los recursos del mismo. Cuando nos referímos a utilizar los recursos del servidor es porque es claro que nuestro Terminal Server tiene muchos mas recursos y prestaciones que nuestro cliente, quien bien podría ser un hardware obsoleto donde jamás imaginaríamos que podría correr el openoffice o firefox en su última versión. El Sistema Operativo del servidor podría ser GNU/Linux o Microsoft.
¿Qué es un ThinClient?
Popularmente conocidas como terminales bobas, terminales sin disco, clientes delgados, etc. Son en su mayoría equipos obsoletos y antiguos que pueden o no tener un sistema operativo instalado pero que son utilizadas para conectarse a un Servidor de Terminales utilizando los recursos del servidor para ejecutar aplicaciones localmente. Estos clientes pueden ser desde equipos muy viejos, como pcs PII con 32mb de ram, sin diskettera, sin lectora de cdroms, sin disco rigido, pero con placas de red PXE que posibilitan el inicio por red. El Sistema Operativo del cliente es exclusivamente GNU/Linux, pudiendo conectarse a un Servidor de Terminales GNU/Linux o Microsoft. La pc se convierte en un televisor donde vemos lo que corre en el "Servidor de Terminales".
¿Qué ventajas aporta el modelo?
Las ventajas son muchas, limitarlo a algo económico sería un claro error. Para explicar y justificar el modelo de terminales podríamos hacer una analogía con un servidor web. Cúantos de Uds tienen un servidor web con google y todas las busquedas imaginables en su pc? Justifica que cada uno de las personas que trabajan en una empresa tengan un servidor web y todos los sitios web en su pc? Volvamos a la realidad y utilicemos un procesador de texto para explicarlo. Hace falta que todos tengan un procesador de texto instalado en su pc? No es demasiado trabajo dar soporte para 40 estaciones de trabajo con 40 procesadores de texto? No sería mejor administrar UN procesador de texto y que todos los usuarios utilicen el mismo? La misma instalación perfecta donde Uds ya configuraron todo como tiene que ser? Bueno, no es una loca idea, google tiene sus X servidores web y Uds no tiene una copia local de todas las busquedas de google. Se conectan, lo usan y listo. Esa misma idea es la que aplica el Servidor de Terminales pero con las aplicaciones que Uds instalen en él.
- No se instala localmente software en ningún ThinClient todo está en el Servidor de Terminales.
- No hay documentos locales en ninguna maquina. Haciendo backup del servidor se hace un resguardo REAL de toda la información de todos los usuarios.
- La actualización de un software para todos los usuarios se hace en UN equipo, el Servidor de Terminales. No en 40 estaciones de trabajo.
- La estación de trabajo local pasa a ser un dispositivo ofimático mas, como un fax o teléfono. No tiene documentos, no tiene software, hasta podría no tener disco rigido. Se rompió? Se cambia por otra y todo está donde estaba sin ninguna demora.
- La incorporación de nuevos usuarios es inmediata. Simplemente se da de alta el usuario y puede utilizar cualquier equipo de la red.
- La mudanza de usuarios no existe mas, el usuario se puede sentar en cualquier estación de trabajo que va a tener todos sus documentos disponibles, sus correos, su configuración, su escritorio, TODO.
Todo lo mencionado impacta directamente en el soporte, tanto en cantidad de informáticos por usuarios como en la demora para una solución. Por un lado porque el hardware es un teléfono, se cambia uno por otro. A eso se suma la clara limitación que van a tener los usuarios para personalizar la estación de trabajo (que seamos realistas, una pc todo personalizada es un problema), el dinamismo para instalar software o actualizarlo y la posibilidad de ofrecer soporte remoto a los usuarios para resolver los problemas que sean de aplicativos. Tengan presente que en ningún momento mencioné un aspecto económico. La realidad es que obviamente ventajas hay, no utilizamos hardware obsoleto en los clientes exclusivamente por una ventaja operativa. Sin entrar a hacer cuentas, la cantidad de licencias en un entorno Microsoft es menor que si tuvieran que instalar en cada PC un disco rigido con un sistema operativo Microsoft. Atentos porque igual existe la licencia de uso de Terminal Server.
¿Qué es el LTSP?
El LTSP el sistema operativo base de un ThinClient. El sitio oficial es www.ltsp.org y ahí van a poder encontrar la última versión del producto disponible, siendo la versión 4.2 al momento de escribir la nota. Éste sistema operativo tiene una serie de funcionalidades para reconocer el hardware, autoconfigurarse, detectar la red y se conectarse al servidor de terminales correspondiente. Es simplemente un GNU/Linux reducido que inicia de red.
¿Cúales son los requerimientos mínimos de hardware de un cliente?
Lo mínimo que pide el sistema son 32mb de ram, un equipo 486 en adelante y fundamental tener una placa de red de 10mb o superior. Casi que ninguna pc queda excluida de esa configuración, pero en la práctica van a ver que con una red de 100mb, 64mb (para evitar el uso de swap) y un microprocesador de 600mhz van a hacer maravillas. Imaginen que estamos hablando de un hardware totalmente obsoleto donde en las mas salvajes fantasias sólo podrían ver en algo así funcinando el Evolution en un Terminal Server Linux o la última versión del Microsoft Office en un Terminal Server Windows.
Van a tener varios problemas sí quieren usar scanners, dado que el sane (que es el aplicativo para darle soporte a los scanners) no tiene naturalmente soporte para todos los scanners que hay.
El tema impresoras van a tenerlo resuelto, usen Windows o GNU/Linux para los servidores, porque en ambos sistemas es algo que funciona bien. Sí tienen un gran volumen de impresora no duden en tener un servidor de impresión administrando el asunto. Las grabadoras de cd y dvd son un problema, imaginense que grabar 4Gigas de un DVD por red, sin tener almacenamiento local, no es algo trivial. Lo mismo pasa con los CDroms. Eso sin tener en cuenta que el aplicativo tiene que acceder a la grabadora de dvd del dispositivo local de Uds. Así que sí su idea es hacer uso de las grabadoras de DVD/CD lo mejor es que contemplen que los clientes de Terminal Server tengan aplicaciones locales o leer el siguiente link en donde plantean una solución en un ambiente mixto como el nuestro: http://wiki.ltsp.org/twiki/bin/view/Ltsp/LocalCDWriting.
¿Cómo dimensiono el hardware del Servidor de Terminales?
La fórmula suele ser, por cada cliente que tengan, aproximadamente 50mb de ram + 100mb de swap con un microprocesador de 3GHz. Esto quiere decir que en un equipo con 1GB de ram y 2GB de swap van a tener 20 clientes concurrentes trabajando. En la práctica van a poder tener tranquilos 30 clientes con ese hardware, ya con 40 el sistema puede que se torne lento, pero va a seguir siendo mas rápido que el hardware del cliente que mencionamos antes (600mhz, 64mb). En una situación ideal lo mejor sería que tengan 2 microprocesadores, discos rápidos para swapear y 2GB de ram, en ese esquema van a poder tener sin problemas 60 usuarios concurrentes trabajando en la mejor de las situaciones. Una vez que se les supere esa cantidad de usuarios, para minimizar la criticidad del servidor, sería óptimo tener un segundo equipo. Sino se pasar a ser un gran problema depender de UN equipo para que trabajen 60 personas.
¿Para qué entornos no está orientado el modelo de Terminal Server?
El sistema se torna complejo en entornos donde se hace un gran uso de aplicaciones multimedia. No está orientado para que tengan 30 clientes concurrentes con un editor de imagenes renderizando. Está orientado a oficinas donde la gente usa aplicativos como clientes de correo, navegadores de internet, clientes de mensajería, planillas de cálculo, documentos de texto, presentaciones. Utilizarlo para editar video y sonido es impracticable.
Antes de seguir avanzando, vamos a tener que aclarar algunos conceptos técnicos:
¿Cómo es el proceso tradicional de inicio de una PC con GNU/Linux?
Probablemente lo conozcan, pero voy a ser repetitivo para que no haya dudas. Una vez finalizado el POST de la PC inicia el GRUB desde el mbr del disco rigido, lee su configuración y sabe que el menu.lst está en tal o cual partición. Una vez leído el menu.lst obtiene la información de donde se encuentra el kernel y el root filesystem. Acto seguido, arranca el kernel, monta el root filesystem (que es una partición de un disco rigido) e inicia el init que lee su inittab y arrancan todos los procesos que correspondan para el runlevel por defecto. Esto es lo mas usual. Ahora veamos cual sería el procedimiento para el LTSP.
¿Cómo es el proceso de inicio de una pc ThinClient con el LTSP?
Ante todo, no entren en pánico, porque voy a contarles por arriba como inicia la pc, pero mas adelante van a tener todas las piezas para armar el proceso que les voy a describir, van a ver todo paso a paso, esto sería un índice solamente. Termina el POST de la PC y tiene varias opciones para iniciar según los recursos que tengan de hardware, empecemos por el ideal:
- Inicia de la placa de red que tiene soporte PXE.
- Inicia del floppy que le da a la placa soporte para PXE.
En ambos casos el paso siguiente es obtener una dirección de IP del DHCP, el cual le dice cual es su servidor NFS y el archivo que tiene que traerse por TFTP. Por TFTP se trae el GRUB y el menu.lst (como se hace en el método anteriormente explicado). El menu.lst dice donde está y cual es el kernel a traerse. Se trae el kernel y lo "ejecuta", antes de continuar monta el root filesystem (por NFS) y luego inicia el init y luego de leer el inittab sabe que el primer proceso a ejecutar es el rc.sysinit (que es un gran script que mas adelante vamos a editar) donde de ahí inicia y llama a todos los servicios. Es decir, no hay scripts de arranque como suelen estar acostumbrados, en /etc/init.d/.
¿Qué es una placa PXE? Cómo se inicia una PC por red?
Las siglas PXE vienen de "Preboot Execution Environment" que es un método por el cual podemos ofrecerle a una pc la posiblidad de iniciar accediendo al sistema operativo por red. Tradicionalmente esto se hace através de un disco rigido, cdrom, dvdrom o diskette, pero como hablamos de equipos que no van a correr con la desgracia de tener un disco rigido, sino que van a almacenar todo en el servidor de terminales, necesitamos una alternativa por la cual iniciar la pc sin estos medios. La mayoría de los motherboards que tienen placas de red onboard soportan esta opción de inicio configurando desde el bios como opción de arranque la placa de red. Sino contamos con una placa de red onboard, las marcas lideres de placas de red vienen con soporte para PXE. Pero como última alternativa podemos emular el cliente PXE nativo de las placas de red con un diskette. El diskette va a tener el driver para nuestra placa de red y el cliente PXE para iniciar el sistema operativo desde la red.
Cómo se hace un diskette para darle la funcionalidad PXE a una placa de red? Hay un sitio que se dedica a esto, rom-o-matic.net (no hace falta el www). En el sitio está todo muy bien explicado, lo mejor es usar la última versión, la 5.4.2 a la hora de escribir el artículo. El link completo sería: http://rom-o-matic.net/5.4.2/. Acá van a poder elegir según la placa de red que tienen crear un diskette de arranque que contiene el driver y el cliente pxe para emular el inicio de red del cual carece nuestro hardware. Es una opción válida si quieren hacer pruebas. Lean bien la documentación porque ahí explican como saber que driver corresponde a que placa de red. La opción que recomiendo y considero la mejor, es la que ofrece la gente de thinstation. Ellos hicieron basandose en lo que ya les mostré un diskette que contiene TODOS los drivers mas conocidos. Esto entenderán que es mucho mejor, dado que sí tienen un entorno con distintas placas de red, lo mejor es que haya UN diskette universal. Bueno, justamente así lo llaman, el "Universal network boot disk" y el link es: http://sourceforge.net/projects/thinstation/. Es un proyecto de sourceforge como verán, sí ingresan al menú de "files" van a encontrar lo que les menciono.
Ahora bien, se bajaron ya sea de rom-o-matic o de sourceforge el floppy, ¿cómo hacen para grabarlo? Desde microsoft van a necesitar el rawrite y leer la documentación, no justifica que les muestre como porque realmente es simple. Desde Linux es nada mas copiar lo que se bajaron al /dev/fd0 que es el floppy en modo raw. Igualmente la documentación es mas que completa y sólo estamos hablando de copiar un archivo. Ahora sólo les queda poner el diskette y configurar el bios de la pc para que inicie de diskette.
¿Qué servicios necesito en mi red?
Sí leyeron el último paso por hay les quedó la sensación de que ya casi estamos por arrancar. Pero ni por asomo, porque previamente vamos a tener que preparar varios servicios de red para que el diskette consiga una ip, se baje por red un kernel y se conecte a un servidor por nfs para tener un root filesystem. Para lo primero, para obtener una dirección de red automaticamente necesitamos un servidor DHCP (Dynamic Host Configuration Protocol). Una vez que obtenemos nuestra la dirección de red, se nos da también la información de la ubicación en la red de nuestro kernel correspondiente para bajarlo por TFTP (Trivial File Transfer Protocol) y una vez el kernel iniciado, de donde sacar el servidor NFS (Network FileSystem) y así obtener un root para nuestro linux de red. Todo esto que les estoy contando es a título introductorio, para que vean como sería el proceso de inicio y el porque de cada uno de los servicios de red que vamos a configurar. Luego en la práctica vamos a ver en detalle algunas observaciones acerca de las cosas que mencioné, porque van a encontrar algunas diferencias.
¿Cómo configuro un servidor DHCP?
La idea del artículo no es que aprendan de cero a configurar un servidor DHCP, por esto voy a omitir la explicación de algunos parámetros y simplemente me voy a dedicar a lo relacionado con el funcionamiento del LTSP. Así que como primera medida, les voy a mostrar un archivo de configuración tradicional de un servidor DHCP así ven cuales son los parámetros que asumo saben configurar.
El archivo de ejemplo es para una red clase C en el segmento 192.168.0.0/24; están desactivados los updates de nombres al DNS; el default gateway de la red es la dirección 192.168.0.254; nuestro DNS interno está en la dirección 192.168.0.50; la dirección 192.168.0.1 es la de nuestro servidor WINS; el rango de entrega de direcciones para los clientes es desde 192.168.0.60 a 192.168.0.250. El dhcpd.conf en cuestión:
ddns-updates off;
ddns-update-style interim;
log-facility local6;
default-lease-time 10000;
max-lease-time 72000;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
option routers 192.168.0.254;
option domain-name-servers 192.168.0.50;
option netbios-name-servers 192.168.0.1;
authoritative;
subnet 192.168.0.0 netmask 255.255.255.0 {
get-lease-hostnames true;
use-host-decl-names on;
range 192.168.0.60 192.168.0.250;
}
Así suele ser una configuración básica de un servidor DHCP. Algunas aclaraciones, primero el ejemplo aplica para la version 3 o superior del servidor DHCP de http://www.isc.org. Ahora una un poco mas larga: tengan especial cuidado con los ";" dado que sí omiten alguna el servicio no va a iniciar. Demás está decir que pueden recurrir al syslog para ver en qué línea saltearon el ";". Pero sín el es como que no hay un salto de línea en la configuración. Maneja una sintaxis perversa parecida al lenguaje C.
Ahora les voy a mostrar los cambios que hago sobre el archivo inicial y explicarles paso a paso que hace cada uno.
ddns-updates on;
ddns-update-style interim;
ddns-domainname "dominio.com.ar";
key DHCP_UPDATER { algorithm hmac-md5; secret pRP5Fadasd12EL06sv4PQ==; };
zone dominio.com.ar { primary 127.0.0.1; key DHCP_UPDATER; }
log-facility local6;
default-lease-time 10000;
max-lease-time 72000;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
option routers 192.168.0.254;
option domain-name-servers 192.168.0.50;
option netbios-name-servers 192.168.0.1;
option domain-name "dominio.com.ar";
authoritative;
option root-path "192.168.0.50:/opt/ltsp/i386";
option option-128 code 128 = string;
option option-129 code 129 = text;
option nbgrub-menu code 150 = text;
option nbgrub-menu "(nd)/grub/menu.2st";
subnet 192.168.0.0 netmask 255.255.255.0 {
get-lease-hostnames true;
use-host-decl-names on;
range 192.168.0.60 192.168.0.250;
if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
filename "/grub/pxegrub";}
elsif substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
filename "/grub/nbgrub"; }
}
¿Cómo pruebo la configuración de mi servidor DHCP?
Simple, inicien una pc por dhcp y vean si les asigna una dirección de red acorde a la configuración que armaron. Sí eso funciona bien pueden seguir al paso siguiente que es arrancar una PC vía PXE. Donde como no terminaron todo, probablemente resulte en un kernel panic, pero una vez que terminen todos los pasos y hayan configurado el LTSP (como verán mas adelante), van a poder probar todo en conjunto. Sino van a tener un DNS interno, pueden sacar las opciones que les muestro y simplemente poner en "off" los ddns-updates así evitan errores en los logs, todo va a funcionar, pero van a tener errores en los logs.
ddns-updates on;
ddns-update-style interim;
ddns-domainname "dominio.com.ar";
key DHCP_UPDATER { algorithm hmac-md5; secret pRP5Fadasd12EL06sv4PQ==; };
zone dominio.com.ar { primary 127.0.0.1; key DHCP_UPDATER; }
¿Cómo configuro un servidor TFTP?
Hay varios servidores TFTP, la diferencia con un FTP tradicional que seguramente todos conocen radica en que un servidor TFTP es mas simple, no incluye usuarios y contraseñas, y tiene muchas menos funciones. Es algo básico y simple que es justamente lo que necesita nuestro sistema al iniciar para bajarse lo necesario como para arrancar el Sistema Operativo. El servidor tftp por defecto inicia desde el inetd, pero encontré varios problemas de timeout operando de esta forma, así que opté por dar de baja el inetd o xinetd y hacerlo correr como demonio directamente. Realmente la configuración del tftp, valga la redundancia, es trivial. Según la distribución que usen varía mucho donde configurar las opciones que les voy a mostrar. Por esto, simplemente les muestro las opciones con las que ejecuto el demonio y con esto van a poder adaptarlo a la distro que haga falta. En mi caso, Debian acepta todos estos parámetros en el /etc/default/atftpd
"--daemon --port 69 --retry-timeout 3 --no-timeout --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=7 --logfile /var/log/atftpd.log /tftpboot"
Lo importante de todo esto es que corre como demonio, no desde el inetd, que el directorio compartido es el /tftpboot (que van a tener que crearlo) y que los logs van al /var/log/atftpd.log.
Cómo pruebo la configuración de mi servidor TFTP? Sí me hicieron caso, cada vez que alguien se baje info de nuestro tftp va a quedar registrado en el log en /var/log/atftpd.log. Usen como herramienta de diagnostico esto. Existe el cliente tftp con el que localmente pueden probar de conectarse como si fueran un cliente Terminal Server y simular la bajada del kernel, del grub, etc. Por ahora pongan un archivo generico de prueba en /tftpboot e intenten bajarlo desde el propio servidor para probar que todo funcione como debiera.
linux-ltsp:/tftpboot# touch hola linux-ltsp:/tftpboot# cd linux-ltsp:~# atftp localhost tftp> get hola tftp> quit linux-ltsp:~# ls -l hola -rw-r--r-- 1 root root 0 Oct 17 22:12 hola
Así logro traerme un archivo que hice en el momento, llamado "hola". Mas adelante en la instalación van a poder simular lo que hice con los archivos reales.
¿Cómo configuro un servidor NFS?
Las siglas hacen referencia al Network FileSystem y la página oficial es http://nfs.sourceforge.net/ Ahí van a encontrar documentación, listas de correo y el paquete y los utilitarios para instalar. Obviamente usen los de su distribución, que en el caso de Debian el paquete es nfs-kernel-server. La configuración no es muy extensa. Tan sólo hay que tener instalado y corriendo el portmap como requerimiento previo y el archivo de configuración que van a tener que utilizar para tener funcionando el LTSP es el siguiente:
linux-ltsp:~# cat /etc/exports /opt/ltsp/i386 *(ro,async,no_root_squash) /opt/swapfiles *(rw,async,no_root_squash)
Acá estoy exportando dos directorios, el /opt/ltsp/i386 donde vamos a instalar todo lo relacionado con el LTSP, la raíz del disco de red y el /opt/swapfiles donde toda pc que no tenga suficiente ram va a utilizar para guardar su archivo de swap sobre NFS.
Notarán que a lo distinto entre un share y otro es que el primero es RO y el segundo RW. Esto es porque el root filesystem que vamos a exportar por red no debería nadie escribir ni modificar, por ser el mismo para todos los clientes, mientras que el /opt/swapfiles va a ser escrito de forma individual por cada cliente que necesite esa memoria extra usando swap por NFS.
Cómo pruebo la configuración de mi servidor NFS? Sí hicieron todo bien en el paso previo e iniciaron el servicio tiene que estar corriendo el portmap y varios procesos nfsd.
linux-ltsp:~# ps -fea | grep portmap daemon 1940 1 0 Oct10 ? 00:00:01 /sbin/portmap root 14144 14083 0 14:53 pts/1 00:00:00 grep portmap linux-ltsp:~# ps -fea | grep nfs root 2496 1 0 Oct10 ? 00:11:58 [nfsd] root 2497 1 0 Oct10 ? 00:10:58 [nfsd] root 2498 1 0 Oct10 ? 00:10:39 [nfsd] root 2499 1 0 Oct10 ? 00:11:29 [nfsd] root 2500 1 0 Oct10 ? 00:11:30 [nfsd] root 2501 1 0 Oct10 ? 00:11:08 [nfsd] root 2502 1 0 Oct10 ? 00:11:20 [nfsd] root 2503 1 0 Oct10 ? 00:12:10 [nfsd] root 2504 1 0 Oct10 ? 00:12:27 [nfsd] root 2505 1 0 Oct10 ? 00:12:21 [nfsd] root 2506 1 0 Oct10 ? 00:11:34 [nfsd] root 2507 1 0 Oct10 ? 00:10:45 [nfsd] root 2508 1 0 Oct10 ? 00:11:57 [nfsd] root 2509 1 0 Oct10 ? 00:10:37 [nfsd] root 2510 1 0 Oct10 ? 00:11:22 [nfsd] root 2511 1 0 Oct10 ? 00:11:28 [nfsd] root 2512 1 0 Oct10 ? 00:11:43 [nfsd] root 2513 1 0 Oct10 ? 00:10:51 [nfsd]
Aparte pueden ver que hay exportado de la siguiente forma
linux-ltsp:~# showmount -e Export list for linux-ltsp: /opt/stress * /opt/ltsp-2.6/i386 *
También pueden especificar un host a chequear, por ejemplo:
linux-ltsp:~# showmount -e 10.1.0.51 Export list for 10.1.0.51: /mnt * /opt/ltsp2/i386 * /opt/swapfiles/swapfiles *
Finalmente, para realmente comprobar todo. Sí el "rpcinfo -p" les muestra que los siguientes procesos están activos. No deberían tener problema. Esto es como una sumatoria de todos los chequeos que hicimos hasta acá, para el NFS.
linux-ltsp:~# rpcinfo -p program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100021 1 udp 32775 nlockmgr 100021 3 udp 32775 nlockmgr 100021 4 udp 32775 nlockmgr 100021 1 tcp 32774 nlockmgr 100021 3 tcp 32774 nlockmgr 100021 4 tcp 32774 nlockmgr 100005 1 udp 999 mountd 100005 1 tcp 1002 mountd 100005 2 udp 999 mountd 100005 2 tcp 1002 mountd 100005 3 udp 999 mountd 100005 3 tcp 1002 mountd 100024 1 udp 692 status 100024 1 tcp 695 status
De la misma forma que con el showmount, podemos apuntar a otros equipos definiendo la dirección de red.
¿Necesito un DNS? ¿Cómo lo configuro?
Vamos a empezar por "Qué es un DNS?". El DNS es el sistema por el cual uno escribe un nombre y los equipos saben que dirección de red tienen, que IP tienen. Van a necesitar un DNS en un entorno grande. Un entorno donde tengan una gran cantidad de equipos. Lo van a necesitar porque seguramente van a necesitar un orden para discriminar los equipos, mas que una dirección de IP que no todos van a recordar. Eso sumado a que seguramente los equipos van a tener impresoras conectadas y sí la gente quiere imprimir en ellas, va a tener que decir "imprimo en... " no "imprimo en 192.156.23.21" porque nadie va a en la práctica acordarse de algo así. Lo mismo aplica cuando quieren ir a www.google.com, nadie en su sano juicio escribe en su browser http://66.102.7.147/. Para esta transformación hace falta un DNS en el medio que traduzca el "humano" a "computadora". Así que en resumen, no está para nada de mas poner un DNS. Esto se hace en dos etapas: una que es configurar el servidor named (concretamente el servidor de nombres, dns) y configurar para que el servicio reciba actualizaciones del servidor dhcp. Por qué? Bueno, el dhcp va a recibir las mac address y el nombre del equipo, con esa información va a actualizar el DNS interno. El DNS tiene que estar aceptando actualizaciones de parte del DHCP. Todo este círculo es largo, empecemos!
Empiezo por aclararles que vamos a usar la versión 9.3.x del servidor de nombres bind. La configuración del servidor, si nunca hicieron una, es bastante densa en el sentido de que es mas estricta que la del dhcp. La sintaxis del archivo de configuración es muy importante y es fundamental que se familiaricen con las herramientas que posee el bind para chequearlos. Según la distribución que usen el servicio va a llevar el nombre del paquete o del demonio. Qué quiero decir? Bind es el paquete, el nombre de un conjunto de aplicaciones. Una de las aplicaciones es el named, que es el proceso que van a ver corriendo como proceso. El named es el servidor de nombres propiamente dicho, pero no es la única aplicación del paquete Bind. También existe el dig, el named-checkzone, el named-checkconf, el rndc, entre otros.
Les muestro un archivo de configuración base del named que practicamente podrían utilizarlo para cualquier servidor. Esto es porque el bind, al igual que el xinetd y el samba, tiene una particularidad muy cómoda y es que dentro del archivo de configuración se pueden llamar a otros archivos de configuración. Teniendo de esta forma un global para todos los DNS que tengan y en él llamar a todas las configuraciones personalizables, como las zonas. No se impacienten, ya veremos que es una zona.
include "/etc/bind/named.conf.options";
zone "." {
type hint;
file "/etc/bind/db.root";
};
acl slave-servers {
10.1.0.50;
10.1.0.51;
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
include "/etc/bind/named.conf.local";
Notarán que nuevamente volvemos al tema del ";" para finalizar una línea, como en el dhcpd.conf. Esto van a tener que respetarlo, sino no va a funcionar nada y el syslog va a recibir el mensaje explicando porque el servicio no inició y en que línea falta el ";". Les remarco algunas cosas importantes, en primer lugar las líneas que dicen "include" llaman, como les mencioné antes, a otros archivos de configuración donde estaría la configuración personal que identifica al servidor. Lo que no sería repetitivo. Las zonas que hay definidas, con zone "...." son las zonas nativas que necesita el named para funcionar. Esto nos lleva a "Qué es una zona?" Una zona es la definición de los hosts que hacen a un dominio. Por ejemplo, www.google.com NO es un dominio, es un host del dominio google.com. Así también mail.google.com NO es un dominio, es un host del mencionado dominio. Parecerá algo trivial, pero es importante tengan claro la diferencia. En un archivo de zona se definen parámetros fundamentales que hacen al funcionamiento del dominio, como quien es el dns dueño de la zona, quien es el servidor de correo del dominio, que hosts resuelve que dirección y datos que hacen a la configuración de la zona. Veamos como definir en el archivo named.conf.local (siguiendo nuestro named.conf de ejemplo) para así configurar nuestro dominio local.
zone "dominio.com.ar" IN {
type master;
file "dominio.com.ar";
};
Uso de ejemplo "dominio.com.ar", cambien esto por el dominio que realmente Uds usen.
Ahora paso a mostrarles una zona modelo para que tengan una idea, tengan presente los espacios, los puntos, las comas, un error y nada funciona. El nombre del archivo es "dominio.com.ar", por lo que antes configuramos en el named.conf.local.
Explicar el named.conf.options
$TTL 43200
dominio.com.ar. IN SOA dominio.com.ar. postmaster.dominio.com.ar. (
50 ; Serial
300 ; Refresh - 5 Minutes
60 ; Retry - 1 minute
1209600 ; Expire - 2 Weeks
43200) ; Minimum - 12 Hours
IN NS dns.dominio.com.ar.
dns A 10.1.0.152
tftp A 10.1.0.152
cups A 10.1.0.153
nfs A 10.1.0.153
La verdad es que es un ejemplo esto, pero lo ideal es que lean un poco la documentación del BIND porque estoy siendo lo mas breve posible, considerando que no es el artículo referido a DNS. Finalmente el named.conf.local también tienen que tener lo que les voy a mostrar, que hace a la seguridad del DNS y a aceptar las actualizaciones del dhcp. Imaginense que el DHCP de forma automática va a actualizar el DNS, alguna mínima seguridad tiene que haber, así que considerando que el DHCP y el DNS están en el mismo equipo, esto tendrían que agregar en el named.conf.local, donde corresponden las llaves definidas en el dhcpd.conf
key DHCP_UPDATER {
algorithm hmac-md5;
secret pRP5Fadasd12EL06sv4PQ==;
};
Les aclaro que no usen las llaves que hice yo, generen sus propias llaves. A modo de prueba pueden utilizar las que hice, pero idealmente lean la documentación del BIND para hacer su propio par de llaves.
¿Qué es el GRUB? ¿Por qué voy a utilizarlo? ¿Cómo lo instalo?
El GNU Grub es un multiboot loader. Vieron la pantalla de colores al inicio donde seleccionan el método de arranque? Sí arrancan con un kernel, con otro kernel, con otro sistema operativo, en modo "a prueba de fallos", etc? Bueno, eso es el grub. Tradicionalmente se instala en el mbr de los discos rigidos y de ahí inicia el kernel o SO correspondiente con algunos parámetros mínimos, como cual es la partición root.
Les muestro un ejemplo de un grub tradicional:
linux-ltsp grub # cat menu.lst # Boot automatically after 30 secs. timeout 5 # By default, boot the first entry. default 0 # Fallback to the second entry. fallback 1 # For booting GNU/Linux title GNU/Linux root (hd0,0) kernel /vmlinuz root=/dev/sda2 #initrd /initrd.img # For booting Windows NT or Windows95 title Windows NT / Windows 95 boot menu rootnoverify (hd0,2) makeactive chainloader +1 # For loading DOS if Windows NT is installed # chainload /bootsect.dos # For installing GRUB into the hard disk title Install GRUB into the hard disk root (hd0,0) setup (hd0)
Probablemente lo conozcan y se encuentren familiarizados con él. Por esto mismo opté por usar el grub para iniciar las maquinas de red. En lugar de grabarlo en el mbr, como les comenté, lo dejo disponible en un tftp y le paso al dhcp el parámetro para que los clientes dhcp sepan donde está el archivo que tienen que bajarse para iniciar de red. Cómo es esto? Bueno, van a ver en la documentación del LTSP que no usan el grub para iniciar las maquinas sin disco, ellos sugieren modificar el dhcp (porque no hay otra forma) pero en su lugar usar el PXE-Daemon. Que hace justamente esto, uno puede personalizar la configuración por mac address y ofrecer tal y cual kernel según el cliente que pide iniciar de red. Descarté esta opción porque era aprender algo nuevo y después de haberlo leído un rato largo me encontré con que no tengo la flexibilidad que me ofrece el grub: puedo modificarlo con contraseña al inicio desde una maquina sin disco, ya conozco el sistema y los parámetros de configuración, no tengo que explicar en detalle como funciona a los operadores del sistema (porque todo operador linux conoce el grub) y no hay ninguna función en el PXE-Daemon que no tenga el grub.
Por todo lo expuesto, voy a continuar con la explicación llendo directo a la opción Grub. Para bajarlo, que van a tener que hacerlo aunque lo tengan disponible en la distribución que usen, el sitio es http://www.gnu.org/software/grub/grub.en.html Ahí bajen el "Grub Legacy", porque la versión 2 todavía no incluye el soporte para iniciar de red y esto es justamente lo fundamental para nuestro LTSP.
Una vez bajadas las fuentes del Grub y descomprimidas se van a encontrar con la opción que seguramente todos conocen, de compilar (./configure), compilar (make) e instalar (make install). Pero antes de llegar a eso lean la documentación que habla puntualmente del método "net boot" que es lo que vamos a necesitar. Tiene algunos "gotchas" de ciertas placas de red que probablemente vayan a usar en los clientes. Ahí van a encontrar los parámetros para compilar el grub con soporte "diskless" y un parámetro por cada driver de red que quieren que conozca el grub. Es decir, el grub va a tener su propio soporte de red. Lo cual tiene sentido, sí la maquina inicia desde el bios (o diskette) y se trae el grub por dhcp, a su vez el grub tiene que tener soporte de red y poder volver a conectarse al tftp para bajar su configuración y el kernel que le corresponda. Veamos como modificar el menu.lst del grub para que luego de haberse bajado el grub por red él sepa que kernel bajarse en lugar de sacarlo del disco rigido. Ahora bien, volviendo con la compilación, les muestro un ejemplo concreto donde todos mis clientes tiene la misma placa de red, o una sis900 o una realteck8139.
linux-ltsp:/usr/src/grub-0.97# ./configure --enable-diskless --enable-rtl8139 --enable-sis900 linux-ltsp:/usr/src/grub-0.97# make
Cuando finalice la compilación, no tiren el "make install". Porque no van a querer reemplazar el grub del sistema donde están compilando, sino que van a reemplazar el grub de las maquinas sin disco. Así que el resultado de la compilación son dos archivos que nos interesan y ambos están en el directorio "stage2" dentro de las fuentes.
linux-ltsp:/usr/src/grub-0.97/stage2# ls *grub nbgrub pxegrub
Esos dos, ambos vamos a dejarlos disponibles en el servidor tftp. Para tener un orden creen el directorio "grub" dentro de /tftpboot/ y ahí dentro dejen los dos archivos resultantes de la compilación y el menu.lst que les presento ahora:
linux-ltsp:/tftpboot/grub# cat menu.2st default=0 timeout=9 color cyan/blue white/blue #splashimage=(nd)/grub/pxes2-splash.xpm.gz password SECRETOLOCO root (nd) title LTSP v2.6 kernel /lts/vmlinuz-2.6.17.6-2 rw root=/dev/ram0 initrd /lts/initramfs.gz title LTSP (con traza) v2.6 kernel /lts/vmlinuz-2.6.17.6-2 rw root=/dev/ram0 console=null initrd /lts/initramfs.gz title Memtest kernel /memtest86.bin
'''ATENCIÓN: NO modifiquen el menu.lst del servidor, es el menu.lst de las maquinas sin disco. Para evitar errores cambié el nombre del menu.lst del grub de las maquinas sin disco a menu.2st, mas allá de que está en otro path.
Hasta acá tendríamos toda la parte relacionada con el GRUB terminada, ahora vamos a ver como funciona la parte del kernel para seguir avanzando.
Qué necesito para compilar mi propio kernel para mis ThinClients?
Finalmente tengo todos los servicios funcionando! Cómo instalo el LTSP? El la página oficial hay una serie de scripts que hay que instalar en el servidor de NFS y que automatizan el proceso de instalación. Tienen un pseudo administrador de paquetes, por decirlo de alguna forma. En la sección de "download" opten por la versión 4.2 y ahí van a encontrar enpaquetado para varias distros estos scripts. Lo mejor es que se bajen el tgz multidistro.
Una vez bajado y descomprimido ejecuten el ltspadmin y sigan los pasos para bajarse los paquetes. Van a tener que configurar un path adonde instalar las aplicaciones, el root que van a exportar por nfs. Recuerden como configuraron el NFS y que coincida esto para que todo se descomprima donde tiene que ser.
Otro script que viene es el ltspcfg que intenta autoconfigurar los servicios, no se los recomiendo si vienen leyendo hasta acá porque va a hacerles cambios en los archivos de configuración y no siempre resultan positivos.
La otra opción es que bajen un ISO con todo, la dirección oficial es: http://ltsp.mirrors.tds.net/pub/ltsp/isos y ahí tienen una iso disponible. Para no quemar un cd, copien la ISO al servidor NFS y "montenla" directamente:
linux-ltsp:#mount -o loop /tmp/ltsp-*.iso /media/cdrom linux-ltsp:#cd /media/cdrom/ltsp-utils linux-ltsp:#tar xvzf ltsp-utils-0.25-0.tgz -C /opt/ linux-ltsp:#/opt/ltsp-utils/install.sh linux-ltsp:#ltspadmin
Una vez adentro tienen que decirle donde está la info, en nuestro ejemplo: file:///media/cdrom
Una vez terminado...
linux-ltsp:#umount /mnt
Listo, hasta acá tienen todo bajado, descomprimido e instalado, ahora queda pendiente configurar el ltsp. El archivo principal está en el /etc del root de la maquina sin disco. En nuestro ejemplo /opt/ltsp/i386/etc y el archivo se llama lts.conf. Es el archivo mas importante en el cual vamos a definir todas las opciones y vamos a hacer la gran mayoría de cambios. Veamos las opciones mas importantes, tengan presente que hay un lts.conf.readme con una explicación similar a la mía.
El archivo está dividido en una configuración global y en una per host. La situación ideal se presenta cuando no tienen que personalizar cada cliente, esto lo vamos a ir viendo en la medida que avancemos en el artículo, métodos para evitar esto de la configuración por cliente.
[Default] SERVER = 192.168.0.1 RDP_SERVER = rdpserver.dominio.com.ar DNS_SERVER = 192.168.0.50 XSERVER = auto X_MOUSE_PROTOCOL = PS/2 X_MOUSE_DEVICE = /dev/psaux X_MOUSE_BUTTONS = 2 USE_XFS = N SCREEN_01 = rdesktop SCREEN_02 = shell X_MODE_0 = 800x600 SOUND = N PRINTER_0_DEVICE = /dev/lp0 PRINTER_0_TYPE = P XkbLayout = "es" XkbModel = "pc102" SEARCH_DOMAIN = dominio.com.ar LOCAL_APPS = N NFS_SERVER = 192.168.0.50 SWAPFILE_SIZE = 32m NFS_SWAPDIR = /opt/swapfiles USE_NFS_SWAP = Y WDOMAIN = DOMINIO
Les cuento línea a línea...
- Servidor por default para NFS, SWAP, X, sino definen ninguno luego.
- Servidor RDP, que no suele coincidir con los demás por ser Microsoft
- Servidor DNS
- Servidor de X para el cliente. Lo mejor es auto y así utilizan la versión mas nueva.
- Tipo de Mouse para TODOS los clientes. Esa opción podrían personalizarla por host como les voy a mostrar en breve o autodetectarla como verán mas tarde.
- El device del mouse, mismo criterio que lo anterior.
- Cantidad de botones en el mouse, lo mismo que antes, mas adelante vamos a tener una solución mejor.
- Que use un servidor de fuentes. No se suele usar la opción, porque apunta a tener aplicaciones corriendo localmente y usar el servidor de fuentes de otro linux. Un esquema bastante particular.
- Que se ejecuta en la primera consola. rdesktop es una conexión por escritorio remoto a un servidor RDP de Microsoft, startx es una conexión XDMP a un servidor X GNU/Linux.
- Que definición tienen los monitores.
- Sí hay soporte para sonido o no activado.
- Que device corresponde a la impresora.
- Que tipo de impresora hay, P = paralelo y U = usb
- Layout del teclado.
- Modelo del teclado.
- Dominio de la red.
- Activar las aplicaciones locales, como les dije antes, un esquema medio particular. No tengo activadas las aplicaciones locales, para eso uso los Servidores de Terminales.
- Servidor NFS, por sino coincide con el Servidor de Terminales.
- Tamaño de los archivos de swap. Viendo que los clientes no van a correr aplicaciones localmente, sino que los que van a trabajar son los Servidores de Terminales no tiene sentido darles mucha swap.
- Que use o no SWAP.
- El dominio sí usan Microsoft y usan validación de usuarios en un dominio.
Con todo esto definido y los servicios ya estamos en condiciones de probar todo el escenario arrancando nuestro sistema desde la red. Así que vamos! A probar!!!
No se me detecta la "ruedita" del mouse! Esto es de mi propia auditoría, resulta que el archivo de configuración del Xorg que viene originalmente en el LTSP no autodetecta la presencia de un mouse con o sin ruedita. Se imaginarán, es un elemento crítico para los usuarios de un Servidor de Terminales tener la ruedita del mouse funcional! Al no autodetectar la ruedita el LTSP ofrece en la configuración del sistema, en el lts.conf, definir que pcs tienen ruedita y que pcs no con un parámetro por defecto. Esto ya lo vimos antes, pero se imaginarán que muy práctico no es. Lo que les muestro les permite dejar un parámetro por defecto para todos los clientes pero no personalizar mas, de acá en adelante el script de configuración del Xorg autodetecta la presencia de la ruedita (idealmente). El primer componente que hace gran parte de la magia es el "mdetect", que no viene para el lts nativamente, así que van a tener que bajar las fuentes y compilarlas. El sitio de donde lo bajé sin problemas, porque tuve en otros mirrors, es el de debian: http://packages.debian.org/stable/utils/mdetect. Concreamente el link directo, sino cambia la versión, es: http://ftp.debian.org/debian/pool/main/m/mdetect/mdetect_0.5.2.tar.gz
Sí no tuvieron problemas para compilar el grub, el mdetect es mucho mas simple y el resultado de la compilación les va a dar un binario llamado mdetect. Eso es todo, realmente explayarnos en como compilarlo no tiene mucho valor. Una vez compilado y funcionando instalenlo en nuestro root del ltsp. Idealmene en un directorio nuevo, así podemos distinguir que cosas le agregamos y con que cosas viene. Por ejemplo: /opt/ltsp/i386/usr/local/bin y ahí copiar el mdetect.
El mdetect tiene un problema y es que NO funciona con devfsd. Sí están usando el LTSP viejo, la versión 4.0, no les va a funcionar con la explicación que estoy dando. Tampoco tiene mucho valor que explique tanto sobre una versión que ya no se usa mas y que les insisto no usen, usen la 4.2 que viene muy mejorada. Pero si por algún motivo optan por usar la vieja, vayan al siguiente link donde está la explicación de como usarlo con la versión 4.0:
http://wiki.ltsp.org/twiki/bin/view/Ltsp/WorkInProgress#Mouse_Autodetection
La versión oficial del LTSP actual viene con un kernel 2.6 y con udev, así que el problema que aclaré antes no se nos va a presentar. Una vez instalado el mdetect necesitamos modificar el script de inicio de LTSP. El archivo /opt/ltsp/i386/etc/rc.sysinit. Editenlo haciendo un backup y agreguen lo siguiente después de la línea que hace el primer umount como muestro en el ejemplo:
PATH=/bin:$PATH; export PATH . /etc/ltsp_functions umount /oldroot >/dev/null 2>&1 # Creando los devices necesarios mknod /dev/psaux c 10 1 mknod /dev/ttyS0 c 4 64 # Autodetectando el mouse :) /usr/local/bin/mdetect -x >/tmp/mdetect.log
El archivo es muy largo, yo sólo les mostré el extracto que hay que modificar. Así van a tener en /tmp/mdetect.log un archivo con el output del mdetect. El output del mdetect es la configuración que tendría que tener el xorg.conf para utilizar todas las funciones del mouse. Por ejemplo:
PS/2 /dev/psaux
Finalmente van a necesitar modificar el archivo /opt/ltsp/i386/etc/build_x4_cfg por uno que hay en el CD de la revista. En su defecto, pueden bajar el script de la página que les mencioné antes: http://wiki.ltsp.org/twiki/bin/view/Ltsp/WorkInProgress#Mouse_Autodetection donde figuran los documentos disponibles para bajar.
Me conecto a un Servidor de Terminales GNU/Linux
Me conecto a un Servidor de Terminales Microsoft
Cómo imprimo en una impresora sí la tengo conectada localmente en mi ThinClient? Hay un parámetro en el lts.conf para habilitar un demonio que traduce que traduce jetdirect a puerto paralelo. Así que para el servidor de terminales el cliente es una impresora de red. Esto quiere decir que deberían instalar en el servidor de terminales una impresora de red, con la dirección ip del cliente ( o el nombre sí pusieron un dns ) y con el driver acorde al modelo. Así de simple tienen acceso a la impresora. Después queda en Uds definir privilegios para que los distintos usuarios del servidor puedan o no imprimir en esa impresora. Sí optaron por no poner un dns, lean la documentación del servidor dhcp para fijarles la ip a los clientes que tengan impresora y así no depender del DNS para poder seguir imprimiendo después de que la ip del cliente cambió.
El parámetro que les mencioné a un principio es el:
PRINTER_0_TYPE = P PRINTER_0_DEVICE = /dev/lp0
Opté por definirlo globalmente en el lts.conf en lugar de por cliente. Esto lo hice porque no consume recursos del cliente y tener que tomarme el trabajo de configurarlo por cliente era demasiado. La opción P hace a impresoras paralelas, mientras que la U a las impresoras USB.
Llegando al final del artículo les sugiero no instalar el spool de las impresoras en los servidores de terminales por el consumo del equipo que genera un alto volumen de impresión, así que sí optan por el entorno Linux o por un servidor dedicado CUPS para imprimir van a tener que configurar las impresoras en él. El ejemplo de una impresora por jetdirect es el siguiente:
socket://tsclient01:9100/
Así definen al cliente "tsclient01" en el puerto 9100 (el por default del jetdirect).
Cómo veo mis unidades locales desde el Servidor de Terminales? Con la versión 4.2 del LTSP no hay casi problemas. Con la versión vieja es realmente complejo y hay que introducir muchos cambios. Les sugiero ni intenten. Uno de los cambios importantes de la versión 4.2 es que incluye udev para administrar los dispositivos y esto sumado a una versión mucho mas nueva del kernel. Así que el cliente linux reconoce todo mucho mejor. Acá otra vez la situación nos depara dos caminos, siendo los Servidores de Terminales Linux anda muy bien, en el lts.conf definan lo siguiente:
LOCAL_STORAGE = Y
Mientras que en el Servidor de Terminales hay que tener instalado el aplicativo "fuse" que son las siglas de "Filesystem in Userspace". Lo que hace realidad toda la fantasia de poner un floppy en el cliente y que se vea en el servidor. Según la distro que usen como servidor es distinto el accionar, les muestro como ejemplo mi Debian y van a tener que adaptarlo a la que Uds utilicen, dado que no es lo mismo en todas.
Requisito mínimo del servidor, tener instalado el kernel 2.6.8 y los paquetes: fuse-source, fuse-utils, libfuse2 y module-assistant. Como root instalar el módulo de fuse con:
linux-ltsp:#m-a a-i fuse linux-ltsp:#modprobe fuse linux-ltsp:#echo "fuse" >> /etc/modules
Sí usan gnome para que puedan ver los íconos en el escritorio cada vez que saquen o pongan algún dispositivo en el cliente tienen que crear el archivo /etc/fuse.conf e incluír el siguiente parámetro:
linux-ltsp:#echo "user_allow_other" >> /etc/fuser.conf
La segunda opción es que usen Microsoft como servidor, acá tampoco se presentan problemas y sea que usen la versión vieja del LTSP o la nueva todo funciona bien. El método preferido para exportar las unidades es usando el mismo rdesktop. El cual acepta como parámetros exportar directorios locales al equipo donde se conecten. Prueben desde su estación de trabajo linux, donde previamente instalen el cliente rdesktop, como sería conectarse y exportar un directorio para que entiendan la idea:
rdesktop -r disk:floppy=/media/floppy servidor-de-terminales
Así se conectan al equipo que tiene como dirección de red "servidor-de-terminales" exportando una unidad que van a ver en "Mi PC" y que se llama "floppy. Lo que exportan son todos los documentos que hay en /media/floppy. Ahí sí montan su floppy tienen todo resuelto. Demás está decir que seguramente necesitan exportar mas unidades, así que simplemente agreguen una detrás de la otra:
rdesktop -r disk:floppy=/media/floppy -r disk:cdrom=/media/cdrom servidor-de-terminales
Incluyan todas las que necesiten y van a ver que van a tener varias unidades remotas en "Mi PC". Ahora bien, del lado del cliente hay que hacer algún cambio, esto no sale así no mas. En el lts.conf van a tener que definir estas opciones para que sean ejecutadas cuando inician la conexión con el servidor.
RDP_OPTIONS="-r disk:floppy=/media/floppy -r disk:cdrom=/media/cdrom -r disk:pendrive=/media/usb"
Aparte van a tener que montar los dispositivos mencionados en los puntos de montaje definidos. Esto no es una pavada, porque para un usuario final no es muy realizable esto. Cada vez que sacan o ponen algo tienen que montarlo y desmontarlo? Nadie va a hacer nada de eso seguramente. En la opción Linux es mas fácil, pero en la opción Windows que no hay un diálogo a nivel device la situación cambia. Así que mi alternativa fué agregarle al kernel de los clientes el soporte para supermount. El supermount es un filesystem que hace que los dispositivos se comporten como en Windows, ponen un diskette y lo monta, ponen un cdrom y lo monta. Lo quieren expulsar? Lo desmonta. Es realmente simple para los usuarios finales acostumbrados a esto. Vuelvan a leer la documentación donde hablo sobre como armar nuestro propio kernel y contemplen la instalación del parche que está disponible en: http://sourceforge.net/projects/supermount-ng
Es medio extenso, pero lo importante es que tengan un kernel con el soporte para supermount y que modifiquen el LTSP para que use el parche. La modificación deberían hacerla el archivo rc.localdev para que en lugar de hacer lo que hace, que monte todos los dispositivos, existan o no. Por ejemplo, reemplacen el rc.localdev con lo siguiente:
mount -t supermount -o dev=/dev/floppy/0,fs=vfat,--,rw none /tmp/drives/floppy mount -t supermount -o dev=/dev/cdroms/cdrom0,fs=iso9660,--,ro none /tmp/drives/cdrom mount -t supermount -o dev=/dev/sda1,fs=vfat,--,rw none /tmp/drives/usb
Es probable que tengan problemas con los llaveros USB que no están particionados, porque no funciona 100% bien eso, dado que necesitamos definirle una partición para montarlo. El camino para resolver esto sería ajustar la configuración del udev para llegar a algo satisfactorio, se los dejo como tarea porque no tuve suerte :)
¿Qué pasa cuando me quedo sin memoria ram en el cliente?
Esto es un problema que se puede presentar sí tienen clientes de menos de 32mb de ram. El rdesktop consume mucha memoria ram sí quieren copiar un gran volumen de información desde las unidades removibles al Servidor de Terminales y se quedan sin ram el kernel mata al rdesktop por la falta de recursos. Otro caso es la impresión, la terminal sin disco va a tener corriendo un demonio de jetdirect para recibir las impresiones y enviarlas al puerto paralelo o usb, al tener mucho volumen de impresión y quedarse sin ram se cuelga el puerto de impresión y para el usuario final no queda otra que reiniciar la pc para poder volver a imprimir. En fin, cómo lo solucionan? En el lts.conf hay una opción que habla sobre habilitar el swap over nfs o no. A mi esa opción tanto no me gustó, porque sí definen en el lts.conf pasa a ser global para todos los equipos. La otra posibilidad es personalizarla por equipo, pero como con el mouse, encontré una alternativa para esto. Les muestro primero la oferta de la gente del ltsp.org.
Agregar globalmente o per host en el lts.conf lo siguiente:
USE_NFS_SWAP=yes
SWAPFILE_SIZE=yes
SWAP_SERVER="dirección IP del servidor de NFS"
Sino definen nada, va a usar el servidor nfs que ya tienen configurado.
NFS_SWAPDIR="path en el servidor NFS donde exportarmos para que se graben los archivos de swap"
Recuerdan cuando configuramos el nfs? Que exportamos el /opt/swapfiles/? Bueno, acá deberían poner eso mismo. Así en ese share de NFS guarda los archivos de swap por cada cliente.
Les hago una advertencia en cuanto a esto, los archivos de swap los genera random al inicio según la ip del cliente, esto quiere decir que al día de mañana van a tener los swap creados de hoy y mañana, porque por hay esa ip fué liberada o tomada por otro cliente. Entienden adonde voy? Que van a tener que "limpiar" el directorio eventualmente antes que se llene el disco después de N1 días por N2 clientes por N3 reiniciadas diarias. Cómo? Programen en el cron algo como:
find /opt/swapfiles -mtime +4 -exec rm -rf {} \;
Eso va a borrar los swapfiles creados que tengan mas de 4 días de antiguedad. Sí en cuatro días no reinciaron la pc, es hora de que lo hagan.
Les cuento ahora cual es la opción por la que opté yo, dado que era mucho trabajo activar y desactivar el swap por cliente o activarselo a todo el mundo. El swap se crea al inicio, como vimos el script de arranque se llama rc.sysinit. En ese paso crea el swapfile. Lo mejor sería modificarlo agregandole un "if" para que sí la pc tiene menos de 32mb haga el swapfile, sino... no. Así ni le prestamos atención a la variable del lts.conf. Apartir de esto, vean los cambios que hice en el rc.sysinit para adaptarme a la situación, es una parte del rc.sysinit, busquen y hagan los cambios según corresponda.
# Setup swap
MEMORIA=`free | grep Mem | awk {'print $2'}`
echo $MEMORIA >> /tmp/mem.txt
if [ $MEMORIA -lt 32768 ]; then
# 32768 = 32 mb de ram
export "USE_NFS_SWAP"="Y"
else
export "USE_NFS_SWAP"="N"
fi
if [ "${USE_NFS_SWAP}" = "Y" ]; then
pr_set 73 "Checking for NFS swap"
modprobe nfsswap
mkdir /tmp/swapfiles
IPADDR=`ifconfig eth0 | sed -n '/addr:/p' | cut -f2 -d: | cut -f1 -d" "`
SWAPFILE=/tmp/swapfiles/${IPADDR}.swap
SWAP_SERVER=${SWAP_SERVER:-${NFS_SERVER}}
NFS_SWAPDIR=${NFS_SWAPDIR:-"/var/opt/ltsp"}
pr_set 74 "Mounting swapfiles directory"
echo "Mounting swapfiles directory"
mount -t nfs -o rsize=2048,wsize=2048,nolock,nfsvers=2,proto=udp \
${SWAP_SERVER}:${NFS_SWAPDIR}/swapfiles \
/tmp/swapfiles
ERR=$?
if [ ${ERR} -ne 0 ]; then
pr_set 74 "Mounting of swap filesystem failed, err=${ERR}"
pr_fail
echo "Mounting of swap filesystem failed, err=${ERR}"
El agregado es al inicio, donde en el comentario dice " Setup swap ". Ahí como ven guardo el resultado del free en un archivo y comparo la memoria del equipo. Sí tiene menos de 32mb activo la variable que la gente del proyecto define en el lts.conf. Sí la activo me traigo el directorio exportado por nfs y creo un swapfile. Esto es en resumidas cuentas como funciona el swap y porque lo necesitan.
¿Sonido? ¿Voy a poder escuchar sonido en mis ThinClients?
Acá es donde van a encontrar la mayor resistencia de los usuarios. El tema sonido es bastante aspero. La verdad es que me ha traído muchos problemas el tema del audio. En primer lugar porque es como hacer streaming del audio por la red. Imaginense que sí tienen muchos clientes la red no se pone precisamente felíz por tener tanto tráfico constante. Por otro lado, los servidores de terminales tampoco estallan de felicidad por tener varios xmms corriendo reproduciendo continuamente, ni mucho menos Windows Media Player en el caso de Microsoft. El esquema de aplicaciones multimedia en Terminal Server es bastante complejo. La verdad es que opté por cortar por lo sano y no avanzar con el tema del audio sobre los terminales. En la versión 4.0 del ltsp directamente no funciona, en muy poca situaciones funciona bien. Dado que como no soporta ALSA, la configuración es tortuosa y la autodetección de los drivers de audio es nula. Ya utilizando la versión 4.2 con soporte de alsa el escenario cambia radicalmente, porque la autodetección del audio funciona bien en los clientes. En el escenario Windows se van a encontrar con que el rdesktop no funciona bien para transportar el audio, practicamente con ningún driver. Con Linux como servidor tienen mas esperanzas, igualmente hay muchas variantes y muchos casos puntuales por aplicación. Es un tema muy extenso en donde van a tener que hacer pruebas para encontrar la mejor combinación, mi sugerencia después de mucho probar es optar por gnome + esd y probar las aplicaciones conflictivas como el xmms, el firefox con el plugin de flash, etc. Les paso el link para que vean todas las variantes porque sería muy extenso avanzar en detalle sobre el tema y acá realmente están cubiertos todos los temas: http://wiki.ltsp.org/twiki/bin/view/Ltsp/Sound.
Qué aspectos tengo que contemplar sí quiero dimensionar esto a gran escala? Hay dos grandes problemas que se van a presentar, cada uno de ellos va a tener varios items para resolver si la idea es dimensionar esto a gran escala. Por un lado es el tema de la compatibilidad del hardware de los clientes, las maquinas sin disco. Fundamental tener un relevamiento inicial de los clientes para:
- Compilar el grub con los drivers de red necesarios. Con un inventario de las placas de red van a poder compilar el grub para que soporte todas las placas que tengan.
- Analizar la necesidad de usar swap sobre NFS: De presentarse el caso de tener clientes con menos de 32mb va a ser fundamental que los equipos tengan la memoria necesaria via swap, sin disco el swap depende de la conectividad de red. Nuevamente, con el inventario van a determinar si necesitan o no dar soporte para swap over NFS.
- Instalar el "parche" para la autodetección del mouse: Sí van a tener muchos clientes seguro van a tener un problema con los distintos tipos de mouses.
El otro aspecto importante es la arquitectura de la red y el hardware con el que contamos.
- Instalar un servidor de impresión: Sí tienen muchos clientes con impresora van tener que instalar un servidor de impresión CUPS para tener un lugar donde apuntar a los servidores de terminales. Por qué? Sí tienen 40 impresoras, levantar un servidor CUPS (Terminal Server Linux) o usar el spool de impresión de Microsoft (Terminal Server Windows2003) es impensable. Sea Linux o Windows el servidor, no va a poder manejar el spool de esa cantidad de impresoras, el procesamiento va a tener que hacerlo un equipo dedicado, un servidor CUPS dedicado.
- Instalar un servidor de archivos: Esto es fundamental sí tienen mas de DOS servidores de terminales, de la plataforma que sea. Necesitan un lugar en común para guardar los /home de los usuarios y así poder distribuir y balancear la carga de los usuarios entre los distintos servidores de terminales. Sí optan por el camino Microsoft, un servidor de archivos samba con perfiles remotos es lo mejor que pueden hacer. En cambio, si optan por Linux, nuevamente con el servidor de archivos Samba sería lo mejor tener montado los /home de un servidor de archivos en ambos servidores de terminales. Es un tema amplio para tocar y hay muchas formas de manejar el tema. En la opción Linux por hay lo mejor en lugar de samba es usar un "rsync" en tiempo de login para sincronizar los homes.
- Armar un esquema de backup acorde: La ausencia total de discos rigidos les deja a Uds la reponsabilidad de el backup absoluto de toda la documentación. Esto tiene sus ventajas y sus desventajas obviamente, pero lo fundamental es que van a poder tener un backup REAL de toda la información. Para esto van a necesitar o un segundo servidor de archivos para espejar todo con frecuencia vía rsync o un servidor dedicado a backups con un storage a cinta. Después de haber probado el amanda y el arkeia les sugiero el bacula, www.bacula.org. Dado que los dos que mencioné antes, el primero es tortuosa la configuración y el segundo simplemente no funciona. La última versión que probé del arkeia usa como base de datos archivos de texto plano, se imaginarán lo que esto representa cuando tienen que recuperar algo? Impensable. El bacula usa un mysql para guardar la info lo que lo hace super amigable.
- Reducir el uso de los discos en los servidores de terminales. Imaginense que sí tienen muchos servidores de terminales, el proposito de tener un lugar centralizado de backup comienza a alejarse. Lo mejor sería que los usuarios se ocupen de guardar la info en el servidor de archivos, pero que a la vez lo usen lo menos posible, por mas incoherente que esto suene. Cómo? Bueno, uno de los principales problemas es que los usuarios tienen la tendencia de guardar ilimitados documentos, por hay es un buen momento para pensar en quotas de disco.
- Mudar las cuentas de correo a imap: Seamos honestos, el pop3 es lo peor que pudo haberle pasado a la gente que usa mails diariamente. No sé si todos conocen el servicio de imap, pero es muy superior y mucho mas cómodo. Tener la posibilidad de acceder a todos los mails desde cualquier lado y no "perderlos" cuando los bajan en una pc que no es la de Uds es lo mejor. Esto en nuestro esquema genera que los usuarios no tengan que llenar los discos de mails pop3, sólo hacen backup de UN servidor de imap y listo, pueden pasar a la gente de un servidor de terminales sin hacer backup del "outlook", "evolution", "thunderbird", lo que sea. Sólo le reconfiguran el cliente y tiene todos sus mails sin hacer ningún backup extra.
- Mejorar el esquema de red: Es fundamental que tengan red de 100mb, una red de 10mb se vuelve medio lenta al tener una cantidad importante de clientes y los 100mb hacen mucha diferencia. El tiempo de inicio del cliente se reduce exponencialmente y sí usan Linux como Servidor de Terminales es mucho mas notable la velocidad con una red de 100mb. En el modelo con Windows no se nota tanto porque el rdesktop ya usa un protocolo comprimido.
- Segmentar los servicios para generar mayor disponibilidad: Les comenté lo de tener X Servidores de Terminales, un servidor de impresión, un servidor de archivos, un servidor de backup, pero lo mejor sería agregar al escenario uno o dos servidores de NFS+DHCP+TFTP+DNS. Con esos dos equipos, que pueden ser pcs medianamente viejas y lentas, van a tener un backup de todo y aislan problemas al segmentar los servicios. Existe la posibilidad de dar soporte para dhcp failover y espejar los equipos así ante la caída de alguno que el otro tome la personalidad.
Como comentarios finales les sugiero prueben el sistema porque realmente es útil y redituable. No dejen de ponerse en contacto con nosotros por cualquier consulta y en un futuro artículo probablemente veamos la parte "servidor", cuando hoy vimos tan sólo los clientes. Les anticipo el link para que vayan leyendo: www.nomachine.com. Saludos!
Fuentes
- Linux Terminal Service Project de GUIDO LORENZUTTI
- http://www.ltsp.org/
- http://terminales.hispalinux.es/tiki-index.php