Cambiar IP pública del router Comtrend en JDownloader

JDownloader es una aplicación multiplataforma hecha en java que sirve para descargar desde sitios tipo rapidshare, megaupload, etc...

Para los que usen JDownloader y tengan un router Comtrend, es posible renovar automáticamente la IP pública de nuestro router, escribiendo el siguiente conjunto de instrucciones en el apartado de configuración que se muestra en la imagen:

[[[HSRC]]]
[[[STEP]]]
[[[REQUEST]]]
GET /rebootinfo.cgi HTTP/1.1
Host: %%%routerip%%%
Authorization: Basic %%%basicauth%%%
[[[/REQUEST]]]
[[[/STEP]]]
[[[/HSRC]]]

Actualizar BIOS del EEEPC 701

Es posible actualizar de una forma sencilla la BIOS de nuestro eeepc utilizando un pendrive formateado en FAT16.

Para actualizar la bios, lo primero que haremos será buscar en la web de soporte de Asus la última versión disponible y descargarla:
http://support.asus.com/download/download.aspx?SLanguage=es-ES

Imaginemos que hemos descargado la última versión disponible: 701-ASUS-1302.zip

Descomprimimos el fichero:

# unzip 701-ASUS.1302.zip

Al descomprimirlo, tendremos el fichero con la nueva BIOS. En el ejemplo:

701-ASUS-1302.ROM

Lo renombramos para que tenga el nombre 701.ROM:

# mv 701-ASUS-1302.ROM 701.ROM

Y lo copiamos al pendrive. Es importante que el pendrive esté formateado en FAT16. Al menos a mí no me ha funcionado teniéndolo formateado en FAT32.

Una vez que tenemos el fichero 701.ROM en el pendrive, apagaremos nuestro EEEPC 701, conectaremos el pendrive y lo encenderemos. Cuando comience a encenderse, pulsaremos Alt+F2 para iniciar la herramienta de actualización de la BIOS. Ésta herramienta buscará el fichero 701.ROM en el pendrive y actualizará su bios.
Importante: No interrumpir el proceso y asegurarse de que el portátil tiene la batería cargada. Lo mejor es tener carga en la batería y al mismo tiempo mantenerlo conectado a la red eléctrica, por si acaso.

sshfs: Montar directorios remotos de forma segura

sshfs es una herramienta muy útil para todos aquellos que administramos sistemas linux.

Es bastante interesante porque nos permite montar directorios remotos usando ssh y trabajar con sistemas de archivos remotos como si fueran locales, con el añadido de que al utilizar ssh, la comunicación es segura.

Lógicamente, para montar un directorio remoto vía sshfs, el servidor tendrá que tener un servidor ssh.

Instalar sshfs en la máquina cliente.-
En cuanto al cliente, deberá disponer de soporte FUSE (Filesystem in User Space) en el kernel, algo seguro si la versión del kernel es igual o posterior a la versión 2.6.14.

Podemos comprobar si tenemos cargado el módulo fuse de la siguiente manera:

# lsmod | grep fuse

Si obtenemos una línea parecida a la siguiente, es que está cargado:

fuse 60956 3

Si no estuviera, cargado, lo cargamos:

# modprobe fuse
# depmod -A

Una vez que tenemos cargado el módulo fuse, instalaremos sshfs:

# apt-get install sshfs

Y ya podremos montar directorios remotos vía ssh.

Montar directorios remotos usando sshfs.-
Cuando queramos montar un directorio de una máquina remota vía sshfs, no tendremos más que ejecutar:

# sshfs usuarioremoto@servidor:dir_remoto dir_local

Por ejemplo, si queremos montar el directorio /backup que tenemos en una máquina remota llamada recursos, como root, en el directorio local /mnt/backup, ejecutaremos el siguiente comando:

# sshfs root@recursos:/backup /mnt/backup

Una vez hecho ésto, si entramos dentro del directorio /mnt/backup, veremos el contenido del directorio /backup de la máquina recursos.

Desmontar un directorio remoto montado vía sshfs.-
Cuando queramos desmontar un directorio de una máquina remota vía sshfs, no tendremos más que ejecutar:

# fusermount -u dir_local

Siguiendo con el ejemplo anterior: Si queremos desmontar el directorio que teníamos montado en /mnt/backup, ejecutaremos:

# fusermount -u /mnt/backup

killall en Lenny

