Subsecciones

- 7.1.1 Componentes hardware requeridos
- 7.1.2 Componentes hardware prescindibles
- 7.1.3 Ventajas e inconvenientes
- 7.1.4 Croquis de la arquitectura
- 7.1.5 Diálogo de comunicación
- 7.1.6 Servicios requeridos
- 7.1.7 Configuración de los servicios requeridos

# 7.1 Nodos sin discos

Previamente se dará un repaso para tener las nociones básicas sobre el ensamblaje del hardware necesario para la construcción de este tipo de computadoras minimalistas. De esta manera si los nodos ya son funcionales7.1, podrás pasarte los primeros apartados. A continuación se exponen esquematicamente los diálogos de comunicación entre nuestras computadoras, a fin de hacer comprender mejor el funcionamiento y poder detectar disfunciones con mayor precisión en el caso de no obtener una rápida puesta en marcha del sistema.

Aquí cubriremos todo el proceso de construcción de un cluster con una política de máquinas centrales -servidores- que servirán los servicios necesarios a un conjunto de nodos que poseerán los componentes hardware mínimos para funcionar -clientes-: desde la construcción de nodos minimalistas hasta su puesta en marcha con linux. Empecemos pues con lo tangible, las piezas.

## 7.1.1 Componentes hardware requeridos

Como ya se ha indicado, en este tipo de clusters tendremos dos tipos de computadoras: los servidores y los clientes.

Los servidores serán máquinas completas, entendiendo como tal un ordenador manejable localmente a través de su teclado, ratón y con la salida estándar direccionada a un monitor. Los clientes serán nodos con los mínimos componentes para funcionar. Éstos son, para cada uno:

- fuente de alimentación -a su vez podrá alimentar varios nodos si sabemos cómo realizar las conexiones-.
- placa madre -motherboard- con soporte de arranque por red.
- procesador -cpu-.
- memoria -entendiendo memoria principal de acceso aleatorio RAM-.
- y tarjeta de red con soporte de arranque por RPL (Remote Program load).

PRECAUCIONES: Deberemos prestar máxima atención a las compatibilidades entre las piezas que hayamos adquirido, puesto que resulta sumamente desagradable descubrir tras días de pruebas que todas ellas funcionan correctamente por separado, pero no en conjunto. Los problemas de temperatura, sobretodo de los procesadores, también son de máxima importancia, puesto que quemarlos no entra dentro de los objetivos a cubrir. Otra manera de reducir el riesgo de averías es trabajar siempre desconectado de la red eléctrica mientras trabajemos con las tarjetas y demás componentes.

## 7.1.2 Componentes hardware prescindibles

Para enfatizar aún más sobre lo que NO es necesario cabe mencionar, como componentes estándar, los siguientes:

- monitor, pantalla y targeta gráfica.
- teclado.
- ratón -mouse-.
- discos duros.
- diqueteras -floppy-.
- cualquier tipo de circuito integrado en placa madre.

## 7.1.3 Ventajas e inconvenientes

Ventajas

- configuración más sencilla, organizada y barata.
- mayor seguridad en el sistema -pérdida de datos, intrusiones-.
- menores costes de mantenimiento del maquinario.
- menores riesgos por averías en discos, al disponer de menor número de ellos.

Inconvenientes

- rompemos la descentralización y las ventajas que ello supone en un cluster.
- mayor tráfico en la red, puesto que añadiremos al tráfico de procesos del cluster el acceso a sistemas de ficheros remotos.
- menor robustez de la red: por estar más cargada es más susceptible a fallos y congestiones.

## 7.1.4 Croquis de la arquitectura

Los servidores proveerán las cuatro necesidades básicas para que un cliente pueda arrancar y funcionar adecuadamente en red.

1. Arranque (protocolo RPL). Desde el momento de su puesta en marcha el computador deberá ser capaz de dejar a parte el reconocimiento de dispositivos locales e intentar hacerse con los servicios de arranque a través de su nic.

2. Identificación (DHCP). Los clientes no tienen forma de mantener sus configuraciones anteriores -si hubieran existido- en ningun medio físico, puesto que no disponen de memoria secundaria -discos duros, ...-. Los servidores deben ocuparse de asignar la identidad a cada cliente cada vez que arranquen.

3. Descarga de la imagen del kernel (TFTP). Igualmente los clientes no pueden almacenar el kernel con el que deben arrancar. Éste debe mantenerse en el servidor y ser trasferido cada vez que el cliente lo solicite.

