Linux sin disco (Diskless)

por Xavier Eduardo Mármol.

Grupo de Usuarios Linux de Venezuela, VELUG Tutorial presentado en LinuxWeek Iberoamérica’99

Septiembre 1.999 - Caracas, VENEZUELA 2

Índice General

1 Resumen 1

2 Fundamentos Teóricos 3

2.1 Arranque y Autoconfiguración . . . . . . . . . . . . . . . . . 3 2.1.1 Utilización de IP para determinar una dirección IP . . 4 2.1.2 Procedimiento de arranque de dos pasos . . . . . . . . 5 2.1.3 La necesidad de una configuración dinámica . . . . . . 5 2.1.4 Configuración dinámica de anfitrión . . . . . . . . . . 6 2.1.5 Asignación dinámica de direcciones IP . . . . . . . . . 7 2.1.6 Resumen . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 TFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3 NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.1 Implantación NFS . . . . . . . . . . . . . . . . . . . . 11

3 Configuración del servidor 13 3.1 Configurando el demonio bootpd . . . . . . . . . . . . . . . . . 13 3.2 Configurando el demonio dhcpd . . . . . . . . . . . . . . . . . 15 3.3 Configurando el demonio tftpd . . . . . . . . . . . . . . . . . . 16 3.4 Creando el sistema de archivos raíz para el cliente . . . . . . 17

4 Preparación del núcleo de Linux 19 4.1 Compilando el núcleo . . . . . . . . . . . . . . . . . . . . . . 19 4.2 Haciendo una “imagen marcada” del núcleo . . . . . . . . . . 20

5 Cómo crear una imagen ROM 21

6 Entonación y Aplicaciones del arranque por red 23 6.1 Entonación del sistema . . . . . . . . . . . . . . . . . . . . . . 23 6.2 Aplicaciones del arranque por red . . . . . . . . . . . . . . . . 24 4

Resumen

La versatilidad del sistema operativo Linux lo hacen la elección ideal para crear “granjas” de computadores sin disco trabajando coordinadamente. En este tutorial estudiaremos los aspectos fundamentales del arranque a través de la red desde un programa almacenado en una memoria no-volátil y la puesta a punto de equipos que no poseen unidades de almacenamiento. El tutorial estará dividido en las siguientes etapas:

• Fundamentos Teóricos

• Configuración del servidor

• Preparación del Núcleo

• Como crear un BootROM

• El sistema de archivos raíz para los clientes

• Entonación del sistema

• Aplicaciones del arranque por red y equipos sin disco

Siguiendo este esquema mostraremos paso a paso los detalles de la configuración del servidor, los clientes “diskless” y la creación de un BootROM; además de hacer un énfasis especial en los usos, ventajas y desventajas de este paradigma de conexión.

2 Linux sin disco (Diskless)

Fundamentos Teóricos

2.1 Arranque y Autoconfiguración

Para comenzar, mostraremos cómo se utiliza el paradigma cliente-servidor para el proceso de arranque. Cada computadora conectada a una red de redes TCP/IP necesita saber su dirección IP antes de que pueda enviar o recibir datagramas. Además, una computadora requiere información adicional como la dirección de un ruteador, la mascara de red en uso y la dirección de un servidor de nombres. Nosotros estudiaremos dos protocolos del proceso de arranque muy relacionados que permiten a un anfitrión determinar su dirección IP. Sorprendentemente, el cliente y el servidor se comunican mediante el UDP.

Lo que es sorprendente del procedimiento de arranque es que el UDP depende del protocolo IP para transferir mensajes, y podría parecer imposible que una computadora pudiese utilizar el UDP para localizar la dirección IP que utiliza ésta cuando se comunica. Examinaremos los protocolos que nos ayudarán a entender cómo puede una computadora utilizar una dirección IP especial y la flexibilidad del mecanismo de transporte UDP/IP. También veremos de qué manera asigna un servidor una dirección IP a una computadora en forma automática. Esta asignación es especialmente importante en ambientes que permiten conexiones de red de redes temporales en los que las computadoras se transfieren de una red a otra (por ejemplo, un empleado con una computadora portátil puede moverse de una localidad hacia otra en una compañía).

2.1.1 Utilización de IP para determinar una dirección IP

Dijimos que BOOTP se vale del UDP para transportar mensajes y que los mensajes UDP están encapsulados en los datagramas IP para su entrega. A fin de entender cómo puede enviar una computadora a BOOTP un datagrama IP antes de que la computadora conozca su dirección IP, recordemos que hay varias direcciones IP de casos especiales. En particular, cuando se usa como una dirección de destino, la dirección IP está formada sólo por unos (255.255.255.255), que especifican el límite para la difusión. El software IP puede aceptar y difundir datagramas que especifican la dirección de difusión límite, incluso antes de que el software haya descubierto la información de su dirección IP local. El punto es el siguiente:

Un programa de aplicación puede utilizar la dirección IP de difusión límite para obligar al IP a difundir un datagrama en la red local, antes de que el IP haya descubierto la dirección IP de la red local o la dirección IP de la máquina.

Supongamos que la máquina cliente A desea utilizar BOOTP para localizar información de arranque (incluyendo su dirección IP) y que B es el servidor en la misma red física que responderá a la solicitud. Dado que A no conoce la dirección IP de B o la direccin IP de la red, débe difundir en su BOOTP inicial la solicitud para utilizar la dirección IP de difusión límite. ¿Cual será la réplica? ¿Puede B enviar una réplica directamente? Por lo general no. Aun cuando pueda no ser obvio, B quizás necesite utilizar la dirección de difusión límite para su réplica, aunque conozca la dirección IP de A. Para entender por qué, considere qué sucedería si un programa de aplicación en B logra enviar un datagrama utilizando la dirección IP de A. Después de rutear el datagrama, el software IP en B pasará el datagrama al software de interfaz de red. El software de interfaz debe transformar la siguiente dirección IP de salto hacia la dirección de hardware correspondiente, presumiblemente utilizando ARP. Sin embargo, debido a que A no ha recibido la réplica BOOTP, no reconocerá su dirección IP y no podrá responder a la solicitud ARP de B. Además, B tiene sólo dos alternativas: difundir la réplica o utilizar información del paquete de solicitud para añadir de manera manual una entrada a su memoria intermedia ARP. En los sistemas que no permiten a los programas de aplicación modificar la memoria intermedia ARP, la difusión es la única solución.

2.1.2 Procedimiento de arranque de dos pasos

BOOTP utiliza un procedimiento de arranque de dos pasos. No proporciona una imagen de memoria a los clientes -sólo proporciona al cliente información necesaria para obtener una imagen. El cliente entonces utiliza un segundo protocolo (por ejemplo, el TFTP) para obtener la imagen de memoria. Aunque el procedimiento de dos pasos muchas veces parece innecesario, permite una clara separación de configuración y almacenamiento. Un servidor BOOTP no necesita correr en la misma máquina que almacena las imágenes de memoria. De hecho, el servidor BOOTP opera desde una simple base de datos que sólo conoce los nombres de las imágenes de memoria.

Mantener la configuración separada del almacenamiento es importante pues permité al administrador configurar conjuntos de máquinas para que éstas actúen en forma idéntica o de manera independiente. El campo BOOT FILE NAME de un mensaje BOOTP ilustra el concepto. Supongamos que un administrador tiene varias estaciones de trabajo con diferentes arquitecturas de hardware, y supongamos que cuando el usuario arranca una de las estaciones de trabajo, éstas seleccionan correr en UNIX o en un sistema operativo local. Debido a que el conjunto de estaciones de trabajo incluye múltiples arquitecturas de hardware, no operará en todas las máquinas una sola imagen de memoria. Para adaptarse a esta diversidad, BOOTP permite que el campo BOOT FILE NAME en una solicitud contenga un nombre genérico como ünix”, lo cual significa ”quiero arrancar el sistema operativo UNIX para esta máquina”. El servidor BOOTP consulta su base de datos de configuración para transformar el nombre genérico en un nombre de archivo específico que contiene imagen de memoria UNIX apropiada para el hardware del cliente y devuelve el nombre específico (es decir, completamente definido) en su réplica. Por supuesto, la base de datos de configuración tambin permite un arranque completamente automático mediante el cual el cliente coloca ceros en el campo BOOT FILE NAME y con ello, BOOTP selecciona una imagen de memoria para la máquina. La ventaja del método automático es que permite al usuario especificar nombres genéricos que trabajen en cualquier máquina. No es necesario recordar nombres de archivos específicos o arquitecturas de hardware.

2.1.3 La necesidad de una configuración dinámica

Como RARP, BOOTP fue diseñado para un ambiente relativamente estático en el que cada anfitrión tiene una conexión de red permanente. Un administrador crea un archivo de configuración BOOTP que especifica un conjunto de parámetros BOOTP para cada anfitrión. El archivo no cambia con frecuencia pues la configuración generalmente se mantiene estable. Por lo común, una configuración no registra cambios durante semanas.

Con la llegada de redes inalámbricas y computadoras portátiles como las laptop y las notebook, se ha vuelto posible transportar a las computadoras de una localidad a otra rápida y fácilmente. BOOTP no se ádapta a esta situación pues la información de configuración no puede cambiar rápidamente. Así pues, sólo proporciona una transformación estática desde un identificador de anfitrión hacia parámetros para el anfitrión. Además, un administrador debe introducir un conjunto de parámetros para cada anfitrión y luego almacenar la información en un archivo de configuración de servidor BOOTP -BOOTP no incluye una forma para asignar dinámicamente valores a máquinas individuales. En particular, un administrador debe asignar cada anfitrión a una dirección IP y configurar el servidor para entender la transformación del identificador de anfitrión a la direccin IP. Los parámetros de asignación estática trabajan bien si las computadoras se mantienen en localidades fijas y el administrador tiene suficientes direcciones IP para asignar a cada computadora una dirección IP única. Sin embargo, en los casos en los que las computadoras se muevan con frecuencia o que el número de computadoras físicas exceda el de direcciones de anfitrión IP disponibles, la asignación estática generará sobrecargas excesivas. Por lo tanto está claro que un sistema es inadecuado si requiere que el administrador cambie el archivo de configuración del servidor antes de que se añada una nueva computadora a la red y comience a comunicarse; se necesita pues un mecanismo automatizado.