He instalado un Debian Lenny mínimo sin entorno gráfico para un servidor y me he dado cuenta de que no tenía el comando killall. Como lo necesitaba, he estado buscando y he encontrado que esta utilidad está disponible al instalar el paquete psmisc.

Administración centralizada de equipos mediante PUPPET

PUPPET es una herramienta que facilita el trabajo de un administrador de sistemas permitiéndole hacer instalaciones, actualizaciones, cambios de configuraciones, etc... en equipos remotos. Lo que evita tener que desplazar un técnico para realizar dichas modificaciones.

Puppet se compone de varios elementos:

• Un servidor -> puppetmaster.
  
• Un servicio para los clientes -> puppetd.
• Un lenguaje declarativo para definir lo que se quiere hacer en los clientes.
  
• Un sistema para obtener datos de los clientes -> facter.

Un detalle importante para entender puppet es tener en cuenta que el servidor define, mediante el lenguaje declarativo de puppet, los estados que se desea tener en los clientes. Y no es necesario definir las instrucciones que hay que ejecutar para lograr esos estados.

Por ejemplo: Supongamos que queremos que en nuestros clientes debe estar instalado el paquete sshfs. Para garantizar que esté instalado tan sólo tendremos que escribir una regla como la siguiente en el servidor:

package { "sshfs":
ensure => installed
}

Y puppet se encargará de que se instale si el paquete no está instalado aún, sin tener que preocuparnos de hacer ningún procedimiento para instalarlo.

Además hay un principio fundamental en puppet: el principio de idempotencia. No importa el número de veces que se ejecute una regla. El efecto debe ser como si sólo se hubiera ejecutado una vez. Además, puppet se encargará de no ejecutar una regla si el objetivo final se ha conseguido.

Comunicación entre el cliente y el servidor puppet.
La comunicación entre el cliente y el servidor es cifrada mediante SSL.
Para garantizar que esta comunicación sea cifrada, el servidor puppet tiene una pequeña autoridad certificada que maneja certificados X509.

Instalación de puppet.
Para instalar puppet, tendremos que hacer varias cosas:

• Instalar un servidor puppet.
  
• Configurar el servidor puppet.
  
• Instalar el cliente puppet en todas las máquinas que queramos administrar.
• Configurar el cliente puppet.
  

Instalar un servidor puppet.
Instalar un servidor puppet es tan sencillo como instalar el paquete puppetmaster:

# apt-get install puppetmaster

Se resolverán todas las dependencias y se instalarán todos los paquetes necesarios.

Configurar el servidor puppet.

Primer paso.- Configurar el servidor de ficheros.
Para poder servir ficheros a los clientes puppet, lo primero que tenemos que hacer es modificar el fichero /etc/puppet/fileserver.conf. En este fichero especificaremos a qué rango de máquinas de la red queremos servirles ficheros. Ésto se hace en la sección [files] de dicho fichero. Por ejemplo, si mi red es la 192.168.1.0 y quiero servir ficheros de puppet a todas las máquinas de esta red, añadiré una línea allow:

[files]
path /etc/puppet/files
allow 192.168.1.0/24

En este fichero también se puede usar deny para denegar el acceso a ciertas máquinas. Y da igual el orden que coloquemos el allow y el deny. El allow prevalece sobre el deny.
Además, tanto en el allow como en el deny, se puede especificar tanto un rango de red como un nombre de dominio. Ejemplo: allow *.valledeljerte3

Segundo paso.- Modificar el el fichero /etc/puppet/puppet.conf
Por defecto, este fichero contiene la localización de los directorios de logs, de datos, de certificados ssl, etc. Como los valores por defecto nos sirven para hacer una configuración básica, tan sólo le añadimos las dos líneas que he resaltado en negrita:

[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
pluginsync=true

[puppetmasterd]
templatedir=/var/lib/puppet/templates
certname=puppetdptos
autosign=false

En la primera línea añadida (certname=puppetdptos) estamos indicando que el servidor de certificación se llama puppetdptos (es el nombre de la máquina en la que hemos instalado puppetmaster).

En la segunda (autosign=false) estamos indicando al servidor que no debe firmar las peticiones de certificados que le lleguen de forma automática. Si quisiéramos que el servidor firmase todas las peticiones de certificados que le llegasen, pondríamos autosign=true. La opción por defecto es autosign=false, con lo que no sería necesario especificar esta opción. La pongo más que nada por si en algún momento quiero que el servidor firme de forma automática los certificados.

Tercer paso.- Crear el esqueleto manifests.
Si no estuviera creado el directorio de clases y/o el directorio manifests, lo creamos:

# mkdir -p /etc/puppet/manifests/classes

Cuarto paso.- Crear el fichero site.pp
Este es un fichero de control fundamental del servidor puppet. Podríamos crearlo con:

# touch /etc/puppet/manifests/site.pp

Supongamos que en el directorio /etc/puppet/manifests/classes/ hemos creado un fichero llamado test_class.pp con el siguiente contenido:

class test_class {
file {"/tmp/fichero.test":
ensure => present,
mode => 744,
owner => root,
group => root
}
}

En este archivo hemos definido la clase test_class, que contiene una definición del tipo file que se puede leer de la siguiente forma: Debe existir el archivo /tmp/fichero.test con permisos 744 y debe pertenecer al usuario root y al grupo root.

Existen otros tipos de definición que podemos utilizar y que son particularmente útiles. Por ejemplo:

• package, para el manejo de de software.
• exec, para ejecutar comandos en el sistema del cliente.
• cron, para programar tareas en el sistema del cliente.
• Existen muchos más tipos de definiciones. Podemos verlas en el Type Reference de Puppet.

Podemos añadir un contenido básico al fichero site.pp, y utilizar en él la clase test_class creada en anteriormente:

# Importamos todas las clases del directorio classes
import "classes/*.pp"

# En node default incluimos las tareas para todos los nodos
node default {
include test_class
}

# Definimos un nodo de pruebas
node "a25-pro" inherits default {
# include clase_a_probar
}

Crearemos las tareas en el directorio /etc/puppet/manifests/classes y las llamaremos con include en el nodo de pruebas. Las ejecutaremos. Y si todo va bien, pasaremos la tarea al nodo default para que se ejecute en todos los clientes.

Una vez terminada la configuración del servidor puppet, si no está iniciado, lo iniciamos:

# /etc/init.d/puppetmaster start

No es necesario reiniciarlo después de hacer cambios en los ficheros de configuración. El servidor está monitoreando los archivos de configuración y los reelerá a los pocos segundos de ser modificados.

Instalar un cliente puppet.
Instalar un cliente puppet es tan sencillo como instalar el paquete puppet:

# apt-get install puppet

Se resolverán todas las dependencias y se instalarán todos los paquetes necesarios.

Configurar el cliente puppet.
Configurar el cliente puppet es más sencillo aún. Lo único que tendremos que hacer es editar el fichero /etc/puppet/puppet.conf y añadir una línea server=servidorpuppet.
En la línea server=XXXXXXXXXXXXX podemos indicar:

• La dirección ip del servidor puppet.
• O el nombre de dicho servidor, si tenemos un servidor de dns en la red.
  

El contenido básico del fichero /etc/puppet/puppet.conf en el cliente podría ser el siguiente:

[main]
server=puppetdptos
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
# pluginsync=true

Funcionamiento de puppet y comprobaciones.
No olvidemos que para que el sistema funcione, deben estar iniciados puppetmaster en el servidor y puppet en el cliente. Si no lo están, los iniciamos:

# /etc/init.d/puppetmaster start (en el servidor)

# /etc/init.d/puppet start (en el cliente)

Si hubiera algún problema en el funcionamiento, lo mejor es echar un vistazo a los logs, que se encuentran almacenados en /var/log/puppet

El tiempo predeterminado de contacto del cliente con el servidor es de 30 minutos, cosa que podemos cambiar (Se define en segundos).

Para probar si una tarea se ejecuta correctamente en un cliente, paramos puppet y ejecutamos puppetd -t:

# /etc/init.d/puppet stop

# puppetd -t

Una vez comprobado que las tareas se han ejecutado, volvemos a iniciar el servicio:

# /etc/init.d/puppet start

No es necesario reiniciar puppet ni puppetmaster después de hacer cambios en los ficheros de configuración. El servidor está monitoreando los archivos de configuración y los reelerá a los pocos segundos de ser modificados.

Gestión de certificados en el servidor.
Cuando un cliente intenta comunicarse con el puppetmaster, el servidor se encargará de comprobar si sus certificados son válidos.

Si tenemos configurado nuestro servidor con autosign=false (opción por defecto), podemos comprobar si hay peticiones de certificados pendientes de firmar, ejecutando:

# puppetca --list

Por otra parte, si al ejecutar el comando anterior, vemos que la máquina a24-pro.valledeljerte3 ha hecho una petición y su certificado no ha sido firmado aún, podemos firmárselo con:

# puppetca --sign a24-pro.valledeljerte3

Si quisiéramos revocar el certificado concedido a esta máquina, haríamos lo siguiente:

# puppetca --revoke a24-pro.valledeljerte3

Y si quisiéramos limpiar los ficheros relacionados con la petición de certificación de un host para que se vuelva a hacer una petición de certificado:

# puppetca --clean a24-pro.valledeljerte3

WBFS: Wii Backup File System

WBFS (Wii Backup File System) es un sistema de ficheros que sirve para almacenar backups de juegos wii, de forma eficiente en un disco duro. Lo más interesante es que no sólo podemos almacenarlos, sino que, además, podemos jugar directamente con ellos utilizando un USB Loader.

Este sistema puede ser útil para tener copia de nuestros juegos originales Wii en un disco duro USB y jugar con ellos utilizando un USB Loader. De este modos, conservaremos en mejor estado los discos originales.

Algo que hay que mencionar es que cada juego Wii se almacena en un DVD de al menos 4,7GB que no se aprovecha totalmente.
El sistema de ficheros WBFS es eficiente porque conoce el sistema de ficheros de los discos wii y copia a las particiones WBFS tan sólo la parte que es realmente necesaria, eliminando información "basura".
Esta idea no es nueva. La herramienta WiiScrubber también saca partido de ello.

Suponiendo que tengamos instalado un USB Loader en la Wii, vamos a ver cómo sacar partido de WBFS en linux.

Si tenemos un disco duro USB dedicado exclusivamente para este propósito, tan sólo tendremos que eliminar las particiones que tenga y crear una única partición que pasaremos a formato wbfs.
Otra posibilidad es que tengamos un disco duro multimedia cerca de nuestra consola. Reducimos el tamaño de la partición que tenga para crear una nueva partición en formato wbfs.
Es importante que la partición a usar para los backups sea wbfs. No vale tener un USB con una partición FAT o NTFS o EXT3.

Lo primero: Instalar las herramientas en linux:
Para crear y activar particiones wbfs necesitaremos:

• Un gestor de particiones, como por ejemplo: gparted.
• wbfs.
• Un gui para manejar nuestros backups de forma cómoda. Recomiendo wiithon, una herramienta hecha en python. Se puede manejar de forma sencilla en la línea de comandos y tiene unos scripts nautilus para trabajar desde gnome. Además incorpora wbfs.
  

Instalar gparted es tan sencillo como tirar de repositorios:
# apt-get update; apt-get install gparted

Para instalar wiithon, primero lo descargamos:
# wget http://www.speedyshare.com/data/790517126/16340244/92166603/wiithon%20v0.98%20r6.tar.gz

La última versión a día de hoy es la 0.98.

Lo que descargamos es el código fuente. Para instalarlo lo primero será descomprimirlo:
# tar xfvz wiithon v0.98 r6.tar.gz

Una vez descomprimido, tendremos un directorio con el código fuente: wiithon. Nos introducimos en él:
# cd wiithon

Si tenemos instalada una versión y queremos actualizarla, el autor nos recomienda desinstalar la anterior e instalar la nueva.

Para desinstalar la versión anterior hacemos:
# make uninstall

Después, instalamos la nueva versión:
# make install

Y listo. Si todo ha ido bien, ya tendremos wiithon instalado y podremos manejarlo mediante comandos.

Manejar wiithon desde la línea de comandos (sacado de la ayuda):

* Ver la ayuda:
wiithon ayuda

* Listar juegos:
wiithon

* Añadir ISO's especificando una lista:
wiithon “juego1.iso” “juego2.iso″ ...

* Añadir ISO's usando comodines (La expresión solo afecta al directorio actual, no es recursivo):
wiithon *.iso

* Buscar y Añadir ISO’s recursivamente. Busca todos las imagenes isos RECURSIVAMENTE, incluso tambien busca dentro de RAR, a falta de implementar zip), tal vez necesites sudo apt-get install rar:
wiithon buscar

