El manual para el clustering con openMosix - Nodos sin discos (II)

Configuración de los servicios requeridos

Reiteremos una vez más un par de puntos importantes:

• A la computadora completa que proporciona los servicios la referenciaremos como servidor y hará las funciones de servidor RPL, DHCP, TFTP y de NFS. Será la encargada de gestionar el arranque y de exportar la totalidad del sistema de ficheros para los nodos diskless -clientes-.

• Para todo ello deberemos estar seguros de haber incluido soporte para NFSroot en la configuración del kernel del cliente. Los demás servicios no tienen nada a configurar en la parte del cliente -puesto que no tendrí a donde almacenarla-.

En este capítulo aprenderemos a configurar los servicos que anteriormente se han expuesto, así pues se seguirá la misma estructurarión cuaternaria: rpl, dhcp, tftp y nfs.

I- CONFIGURACIÓN SERVIDOR RPL. rpld.conf

Lo primero será conseguir un demonio para el protocolo RPL. Una implementación funcional y estable puede bajarse de un rincón de la web de la Universidad de Cambridge^7.5.

Una vez compilado e instalado -y siendo root- podremos ejecutar el comando

rpld

Este demonio intentará acceder al fichero /etc/rpld.conf. Este fichero tiene una sintaxis muy concreta -a la vez que potente- y por ello se recomienda leer las páginas man posteadas en la misma dirección. Su lectura permitirá al administrador hacer un examen exhaustivo de todas las posibilidades que pueda brindarnos este servicio.

Existe un ejemplo de este tipo de fichero en el apéndice Salidas de comandos y ficheros. Basta con anotar la dirección MAC del cliente que realizará la petición e indicar la imagen rom que se corresponde al modelo de chipset de su nic^7.6. Los demás parámetros se refieren al tamaño de los bloques que se transferirán; los valores indicados en el fichero de ejemplo no deben dar problemas.

N. al LECTOR. La documentación necesaria para generar la rom adecuada a cada modelo de nic se encuentra en la siguiente sección: ROMs para arranque sin discos.

II- CONFIGURACIÓN SERVIDOR DHCP. dhcpd.conf

El fichero que el demonio dhcpd leerá para cargar la configuración será el /etc/dhcpd.conf . Este demonio puede lanzarse con el comando

/etc/init.d/dhcpd start

La ruta del demonio puede variar según la distribución. En el apéndice Salidas de comandos y ficheros hay un ejemplo de este tipo de fichero, para comprenderlo se aconseja ejecutar man dhcpd en cualquier consola. A continuación se detallan los parámetros que pueden ser más interesantes. Para la red:

• default/max-lease-time tiempos en milisegundos para las operaciones de reconocimiento.
• option domain-name define el nombre para la red.
• option domain-name-server dirección del servidor.
• option subnet-mask máscara de subred.
• range dynamic-bootp rango de direcciones, en este caso son 255 computadoras (de la 0 a la 254).
• option routers aquí indicaremos la dirección de un nodo que haga de enrutador, si existe.

• host indicará el nombre del nodo.
• hardware-ethernet quizás haga falta decir que cada X se refiere a un dígito hexadecimal correspondiente a la dirección MAC de la targeta en concreto.
• fixed-address asigna al nodo la dirección IP que el servidor hará llegar al cliente con la MAC anterior.
• filename referencia a la tagged image (imagen de kernel modificada) para arrancar.
• option root-path ruta para / del nodo.

El parámetro filename hace referencia a una imagen del kernel distinta a la salida del comando make bzImage utilizado para realizar la imagen del kernel linux. Para conocer las modificaciones necesarias a una iamgen para obtener una tagged image consúltese ROMs para arranque sin discos en la próxima sección.

III- CONFIGURACIÓN DEL SERVICIO TFTP inetd.conf

Como ya se ha mencionado, el protocolo TFTP es inseguro per se, es conveniente asegurar nuestro sistema con herramientas como tcp-wrapper y algún tipo de cortafuego -firewall- si queremos bajar las probabilidades de que llegue a darse una intrusión^7.7.

Una vez hagamos hecho las modificaciones ya dadas al fichero /etc/inetd.conf, para relanzar el demonio inetd^7.8 deberá ejecutarse:

/etc/init.d/inetd reload

Otra opción para relanzarlo es la señal HUP. Para ello deberemos conocer el PID del demonio y ejecutar:

kill -HUP inetd_pid

Para restablecer la seguridad que TFTP restará a nuestro sistema se debe hacer el máximo esfuerzo para: evitar recibir ataques de ipspoofing, proteger mediante permisos correctos el sistema, realizar un control sobre los logs creados y dar el mínimo de permisos posibles al servicio tftpd, por eso ejecutamos el demonio como el usuario nobody. El chroot es imprescindible así como el control de tcp-wrapper mediante los ficheros.

     /etc/host.allow
       /etc/host.deny
       /etc/syslog.conf
       /etc/inetd.conf
  

En la línea que hay que añadir -o descomentar- en el inetd.conf aparece como último parámetro el directorio raíz que sirve para encontrar los ficheros a importar. En este caso se ha considerado el directorio /tftpboot/ del servidor. En este directorio sería conveniente colocar todas las imágenes de los clientes^7.9, para dotar al sistema de cierto criterio y coherencia. Cabe recordar que es el fichero dhcpd.conf el que marca qué imagen debe recoger cada cliente.

IV- SERVIDOR NFS