2.1.4 Configuración dinámica de anfitrión

Para manejar la asignación de direcciones de manera automática, el IETF ha diseñado un nuevo protocolo. Conocido como Dynamic Host Configuration Protocol (Protocolo de configuración dinámica de anfitrión o DHCP), el nuevo protocolo extiende BOOTP ya que el DHCP permite que una computadora posea una dirección IP en forma rápida y dinámica. Para utilizar el mecanismo de asignación de direcciones dinámico DHCP, un administrador debe configurar un servidor DHCP supliendo un conjunto de direcciones IP. Cada vez que una computadora nueva se conecta a la red, la computadora contacta al servidor y solicita una dirección. El servidor selecciona una de las direcciones especificadas por el administrador y la asigna a la computadora. Para ser completamente general, el DHCP permite tres tipos de asignación de direcciones; un administrador selecciona cómo responderá el DHCP a cada red o a cada anfitrión. Como BOOTP, el DHCP permite la configuración manual, mediante la cual un administrador puede configurar una dirección específica para una computadora específica. El DHCP tambin permite la configuración automática, por medio de la cual el administrador permite a un servidor DHCP asignar una dirección permanente cuando una computadora es conectada por primera vez a la red. Por último, DHCP permite una configuración dinámica completa, con la cual el servidor “presta” una dirección para una computadora por tiempo limitado. Como en BOOTP, el DHCP utiliza la identidad del cliente para decidir cómo proceder. Cuando un cliente contacta un servidor DHCP, envía un identificador, por lo general, la dirección de hardware del cliente. El servidor utiliza el identificador del cliente y la red a la que el cliente se ha conectado para determinar cómo asignar el cliente y la dirección IP. Así, el administrador tiene un control completo sobre la forma en que se asignan las direcciones. Un servidor puede configurarse para asignar direcciones a computadoras específicas de manera estática (como BOOTP), mientras permite a otras computadoras obtener dinámicamente direcciones de manera permanente o temporal.

2.1.5 Asignación dinámica de direcciones IP

La asignación dinámica de direcciones es el más significativo y novedoso aspecto del DHCP. A diferencia de la asignación de direcciones estática, utilizada en BOOTP, la asignación de direcciones dinámica no es una transformación uno a uno, y el servidor no necesita conocer la identidad de un cliente a priori. En particular, un servidor DHCP puede ser configurado, para permitir que una computadora arbitraria obtenga una dirección IP y comience la comunicación. Así, el DHCP permite diseñar sistemas que se autoconfiguren. Luego de que una computadora ha sido conectada a la red, la computadora se vale del DHCP para obtener una dirección IP y entonces configura su software TCP/IP a fin de utilizar la dirección. Por supuesto, la autoconfiguración está sujeta a restricciones administrativas -es el administrador el que decide qué servidor DHCP puede realizar la autoconfiguración. En resumen:

Como el DHCP permite a un anfitrión obtener todos los parámetros necesarios para la comunicación, sin la intervención manual, también permite la autoconfiguración. ésta se encuentra sujeta, por supuesto, a restricciones administrativas.

Para hacer posible la autoconfiguración, un servidor del DHCP comienza con un conjunto de direcciones IP que el administrador de red asigna al servidor para su manejo. El administrador especifica las reglas bajo las que opera el servidor. Un cliente DHCP negocia el uso de una dirección intercambiando mensajes con un servidor. En el intercambio, el servidor proporciona una dirección para el cliente y el cliente verifica que la dirección sea aceptable. Una vez que el cliente ha aceptado una dirección, puede comenzar a utilizar la dirección para comunicarse. A diferencia de la asignación de direcciones estática, que asigna permanentemente cada dirección IP a un anfitrión específico, la asignación de direcciones dinámica es temporal. Decimos que un servidor DHCP arrienda una dirección a un cliente por un período de tiempo finito. El servidor especifica el período de arrendamiento cuando asigna la dirección. Durante el período de arrendamiento, el servidor no arrendará la misma dirección a ningún otro cliente. Al final del período de arrendamiento, sin embargo, el cliente debe renovar el arrendamiento o dejar de usar la dirección. ¿Cuánto debe durar un arrendamiento DHCP? El tiempo óptimo de arrendamiento depende en particular de la red y de las necesidades de un anfitrión. Por ejemplo, para garantizar que las direcciones puedan reciclarse con rapidez, las computadoras en una red utilizadas por estudiantes en un laboratorio universitario deben tener un corto período de arrendamiento (por ejemplo, una hora): En contraste, la red de una compañía podría utilizar un período de arrendamiento de un día o de una semana. Para adaptarse a todos los posibles ambientes, el DHCP no especifica un período de arrendamiento fijo y constante. De hecho, el protocolo permite que un cliente solicite un período de arrendamiento específico y permite a un servidor informar al cliente que el período de arrendamiento está garantizado. Así, un administrador puede decidir durante cuánto tiempo podrá asignar cada servidor una dirección a un cliente. En el caso extremo, el DHCP reserva un valor infinito para permitir un arrendamiento por un período de tiempo indeterminadamente largo, como la asignación de direcciones permanente utilizada en BOOTP.