* Borrar juegos. Especificando el juego mediante un menú.:
wiithon borrar

* Borrar juegos. Podemos borrar con el IDGAME.:
wiithon borrar IDJUEGO

* Borrar juegos. Podemos borrar con el IDGAME obtenido a partir de un ISO local. El archivo ISO local NO es borrado:
wiithon borrar “./wii/mario.iso”

* Renombrar juegos. Especificando el juego mediante un menú.:
wiithon renombrar

* Renombrar juegos, puedes cambiar el nombre de los juegos ya metidos en HD, útil para que nos enteremos cuando estemos con el USB Loader:
wiithon renombrar IDGAME “Mario Kart Wii”

* Extraer juegos a un archivo ISO. Podemos extraer un juego de la partición wbfs y almacenarlo en un archivo iso. El juego es especificado mediante un menú: wiithon extraer

* Extraer juegos a un archivo ISO. OJO! : El archivo ISO de salida pertenecerá al usuario root:
wiithon extraer IDJUEGO

* Descargar todas las caratulas automaticamente a 160×225. Ojo puede que el servidor te banee, si te ocurre intentalo 5 minutos más tarde:
wiithon caratulas

*Descargar la caratulas de un juego especificado por su IDGAME, la imagen es bajada a 160×225. El comando es un singular, es “caratula” ya que “caratulas” descarga todo:
wiithon caratula IDGAME