4. Sistema de archivos remoto (NFS). Una vez que los clientes dispongan de identidad y hayan arrancado su kernel les faltará un lugar donde volcar sus resultados y donde obtener los ejecutables que sus operaciones requieran. Necesitaremos configurar NFSroot

Consecuentemente los clientes a su vez seguirán un proceso de arranque distinto al común. Véase este nuevo método.

1. Arranque desde tarjeta de red (RPL). La única información útil de que disponen los clientes es su dirección MAC -o dirección ethernet- que está en el firmware de su tarjeta de red -viene especificada por el fabricante-. Ésta es única en el mundo y es lo primero que el servidor recibirá de un cliente y le permitirá reconocerlo, o no.

2. Identificación como miembro de la red (DHCP).

3. Descarga del kernel (TFTP). Para el arranque en las computadoras clientes la imagen del kernel tendrá que sufrir ciertas modificaciones que le permitan cargarse en memoria y poder ser arranacadas desde ahí. El resultado de dichos cambios en un bzImage común dan lugar a una tagged images del mismo. La transmisión se realiza por TFTP, todo ello se explicará más tarde.

4. Sistema de ficheros remoto (NFS). Para que el host sea útil debe poseer un directorio raíz donde montar su sistema de ficheros y así pasar a ser operable como cualquier sistema linux.

5. Integración en el cluster. Para terminar, tendremos que cargar los scripts necesarios para poder integrar cada cliente al cluster openMosix.

## 7.1.5 Diálogo de comunicación

Llegados a este punto se acuerda tener una idea del proceso que debe llevar a cabo cada tipo de computadora. Seguidamente se presenta todo ello en un pequeño diálogo -muy intuitivo- para esclarecer posibles dudas de procedimiento. Se indica igualmente el protocolo que lo implementa.

El primer paso es arrancar algún servidor, puesto que por deficnición sin ellos ningún cliente podría arrancar ningún servicio. Una vez hecho esto podrá ponerse en marcha un cliente. Su BIOS deberá percatarse de que debe iniciar desde la tarjeta de red -así lo habremos configurado, se explicará más tarde- y enviará por broadcast 7.2 su dirección MAC a la espera que alguien -un servidor- la reconozca y sepa qué configuración asignarle.

RPL

- Cliente (C): ¿alguien en esta red reconoce mi MAC?
- Servidor (S): yo mismo. Paso a darte capacidad para formar parte de esta red.

DHCP

- C: perfecto S, ¿quién soy?
- S: eres la IP x.x.x.x, tu servidor soy yo y tu fichero de arranque es `vmlinuz.etiqueta`

TFTP

- C: por favor S, dame `vmlinuz.etiqueta` para poder arrancar linux
- S: coge el fichero de mi directorio `/tftpdir/vmlinuz.etiqueta`
- C: correcto, empiezo mi arranque...

NFS

- C: arranque completo. Déjame montar mi sistema de ficheros raíz (con NFS)
- S: lo tienes en `/tftpboot/C/`
- C: déjame montar mis demás directorios (`/usr`, `/home`, etc...)
- S: los tienes ahí también
- C: ¡gracias S, ahora soy totalmente operable!

Como se verá a la hora de dar detalles sobre la forma de configurarlo, los nombres de ficheros y directorios pueden ser escogidos arbitrariamente.

## 7.1.6 Servicios requeridos

El diálogo anterior requiere de los servicios ya introducidos para poder llevarse a cabo.

- el servidor debe ser capaz de responder a peticiones de arranque por RPL de los clientes.
- el servidor y el cliente deberán comprender el protocolo DHCP.
- ídem para el protocolo TFTP.
- el servidor deberá arrancar el demonio servidor de NFS. Las computadoras clientes deben ser capaces de montar unidades por NFS, es una opción del kernel.

Como se ha señalado e impone el número de servicios a configurar, se divide en cuatro partes la temática de esta sección. En una primera fase se comentarán sus especificaciones para tener una visión de las posibilidades que ofrecen y tras ello se verán algunas herramientas necesarias para su configuración.

I - EL SERVIDOR Y EL CLIENTE DEL PROTOCOLO RPL

El protocolo RPL ha sido diseñado para el arranque desde tarjetas de red -nic- y dota al computador de la posibilidad de adquirir la posibilidad de hacer petición por DHCP, servicio que no posee debido a su falta de capacidad de almacenaje.

Instalar un nic con este soporte permite interrumpir a la BIOS del computador -en este caso un nodo cliente- con la interrupción INT 19H para gestionar el arranque desde este dispositivo. Los requerimientos, como ya se ha dicho, es que la placa madre del computador permita arranque por red y que el nic permita arranque RPL, algo común en el maquinario actual.