2.1.6 Resumen

El protocolo de arranque BOOTP proporciona una alternativa a RARP para computadoras que necesitan determinar su dirección IP. BOOTP es más general que RARP pues utiliza el UDP, lo que hace posible extender el proceso de arranque a través de un ruteador. BOOTP también permite a una máquina determinar una dirección de ruteador, una dirección (archivo) de servidor y el nombre de un programa que la computadora deberá correr. Finalmente, BOOTP permite a los administradores establecer la configuración de una base de datos que transforma un nombre genérico como ünix”en un nombre de archivo completamente caracterizado que contiene la imagen de memoria apropiada para el hardware del cliente. BOOTP está diseñado para ser lo suficientemente pequeño y simple como para residir en un arranque localizado en ROM. El cliente utiliza la dirección de difusión limitada para comunicarse con el servidor y tiene la responsabilidad de retransmitir solicitudes si el servidor no responde. La retransmisión emplea un procedimiento de retroceso exponencial similar a Ethernet para evitar el congestionamiento. Diseñado como sucesor de BOOTP, el Dynamic Host Configuration Protocol (DHCP) amplía BOOTP de varias formas. Lo más importante es que el DHCP permite que un servidor localice direcciones IP automática o dinámicamente. La asignación dinámica es necesaria para ambientes como las redes inalámbricas cuyas computadoras pueden conectarse y desconectarse rápidamente. Para utilizar el DHCP, una computadora debe convertirse en cliente. La computadora difunde una solicitud para los servidores DHCP, selecciona una de las ofertas recibidas e intercambia mensajes con el servidor a fin de obtener un arrendamiento de la dirección IP anunciada. Cuando un cliente obtiene una dirección IP, arranca 3 temporizadores. Luego de que el primer temporizador expira, el cliente debe intentar la renovación de su arrendamiento. Si un segundo temporizador expira antes de que se complete la renovación, el cliente debe tratar de reasignar su dirección a cualquier servidor. Si el último temporizador expira antes de que se haya obtenido un arrendamiento, el cliente deja de utilizar la dirección IP y regresa al estado inicial para adquirir una nueva dirección.

2.2 TFTP

