Ken Yap Reside en Sydney, Australia. Dio sus primeros pasos con Unix en 1979, y desde hace 4 años ha estado utilizando Linux para edición de texto, acceso a Internet y como soporte para su afición, la electrónica. Cuando no se entretiene con Linux o se encuentra en su trabajo, le gusta viajar, conocer gente, la gastronomía, o simplemente disfrutar de los alrededores mientras pasea. Trabaja como científico investigador en una compañía multinacional. Para contactar con el autor Índice: ¿Qué es el arranque por red? ¿Cómo funciona? El arranque por red en la práctica Usos del arranque por red Para Más Información |
Resumen: Éste es un artículo para usuarios avanzados en el que se explica cómo realizar el arranque remoto de tu ordenador desde un programa almacenado en una memoria no-volatil sin necesidad de acceder al disco duro. Ésta es una técnica ideal para la configuración y mantenimiento de una "granja de linux" (conjunto de linux trabajando de forma coordianda).
Ésta es ya una vieja idea. Básicamente consiste en que un ordenador posee una rutina de arranque en una memoria permanente, por ejemplo en una ROM, que le permite contactar con el servidor y obtener el sistema de ficheros a través de un enlace de red. Un objetivo es evitar el uso de un disco duro para arrancar el ordenador. Existen varias razones por las que hacer esto. Una de ellas es la de reducir los costes de mantenimiento del software en gran cantidad de máquinas. Mediante un arranque por red los ficheros son mantenidos por un servidor central, con la ventaja de poder ser actualizados exclusivamente sobre esta máquina. Otra razón es la de usar ordenadores en lugares donde los discos duros no son suficientemente resistentes, como podría ser en la planta de una factoría en la que éstos pueden ser relativamente frágiles. Finalmente, una nueva posibilidad de un sistema como el anteriormente descrito permitiría conmutar entre diferentes sistemas operativos sin tener que cargar el software de nuevo.
El arranque por red a menudo coexiste con el arranque típico (por disco). Por ejemplo, un sistema podría estar funcionando bajo Windows en disco, y tener también la posibilidad de arrancar Linux por red. Hay varias aplicaciones interesantes de esta técnica; un amigo mio la utiliza para reinstalar Windows por red. Me explico: cuando una instalación de Windows se corrompe, algo que "puede" suceder aunque os parezca imposible, el administrador del sistema tiene la posibilidad de volver a cargar una instalación de windows fresquita usando el arranque remoto de Linux por red y dejando la faena de formatear el disco y copiar la susodicha instalación en disco, a un 'script' automático.
Para poder arrancar por red, el ordenador debe obtener: 1º una identidad, 2º la imagen de un sistema operativo y 3º normalmente, un sistema de ficheros con el que trabajar.
Supongamos un ordenador sin disco (DC-Diskless computer) que tiene una ROM para el arranque por red. Podría ser uno entre varios DCs idénticos. ¿Cómo podemos nosotros distinguir este ordenador del resto? Existe una información que es única para ese ordenador (en realidad para su adaptador de red) y que se trata de su dirección Ethernet. Cualquier adaptador de Ethernet en el mundo posee una dirección Ethernet de 48 bits exclusiva para él, porque a todo fabricante de hardware Ethernet, le han sido asignados bloques de direcciones. Por convención estos bloques de direcciones se representan en forma de dígitos hexadecimales separados por dos puntos en grupos de dos; por ejemplo: 00:60:08:C7:A3:D8.
Los protocolos usados para obtener un dirección IP, dada una dirección Ethernet, son llamados Boot Protocol (BOOTP) y Dynamic Host Configuration Protocol (DHCP). DHCP es una evolución del BOOTP. En nuestro caso, si no se especifica lo contrario, cualquier cosa que se diga del BOOTP, también es aplicable para el DHCP. (En realidad es una mentirijilla decir que BOOTP y DHCP sólo se encargan de traducir direcciones Ethernet. En previsión, los diseñadores de BOOTP y DHCP les dejaron la capacidad de poder trabajar con cualquier tipo de direcciones hardware. Sin embargo, Ethernet es lo que la mayoría de la gente usa.)
Un ejemplo de intercambio de BOOTP sería el siguiente:
DC: Hola, mi dirección hardware es 00:60:08:C7:A3:D8, por favor, dame mi dirección IP.
Servidor BOOPT: (busca la dirección en su base de datos) Tu nombre es aldebaran, tu dirección IP es 192.168.1.100, tu servidor es 192.168.1.1, el fichero del que se supone que debes arrancar es /tftpboot/vmlinux.nb (y alguna información adicional).
Te podrías preguntar cómo fue capaz el DC de encontrar la dirección del servidor de BOOTP en la primera fase. La respuesta es que no lo hizo. La petición de BOOTP se realizó en forma de multidifusión (broadcast) dentro de la red local, de forma que cualquier servidor de BOOTP que pudiera responder a la petición, lo haría.
Después de obtener la dirección IP, el DC debe conseguir la imagen del sistema operativo y lanzarlo a ejecución. En esta fase, se usa otro protocolo de Internet, conocido como Trivial File Transfer Protocol (TFTP). Éste es una versión reducida del famoso FTP: no contempla autentificación, trabaja a través del User Datagram Protocol (UDP) en vez de Transmisión Control Protocol (TCP). Se prefirió usar UDP a TCP por simplicidad. La implementación de UDP en el DC puede ser suficientemente reducida como para caber en una ROM. Ya que UDP es un protocolo orientado a la transmisión por bloques, en oposición a la transmisión por cadenas, la transferencia se realiza bloque a bloque, de la siguiente forma:
y así en adelante, hasta que se transfiere el fichero completo. El funcionamiento consiste básicamente en el reconocimiento de cada bloque, y la pérdida de paquetes se soluciona mediante su retransmisión al cabo de un tiempo establecido. Cuando todos los bloques han sido recibidos, la ROM de arranque de la red pasa el control a la imagen del sistema operativo.
Finalmente, para poner en funcionamiento un sistema operativo, se le debe proporcionar un sistema de ficheros raíz. El protocolo utilizado por Linux y otros sistemas Unix es normalmente el NFS (Network File System), aunque no es el único. En este caso el código no necesita estar grabado en la ROM, sino que forma parte del sistema operativo que acabamos de cargar. Sin embargo, el sistema operativo debe ser capaz de ejecutarse con un sistema de ficheros raíz NFS, en vez de un disco real. Linux posee las variables de configuración necesarias para construir una versión que soporte este modo de funcionamiento.
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. Las dos pueden ser encontradas a través de la página Etherboot. Para empezar debes asegurarte que tu tarjeta de red soporte Etherboot o Netboot. Seguramente deberás encontrar a alguien que te haga el favor de grabar el código en una EPROM (Erasable Programmable Read Only Memory - Memoria de solo lectura, programable y borrable !! ), aunque al principio tu mismo puedes arrancar por red 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 'octetos' (bytes...) carga en memoria los bloques del disco que lo siguen, y comienza la ejecución. Por lo tanto, para construir este disco úncicamente hace falta concatenar el bloque de arranque con el binario de Etherboot que contenga el controlador de la tarjeta de red que cada uno tenga:
un ejemplo podría ser: cat floppyload.bin 3c509.lzrom /dev/fd0
Antes de poner el disco de arranque en red, necesitas configurar tres servicios en Linux: BOOTP (o DHCP), TFTP y NFS. No hace falta que lo hagas todo de una vez, es posible comprobar su correcto funcionamiento uno a uno.
Supongo que ya has instalado el servidor 'bootpd' (boot protocol daemon) de una distribución o bien comopilándolo desde el código fuente. Debes asegurarte que este servidor está esperando peticiones 'bootp' (cliente del protocolo 'bootp'). Hay dos formas de comprobar esto: una es lanzar bootpd como un servicio de red que siempre se encuentra a la escucha una vez el ordenador ha arrancado, la otra consiste en lanzarlo desde 'inetd'. Para la última, /etc/inetd.conf debería contener una línea como esta:
bootps dgram udp wait root /usr/sbin/tcpd bootpd
Si tuviste que modificar /etc/inetd.conf, entonces te hará falta reiniciar 'inetd' enviándole una señal 'HUP' al proceso. A continuación, necesitas dar a 'bootp' una base de datos para mapear direcciones Ethernet a direcciones IP. Esta base de datos se encuentra en /etc/bootptab. Contiene líneas con el siguinete aspecto:
aldebaran.foo.com:ha=006008C7A3D8:ip=192.168.1.100:bf=/tftpboot/vmlinuz.nb
Existe más información que se puede especificar pero, por ahora, la obviaremos.
Ahora arranca el DC con el diskette. Debería detectar la tarjeta Ethernet y lanzar una petición de BOOTP en forma de multidifusión. Si todo va bien, el servidor respondería al DC con la información requerida, aunque al no existir el fichero /tftpboot/vmlinux.nb fallará en cuanto intente cargar el mismo.
Ahora necesitas compilar un núcleo especial, uno que tenga la opción de montar el sistema de ficheros raíz vía NFS activado. También hace falta habilitar en el núcleo la opción de obtener la dirección IP desde la respuesta BOOTP original. Adicionalmente debes compilar el controlador para el adaptador de red en el núcleo en vez de como un módulo aparte. Es posible cargar un 'ramdisk' inicial de forma que la carga del módulo funcione, pero esto es algo que podrías hacer más adelante.
No puedes instalar la 'zImage', 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 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.
En cuanto a TFTP, supondré que lo has instalado de una distribucion o bien que has compilado sus fuentes. Normalmente, se lanza 'tftpd' desde 'inetd' con una línea como ésta, en el fichero /etc/inetd.conf.
tftp dgram udp wait root /usr/sbin/tcpd in.tftpd -s /tftpboot
De nuevo debes reiniciar 'inetd' con una señal 'HUP'. Esta vez, al arrancar debería llegar a cargar la imagen del núcleo y empezar a ejecutarlo. El arranque continuará hasta el punto en que intenta montar un sistema raíz de ficheros. Una vez llegados a este punto, has de configurar y exportar particiones vía NFS, para poder continuar.
Por varias razones, no es una buena idea la de asignar el sistema raíz de ficheros del servidor como sistema raíz de ficheros de los DCs. Una de ellas consiste sencillamente, en que existen diferentes ficheros de configuración, de forma que el DC leería una información errónea. Otra razón es la seguridad. Es peligroso permitir acceso de escritura (y éste es necesario para el sistema raíz de archivos, por varias razones) a tu servidor del raíz. Sin embargo, la buena noticia es que un sistema raíz de archivos para el DC no ocupa demasiado, solo unos 30 MB, además, gran parte de estos pueden ser compartidos entre varios DCs.
Idealmente para construir un sistema raíz de archivos, te hará falta saber qué archivos espera encontrar la distribución del sistema operativo que estés usando. Para arrancar son especialmente delicados los ficheros de dispositivo y los ficheros que se encuentran en /sbin y en /etc. Te puedes ahorrar gran parte de la faena más engorrosa haciendo una copia de un sistema raíz de ficheros ya existente, y modificando sobre ésta algunos de los ficheros que requiera el DC. En la distribución de Etherboot, hay un tutorial y enlaces a un par de 'shell scripts' que se encargan de crear este tipo de sistema raíz de ficheros para un DC, partiendo del sistema raíz de ficheros del servidor. También hay una sección de problemas y soluciones en la documentación de Etherboot, ya que ésta es una de las partes más problemáticas del proceso de configuración.
El núcleo de Linux preparado para los DCs espera encontrar sistema raíz de ficheros en /tftpboot/<IP address of the DC>, por ejemplo: /tftpboot/192.168.1.100 en el caso anterior. Esto puede ser modificado durante la configuración del núcleo, si así se quiere.
Ahora crea o edita /etc/exports en el servidor y añade una línea de la siguiente forma:
/tftpboot/192.168.1.100 aldebaran.foo.com(rw,no_root_squash)
El acceso rw es requerido por varios servicios del sistema. El atributo no_root_squash evita que el sistema NFS mapee el ID de root en otro distinto. De no hacer esto, conseguiriamos cabrear a una amplia gama de 'daemons' y 'loggers'.
Inicia o reinicia los servicios NFS (rpc.portmap y rpc.mountd) y reintenta el arranque sin disco. Si todo va bien deberías ver como el núcleo monta un sistema raíz de ficheros y sigue arrancando hasta presentarte el conocido login de usuario. Seguramente, encontrarás 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 ocultado (montado encima) cuando /usr sea importado, y 2. Modificar las rutas(paths) para buscar los ficheros en el sistema raíz. Los ficheros a editar se encuentran en /tftpboot/192.168.1.100 (recuerda, este es el directorio raíz de DC).
Puedes montar otros directorios del servidor, como /usr (el cual puede ser exportado con permiso de sólo lectura).
Cuando hayas afinado el arranque por red y no te problemas, tienes la posibilidad de poner el código en una EPROM. Un programador de EPROMs viene a costar unos 100 dolares americanos, por lo que no es inversión rentable para un aficionado que lo vaya a usar esporádicamente. Quizás puedas encontrar alguna ganga de segunda mano, aunque en este caso lo jodido (chungo,... difícil) será encontrar software disponible para éste. Un aficionado que destaque en electrónica podría construir uno usando alguno de los diferentes diseños publicados gratuitamente en Internet, pero para la mayoría de los lectores, la mejor solución es hacerle la pelota a cualquier individuo con acceso a un dispositivo de esta clase, quizás alguien en el seminario de electrónica o alguien que trabaje en la industria electrónica.
Una pequeña nota en la tecnología de EPROMs: Los bits de una EPROM son programados mediante la inyección de electrones a una elevada tensión en una puerta flotante de un transistor de efecto de campo, en el que se desea grabar un 0. Los electrones allí atrapados provocan la conducción del transistor, leyéndose en él un 0. Para borrar la EPROM, los electrones atrapados deben recibir la suficiente energía como para poder escapar de la puerta flotante, y esto se consigue exponiendo el chip a radiación ultravioleta, que pasa a través de la ventana de cuarzo. Para evitar un lento borrado, provocado por la luz del sol y de los tubos fluorescentes a lo largo de un periodo de años, se suele tapar esta ventana de cuarzo con una etiqueta opaca.
Existe otra tecnología, llamada EEPROM o 'Electrically Erasable PROM', a veces llamada Flash PROM. En ella los bits son borrados mediante señales eléctricas. Esto evita el uso de un borrador de luz ultravioleta en caso de que la EPROM sea reutilizada, pero requiere circuitería adicional para soportar la fase de borrado. Si a uno se le da bien la electrónica, existe un diseño público de circuito y un controlador software para una tarjeta EEPROM en la distribución Ethernet. La tarjeta se introduce en cualquier zócalo del bus ISA libre de un PC, y arranca una tarjeta de red colocada en cualquier otro zócalo.
Los terminales de X son una de las aplicaciones más directas de esta técnica. La ausencia de un disco en un terminal lo hace más silencioso y contribuye a un entorno de trabajo más agradable. Idealmente la máquina tendría de 16MB de memoria o más y la mejor tarjeta de vídeo que le puedas conseguir. Esta es una forma ideal de aprovechar un 'buen' 486 o un Pentium que haya quedado obsoleto por los avances hardware.
Otras personas han utilizado el arranque por red en de máquinas con poco tiempo de utilización y a las que no vale la pena instalarles disco, e.g. un 'cluster' de máquinas de en una clase docente.
Tu primera parada debería ser la página de Etherboot:
http://www.slug.org.au/etherboot/
Allí encontrarás enlaces a otras fuentes, incluyendo una lista de correo a la que te puedes suscribir y en la que diferentes problemas y soluciones son discutidos.
¡Que lo disfrutéis!
Traducido por Javi Cano
Páginas web mantenidas por Miguel Ángel Sepúlveda LinuxFocus 1998 |