Hasta este punto los clientes tienen que poder empezar a arrancar su kernel, no obstante no podrán iniciar el proceso con PID 1 , el INIT, debido a que no deben ser capaces de poder montar ninguna unidad. Aquí es donde entra el único servicio que resta: el NFS. Esta sección está separada, según sea el cometido:

• la exportación -por parte del servidor- de una serie de directorios
• o la importación del directorio / por parte del cliente.

IV A- EXPORTACIÓN DE DIRECTORIOS CON NFS

El servidor debe tener arrancado el demonio de servidor de nfs para poder proveer este servicio. Este demonio comunmente -en la mayor parte de las distribuciones linux- viene con el nombre nfssserver; para arrancarlo puede procederse como en cualquier demonio:

/etc/init.d/nfsserver start

El fichero de configuración de NFS que exporta los directorios necesarios suele estar en /etc/exports. Tiene su propio manual (man exports) que se deberá leer para incluir los directorios con una sintaxis correcta y añadir algo de seguridad al servicio NFS. En el caso de dos clientes - metrakilate y mCi- de arranque sin discos, este fichero de configuración tendría que ser algo parecido a lo siguiente:

/tftpboot/metrakilate/  192.168.1.2/255.255.255.0(rw,no_root_squash,sync)
  /tftpboot/mCi/          192.168.1.3/255.255.255.0(rw,no_root_squash,sync)
  /media/dvd/             192.168.1.0/255.255.255.0(ro,no_root_squash,sync)
  

En este ejemplo se indica donde se encuentra la raíz para cada una de las dos máquinas, más un directorio -la unidad local de dvd- que será exportada a cualquier nodo con IP 192.168.1.X (siendo X un valor entre 1 y 255).

El comando exportfs -a hace que se proceda a exportar los directorios que se lean de este fichero en el caso de que se añada alguna entrada cuando el servicio está activado. Otra posibilidad es guardar los cambios al fichero y enviar una señal tHUP o llamar al script con la opción reload.

IV B- RA´iZ EN LOS NODOS CLIENTES

Dentro de /tftpboot/directorio_raiz_de_un_nodo se debe encontrar un sistema réplica de ficheros a la distribución que queramos utilizar. La edción de ficheros para configuraciones añadidas o la ejecución de aplicaciones podrá hacerse normalmente como si se trabajara con unidades locales, ya que la capa de VFS nos hace transparente el proceso.

Así pues una solución es comenzar una instalación de linux cambiando la ruta de instalación a /tftpboot/ directorio_raiz_de_un_nodo, de manera se aseguran que todos los archivos necesarios se encuentran en el lugar requerido.

Otra posibilidad es hacer una instalación normal en un disco conectado a la placa madre del nodo cliente para asegurar que todo funciona correctamente. Una vez se ha comprobado que el sistema operativo es capaz de montar unidades por NFS y tiene capacidad de entrar en una red, puede procederse a empaquetar su directorio / desde la máquina servidora^7.10 para luego desempaquetarlo en el /tftpboot/directorio_raiz_de_un_nodo elegido.

La alternativa más dura será montar un linux -existente en algun disco- en el directorio mencionado del servidor. Esta alternativa pasa por copiar en el directorio lo siguiente:

• /bin, /sbin, /lib. Estos directorios pueden ser copiados directamente del directorio raíz con cp -a /bin /tftpboot/directorio_comun_a_los_nodos/ y luego hacerlos compartirdos entre todos los clientes sin discos mediante enlaces duros^7.11.

• /var, /tmp, /etc. Deben ser copiados en cada cliente y adaptados a las necesidades de cada uno de ellos, más abajo se da una breve descripción de lo que debe ser cambiado en /etc para que funcione.

• /proc, /root, /home. Deben existir y tener los permisos adecuados según sea su propietario.

• /dev. Debe ser único de cada cliente. Para crearlo se pueden utilizar dos opciones, devfs o una copia del sistema y luego la ejecución de MAKEDEV (script) y añadir un dispositivo /nfsroot al kernel que utilicemos.

Existen dos puntos que complican sensiblemente el proceso. Se detallan seguidamente.

1. configuración propia de cada nodo.
2. los dispositivos /dev .

En el caso de /etc es conveniente quitar del entorno rc.d todos aquellos scripts de arranque que no sean necesarios para cada nodo. Hay que configurar todos los apartados específicos como pueden ser el /etc/network/interfaces/ y/o adecuar el openmosix.map -que debiere ser indistinto para cualquier máquina del cluster-.

En general deben ser cambiados todos los parámetros propios de cada nodo, es relevante señalar la importancia de los parámetros de red. El problema de los dispositivos se puede resolver de dos maneras. La primera es utilizar el viejo sistema de minor y major number que hasta ahora se han utilizado en linux. Para ello puede hacerse una copia con:

cp -a /dev /tftpboot/directorio_raiz_de_un_nodo

cd /tftpboot/directorio_raiz_de_un_nodo

./MAKEDEV

Esto consigue que se generen los enlaces necesarios a este directorio -propio del nodo- en lugar de a /dev/xxxx, que es el directorio del servidor. Además hay que hacer un nuevo dispositivo de major 0 y minor 255, y exportarlo al kernel para que se puedan recibir comandos de nfsroot en él. Esto se puede conseguir con:

mknod /dev/nfsroot b 0 255

rdev bzImage /dev/nfsroot

Aquí bzImage tiene que ser la imagen del kernel del nodo diskless en cuestión. Generalmente se encuentra en /usr/src/linux-version/arch/i386/boot tras su compilación.

Llegados aquí, finalmente, tus clientes disk-less deberían estar funcionando sin nigún problema.