Descargar la caratulas de un juego especificado por menú, la imagen es bajada a 160×225. El comando es un singular, es “caratula” ya que “caratulas” descarga todo:
wiithon caratula

Comprobar Integridad de los juegos. Muchos de nuestros juegos pueden estar corruptos sin aún saberlo debido a el bug de borrado de las primeras versiones de WBFS:
wiithon comprobar

Instar juegos desde el DVD, al estilo del usb loader, pero algo más lento porque dumpea a ISO y cuando termina mete la ISO:
wiithon instalar

Por otra parte, tendremos que instalar una serie de herramientas que necesitaremos también:

• nautilus-actions
• imagemagick
• rar

Las instalamos:
#apt-get install nautilus-actions imagemagick rar

Es sencillo de instalar, pero por si a alguien le parece complicado, puede descargar un paquete debian desde la siguiente dirección e instalarlo con dpkg:
http://www.mediafire.com/?9amueyatlvn

Si ahora queremos tener la posibilidad de usar wiithon mediante nautilus, tendremos que instalar los scripts de nautilus que el autor nos proporciona y que encontraremos en el directorio wiithon:

• wiithon1.schemas
• wiithon2.schemas
• wiithon3.schemas
• wiithon4.schemas
• wiithon5.schemas
• wiithon6.schemas
• wiithon7.schemas
• wiithon8.schemas

Para instalarlos, en gnome, abrimos el menú Sistema -> Preferencias -> Configuración de acciones de Nautilus.

Se nos mostrará una pantalla similar a la siguiente:

Si tenemos acciones de wiithon de versiones anteriores, el autor nos recomienda borrarlas porque seguramente hayan sido actualizadas.

Una vez borradas las acciones, si las teníamos instaladas, hacemos clic en el botón: Importar/Exportar.

Al hacer clic en Importar/Exportar se nos abrirá una ventana similar a la siguiente:

En tipo de configuración: ponemos automático.

Y pulsamos en el botón de los puntos suspensivos para seleccionar el esquema a importar.

Tendremos que importar los 8 ficheros, uno a uno:

1. wiithon1.schemas
2. wiithon2.schemas
3. wiithon3.schemas
4. wiithon4.schemas
5. wiithon5.schemas
6. wiithon6.schemas
7. wiithon7.schemas
8. wiithon8.schemas

Una vez importados, tendremos que reiniciar nautilus para que estas opciones se nos muestren en los menús de contexto:

# killall nautilus

Segundo: Crear las particiones:
Como ya hemos dicho anteriormente, no vale tener un USB con una partición EXT3, FAT o NTFS. Para almacenar los backups y que sean jugables, se necesita tener una partición en formato wbfs creada exclusivamente para ésto.

Para crear las particiones mediante gparted, lo primero es abrir gparted. Podemos abrirlo ejecutando en un terminal:
# gparted

O desde el menú: Sistema->Administración->Editor de particiones.

Una vez abierto gparted, en la parte superior derecha nos aparecerá un dispositivo seleccionado. Hacemos clic para seleccionar el disco USB que queramos particionar (también podemos seleccionar el disco USB en el menú, GParted->Dispositivos).