Aunque el FTP es el protocolo de transferencia de archivos más generalizado en el conjunto TCP/IP, también es el más complejo y difícil de programar. Muchas aplicaciones no necesitan de la funcionalidad completa que ofrece el FTP, ni pueden afrontar la complejidad. Por ejemplo, el FTP requiere que tanto clientes como servidores manejen diversas conexiones TCP concurrentes, algo que puede ser difícil o imposible en computadoras personales que no tengan sistemas operativos sofisticados. El conjunto TCP/IP contiene un segundo protocolo de transferencia de archivos que proporciona un servicio económico y poco sofisticado. Se conoce como Trivial File Transfer Protocol (TFTP, protocolo trivial de transferencia de archivos) y se diseñó para aplicaciones que no necesitan interacciones complejas entre cliente y servidor. El TFTP restringe las operaciones a transferencia de archivos sencilla y no proporciona autenticación. Como es más restrictivo el software TFTP resulta mucho más pequeño que el FTP. El tamaño reducido es importante para muchas aplicaciones. Por ejemplo, los fabricantes de dispositivos sin disco pueden codificar al TFTP en la memoria de sólo lectura (ROM) y usarlo para obtener una imagen de memoria inicial cuando se encienda la máquina. Al programa, en ROM, se le llama arranque del sistema. La ventaja de utilizar el TFTP es que permite al código de arranque emplear los mismos protocolos TCP subyacentes que el sistema operativo utiliza una vez que empieza la ejecución. De este modo es posible para una computadora arrancar desde un servidor en otra red física. A diferencia del FTP, el TFTP no necesita un servicio de transporte de flujo confiable. Corre bajo UDP o cualquier otro sistema de entrega de paquetes no confiable y utiliza tiempos límites y retransmisión para asegurar que los datos lleguen. El lado que envía transmite un archivo de tramaño fijo (512 octetos) bloquea y espera un acuse de recibo para cada bloque antes de enviar el siguiente. El receptor envía un acuse de recibo para cada bloque cuando le llega. Las reglas del TFTP son sencillas. El primer paquete enviado requiere de una transferencia de archivo y establece la interacción entre cliente y servidor, el paquete especifica el nombre de archivo y si el archivo se leerá (transferido al cliente) o se escribirá (transferido al servidor). Los bloques del archivo están numerados en forma consecutiva comenzando con 1. Cada paquete de datos contiene un encabezado que especifica el número de bloque que se transporta. Y cada acuse de recibo contiene el número de bloque del que se está recibiendo el acuse de recibo. Un bloque de menos de 512 octetos señala el final del archivo. Es posible enviar un mensaje de error en lugar de los datos o del acuse de recibo. Los errores terminan con la transferencia. Una vez que se ha hecho una petición de escritura o de lectura, el servidor utiliza la dirección IP y el número de puerto de protocolo UDP del cliente para identificar las operaciones subsiguientes. De este modo, ni los mensajes de datos (los mensajes que transportan bloques del archivo) ni los mensajes ack (los mensajes que dan el acuse de recibo de los bloques de datos) necesitan especificar el nombre de archivo. Finalmente hay un tipo de mensaje que se utiliza para reportar errores. Los mensajes perdidos se pueden volver a transmitir después de un tiempo límite, pero la mayor parte de los demás errores simplemente causa que la interacción se acabe. La retransmisión TFTP resulta inusual porque es simétrica. Cada lado implanta un tiempo límite y una retransmisión. Si el lado que envía llega a su tiempo límite, vuelve a transmitir el último bloque de datos. Si el lado responsable de los acuses de recibo llega a su tiempo límite vuelve a transmitir el último acuse de recibo. Tener a ambas partes participando en la transmisión ayuda a asegurar que no falle la transferencia después de que se haya perdido un paquete. Aunque que la retransmisión simétrica garantiza potencia, puede conducir a retransmisiones excesivas. El problema conocido como Falla del aprendiz de brujo surge cuando un acuse de recibo para el paquete de datos k se demora pero no se pierde. El emisor vuelve a transmitir el paquete de datos para el cual el receptor emite un acuse de recibo. Ambos acuses de recibo llegan en algún momento y cada uno dispara una transmisión del paquete de datos k + 1. El receptor emite su acuse de recibo para ambas copias del paquete de datos k + 1, y los dos acuses de recibo causan que el emisor transmita el paquete de datos k + 2. La falla del aprendiz de brujo también puede iniciarse si la red de redes subyacente duplica los paquetes. Una vez que empieza el ciclo, continua indefinidamente con cada paquete de datos que se transmite justo dos veces. Aunque el TFTP contiene lo mínimo necesario para la transferencia, soporta diversos tipos de archivo. Un aspecto interesante del TFTP es el hecho de que puede estar integrado al correo electrnico. Un cliente puede especificar al servidor que enviará un archivo al que se le considerará como correo con el campo FILENAME, tomado como nombre para un buzón en el que el servidor deberá entregar el mensaje.

2.3 NFS

El Network File System (Sistema de archivos de red o NFS), que originalmente fue desarrollado por Sun Microsystem Incorporated, proporciona un acceso de archivos compartidos en línea que es transparente e integrado; muchas de las localidades TCP/IP utilizan el NFS para interconectar los archivos de sus computadoras. Desde la perspectiva del usuario, el NFS es casi invisible. Un usuario puede ejecutar un programa de aplicacin arbitrario y valerse de archivos arbitrarios de entrada o salida. Los nombres de los archivos per se no muestran si son locales o remotos.

2.3.1 Implantación NFS

En la figura se ilustra cómo es que el NFS está embebido en un sistema operativo. Cuando se ejecuta un programa de aplicación, se llama al sistema operativo para que abra un archivo o para que almacene y recupere datos en archivos. El mecanismo de acceso de archivos acepta la petición y la transmite de manera automática al software de sistema de archivo local o al cliente NFS, dependiendo de si el archivo está en el disco local o en una máquina remota. Cuando recibe una petición, el software del cliente utiliza el protocolo NFS para ponerse en contacto con el servidor apropiado en una máquina remota y ejecutar la operación requerida. Cuando contesta el servidor remoto, el software del cliente devuelve los resultados al programa de aplicación.

12 Linux sin disco (Diskless)

Configuración del servidor

Una vez que estudiamos brevemente los conceptos fundamentales del arranque a través de la red y los protocolos involucrados; vamos a fijar esos conocimientos poniendolos en practica. Al finalizar de leer y practicar esta guia el lector estará en capacidad de instalar, configurar y utilizar una “granja” de computadores Linux.

3.1 Configurando el demonio bootpd

Comenzaremos configurando el demonio bootpd en nuestro servidor Linux. Este demonio generalmente viene como parte de casi todas las distribuciones modernas de Linux, en caso que necesite instalarlo, debe obtener el paquete bootpd-2.4.tar.gz desde su servidor de archivos favorito, compilarlo e instalarlo^{1}.