La estructura de datos en que se basa RPL es una pequeña imagen -rom- que deberá ser transferida al nic. Esta rom puede ubicarse en 2 localizaciones:

- Integrarse directamente en el hardware del nic. Aunque esta posibilidad solo viene contemplada de serie por las tarjetas más caras puesto que requiere un chip bootp rom específico para cada modelo. Este chip ha de colocarse sobre el socket -que suelen llevar todas las tarjetas- y tiene una capacidad de unos 32KB.

- La otra posibilidad -que es la más económica y la que aquí se detalla- es montar un servidor de roms para que los clientes obtengan la suya desde él. Esta posibilidad ofrece ventajas tanto a nivel de flexibilidad -no será necesario el chip. Las imágenes suelen ocupar 16KB.

II - EL SERVIDOR Y EL CLIENTE DEL PROTOCOLO DHCP

DHCP es un superconjunto de las operaciones que puede realizar BOOTP, que a su vez es una mejora sobre el antiguo protocolo de arranque RARP. En este caso utilizaremos DHCP para conseguir la dirección IP.

El funcionamiento de BOOTP -y por extensión DHCP- es sencillo. Es un protocolo de Internet que desde hace años -concretamente desde el 1985- está especificado en la RFC9517.3 de la The Internet Engineering Task Force -perteneciente a la Internet Society-. Este protocolo tiene como principales características:

- se realizan intercambios de un solo paquete con el mismo formato tanto para peticiones como respuestas. Este paquete o datagrama es IP/UDP y se utiliza timeout para retransmitir mientras no se reciba respuesta a una petición.

- Existe un código de opción que indica si el paquete es BOOTREQUEST (por el puerto 68) o BOOTREPLY (por el puerto 67). Las peticiones BOOTREQUEST contienen la máquina que las solicitó si ésta es conocida.

- Opcionalmente, se puede conceder el de la BOOTREPLY del nombre de un fichero que se debe descargar.

- Los servidores se comportan como gateway permitiendo incluso peticiones BOOTP entre varias redes.

El contenido de los campos de un paquete en el protocolo BOOTP es interesante para ver sus opciones. Además puede servirnos para detectar, mediante aplicaciones sniffers, fallos en tarjetas. Lo vemos en el `Cuadro` .

Tabla: Nodos diskless: Campos de un paquete del protocolo BOOTP

CAMPO | BYTES | DESCRIPCIÓN
op | 1 | opcode, 1=BOOTREQUEST - 2=BOOTREPLY
htype | 1 | tipo de hardware, 1=10Mbps ethernet
hlen | 1 | longitud de la MAC (normalmente 6)
hops | 1 | utilizado por los gateways para contar los saltos
xid | 4 | ID (identificador) de la transacción
secs | 2 | rellenado por el cliente con el riempo que lleva solicitando respuestas
- | 2 | reservados
ciaddr | 4 | dirección IP del cliente, en el caso de conocerse
yiaddr | 4 | dirección de un cliente, lo rellena el servidor tras consultar su configuración
siaddr | 4 | dirección del servidor
giaddr | 4 | opcional, para atravesar varias redes
chaddr | 16 | dirección hardware del cliente
sname | 64 | nombre del servidor (opcional)
file | 128 | ruta del archivo arranque
Vend | 64 | etiqueta específica del fabricante

Como puede verse, los campos son muy significativos para el tipo de operación que se pretenda realizar. Estos campos están incluidos en un datagrama IP/UDP, lo que representa una ventaja respecto a RARP, que solamente manipulaba operaciones en bruto sobre la red -sobre ethernet- no permitiendo opciones como el encaminamiento entre redes, ni la utilización de otro tipo de tecnologías distintas que no soportasen protocolo ARP.

El funcionamiento es muy sencillo. El cliente rellena un paquete con todos los campos que conoce y con el `opcode` de petición, y lo difunde a la dirección 255.255.255.255 de broadcast.

Luego contesta la máquina servidora rellenando el paquete de manera que el cliente recibe el paquete y lo procesa para colocar como praámetros de su pila IP los proporcionados por el servidor. Este caso se da, como se ha comentado repetidamente, siempre que el servidor esté configurado para responder a la dirección MAC del cliente que genera la petición.

El servidor de DHCP se inicia como un demonio -daemon- externo al inetd. Gracias a DHCP queda especificado todo lo referente a la identificación IP de aquellas máquinas que intenten entrar en la red. Se podrá asignar un rango dinámico de direcciones, también se puede hacer que todos descarguen la misma imagen del kernel sin asignarla directamente a ningún host en particular -útil en un cluster homogéneo-. En el apéndice relativo a Salidas de comandos y ficheros se ve un ejemplo del fjchero dhcpd.conf .