Como el disco es USB, debería ser un dispositivo del tipo /dev/sdx donde x es la letra que identifica el disco duro: sda, sdb ... El disco duro de nuestro ordenador será probablemente sda, así que el disco usb externo será sdb. Tened cuidado de no equivocaros para no cargaros el disco duro de vuestro ordenador.

Una vez seleccionado el disco USB, veréis las particiones que tiene. Debemos desmontar las que aparecen montadas. Podemos desmontarlas con click derecho->desmontar.

Ahora tenemos dos opciones:

• BORRAR TODO Y CREAR UNA SOLA PARTICION: Si queremos usar el disco usb tan sólo para almacenar los backups de juegos (no podremos usar el disco para nada más, puesto que el formato wbfs es tan sólo para wii). Haremos click derecho sobre las particiones que queremos borrar, y luego en el menú Editar->Aplicar todas las operaciones. Se borrarán las particiones del disco. Una vez borradas crearemos una partición haciendo click derecho ->Nuevo en el espacio sin asignar, pondremos la nueva partición como partición primaria y en sistema de archivos pondremos sin formatear.

• REDIMENSIONAR UNA PARTICIÓN PARA HACER ESPACIO PARA OTRA NUEVA: Si tenemos datos y no queremos perderlos, podemos redimensionar una de las particiones que tengamos para encogerla y dejar espacio libre. Haremos Click derecho ->Redimensionar / Mover sobre la partición a redimensionar. Indicaremos el nuevo tamaño de disco que queremos tener en la partición a reducir y nos dirá el espacio que nos quedará libre para la nueva partición de backups. Hacemos click en Redimensionar / Mover y aplicamos los cambios con Editar->Aplicar todas las operaciones. Una vez se ha redimensionado la partición (tardará un tiempo), nos habrá quedado un espacio en el disco USB sin asignar. Hacemos click con el botón derecho en el espacio sin asignar->Nuevo y ponemos la nueva partición como partición primaria. En sistema de archivos indicamos sin formatear.
  

Una vez que tengamos la partición para backups creada, tendremos que inicializarla para que podamos usarla con WBFS.

Tercero: Inicializar la partición wbfs.
Para inicializar la partición utilizamos la aplicación wbfs de la siguiente manera:
# wbfs -p /dev/sdXY init

• sustituyendo X por la letra de unidad del dispositivo USB.
• sustituyendo Y por el número de partición.

Por ejemplo, si hemos creado una partición sdb2 en el dispositivo USB para usar con wbfs, ejecutaremos el comando wbfs de la siguiente manera:
# wbfs -p /dev/sdb2 init

Una vez hecho ésto, habremos inicializado el sistema de archivos en la partición creada. Ahora tan sólo tendremos que usar wiithon o nautilus para añadir, borrar, renombrar, extraer... juegos en la partición.

Por último, tan sólo me queda mencionar que wiithon nos facilita la tarea de trabajar con wbfs. No obstante, también podríamos añadir isos usando directamente wbfs. Por ejemplo, si quisiéramos añadir un backup de un juego llamado "backuporiginal.iso" a la partición wbfs sdb2, haríamos lo siguiente:
# wbfs -p /dev/sdb2 add /home/backups/backuporiginal.iso

Montar un servidor de terminales con LTSP

Últimamente he tenido que montar un par de servidores de terminales. Así que, por si se me olvida lo que he hecho, que se me olvidará... voy a escribir este artículo, y si tengo que volver a hacerlo ya tengo un punto de partida.
No voy a entrar, de momento, en detalles sobre como instalar un servidor dhcp, que es necesario para dar ip a los terminales. Ya lo haré cuando tenga un poco más de tiempo.

LTSP (Linux Terminal Server Project) es un proyecto que nos proporciona un conjunto aplicaciones que nos permitirán conectar muchos equipos con pocos recursos a un servidor Linux. Estos equipos serán clientes ligeros del servidor.

Las aplicaciones que ejecutemos en los clientes correrán directamente en el servidor, que aceptará entradas y mostrará su salida en las pantallas de los clientes ligeros. No obstante, LTSP, en su versión 5, dispone de una herramienta experimental, llamada localapps que nos permite hacer que algunas aplicaciones se ejecuten en el cliente.

Para montar un servidor de terminales, tendremos que instalar los siguientes paquetes, como mínimo:

• ltsp-server
• Un servidor tftp, como por ejemplo: atftp.
• Un servidor dhcp: como dhcp3-server o dnsmasq. En nuestros centros usamos dhcp3-server-ldap porque usamos ldap como backend para almacenar los datos.

Si usamos nfs para servir la imagen a nuestros terminales, instalaremos además:

• nfs-kernel-server

Y si nuestros terminales reciben la imagen via nbd, instalaremos el paquete:

• nbd-server

Se necesitan algunos paquetes más, pero como son dependencias, al instalar los paquetes que hemos dicho, se instalarán todos los demás que son necesarios.

Un paquete necesario, que se me olvidaba mencionar, es openssh-server, dado que el tráfico entre el servidor y los clientes viaja encriptado. Pero bueno, es un paquete que se suele tener instalado.

En cualquier caso, si no queremos instalar uno a uno los paquetes mencionados, siempre podemos instalar el paquete ltsp-server-standalone y se instalará todo lo necesario para montar un servidor de terminales:

# apt-get install ltsp-server-standalone

En nuestros centros las imágenes se sirven mediante nbd. Yo tengo instalados tanto nfs-kernel-server como nbd-server. Y con unos pequeños cambios puedo usar un sistema u otro. Por defecto, se usa nfs, así que, luego veremos cómo cambiar a nbd.

ltsp se instala en /opt. Por lo que, al terminar la instalación, tendremos el siguiente directorio: /opt/ltsp
En este directorio se guardará tanto el sistema que compartimos por nfs como las imágenes que servimos vía nbd.
Cuando creemos las imágenes para los clientes, tendremos un subdirectorio por cada tipo de imagen que sirvamos a los terminales. Por ejemplo, si vamos a servir imágenes i386, en /opt/ltsp tendremos un directorio /opt/ltsp/i386. En cuanto a las imágenes a servir por nbd, se almacenarán en /opt/ltsp/images.

Una vez instalados los paquetes, si usamos nfs, tendremos que compartir el directorio /opt/ltsp. Ésto lo haremos añadiendo la siguiente línea al directorio /etc/exports del servidor de terminales:

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

Una vez añadida, hacemos que el servidor nfs relea el archivo /etc/exports ejecuntando en un terminal el comando:

# exportfs -ra

El siguiente paso, será configurar el servidor dhcp que hayamos instalado. De momento, como he dicho anteriormente, no voy entrar en detalles, y, cuando tenga más tiempo, por si a alguien le interesa, publicaré un artículo más detallado explicando cómo configurar dhcp3-server o dnsmasq. En cualquier caso, podemos ver ejemplos sobre cómo configurar dhcp en /usr/share/doc/ltsp-server/examples/dhcpd.conf o /etc/ltsp/dhcpd.conf y adaptarlos a nuestra red.

El siguiente paso, será crear el S.O. para los clientes. Como mis clientes son de arquitectura i386, ejecutamos la herramienta ltsp-build-client, que creará el entorno necesario para los clientes en /opt/ltsp/i386:

# ltsp-build-client --arch i386

Eso sí. Tendremos que tener un buen ancho de banda, porque se bajará un montón de paquetes para crear el entorno chroot. Si no disponemos de un buen ancho de banda, siempre podemos tirar de un mirror local. Yo tengo un mirror local en un disco duro externo y es lo que uso para crear el chroot.

Hay dos archivos en el chroot que nos permiten personalizar el cliente:

• /etc/lts.conf
  
• /etc/default/ltsp-client-setup.

Podemos ver ejemplos de configuración en /usr/share/doc/ltsp-client

Si quisiéramos actualizar los paquetes del entorno chroot para los clientes, primero hacemos el chroot:

# chroot /opt/ltsp/i386

Ahora que estamos en el entorno chroot de los terminales, ejecutamos:

# mount -t proc proc /proc

Actualizamos la lista de paquetes:

# apt-get update

Y actualizamos los paquetes:

# apt-get upgrade

Una vez terminada la actualización del chroot, desmontamos /proc:

# umount /proc

Y tecleamos el comando exit para salir del chroot.

Si nuestro kernel ha sido actualizado, tendremos que ejecutar el comando ltsp-update-kernels para asegurarnos de que nuestro chroot use la última versión:

# ltsp-update-kernels