Una vez instalado el demonio se puede demonio se puede ejecutar directamente utilizando el comando:

       # bootpd -s

o a través de inetd. En ese caso será necesario:

1. Editar /etc/inetd.conf, y asegurarse de que existe y está descomentada la siguiente línea:

     bootps  dgram  udp  wait  root  /usr/sbin/tcpd   bootpd

2. Asegurese que en el archivo /etc/services existen y están decomentadas las líneas:

     bootps          67/tcp          # BOOTP server
     bootps          67/udp          # BOOTP server

1Siga las instrucciones que encontrará en el archivo README que viene con el paquete

3. Reiniciar inetd usando el comando:

            # killall -HUP inetd

Ahora deberemos configurar el bootpd a través de su archivo de configuración llamado bootptab el cual usualmente se encuentra en /etc. Debe ser modificado insertando la dirección IP de su ruteador, servidor de nombres y los datos correspondientes a sus máquinas sin disco.

La información esencial que usted debe colocar en su bootptab es:

1. El FQDN^{2} de la máquina

2. La dirección física de su adaptador de red, esta generalmente se obtiene de una calcomania en la tarjeta, del programa de configuración o en última instancia activando la opción debug del demonio bootpd para mirar los paquetes que envia la imagen ROM cuando trata de arrancar

3. El nombre que tendr’a la imagen marcada del núcleo y el directorio que la contendrá

4. El IP que usted espera asignarle a cliente sin disco

5. La dirección IP de algunos servidores como DNS, Ruteador, etc.

Aquí le presentamos un ejemplo de un archivo /etc/bootptab para el servidor bootpd; este ejemplo probablemente funcione en otros sabores de UNIX:

# Plantilla general.
.default:hd=/tftpboot:bf=null:\
        :ds=192.168.1.1:\
        :sm=255.255.255.0:\
        :gw=192.168.1.254:\
        :ts=192.168.1.100:\
        :to=-7200:
# Configuracion especifica.
diskless.linux.org.ve:ha=00C0DF116DEF:\
        :ip=192.168.1.2:\
        :bf=vmlinuz.diskless:\
        :tc=.default:

2Nombre de dominio completamente calificado, por sus siglas en Ingles

La primera entrada define una plantilla de valores que puede ser usada por todas las configuraciones especificas “incluyendo” el campo tc=.default. En la entrada correspondiente a la configuración específica el primer campo es el FQDN de la máquina, el campo ha especifica la dirección Ethernet de su NIC^{3}; el campo ip es auto explicativo; el campo bf especifica el nombre de la imagen marcada del núcleo. Para una explicación mas detallada consulte la página del manual (man bootptab).

Recuerde que usted debe ejecutar el comando bootpef cada vez que modifique el archivo bootptab.

3.2 Configurando el demonio dhcpd

Como una alternativa a bootp podemos configurar un servidor DHCP que posee la ventaja de automatizar el manejo de los IP’s, usted debe asegurarse que el paquete dhcp-2.0.tar.gz este instalado. Es de hacer notar que el núcleo seguira enviando una petición bootp para buscar la dirección IP para montar el sistema de archivos raíz a través de NFS. De seguro usted necesitara investigar sobre las opciones del mknbi-linux para configurar la imagen marcada del núcleo para que acepte una respuesta DHCP.

El archivo de configuración /etc/dhcpd.conf es equivalente al bootptab:

# Configuracion para un cliente Diskless.
option domain-name "linux.org.ve";
option domain-name-servers 192.168.1.1;
option broadcast-address 192.168.1.255;
use-host-decl-names on;
subnet 192.168.1.0 netmask 255.255.255.0 {
        filename "/tftpboot/vmlinuz.diskless";
        host xterm {
                hardware ethernet 00:C0:DF:11:6D:EF;
                fixed-address diskless.linux.org.ve;
                filename "/tftpboot/vmlinuz.diskless";
        }
}

Usted no tiene que usar una dirección fija por supuesto, pero si elije usar una dirección variable usted tendrá que manejar con cuidado el NFS y prestar especial atención al contenido de /etc/exports.

3Adaptador de red, por sus siglas en Ingles

Si desea más información sobre el DHCP visite

http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html.

Si usted está en una red local que no posee una conexión directa a Internet, usted puede utilizar una dirección IP “privada” de la clase 192.168.x.y (RFC1918). En otro caso por favor contacte a su administrador de red o a su proveedor de servicio y obtenga su propia dirección IP.

3.3 Configurando el demonio tftpd

Ahora deberemos configurar el demonio tftpd que es el que tranferirá la imagen marcada del núcleo para que el cliente Diskless pueda arrancar. De nuevo asegurese que el paquete netkit-tftp-0.10.tar.gz este correctamente instalado y verifique que el servicio esta activo en los archivos /etc/inetd.conf y /etc/services. El tftpd puede ser usado de dos maneras:

tftp simple:

El cliente puede acceder a la totalidad de su sistema de archivos. Es simple pero puede generar un gran problema de seguridad (cualquiera puede obtener su archivo de claves vía tftp).

tftp seguro:

El servidor tftp utiliza un llamada de sistema chroot.2 para cambiar a su propio directorio raíz. Cualquier cosa que esté fuera del nuevo directorio raíz es completamente inaccesible, ya que el directorio que sufre el chroot se transforma en el nuevo directorio raíz; el campo hd del archivo bootptab debe reflejar esta nueva situación.

Por ejemplo: cuando se utiliza tftp simple, el campo hd contiene el path o camino completo del directorio de arranque: /tftpboot. Cuando se utiliza tftp seguro con /tftpboot como directorio raíz, entonces /tftpboot pasa a ser / y el campo hd debe ser /.

Si usted está arrancando muchos clientes Diskless probablemente se vera limitado por las restricciones del inetd ya que este tipicamente limita el numero de demonios que pueden ser levantados. Si muchos clientes solicitan el servicio de tftp con períodos cortos de diferencia, inetd apagará el servicio. Si usted realiza esta configuración donde existen muchos clientes deberá correr un servidor tffp dedicado, que no sea ejecutado desde el inetd. Usted puede conseguir un servidor tftp independiente en:

ftp://nilo.on.openprojects.net/pub/nilo/snapshots/

3.4 Creando el sistema de archivos raíz para el cliente

Ahora usted necesita crear un directorio y crear una sistema de archivos raíz para el cliente sin disco, este directorio debe contener un sistema de archivos raíz completo para que el sistema operativo pueda arrancar exitosamente. Por tal razón es necesario que dicho sistema contenga los directo-

rios /dev, /proc, /etc, /sbin, /bin, /tmp, /var. Los detalles varian

según la distribución de Linux que este usando. Usted puede copiar estos archivos de un sistema ya instalado y luego modificar ciertos archivos claves.

Peligro: Nunca trate de compartir el sistema de archivos raíz entre en servidor y el cliente exportandolo directamente o a través de un enlace ya que esto podría hacerle peder datos importantes, además de que representa un riesgo de seguridad importante.

El sistema de archivos que creamos de esta manera de estar exportado con permisos de lectura, escritura y con el atributo no_root_squash; de no hacer esto conseguiriamos que una amplia gama de demonios y loggers no funcionaran correctamente.

18 Linux sin disco (Diskless)

Preparación del núcleo de Linux

4.1 Compilando el núcleo

Usted ciertamente necesita compilar un nuevo núcleo de Linux ya que usted necesita soporte BOOTP, NFS-root, etc. para configurar el núcleo vaya al directorio donde guarda las funtes y ejecute:

# make config

responda todas las preguntas de acuerdo a sus requerimientos e incluya las siguientes opciones:

        * Networking options
        TCP/IP networking (CONFIG_INET) [Y/n/?] y
        IP: n\'ucleo level autoconfiguration (CONFIG_IP_PNP) [N/y/?] y
            BOOTP support (CONFIG_IP_PNP_BOOTP) [N/y/?] (NEW) y
        * Network File Systems
        NFS filesystem support (CONFIG_NFS_FS) [Y/m/n/?] y
            Root file system on NFS (CONFIG_ROOT_NFS) [N/y/?] (NEW) y

por último, no olvide compilar el soporte para la interfaz de red dentro del núcleo y no como módulo.

Ahora debe generar la imagen del núcleo con los comandos:

# make dep; make clean; make bzImage

de esta manera ya tienes una imagen del kernel de Linux configurada para el arranque por red, esta imagen quedo almacenada en el directorio

/usr/src/linux/arch/i386/boot con el nombre bzImage.

4.2 Haciendo una “imagen marcada” del núcleo

No puedes instalar la bzImage, que conseguiste de la compilación del núcleo, directamente. Debe ser convertida en una “imagen marcada” Ésta es una imagen normal del núcleo con una cabecera especial que le dice al cargador de arranque en red dónde han de almacenarse los bytes en memoria y en qué dirección empieza el programa. Para crear esta imagen “marcada” se usa un programa llamado mknbi-linux, que puede ser encontrado en la distribución de Etherboot. Después de crear la imagen, ponla en el directorio /tftpboot con el nombre especificado en /etc/bootptab. Asegúrate de darle permiso de lectura para todo el mundo a este archivo porque el servidor “tftpd” no tiene ningún privilegio especial.

Para marcar la imagen nosotros ejecutamos el siguente comendo:

        # mknbi-linux -d /tftpboot/xclient bzImage \
                      /tftpboot/vmlinuz.diskless

este comando “marca” la imagen y le indica que el directorio a montar por

NFS como raíz es /tftpboot/xclient.

La distribución de Etherboot la puedes encontrar en

http://www.slug.org.au/etherboot.

Cómo crear una imagen ROM

