%LinuxWeek Iberoamerica'99
\documentclass[11pt,titlepage,letterpaper]{book}
\usepackage[spanish,english]{babel}
\usepackage{epsfig}
\pagestyle{myheadings}

\begin{document}
\selectlanguage{spanish}
\thispagestyle{empty}

%%%%%% Inicio de Portada
\begin{flushright}                            
\vspace*{\stretch{1}}
{\bf \Huge \vspace{.1cm} Linux sin disco\\
  (Diskless)\\} \vspace{.1cm}

\rule{\linewidth}{2mm}

\vspace*{\stretch{1}}
\vspace{1cm}
por {\bf Xavier Eduardo M\'armol}. \\
Grupo de Usuarios Linux de Venezuela, {\it VELUG} \\
Tutorial presentado en LinuxWeek Iberoam\'erica'99 \\
Septiembre 1.999 - Caracas, VENEZUELA
\end{flushright}
\vspace*{\stretch{4}}
%%%%%% Fin de Portada
 
\cleardoublepage
\thispagestyle{empty}
\thispagestyle{empty}
\tableofcontents
\mainmatter

\chapter*{Resumen}

La versatilidad del sistema operativo {\bf Linux} lo hacen la elecci\'on ideal para 
crear ``granjas'' de computadores sin disco trabajando coordinadamente. En este 
tutorial estudiaremos los aspectos fundamentales del arranque a trav\'es de la 
red desde un programa almacenado en una memoria no-vol\'atil y la puesta a 
punto de equipos que no poseen unidades de almacenamiento. El tutorial 
estar\'a dividido en las siguientes etapas:

\begin{itemize}
\item{Fundamentos Te\'oricos}
\item{Configuraci\'on del servidor}
\item{Preparaci\'on del N\'ucleo}
\item{Como crear un BootROM}
\item{El sistema de archivos ra\'{\i}z para los clientes}
\item{Entonaci\'on del sistema}
\item{Aplicaciones del arranque por red y equipos sin disco}
\end{itemize}

Siguiendo este esquema mostraremos paso a paso los detalles de la 
configuraci\'on del servidor, los clientes ``diskless'' y la creaci\'on de un 
BootROM; adem\'as de hacer un \'enfasis especial en los usos, ventajas y 
desventajas de este paradigma de conexi\'on.

\markboth{Linux sin disco (Diskless)}{Arranque y Autoconfiguraci\'on}

\setcounter{chapter}{2}
\setcounter{section}{0}
\chapter*{Fundamentos Te\'oricos}

\section{Arranque y Autoconfiguraci\'on}

Para comenzar, mostraremos c\'omo 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\'on IP antes de que pueda enviar o recibir datagramas.
Adem\'as, una computadora requiere informaci\'on adicional como la direcci\'on 
de un ruteador, la mascara de red en uso y la direcci\'on de un servidor de 
nombres. Nosotros estudiaremos dos protocolos del proceso de arranque muy 
relacionados que permiten a un anfitri\'on determinar su direcci\'on 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\'{\i}a parecer imposible que una 
computadora pudiese utilizar el UDP para localizar la direcci\'on IP que 
utiliza \'esta cuando se comunica. Examinaremos los protocolos que nos 
ayudar\'an a entender c\'omo puede una computadora utilizar una direcci\'on IP 
especial y la flexibilidad del mecanismo de transporte UDP/IP. Tambi\'en veremos 
de qu\'e manera asigna un servidor una direcci\'on IP a una computadora en 
forma autom\'atica. Esta asignaci\'on 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\'atil puede moverse de una localidad hacia otra en una compa~n\'{\i}a).

\subsection{Utilizaci\'on de IP para determinar una direcci\'on IP}

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

Un programa de aplicaci\'on puede utilizar la direcci\'on IP de difusi\'on 
l\'{\i}mite para
obligar al IP a difundir un datagrama en la red local, antes de que el IP haya 
descubierto la direcci\'on IP de la red local o la direcci\'on IP de la 
m\'aquina.

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

\subsection{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\'olo proporciona al cliente informaci\'on 
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\'on de configuraci\'on y almacenamiento. Un servidor BOOTP no necesita 
correr en la misma m\'aquina que almacena las im\'agenes de memoria. De hecho, 
el servidor BOOTP opera desde una simple base de datos que s\'olo conoce los 
nombres de las im\'agenes de memoria.

Mantener la configuraci\'on separada del almacenamiento es importante pues 
permit\'e al administrador configurar conjuntos de m\'aquinas para que \'estas 
act\'uen en forma id\'entica 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, 
\'estas seleccionan correr en UNIX o en un sistema operativo local. Debido a 
que el conjunto de estaciones de trabajo incluye m\'ultiples arquitecturas de 
hardware, no operar\'a en todas las m\'aquinas 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\'erico como "unix", lo cual significa "quiero 
arrancar el sistema operativo UNIX para esta m\'aquina". El servidor BOOTP 
consulta su base de datos de configuraci\'on para transformar el nombre 
gen\'erico en un nombre de archivo espec\'{\i}fico que contiene imagen de memoria 
UNIX apropiada para el hardware del cliente y devuelve el nombre espec\'{\i}fico 
(es decir, completamente definido) en su r\'eplica. Por supuesto, la base de 
datos de configuraci\'on también permite un arranque completamente autom\'atico 
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\'aquina. La ventaja del m\'etodo 
autom\'atico es que permite al usuario especificar nombres gen\'ericos que 
trabajen en cualquier m\'aquina. No es necesario recordar nombres de archivos 
espec\'{\i}ficos o arquitecturas de hardware.

\subsection{La necesidad de una configuraci\'on din\'amica}

Como RARP, BOOTP fue dise~nado para un ambiente relativamente est\'atico en el 
que cada anfitri\'on tiene una conexi\'on de red permanente. Un administrador 
crea un archivo de configuraci\'on BOOTP que especifica un conjunto de 
par\'ametros BOOTP para cada anfitri\'on. El archivo no cambia con frecuencia 
pues la configuraci\'on generalmente se mantiene estable. Por lo com\'un, una 
configuraci\'on no registra cambios durante semanas.

Con la llegada de redes inal\'ambricas y computadoras port\'atiles como las 
laptop y las notebook, se ha vuelto posible transportar a las computadoras de 
una localidad a otra r\'apida y f\'acilmente. BOOTP no se \'adapta a esta 
situaci\'on pues la informaci\'on de configuraci\'on no puede cambiar 
r\'apidamente. As\'{\i} pues, s\'olo proporciona una transformaci\'on est\'atica 
desde un identificador de anfitri\'on hacia par\'ametros para el anfitri\'on. 
Adem\'as, un administrador debe introducir un conjunto de par\'ametros para cada
anfitri\'on y luego almacenar la informaci\'on en un archivo de configuraci\'on 
de servidor BOOTP -BOOTP no incluye una forma para asignar din\'amicamente 
valores a m\'aquinas individuales. En particular, un administrador debe asignar 
cada anfitri\'on a una direcci\'on IP y configurar el servidor para entender la 
transformaci\'on del identificador de anfitri\'on a la dirección IP.
Los par\'ametros de asignaci\'on est\'atica trabajan bien si las computadoras 
se mantienen en localidades fijas y el administrador tiene suficientes 
direcciones IP para asignar a cada computadora una direcci\'on IP \'unica. Sin 
embargo, en los casos en los que las computadoras se muevan con frecuencia o que
el n\'umero de computadoras f\'{\i}sicas exceda el de direcciones de anfitri\'on IP 
disponibles, la asignaci\'on est\'atica generar\'a sobrecargas excesivas. Por 
lo tanto est\'a claro que un sistema es inadecuado si requiere que el 
administrador cambie el archivo de configuraci\'on del servidor antes de que se 
a~nada una nueva computadora a la red y comience a comunicarse; se necesita 
pues un mecanismo automatizado. 

\subsection{Configuraci\'on din\'amica de anfitri\'on}

Para manejar la asignaci\'on de direcciones de manera autom\'atica, el IETF ha 
dise~nado un nuevo protocolo. Conocido como Dynamic Host Configuration Protocol
(Protocolo de configuraci\'on din\'amica de anfitri\'on o DHCP), el nuevo 
protocolo extiende BOOTP ya que el DHCP permite que una computadora posea una 
direcci\'on IP en forma r\'apida y din\'amica. Para utilizar el mecanismo de 
asignaci\'on de direcciones din\'amico 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\'on. 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\'on de 
direcciones; un administrador selecciona c\'omo responder\'a el DHCP a cada red 
o a cada anfitri\'on. Como BOOTP, el DHCP permite la configuraci\'on manual, 
mediante la cual un administrador puede configurar una direcci\'on espec\'{\i}fica 
para una computadora espec\'{\i}fica. El DHCP también permite la configuraci\'on 
autom\'atica, por medio de la cual el administrador permite a un servidor DHCP 
asignar una direcci\'on permanente cuando una computadora es conectada por 
primera vez a la red. Por \'ultimo, DHCP permite una configuraci\'on din\'amica 
completa, con la cual el servidor ``presta'' una direcci\'on para una 
computadora por tiempo limitado. 
Como en BOOTP, el DHCP utiliza la identidad del cliente para decidir c\'omo 
proceder. Cuando un cliente contacta un servidor DHCP, env\'{\i}a un identificador, 
por lo general, la direcci\'on 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\'omo asignar el cliente y la direcci\'on IP. As\'{\i}, 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\'{\i}ficas de manera est\'atica (como BOOTP), mientras permite 
a otras computadoras obtener din\'amicamente direcciones de manera permanente o 
temporal.

\subsection{Asignaci\'on din\'amica de direcciones IP}

La asignaci\'on din\'amica de direcciones es el m\'as significativo y novedoso 
aspecto del DHCP. A diferencia de la asignaci\'on de direcciones est\'atica, 
utilizada en BOOTP, la asignaci\'on de direcciones din\'amica no es una 
transformaci\'on 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\'on IP y 
comience la comunicaci\'on. As\'{\i}, el DHCP permite dise~nar 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\'on IP y entonces 
configura su software TCP/IP a fin de utilizar la direcci\'on. Por supuesto, 
la autoconfiguraci\'on est\'a sujeta a restricciones administrativas -es el 
administrador el que decide qu\'e servidor DHCP puede realizar la 
autoconfiguraci\'on. En resumen:

Como el DHCP permite a un anfitri\'on obtener todos los par\'ametros necesarios 
para la comunicaci\'on, sin la intervenci\'on manual, tambi\'en permite la 
autoconfiguraci\'on. \'esta se encuentra sujeta, por supuesto, a restricciones 
administrativas.

Para hacer posible la autoconfiguraci\'on, 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\'on intercambiando 
mensajes con un servidor. En el intercambio, el servidor proporciona una 
direcci\'on para el cliente y el cliente verifica que la direcci\'on sea 
aceptable. Una vez que el cliente ha aceptado una direcci\'on, puede comenzar 
a utilizar la direcci\'on para comunicarse.
A diferencia de la asignaci\'on de direcciones est\'atica, que asigna 
permanentemente cada direcci\'on IP a un anfitri\'on espec\'{\i}fico, la 
asignaci\'on de direcciones din\'amica es temporal. Decimos que un servidor 
DHCP arrienda una direcci\'on a un cliente por un per\'{\i}odo de tiempo finito. 
El servidor especifica el per\'{\i}odo de arrendamiento cuando asigna la 
direcci\'on. Durante el per\'{\i}odo de arrendamiento, el servidor no arrendar\'a 
la misma direcci\'on a ning\'un otro cliente. Al final del per\'{\i}odo de 
arrendamiento, sin embargo, el cliente debe renovar el arrendamiento o dejar 
de usar la direcci\'on.
\textquestiondown Cu\'anto debe durar un arrendamiento DHCP? El tiempo \'optimo de arrendamiento
depende en particular de la red y de las necesidades de un anfitri\'on. 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\'{\i}odo de arrendamiento (por ejemplo, una 
hora): En contraste, la red de una compa~n\'{\i}a podr\'{\i}a utilizar un per\'{\i}odo de 
arrendamiento de un d\'{\i}a o de una semana. Para adaptarse a todos los posibles 
ambientes, el DHCP no especifica un per\'{\i}odo de arrendamiento fijo y constante.
De hecho, el protocolo permite que un cliente solicite un per\'{\i}odo de 
arrendamiento espec\'{\i}fico y permite a un servidor informar al cliente que el 
per\'{\i}odo de arrendamiento est\'a garantizado. As\'{\i}, un administrador puede 
decidir durante cu\'anto tiempo podr\'a asignar cada servidor una direcci\'on 
a un cliente. En el caso extremo, el DHCP reserva un valor infinito para 
permitir un arrendamiento por un per\'{\i}odo de tiempo indeterminadamente largo, 
como la asignaci\'on de direcciones permanente utilizada en BOOTP.

\subsection{Resumen}

El protocolo de arranque BOOTP proporciona una alternativa a RARP para 
computadoras que necesitan determinar su direcci\'on IP. BOOTP es m\'as general 
que RARP pues utiliza el UDP, lo que hace posible extender el proceso de 
arranque a trav\'es de un ruteador. BOOTP tambi\'en permite a una m\'aquina 
determinar una direcci\'on de ruteador, una direcci\'on (archivo) de servidor y 
el nombre de un programa que la computadora deber\'a correr. Finalmente, BOOTP 
permite a los administradores establecer la configuraci\'on de una base de 
datos que transforma un nombre gen\'erico como "unix" en un nombre de archivo 
completamente caracterizado que contiene la imagen de memoria apropiada para 
el hardware del cliente.
BOOTP est\'a dise~nado para ser lo suficientemente peque~no y simple como para 
residir en un arranque localizado en ROM. El cliente utiliza la direcci\'on 
de difusi\'on limitada para comunicarse con el servidor y tiene la 
responsabilidad de retransmitir solicitudes si el servidor no responde. La 
retransmisi\'on emplea un procedimiento de retroceso exponencial similar a 
Ethernet para evitar el congestionamiento.
Dise~nado como sucesor de BOOTP, el Dynamic Host Configuration Protocol (DHCP) 
ampl\'{\i}a BOOTP de varias formas. Lo m\'as importante es que el DHCP permite 
que un servidor localice direcciones IP autom\'atica o din\'amicamente. La 
asignaci\'on din\'amica es necesaria para ambientes como las redes 
inal\'ambricas cuyas computadoras pueden conectarse y desconectarse 
r\'apidamente. 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\'on IP anunciada.
Cuando un cliente obtiene una direcci\'on IP, arranca 3 temporizadores. Luego 
de que el primer temporizador expira, el cliente debe intentar la renovaci\'on 
de su arrendamiento. Si un segundo temporizador expira antes de que se complete 
la renovaci\'on, el cliente debe tratar de reasignar su direcci\'on a cualquier 
servidor. Si el \'ultimo temporizador expira antes de que se haya obtenido un 
arrendamiento, el cliente deja de utilizar la direcci\'on IP y regresa al 
estado inicial para adquirir una nueva direcci\'on.

\section{TFTP}

Aunque el FTP es el protocolo de transferencia de archivos m\'as generalizado 
en el conjunto TCP/IP, tambi\'en es el m\'as complejo y dif\'{\i}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\'{\i}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\'omico y poco sofisticado. Se conoce como 
Trivial File Transfer Protocol (TFTP, protocolo trivial de transferencia de 
archivos) y se dise~n\'o 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\'on. Como es 
m\'as restrictivo el software TFTP resulta mucho m\'as peque~no que el FTP.
El tama~no reducido es importante para muchas aplicaciones. Por ejemplo, los 
fabricantes de dispositivos sin disco pueden codificar al TFTP en la memoria 
de s\'olo lectura (ROM) y usarlo para obtener una imagen de memoria inicial 
cuando se encienda la m\'aquina. Al programa, en ROM, se le llama arranque del 
sistema. La ventaja de utilizar el TFTP es que permite al c\'odigo de arranque 
emplear los mismos protocolos TCP subyacentes que el sistema operativo utiliza 
una vez que empieza la ejecuci\'on. De este modo es posible para una computadora
arrancar desde un servidor en otra red f\'{\i}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\'{\i}mites y retransmisi\'on para asegurar que los 
datos lleguen. El lado que env\'{\i}a transmite un archivo de trama~no fijo (512 
octetos) bloquea y espera un acuse de recibo para cada bloque antes de enviar 
el siguiente. El receptor env\'{\i}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\'on entre cliente y servidor, 
el paquete especifica el nombre de archivo y si el archivo se leer\'a 
(transferido al cliente) o se escribir\'a (transferido al servidor). Los 
bloques del archivo est\'an numerados en forma consecutiva comenzando con 1. 
Cada paquete de datos contiene un encabezado que especifica el n\'umero de 
bloque que se transporta. Y cada acuse de recibo contiene el n\'umero de bloque 
del que se est\'a recibiendo el acuse de recibo. Un bloque de menos de 512 
octetos se~nala 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\'on de escritura o de lectura, el servidor 
utiliza la direcci\'on IP y el n\'umero 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\'es de un tiempo l\'{\i}mite, pero la mayor parte de los dem\'as 
errores simplemente causa que la interacci\'on se acabe.
La retransmisi\'on TFTP resulta inusual porque es sim\'etrica. Cada lado 
implanta un tiempo l\'{\i}mite y una retransmisi\'on. Si el lado que env\'{\i}a 
llega a su tiempo l\'{\i}mite, vuelve a transmitir el \'ultimo bloque de datos. 
Si el lado responsable de los acuses de recibo llega a su tiempo l\'{\i}mite 
vuelve a transmitir el \'ultimo acuse de recibo. Tener a ambas partes 
participando en la transmisi\'on ayuda a asegurar que no falle la transferencia 
despu\'es de que se haya perdido un paquete.
Aunque que la retransmisi\'on sim\'etrica 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\'un momento y cada uno dispara una transmisi\'on 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\'en 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\'{\i}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 electrónico. Un cliente puede especificar al 
servidor que enviar\'a un archivo al que se le considerar\'a como correo con 
el campo FILENAME, tomado como nombre para un buz\'on en el que el servidor 
deber\'a entregar el mensaje.

\section{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\'{\i}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 aplicación arbitrario y valerse de 
archivos arbitrarios de entrada o salida. Los nombres de los archivos per se 
no muestran si son locales o remotos.

\subsection{Implantaci\'on NFS}

En la figura se ilustra c\'omo es que el NFS est\'a embebido en un sistema 
operativo. Cuando se ejecuta un programa de aplicaci\'on, 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\'on y la 
transmite de manera autom\'atica al software de sistema de archivo local o al 
cliente NFS, dependiendo de si el archivo est\'a en el disco local o en una 
m\'aquina remota. Cuando recibe una petici\'on, el software del cliente utiliza 
el protocolo NFS para ponerse en contacto con el servidor apropiado en una 
m\'aquina remota y ejecutar la operaci\'on requerida. Cuando contesta el 
servidor remoto, el software del cliente devuelve los resultados al programa 
de aplicaci\'on.

\setcounter{chapter}{3}
\setcounter{section}{0}
\chapter*{Configuraci\'on del servidor}

Una vez que estudiamos brevemente los conceptos fundamentales del arranque a
trav\'es 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\'a en capacidad de instalar, configurar y utilizar una
``granja'' de computadores {\bf Linux}.

\section{Configurando el demonio {\em bootpd}} 
 
Comenzaremos configurando el demonio {\em bootpd} en nuestro servidor 
{\bf Linux}. Este demonio generalmente viene como parte de casi todas las 
distribuciones modernas de {\bf Linux}, en caso que necesite instalarlo, debe obtener
el paquete \verb|bootpd-2.4.tar.gz| desde su servidor de archivos favorito, 
compilarlo e instalarlo\footnote{Siga las instrucciones que encontrar\'a en 
el archivo README que viene con el paquete}.

Una vez instalado el demonio se puede demonio se puede ejecutar directamente
utilizando el comando:
\begin{verbatim}
       # bootpd -s
\end{verbatim}

o a trav\'es de inetd. En ese caso ser\'a necesario:

\begin{enumerate}
\item{Editar \verb|/etc/inetd.conf|, y asegurarse de que existe y est\'a
descomentada la siguiente l\'{\i}nea: 
\begin{verbatim}
bootps  dgram  udp  wait  root  /usr/sbin/tcpd   bootpd
\end{verbatim}
}
\item{Asegurese que en el archivo \verb|/etc/services| existen y est\'an 
decomentadas las l\'{\i}neas:
\begin{verbatim}
bootps          67/tcp          # BOOTP server
bootps          67/udp          # BOOTP server
\end{verbatim}
}
\item{Reiniciar \verb|inetd| usando el comando:
\begin{verbatim}
       # killall -HUP inetd
\end{verbatim}
}
\end{enumerate}

Ahora deberemos configurar el {\em bootpd} a trav\'es de su archivo de 
configuraci\'on llamado \verb|bootptab| el cual usualmente se encuentra en
\verb|/etc|. Debe ser modificado insertando la direcci\'on IP de su ruteador, 
servidor de nombres y los datos correspondientes a sus m\'aquinas sin disco. 

La informaci\'on 
esencial que usted debe colocar en su \verb|bootptab| es:

\begin{enumerate}
\item{El FQDN\footnote{Nombre de dominio completamente calificado, por sus 
siglas en Ingles} de la m\'aquina}
\item{La direcci\'on f\'{\i}sica de su adaptador de red, esta generalmente se
obtiene de una calcomania en la tarjeta, del programa de configuraci\'on o en 
\'ultima instancia activando la opci\'on debug del demonio bootpd para mirar los
paquetes que envia la imagen ROM cuando trata de arrancar}
\item{El nombre que tendr'a la imagen marcada del n\'ucleo y el directorio que la 
contendr\'a}
\item{El IP que usted espera asignarle a cliente sin disco}
\item{La direcci\'on IP de algunos servidores como DNS, Ruteador, etc.}
\end{enumerate} 

Aqu\'{\i} le presentamos un ejemplo de un archivo \verb|/etc/bootptab| para 
el servidor {\em bootpd}; este ejemplo probablemente funcione en otros 
sabores de UNIX:

\begin{verbatim}
# 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:
\end{verbatim}

La primera entrada define una plantilla de valores que puede ser usada por 
todas las configuraciones especificas ``incluyendo'' el campo 
\verb|tc=.default|. En la entrada correspondiente a la configuraci\'on 
espec\'{\i}fica el primer campo es el FQDN de la m\'aquina, el campo \verb|ha|
especifica la direcci\'on Ethernet de su NIC\footnote{Adaptador de red, por sus 
siglas en Ingles}; el campo \verb|ip| es auto explicativo; el campo \verb|bf|
especifica el nombre de la imagen marcada del n\'ucleo. Para una explicaci\'on
mas detallada consulte la p\'agina del manual (\verb|man bootptab|).

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

\section{Configurando el demonio {\em dhcpd}}

Como una alternativa a {\em bootp} podemos configurar un servidor DHCP que posee
la ventaja de automatizar el manejo de los IP's, usted debe asegurarse que el
paquete \verb|dhcp-2.0.tar.gz| este instalado. Es de hacer notar que el n\'ucleo
seguira enviando una petici\'on {\em bootp} para buscar la direcci\'on IP para
montar el sistema de archivos ra\'{\i}z a trav\'es de NFS. De seguro usted 
necesitara investigar sobre las opciones del \verb|mknbi-linux| para configurar
la imagen marcada del n\'ucleo para que acepte una respuesta DHCP.

El archivo de configuraci\'on \verb|/etc/dhcpd.conf| es equivalente al 
\verb|bootptab|:

\begin{verbatim}
# 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";
        }
}
\end{verbatim}

Usted no tiene que usar una direcci\'on fija por supuesto, pero si elije usar
una direcci\'on variable usted tendr\'a que manejar con cuidado el NFS y prestar
especial atenci\'on al contenido de \verb|/etc/exports|.

Si desea m\'as informaci\'on sobre el DHCP visite \linebreak
\verb|http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html|.

Si usted est\'a en una red local que no posee una conexi\'on directa a Internet,
usted puede utilizar una direcci\'on 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\'on IP.

\section{Configurando el demonio {\em tftpd}}

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

\noindent tftp simple:

\begin{quote}
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\'{\i}a tftp). 
\end{quote}

\noindent tftp seguro:

\begin{quote}
El servidor tftp utiliza un llamada de sistema \verb|chroot.2| para cambiar a su
propio directorio ra\'{\i}z. Cualquier cosa que est\'e fuera del nuevo
directorio ra\'{\i}z es completamente inaccesible, ya que el
directorio que sufre el \verb|chroot| se transforma en el nuevo directorio 
ra\'{\i}z; el campo \verb|hd| del archivo \verb|bootptab| debe reflejar esta
nueva situaci\'on.

Por ejemplo: cuando se utiliza tftp simple, el campo \verb|hd| contiene el path 
o camino completo del directorio de arranque: \verb|/tftpboot|.
Cuando se utiliza tftp seguro con /tftpboot como directorio ra\'{\i}z,
entonces /tftpboot pasa a ser / y el campo hd debe ser /. 
\end{quote}

Si usted est\'a arrancando muchos clientes Diskless probablemente se vera 
limitado por las restricciones del \verb|inetd| ya que este tipicamente limita
el numero de demonios que pueden ser levantados. Si muchos clientes solicitan
el servicio de tftp con per\'{\i}odos cortos de diferencia, \verb|inetd| 
apagar\'a el servicio. Si usted realiza esta configuraci\'on donde existen 
muchos clientes deber\'a correr un servidor tffp dedicado, que {\bf no} sea 
ejecutado desde el \verb|inetd|. Usted puede conseguir un servidor tftp
independiente en: \verb|ftp://nilo.on.openprojects.net/pub/nilo/snapshots/|

\section{Creando el sistema de archivos ra\'{\i}z para el cliente}

Ahora usted necesita crear un directorio y crear una sistema de archivos 
ra\'{\i}z para el cliente sin disco, este directorio debe contener un sistema
de archivos ra\'{\i}z completo para que el sistema operativo pueda arrancar
exitosamente. Por tal raz\'on es necesario que dicho sistema contenga los 
directorios \verb|/dev, /proc, /etc, /sbin, /bin, /tmp, /var|. Los detalles
varian seg\'un la distribuci\'on de {\bf Linux} que este usando. Usted puede
copiar estos archivos de un sistema ya instalado y luego modificar ciertos
archivos claves. 

Peligro: {\bf Nunca} trate de compartir el sistema de archivos
ra\'{\i}z entre en servidor y el cliente exportandolo directamente o a trav\'es
de un enlace ya que esto podr\'{\i}a hacerle peder datos importantes, adem\'as 
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 \verb|no_root_squash|; de
no hacer esto conseguiriamos que una amplia gama de demonios y loggers 
no funcionaran correctamente. 

\setcounter{chapter}{4}
\setcounter{section}{0}
\chapter*{Preparaci\'on del n\'ucleo de {\bf Linux}}

\section{Compilando el n\'ucleo}

Usted ciertamente necesita compilar un nuevo n\'ucleo de {\bf Linux} ya que
usted necesita soporte BOOTP, NFS-root, etc. para configurar el n\'ucleo vaya al
directorio donde guarda las funtes y ejecute:
\begin{verbatim}
	# make config
\end{verbatim}
responda todas las preguntas de acuerdo a sus requerimientos e incluya las
siguientes opciones:
\begin{verbatim}
        * 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
\end{verbatim}
por \'ultimo, no olvide compilar el soporte para la interfaz de red dentro del 
n\'ucleo y {\bf no} como m\'odulo. 

Ahora debe generar la imagen del n\'ucleo con los comandos:
\begin{verbatim}
	# make dep; make clean; make bzImage
\end{verbatim}
de esta manera ya tienes una imagen del kernel de {\bf Linux} configurada
para el arranque por red, esta imagen quedo almacenada en el directorio
\verb|/usr/src/linux/arch/i386/boot| con el nombre \verb|bzImage|.

\section{Haciendo una ``imagen marcada'' del n\'ucleo}

No puedes instalar la \verb|bzImage|, que conseguiste de la compilaci\'on del 
n\'ucleo, directamente. Debe ser convertida en una ``imagen marcada''
\'Esta es una imagen normal del n\'ucleo con una cabecera especial que le
dice al cargador de arranque en red d\'onde han de almacenarse los bytes en 
memoria y en qu\'e direcci\'on empieza el programa. Para crear
esta imagen ``marcada'' se usa un programa llamado \verb|mknbi-linux|, que puede
ser encontrado en la distribuci\'on de Etherboot. Despu\'es de crear la imagen, 
ponla en el directorio \verb|/tftpboot| con el nombre especificado en
\verb|/etc/bootptab|. Aseg\'urate de darle permiso de lectura para todo el 
mundo a este archivo porque el servidor ``tftpd'' no tiene ning\'un
privilegio especial.

Para marcar la imagen nosotros ejecutamos el siguente comendo:
\begin{verbatim}
        # mknbi-linux -d /tftpboot/xclient bzImage \
                      /tftpboot/vmlinuz.diskless
\end{verbatim}
este comando ``marca'' la imagen y le indica que el directorio a montar por NFS
como ra\'{\i}z es \verb|/tftpboot/xclient|.

La distribuci\'on de Etherboot la puedes encontrar en \linebreak
\verb|http://www.slug.org.au/etherboot|.

\setcounter{chapter}{5}
\setcounter{section}{0}
\chapter*{C\'omo crear una imagen ROM}

Adem\'as 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\'es de la red. 

Incluido en el paquete Etherboot podemos encontrar el c\'odigo para generar 
im\'agenes 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
\verb|Config| para adaptar las opciones de compilaci\'on a nuestras necesidades,
luego compilamos las imagenes y deberemos seleccionar la que corresponda a 
nuestro adaptador de red.

Es altamente recomendable probar las im\'agenes antes de intentar quemarlas en 
una EPROM. Probar una imagen ROM antes de quemarla en el chip es muy f\'acil,
y se hace simulando el c\'odigo que deber\'{\i}a estar en la EPROM con un 
diskette.

Para crear este disco de arranque, un bloque especial de arranque se proporciona
en la distribuci\'on. Este peque\~no programa de 512 bytes carga en memoria
los bloques del disco que lo siguen, y comienza la ejecuci\'on.
Por lo tanto, para construir este disco \'unicamente 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\'aticamente 
insertando un diskette en \verb|/dev/fd0| y ejecutando desde el directorio donde
construistes la imagenes el comando:
\begin{verbatim}
        # make <card>.fd0 
\end{verbatim}
o manualmente ejecutando:
\begin{verbatim}
        # cat floppyload.bin <card>.lzrom > /dev/fd0 
\end{verbatim}
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\'es del EPROM, esto se hace generalmente
moviendo un par de jumpers o a trav\'es del programa de configuraci\'on que
provee el fabricante.

\setcounter{chapter}{6}
\setcounter{section}{0}
\chapter*{Entonaci\'on y Aplicaciones del arranque por red}

\section{Entonaci\'on del sistema}
Observaras que la primera vez que arranques tu m\'aquina cliente a trav\'es de
la red habran algunas cosas desconfiguradas. La mayor\'{\i}a de las
distribuciones Linux est\'an orientadas hacia operaciones con disco y requieren 
unas peque\~nas modificaciones para acondicionar el arranque sin disco.
El fallo m\'as com\'un es la necesidad de los ficheros que hay en \verb|/usr|
durante el proceso de arranque, el cual, posteriormente, ser\'a importado de 
un servidor. Dos posibles soluciones son:
\begin{enumerate}
\item{Facilitar los pocos ficheros requeridos en un peque\~no directorio 
\verb|/usr| en el sistema ra\'{\i}z de archivos, el cual ser\'a
ocultado (montado encima) cuando \verb|/usr| sea importado}
\item{Modificar las rutas(paths) para buscar los archivos en el sistema 
ra\'{\i}z. Los archivos a editar se encuentran /tftpboot/xclient
(recuerda, este es el directorio ra\'{\i}z del cliente sin disco)}
\end{enumerate}

Puedes montar otros directorios del servidor, como \verb|/usr| (el cual puede 
ser exportado con permiso de s\'olo lectura).

Para entonar tu sistema tambi\'en 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 \verb|syslog|, generalmente no es importante ni necesario 
almacenar los logs de la ma\'aquina sin disco, por la tanto la mejor opci\'on 
es habilitar una consola para que estos sean impresos alli.

Tambien encontraras peque\~nos errores (muy f\'aciles de corregir) con algunos 
enlaces simbolicos.

\section{Aplicaciones del arranque por red}

El arranque a trav\'es 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\'on puede ofrecer.

\begin{itemize}
\item{Una de las aplicaciones m\'as importantes es el arranque de los nodos esclavos de un clusters beowulf}
\item{Otra de las aplicaciones importante es el arranque de terminales gr\'aficos, 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\'aquinas que habian sido desechadas por obsoletas ahora 
puedan rescatarse y utilizarce nuevamente}
\item{El arranque de {\em bridge, routers, servidores de impresi\'on}, etc. tambi\'en
es una aplicaci\'on de este paradigma de conexi\'on}
\item{Muchas personas estan utilizando el arranque por red para realizar labores de
mantenimiento de software y respaldos}
\end{itemize}

Como pueden observar son muchas y muy variadas aplicaciones que ofrece el 
arranque a trav\'es de la red.

\begin{thebibliography}{99}
\bibitem{COMER} COMER, Douglas E.; {\it TCP/IP Principios b\'asicos, protocolos y arquitectura}, Prentice Hall, 1.996
\bibitem{HUNT} HUNT, Craig; {\it TCP/IP Network Administration}, O'RAILLY, 1.997
\bibitem{YAP} YAP, Ken; {\it Introducci\'on al arranque en red y a Etherboot}, LinuxFocus, Septiembre 1.997
\bibitem{GUTSCHKE} GUTSCHKE, Markus - YAP Ken; {\it Etherboot README}, http://www.slug.org.au/etherboot, 14 Septiembre 1.999
\bibitem{RFC} RFC's relacionados con BOOTP, DHCP, TFTP y NFS
\end{thebibliography}

\end{document}