Todos nuestros clientes usarán el último kernel la próxima vez que se reinicien.

Por último, si estamos usando nbd, ejecutaremos ltsp-update-image para que se cree una versión actualizada de la imagen que se servirá a los terminales:

# ltsp-update-image --arch i386

La primera vez que montemos el servidor de terminales, ejecutaremos:

# ltsp-update-sshkeys

Como el servidor de terminales se comunica con los clientes mediante un canal encriptado, la primera vez es necesario que se creen los certificados SSL. Sin la ejecución de este comando ningún cliente podrá hacer login en el servidor.

También tendremos que ejecutar ltsp-update-sshkeys cuando en el cliente intentemos hacer login y recibamos un error diciéndonos algo así como que "Este esquipo no está autorizado para conectarse al servidor".

Eso sí. Es importante que cuando tengamos que hacer un ltsp-update-sshkeys, primero ejecutemos un ltsp-update-sshkeys y seguidamente hagamos un ltsp-update-image. Y no al revés. También habrá que hacerlo cuando, por lo que sea, cambiemos la IP del servidor de terminales.


Qué usar: ¿nfs o nbd?
En Debian, por defecto, se usa nfs para servir el sistema a los terminales.
La ventaja que tiene usar nfs es que no es necesario crear una imagen. Se usa directamente el sistema montado en /opt/ltsp/i386.
Como desventaja, podemos decir que a mayor número de usuarios el sistema se ralentiza.

Si usamos nbd para servir el sistema a los terminales, la desventaja es que es necesario hacer una imagen comprimida (ltsp-update-image).
La ventaja está en que a mayor número de usuarios el sistema no se hace más lento, si no que se mantiene igual.

¿Cómo cambiar de nfs a nbd?
Primero.- Para usar nbd, lo primero que tenemos que hacer es instalar dos módulos en el chroot:

• squashfs
• aufs

Para ello, hacemos el chroot:

# chroot /opt/ltsp/i386

Ahora que estamos en el entorno chroot de los terminales, ejecutamos:

# mount -t proc proc /proc

Actualizamos la lista de paquetes:

# apt-get update

E instalamos los paquetes que nos instalan los módulos squashfs y aufs:

# apt-get install squashfs-modules-2.6.26-1-686 aufs-modules-2.6.26-1-686

Ojo. En el ejemplo tenemos instalado el kernel 2.6.26-1-686, por lo que instalamos los paquetes squashfs y aufs para ese módulo.

Una vez instalados, actualizamos el initrd:

# update-initramfs

Una vez terminado, desmontamos /proc:

# umount /proc

Y tecleamos el comando exit para salir del chroot.

Segundo.- Vamos a modificar dos ficheros:

• /opt/ltsp/i386/boot/pxelinux.cfg/default
• /opt/ltsp/i386/etc/default/ltsp-client-setup
  

En el fichero /opt/ltsp/i386/boot/pxelinux.cfg/default viene una línea como la siguiente: DEFAULT vmlinuz ro initrd=initrd.img quiet root=/dev/nfs ip=dhcp boot=nfs
Para que no se use nfs, la comentamos y ponemos una como la siguiente:
DEFAULT vmlinuz ro initrd=initrd.img quiet

Para no tener que acordarme, así es como tengo el fichero /opt/ltsp/i386/boot/pxelinux.cfg/default:

# Para usar nfs
#DEFAULT vmlinuz ro initrd=initrd.img quiet root=/dev/nfs ip=dhcp boot=nfs

# Para usar nbd
DEFAULT vmlinuz ro initrd=initrd.img quiet

Cuando quiero usar nbd comento la línea nfs y cuando quiero usar nfs comento la línea nbd

Una vez modificado el primer fichero, tenemos que modificar /opt/ltsp/i386/etc/default/ltsp-client-setup
En este segundo fichero lo único que tenemos que cambiar es el parámetro root-write-method=" " por root-write-method="aufs"

Una vez modificados los dos ficheros, como el primero afecta al kernel, ejecutamos un ltsp-update-kernels:

# ltsp-update-kernels

Y como usamos nbd, una vez hecho el ltsp-update-kernels haremos el ltsp-update-image:

# ltsp-update-image --arch i386

Si queremos volver a usar nfs, lo único que tendremos que hacer es modificar los dos ficheros anteriores. No tenemos que volver a crear la imagen, puesto que, mediante nfs, no se usan imágenes.