Además de ROMs de arranque comerciales, existen dos fuentes gratis de las que conseguir paquetes para el arranque por red. Ellas son Etherboot y Netboot. Para empezar debes asegurarte que tu tarjeta de red soporte el arranque a través de la red.

Incluido en el paquete Etherboot podemos encontrar el código para generar imágenes ROM tanto de 16 bit como de 32 bit existe soporte para los adaptadores de red mas populares en todo el mundo.

Antes de que podamos compilar alguna de las imagenes debemos editar el archivo Config para adaptar las opciones de compilación a nuestras necesidades, luego compilamos las imagenes y deberemos seleccionar la que corresponda a nuestro adaptador de red.

Es altamente recomendable probar las imágenes antes de intentar quemarlas en una EPROM. Probar una imagen ROM antes de quemarla en el chip es muy fácil, y se hace simulando el código que debería estar en la EPROM con un diskette.

Para crear este disco de arranque, un bloque especial de arranque se proporciona en la distribución. Este pequeño programa de 512 bytes carga en memoria los bloques del disco que lo siguen, y comienza la ejecución. Por lo tanto, para construir este disco únicamente hace falta concatenar el bloque de arranque con el binario de Etherboot que contenga el controlador del adaptador de red que usted posea. Esto pude hacerse automáticamente insertando un diskette en /dev/fd0 y ejecutando desde el directorio donde construistes la imagenes el comando:

        # make <card>.fd0

o manualmente ejecutando:

        # cat floppyload.bin <card>.lzrom > /dev/fd0

en ambos casos ¡card¿ debe ser sustituido por el nombre del controlador de su adaptador de red.

Luego de probar esta imagen puedes utilizando el hardward apropiado quemarla en un chip EPROM y colocarla en tu adaptador de red, el cual debes configurar para que reconozca el arranque a través del EPROM, esto se hace generalmente moviendo un par de jumpers o a través del programa de configuración que provee el fabricante.

Entonación y Aplicaciones del arranque por red

6.1 Entonación del sistema

Observaras que la primera vez que arranques tu máquina cliente a través de la red habran algunas cosas desconfiguradas. La mayoría de las distribuciones Linux están orientadas hacia operaciones con disco y requieren unas pequeñas modificaciones para acondicionar el arranque sin disco. El fallo más común es la necesidad de los ficheros que hay en /usr durante el proceso de arranque, el cual, posteriormente, será importado de un servidor. Dos posibles soluciones son:

1. Facilitar los pocos ficheros requeridos en un pequeño directorio /usr en el sistema raíz de archivos, el cual será ocultado (montado encima) cuando /usr sea importado

2. Modificar las rutas(paths) para buscar los archivos en el sistema raíz. Los archivos a editar se encuentran /tftpboot/xclient (recuerda, este es el directorio raíz del cliente sin disco)

Puedes montar otros directorios del servidor, como /usr (el cual puede ser exportado con permiso de sólo lectura).

Para entonar tu sistema también deberas modificar algunos script en /etc/rc.d, ya que ellos intentaran hacer un chequeo de disco y al no encontrarlo reportaran un error inexistente.

Reconfigura el syslog, generalmente no es importante ni necesario almacenar los logs de la maáquina sin disco, por la tanto la mejor opción es habilitar una consola para que estos sean impresos alli.

Tambien encontraras pequeños errores (muy fáciles de corregir) con algunos enlaces simbolicos.

6.2 Aplicaciones del arranque por red

El arranque a través de la red posee muchas aplicaciones y actualmente ha despertado mucho interes ya que ahora las velocidades de las redes permiten extender el campo de aplicaciones que este paradigma de conexión puede ofrecer.

• Una de las aplicaciones más importantes es el arranque de los nodos esclavos de un clusters beowulf

• Otra de las aplicaciones importante es el arranque de terminales gráficos, ya que estos solo corren las aplicaciones necesarias para conectarse a un servidor potente que le provee todo lo necesario, esto es excelente ya que hace que esas máquinas que habian sido desechadas por obsoletas ahora puedan rescatarse y utilizarce nuevamente

• El arranque de bridge, routers, servidores de impresión, etc. también es una aplicación de este paradigma de conexión

• Muchas personas estan utilizando el arranque por red para realizar labores de mantenimiento de software y respaldos

Como pueden observar son muchas y muy variadas aplicaciones que ofrece el arranque a través de la red.

Bibliografía

[1] COMER, Douglas E.; TCP/IP Principios básicos, protocolos y arquitectura, Prentice Hall, 1.996

[2] HUNT, Craig; TCP/IP Network Administration, O’RAILLY, 1.997 [3] YAP, Ken; Introducción al arranque en red y a Etherboot, LinuxFocus,

Septiembre 1.997

[4] GUTSCHKE, Markus - YAP Ken; Etherboot README, http://www.slug.org.au/etherboot, 14 Septiembre 1.999

[5] RFC’s relacionados con BOOTP, DHCP, TFTP y NFS