En cualquier caso y como resulta obvio, será necesario asignar una IP a cada host -sea nodo cliente o servidor- para que forme parte de la red del cluster y poder especificar el entorno de configuración de cada máquina, así como asignar los ficheros de configuración de openMosix.

III- EL SERVIDOR Y EL CLIENTE DEL PROTOCOLO TFTP

Como su nombre indica -Trivial FTP- este protocolo es un FTP especial: mucho más simple que éste. Para empezar, la capa de transporte utiliza UDP en lugar de TCP y transferencia por bloques para el envío de los ficheros, lo que hace más sencilla la transferencia (y más en una red ethernet). El otro motivo por el que se utiliza UDP y un mecanismo tan simple de control de paquetes es porque se necesita que el programa y lo mínimo de pila IP ocupen poco en memoria para que este pueda grabarse en ROMs, que inherentemente disponen de poca capacidad (32KBytes por lo general).

El servidor de TFTP -controlado por el demonio tftpd- se suele arrancar desde inetd. Su configuración se centrará en el servidor, puesto que el cliente lo adopta sin que sea necesario que lo hagamos explícito en ninguna parte.La configuración puede hacerse:

- Simple. Hay que tener cuidado del entorno en el que se encuentra el servidor, ya que el protocolo tftp es inherentemente inseguro y al no exigir autentificación, los clientes pueden solicitar el fichero /etc/passwd o similar sin ningún problema, lo que supone una inseguridad considerable.

- Seguro. Basa su seguridad en una llamada a chroot(). De este modo, en la ejecución de la rutina de aceptación de peticiones, el directorio exportado se convierte en directorio raíz. Consecuentemente el acceso a otros ficheros es más difícil.

TFTP es un servicio inseguro, ya que el propio protocolo es simple e inseguro, por lo que es recomendable que el servidor que posea este servicio esté aislado de cualquier red que no garantice medidas serias de seguridad. En casi contrario, cualquiera podría sustituir los ficheros que descargan los clientes e incluir en ellos alguna rutina no deseada.

La activación de este servicio es tan fácil como una línea en el fichero /etc/inetd.conf. Los parámetros pueden variar sensiblemente dependiendo de la aplicación que usemos para controlar el demonio. En principio debería no haber problemas con:

       tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd /tftpboot

IV- NFS

NFS es el sistema de almacenamiento ingeniado por Sun Microsystems y que utiliza RPC. Es un modelo de servidores sin estado, es decir, los servidores NFS no guardan en nigún momento los archivos a los que se están accediendo7.4.

El funcionamiento se basa en dos secciones: cliente y servidor. El cliente monta el sistema de ficheros exportado por el servidor y a partir de este momento accede a los ficheros remotos como si fuesen propios. Este sistema es utilizado desde hace tiempo en casi todos los sistemas Unix como método de compartir ficheros en red. NFSroot designa el método que sigue el kernel cuando en lugar de tomar el clásico sistema de ficheros ext2 o reiserfs para montar /, importa un directorio NFS de un servidor.

El sistema de archivos que debemos exportar en el servidor debe contener todos los archivos necesarios para que la distribución pueda funcionar. Este factor es muy variable, dentro de cada distribución, según activemos unos servicios u otros.

En principio cabe pensar en qué directorios deben ser necesariamente de lectura y escritura o solamente de lectura. Una buena forma de ahorrar espacio en el servidor sería exportando para todos los clientes los mismos directorios para solo lectura y particularizando para cada uno los de escritura y lectura. De cara a evitar mayores consecuencias en los posibles errores que puedan cometerse en la puesta en marcha del servicio, un buen consejo es no exportar directamente ningún directorio del servidor, sino uno propio de un cliente puesto en el directorio del servidor que usemos para disponer los directorios exportables -normalmente `/tftpboot/`-.

Aproximadamente se requieren unos 30MB de información específica para cada nodo -si estos disponen de un sistema linux mínimo-, mientras que el resto puede ser compartida.

## 7.1.7 Configuración de los servicios requeridos

Llegados a este punto tenemos un conocimiento adecuado de lo que pueden ofrecernos los cuatro servicios que utilizaremos. Sigamos la lectura para lograr hacer nuestras configuraciones, y aún más, entenderlas.

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 Cambridge7.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 nic7.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.

Para cada nodo:

- 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ón7.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 clientes7.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 servidora7.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 duros7.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.