\newpage
%===========================================================================
%       x.20 > Nodos sin disco
%===========================================================================
\pagestyle{empty}
\begin{latexonly}
\ifpdf
 \begin{figure}[htbp]
%       \includegraphics[bb = -200 220 0 0, scale=1]{./TuXes/tux-laptop.png}
 \end{figure}
 \vspace{5in}
\else
 \begin{figure}
%       \scalebox{.9}[.9]{\includegraphics[-300,750][0,0]{./TuXes/tux-laptop}}
 \end{figure}
\fi
\hfill\line(1,0){400}
\end{latexonly}
\topmargin 1in
\section{Nodos sin discos}
\begin{latexonly}
\line(1,0){400}
\newpage
\end{latexonly}
\topmargin 0in
\pagestyle{fancy}
%========================cita===============================================
\begin{latexonly}
\hspace{1in}\textcolor{blue_omosix}{{\em Never trust a computer you can't throw out a window.}}

\hspace{4in}\textcolor{blue_omosix}{{\em Steve Wozniak}}
\vspace{0.5in}

\end{latexonly}
%===========================================================================
Previamente se dar\'a un repaso para tener las nociones
b\'asicas sobre el ensamblaje del hardware necesario para la construcci\'on de
este tipo de computadoras minimalistas. De esta manera si los nodos ya
son funcionales\footnote{Entendi\'endose que tras el correcto ensamblaje podemos acceder a la BIOS de la
  placa madre.}, podr\'as pasarte los primeros apartados. A continuaci\'on se
  exponen esquematicamente los di\'alogos de comunicaci\'on entre nuestras
  computadoras, a fin de hacer comprender mejor el funcionamiento y poder
  detectar disfunciones con mayor precisi\'on en el caso de no obtener una
  r\'apida puesta en marcha del sistema.

%Si has llegado aqu\'\i\ movido por la curiosidad de no saber a ciencia cierta
%c\'omo puede arrancarse una computadora sin disponer \'esta de su disco duro,
%o simplemente quieres saber si te interesa este m\'etodo, echa un vistazo al
%apartado sobre ventajas e inconvenientes.

%\vspace{.2in}
%N. al LECTOR: no te impacientes en los primeros apartados puesto que se ha
%seguido una profundizaci\'on progresiva del tema, as\'\i\ que es normal que
%desconozcas algunos de los protocolos citados (o todos). No obstante, ir\'as
%aprendiendo el uso de todo lo necesario a medida que avances en la
%lectura. Recuerda tambi\'en que existe una compilaci\'on de acr\'onimos al
%final de este documento, puede serte \'util.

\vspace{.2in}
Aqu\'\i\ cubriremos todo el proceso de construcci\'on de un cluster con una
pol\'\i tica de m\'aquinas centrales -{\em servidores}- que servir\'an los servicios necesarios
a un conjunto de nodos que poseer\'an los
componentes hardware m\'\i nimos para funcionar -{\em clientes}-: desde la
construcci\'on de nodos minimalistas hasta su puesta en marcha con
linux. Empecemos pues con lo tangible, las piezas.
%------------------------------------------------------------------
\subsection{Componentes hardware requeridos}
Como ya se ha indicado, en este tipo de clusters tendremos dos tipos de computadoras: los {\em servidores} y los {\em clientes}.

Los {\bf servidores} ser\'an m\'aquinas completas, entendiendo como tal un ordenador manejable localmente a trav\'es de su teclado, rat\'on y con la salida est\'andar direccionada a un monitor.
Los {\bf clientes} ser\'an nodos con los m\'\i nimos componentes para funcionar. \'Estos son, para cada uno:
\begin{itemize}
  \item fuente de alimentaci\'on -a su vez podr\'a alimentar varios nodos si
  sabemos c\'omo realizar las conexiones-.
  \item placa madre -{\em motherboard}- con soporte de arranque por red.
  \item procesador -{\em cpu}-.
  \item memoria -entendiendo memoria principal de acceso aleatorio RAM-.
  \item y tarjeta de red con soporte de arranque por RPL ({\em Remote Program load}).
\end{itemize}

PRECAUCIONES: Deberemos prestar m\'axima atenci\'on a las compatibilidades entre las piezas
que hayamos adquirido, puesto que resulta sumamente desagradable descubrir
tras d\'ias de pruebas que todas ellas funcionan correctamente por separado,
pero no en conjunto.
Los problemas de temperatura, sobretodo de los procesadores, tambi\'en son de
m\'axima importancia, puesto que quemarlos no entra dentro de los objetivos a
cubrir.
Otra manera de reducir el riesgo de aver\'\i as es trabajar siempre
desconectado de la red el\'ectrica mientras trabajemos con las tarjetas y
dem\'as componentes.
%------------------------------------------------------------------
\subsection{Componentes hardware prescindibles}
Para enfatizar a\'un m\'as sobre lo que NO es necesario cabe mencionar,
como componentes est\'andar, los siguientes:

\begin{itemize}
  \item monitor, pantalla y targeta gr\'afica.
  \item teclado.
  \item rat\'on -{\em mouse}-.
  \item discos duros.
  \item diqueteras -{\em floppy}-.
  \item cualquier tipo de circuito integrado en placa madre.
\end{itemize}
%------------------------------------------------------------------
\subsection{Ventajas e inconvenientes}
\vspace{.1in}
{\bf Ventajas}
\begin{itemize}
  \item configuraci\'on m\'as sencilla, organizada y barata.
  \item mayor seguridad en el sistema -p\'erdida de datos, intrusiones-.
  \item menores costes de mantenimiento del maquinario.
  \item menores riesgos por aver\'\i as en discos, al disponer de menor n\'umero de ellos.
\end{itemize}

\vspace{.2in}
{\bf Inconvenientes}
\begin{itemize}
  \item rompemos la descentralizaci\'on y las ventajas que ello supone en un cluster.
  \item mayor tr\'afico en la red, puesto que a\~{n}adiremos al tr\'afico de procesos del cluster el acceso a sistemas de ficheros remotos.
  \item menor robustez de la red: por estar m\'as cargada es m\'as susceptible
  a fallos y congestiones.
\end{itemize}
%------------------------------------------------------------------
\subsection{Croquis de la arquitectura}
%La mejor manera de comprender esta construcci\'on es llegando al caso m\'as
%simple que cumpla las espectativas que deber\'a esperarse de cualquier otro
%mayor. Los requsitos m\'\i nimos para poner en marcha esta arquitectura ser\'an dos
%computadoras enlazadas por un cable de red cruzado -{\em cross cable}-; una a
%modo de {\em servidor} y otra como {\em cliente}. Esta diferenciaci\'on se
%mantendr\'a durante todo el proceso explicativo puesto que define y cunple
%todo lo que se necesita para tras ello, ser capaz de escalar este mismo
%sistemas hasta donde nuestras posibilidades econ\'omicas permitan.

%As\'\i\ pues
Los {\bf servidores} proveer\'an las cuatro necesidades b\'asicas
para que un cliente pueda arrancar y funcionar adecuadamente en red.

\begin{enumerate}
  \item \underline{Arranque (protocolo RPL).} Desde el momento de su puesta en marcha el computador deber\'a ser
  capaz de dejar a parte el reconocimiento de dispositivos locales e intentar
  hacerse con los servicios de arranque a trav\'es de su nic.

  \item \underline{Identificaci\'on (DHCP).} Los clientes no tienen forma de mantener
  sus configuraciones anteriores -si hubieran existido- en ningun medio f\'\i sico,
  puesto que no disponen de memoria secundaria -discos duros, ...-. Los
  servidores deben ocuparse de asignar la identidad a cada cliente cada vez
  que arranquen.

  \item \underline{Descarga de la imagen del kernel (TFTP).} Igualmente los clientes no
  pueden almacenar el kernel con el que deben arrancar. \'Este debe mantenerse
  en el servidor y ser trasferido cada vez que el cliente lo solicite.

  \item \underline{Sistema de archivos remoto (NFS).} Una vez que los clientes
  dispongan de identidad y hayan arrancado su kernel les faltar\'a un lugar
  donde volcar sus resultados y donde obtener los ejecutables que sus
  operaciones requieran. Necesitaremos configurar NFSroot
\end{enumerate}

Consecuentemente los {\bf clientes} a su vez seguir\'an un proceso de arranque distinto al
com\'un. V\'ease este nuevo m\'etodo.

\begin{enumerate}
  \item \underline{Arranque desde tarjeta de red (RPL).} La \'unica informaci\'on
  \'util de que disponen los clientes es su direcci\'on MAC -o direcci\'on
  ethernet- que est\'a en el {\em firmware} de su tarjeta de red -viene
  especificada por el fabricante-. \'Esta es \'unica en el mundo y es lo
  primero que el servidor recibir\'a de un cliente y le permitir\'a
  reconocerlo, o no.

  \item \underline{Identificaci\'on como miembro de la red (DHCP).}

  \item \underline{Descarga del kernel (TFTP).} Para el arranque
  en las computadoras clientes la imagen del kernel tendr\'a que sufrir
  ciertas modificaciones que le permitan cargarse en memoria y poder ser arranacadas desde
  ah\'\i . El resultado de dichos cambios en un {\em bzImage} com\'un dan
  lugar a una {\em tagged images} del mismo. La transmisi\'on se realiza por TFTP, todo ello se explicar\'a
  m\'as tarde.

  \item \underline{Sistema de ficheros remoto (NFS).} Para que el {\em host} sea
  \'util debe poseer un directorio ra\'\i z donde montar su sistema de
  ficheros y as\'\i\ pasar a ser operable como cualquier sistema linux.

  \item \underline{Integraci\'on en el cluster.} Para terminar, tendremos que
  cargar los {\em scripts} necesarios para poder integrar cada cliente al
  cluster openMosix.
\end{enumerate}
%------------------------------------------------------------------
\subsection{Di\'alogo de comunicaci\'on}
Llegados a este punto se acuerda tener una idea del proceso que debe llevar a cabo
cada tipo de computadora. Seguidamente se presenta todo ello en  un
peque\~{n}o di\'alogo -muy intuitivo- para esclarecer posibles dudas de
procedimiento. Se indica igualmente el protocolo que lo implementa.

El primer paso es arrancar alg\'un servidor, puesto que por deficnici\'on sin
ellos ning\'un cliente podr\'\i a arrancar ning\'un servicio.
Una vez hecho esto podr\'a ponerse en marcha un cliente. Su BIOS deber\'a percatarse de que
debe iniciar desde la tarjeta de red -as\'\i\ lo habremos configurado, se
explicar\'a m\'as tarde- y enviar\'a por {\em broadcast}\footnote{Es la direcci\'on de difusi\'on
  (255.255.255.255), se env\'\i a a todas las direcciones del segmento de
  red.} su direcci\'on MAC a la espera que alguien -un servidor- la reconozca
y sepa qu\'e configuraci\'on asignarle.

\vspace{.2in}
\hspace{-0.2in}RPL
\begin{itemize}
  \item {\bf Cliente (C):} ?`alguien en esta red reconoce mi MAC?
  \item {\bf Servidor (S):} yo mismo. Paso a darte capacidad para formar parte
  de esta red.
\end{itemize}
DHCP
\begin{itemize}
  \item {\bf C:} perfecto S, ?`qui\'en soy?
  \item {\bf S:} eres la IP x.x.x.x, tu servidor soy yo y tu fichero de
  arranque es {\tt vmlinuz.$<$etiqueta$>$}
\end{itemize}
TFTP
\begin{itemize}
  \item {\bf C:} por favor S, dame {\tt vmlinuz.$<$etiqueta$>$} para poder arrancar linux
  \item {\bf S:} coge el fichero de mi directorio {\tt /tftpdir/vmlinuz.$<$etiqueta$>$}
  \item {\bf C:} correcto, empiezo mi arranque...
\end{itemize}
NFS
\begin{itemize}
  \item {\bf C:} arranque completo. D\'ejame montar mi sistema de ficheros ra\'\i z (con NFS)
  \item {\bf S:} lo tienes en {\tt /tftpboot/C/}
  \item {\bf C:} d\'ejame montar mis dem\'as directorios ({\tt /usr}, {\tt /home}, etc...)
  \item {\bf S:} los tienes ah\'\i\ tambi\'en
  \item {\bf C:} !`gracias S, ahora soy totalmente operable!
\end{itemize}

Como se ver\'a a la hora de dar detalles sobre la forma de configurarlo, los
nombres de ficheros y directorios pueden ser escogidos arbitrariamente.
%------------------------------------------------------------------
\subsection{Servicios requeridos}
El di\'alogo anterior requiere de los servicios ya introducidos para
poder llevarse a cabo.

\begin{itemize}
  \item el servidor debe ser capaz de responder a peticiones de arranque por
  {\bf RPL} de los clientes.
  \item el servidor y el cliente deber\'an comprender el protocolo {\bf DHCP}.
  \item \'\i dem para el protocolo {\bf TFTP}.
  \item el servidor deber\'a arrancar el demonio servidor de {\bf NFS}.
Las computadoras clientes deben ser capaces de montar unidades por
  NFS, es una opci\'on del kernel.
\end{itemize}

Como se ha se\~{n}alado e impone el n\'umero de servicios a configurar, se
divide en cuatro partes la tem\'atica de esta secci\'on.
En una primera fase se comentar\'an sus especificaciones para tener
una visi\'on de las posibilidades que ofrecen y tras
ello se ver\'an algunas herramientas necesarias para su configuraci\'on.

\vspace{.2in}
\underline{{\bf\sc i - El servidor y el cliente del protocolo RPL}}

\vspace{.1in}
El protocolo RPL ha sido dise\~{n}ado para el arranque desde tarjetas de red
-nic- y dota al computador de la posibilidad de adquirir la posibilidad de
hacer petici\'on por DHCP, servicio que no posee debido a su falta de
capacidad de almacenaje.

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

La estructura de datos en que se basa RPL es una peque\~{n}a imagen -rom- que
deber\'a ser transferida al nic. Esta rom puede ubicarse en 2 localizaciones:
\begin{itemize}
 \item {\bf Integrarse directamente en el hardware del nic.} Aunque esta posibilidad solo viene contemplada {\em de serie}
por las tarjetas m\'as caras puesto que requiere un chip {\em bootp rom}
espec\'\i fico para cada modelo. Este chip ha de colocarse sobre el socket -que
suelen llevar todas las tarjetas- y tiene una capacidad de unos 32KB. 

  \item La otra posibilidad -que es la m\'as econ\'omica y la que aqu\'\i\ se detalla-
es {\bf montar un servidor de roms} para que los clientes obtengan la suya desde
\'el. Esta posibilidad ofrece ventajas tanto a nivel de flexibilidad -no
ser\'a necesario el chip. Las im\'agenes suelen ocupar 16KB.
\end{itemize}

\vspace{.2in}
\underline{{\bf\sc ii - El servidor y el cliente del protocolo DHCP}}

\vspace{.1in}
DHCP es un superconjunto de las operaciones que puede realizar BOOTP, que a su
vez es una mejora sobre el antiguo protocolo de arranque RARP. En este caso
utilizaremos DHCP para conseguir la direcci\'on IP. 

El funcionamiento de BOOTP -y por extensi\'on DHCP- es sencillo. Es un
protocolo de Internet que desde hace a\~{n}os -concretamente desde el 1985-
est\'a especificado en la RFC951\footnote{{\tt
    \htmladdnormallink{http://www.ietf.org/rfc/rfc0951.txt?number=951}{http://www.ietf.org/rfc/rfc0951.txt?number=951}}} de la {\em The Internet Engineering Task Force} -perteneciente a la {\em Internet Society}-.
Este protocolo tiene como principales caracter\'\i sticas:

\begin{itemize}
  \item se realizan intercambios de un solo paquete con el mismo formato tanto
  para peticiones como respuestas. Este paquete o datagrama es IP/UDP y se
  utiliza {\em timeout} para retransmitir mientras no se reciba respuesta a
  una petici\'on.

  \item Existe un c\'odigo de opci\'on que indica si el paquete es BOOTREQUEST
  (por el puerto 68) o BOOTREPLY (por el puerto 67). Las peticiones
  BOOTREQUEST contienen la m\'aquina que las solicit\'o si \'esta es conocida.

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

  \item Los servidores se comportan como {\em gateway} permitiendo incluso
  peticiones BOOTP entre varias redes.
\end{itemize}

El contenido de los campos de un paquete en el protocolo BOOTP es interesante
para ver sus opciones. Adem\'as puede servirnos para detectar, mediante aplicaciones
{\em sniffers}, fallos en tarjetas. Lo vemos en el {\tt Cuadro \ref{c_diskless01}}.


\begin{table}
\begin{center}
\begin{tabular}{ | c | c | l | } \hline
CAMPO & BYTES & DESCRIPCI\'ON  \\ \hline \hline
op & 1 &  opcode, 1=BOOTREQUEST -- 2=BOOTREPLY  \\ \hline
htype  & 1  & tipo de hardware, 1=10Mbps ethernet  \\ \hline
hlen  & 1  & longitud de la MAC (normalmente 6)  \\ \hline
hops  & 1  & utilizado por los {\em gateways} para contar los saltos  \\ \hline
xid  & 4  & ID (identificador) de la transacci\'on  \\ \hline
secs  & 2  & rellenado por el cliente con el riempo que lleva solicitando respuestas  \\ \hline
-  & 2  & reservados  \\ \hline
ciaddr  & 4  & direcci\'on IP del cliente, en el caso de conocerse  \\ \hline
yiaddr  & 4  & direcci\'on de un cliente, lo rellena el servidor tras consultar su configuraci\'on  \\ \hline
siaddr  & 4  & direcci\'on del servidor   \\ \hline
giaddr  & 4  & opcional, para atravesar varias redes  \\ \hline
chaddr  & 16  & direcci\'on hardware del cliente  \\ \hline
sname  & 64  & nombre del servidor (opcional)  \\ \hline
file  & 128  & ruta del archivo arranque  \\ \hline
Vend  & 64  & etiqueta espec\'\i fica del fabricante  \\ \hline
\end{tabular}
\caption{Nodos {\em diskless}: Campos de un paquete del protocolo BOOTP}
\label{c_diskless01}
\end{center}
\end{table}

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

\vspace{.2in}
El funcionamiento es muy sencillo. El cliente rellena un paquete con todos los
campos que conoce y con el {\tt opcode} de petici\'on, y lo difunde a la direcci\'on 255.255.255.255 de broadcast.

Luego contesta la m\'aquina servidora rellenando el paquete de manera que
el cliente recibe el paquete y lo procesa para colocar como pra\'ametros de su
pila IP los proporcionados por el servidor. Este caso se da, como se ha
comentado repetidamente, siempre que el servidor est\'e configurado para responder a la direcci\'on MAC
del cliente que genera la petici\'on.

\vspace{.2in}
El servidor de DHCP se inicia como un demonio -{\em daemon}- externo al
{\em inetd}. Gracias a DHCP queda especificado todo lo referente a la identificaci\'on IP de
aquellas m\'aquinas que intenten entrar en la red. Se podr\'a asignar un rango
din\'amico de direcciones, tambi\'en se puede hacer que todos descarguen la
misma imagen del kernel sin asignarla directamente a ning\'un host en
particular -\'util en un cluster homog\'eneo-. En el ap\'endice relativo a
{\em Salidas de comandos y ficheros} se ve un ejemplo del fjchero {\em dhcpd.conf} .

En cualquier caso y como resulta obvio, ser\'a necesario asignar una IP a cada
{\em host} -sea nodo cliente o servidor- para que forme parte de la red del
cluster y poder especificar el entorno de configuraci\'on de cada m\'aquina,
as\'\i\ como asignar los ficheros de configuraci\'on de openMosix.

\vspace{.2in}
\underline{{\bf\sc iii- El servidor y el cliente del protocolo TFTP}}

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

\vspace{.2in}
El servidor de TFTP -controlado por el demonio {\em tftpd}- se suele
arrancar desde {\em inetd}. Su configuraci\'on se centrar\'a en el servidor,
puesto que el cliente lo adopta sin que sea necesario que lo hagamos expl\'\i
cito en ninguna parte.La configuraci\'on puede hacerse:

\begin{itemize}
  \item {\bf Simple.} Hay que tener cuidado del entorno en el que se encuentra el
  servidor, ya que el protocolo tftp es inherentemente inseguro y al no exigir
  autentificaci\'on, los clientes pueden solicitar el fichero {\em
  /etc/passwd} o similar sin ning\'un problema, lo que supone una inseguridad
  considerable.

  \item {\bf Seguro.} Basa su seguridad en una llamada a {\em chroot()}. De
  este modo, en la ejecuci\'on de la rutina de aceptaci\'on de peticiones, el
  directorio exportado se convierte en directorio ra\'\i z. Consecuentemente el acceso a
  otros ficheros es m\'as dif\'\i cil.
\end{itemize}

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

La activaci\'on de este servicio es tan f\'acil como una l\'\i nea en el
fichero {\em /etc/inetd.conf}. Los par\'ametros pueden variar sensiblemente
dependiendo de la aplicaci\'on que usemos para controlar el demonio. En
principio deber\'\i a no haber problemas con:

\begin{verbatim}
   tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd /tftpboot
\end{verbatim}

\vspace{.2in}
\underline{{\bf\sc iv- NFS}}

\vspace{.1in}
NFS es el sistema de almacenamiento ingeniado por {\em Sun Microsystems} y que
utiliza RPC. Es un modelo de servidores sin estado, es decir, los servidores
NFS no guardan en nig\'un momento los archivos a los que se est\'an
accediendo\footnote{lo que puede ser un problema en el caso de querer
  controlar el bloqueo de un fichero en concreto, o una ventaja en el caso de
  que caiga la m\'aquina y se recupere r\'apidamente.}.

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

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

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

Aproximadamente se requieren unos 30MB de informaci\'on espec\'\i fica para
cada nodo -si estos disponen de un sistema linux m\'\i nimo-, mientras que el
resto puede ser compartida. 
%------------------------------------------------------------------
\subsection{Configuraci\'on de los servicios requeridos}
Llegados a este punto tenemos un conocimiento adecuado de lo que pueden
ofrecernos los cuatro servicios que utilizaremos. Sigamos la lectura para
lograr hacer nuestras configuraciones, y a\'un m\'as, entenderlas.

Reiteremos una vez m\'as un par de puntos importantes:
\begin{itemize}
  \item A la computadora {\em completa} que proporciona los servicios la
  referenciaremos como {\em servidor} y har\'a las funciones de servidor RPL,
  DHCP, TFTP y de NFS. Ser\'a la encargada de gestionar el arranque y de exportar la totalidad del
  sistema de ficheros para los nodos {\em diskless} -{\em clientes}-.

  \item Para todo ello deberemos estar seguros de haber incluido soporte para
  NFSroot en la configuraci\'on del kernel del cliente. Los dem\'as servicios
  no tienen nada a configurar en la parte del cliente -puesto que no tendr\'\i
  a donde almacenarla-.
\end{itemize}

En este cap\'\i tulo aprenderemos a configurar los servicos que anteriormente
se han expuesto, as\'\i\ pues se seguir\'a la misma estructurari\'on cuaternaria:
rpl, dhcp, tftp y nfs.

\vspace{.2in}
\underline{{\bf\sc i- Configuraci\'on servidor RPL.} {\em rpld.conf}}

\vspace{.1in}Lo primero ser\'a conseguir un demonio para el protocolo RPL. Una
implementaci\'on funcional y estable puede bajarse de un rinc\'on de la web de
la Universidad de Cambridge\footnote{
\htmladdnormallink{http://gimel.esc.cam.ac.uk/james/rpld/}{http://gimel.esc.cam.ac.uk/james/rpld/}}.

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

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt rpld}}

\vspace{.1in}
Este demonio intentar\'a acceder al fichero {\em /etc/rpld.conf}. Este fichero
tiene una sintaxis muy concreta -a la vez que potente- y por ello se recomienda leer
las p\'aginas {\em man} posteadas en la misma direcci\'on. Su lectura
permitir\'a al administrador hacer un examen exhaustivo de todas las
posibilidades que pueda brindarnos este servicio.

Existe un ejemplo de este tipo de fichero en el ap\'endice {\em Salidas de comandos y ficheros}.
Basta con anotar la direcci\'on MAC del cliente que realizar\'a la petici\'on
e indicar la imagen rom que se corresponde al modelo de chipset de su
nic\footnote{La generaci\'on y manejo de estas roms ser\'a f\'acil una vez se
conozca el tema de primera mano. La opci\'on m\'as recomendable viene de parte del proyecto
Etherboot. Para m\'as informaci\'on {\em ROMs para arranque sin discos}.
}. Los dem\'as par\'ametros se refieren al tama\~{n}o de los bloques que se
transferir\'an; los valores indicados en el fichero de ejemplo no deben dar
problemas.

N. al LECTOR. La documentaci\'on necesaria para generar la rom adecuada a cada
modelo de nic se encuentra en la siguiente secci\'on: {\bf ROMs para arranque
  sin discos}.

\vspace{.2in}
\underline{{\bf\sc ii- Configuraci\'on servidor DHCP.} {\em dhcpd.conf}}

\vspace{.1in}
El fichero que el demonio {\em dhcpd} leer\'a para cargar la configuraci\'on
ser\'a el {\em /etc/dhcpd.conf} . Este demonio puede lanzarse con el comando 

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt /etc/init.d/dhcpd start}}

\vspace{.1in}
La ruta del demonio puede variar seg\'un la distribuci\'on. En el ap\'endice
{\em Salidas de comandos y ficheros} hay un ejemplo de este tipo de fichero,
para comprenderlo se aconseja ejecutar {\tt man dhcpd} en cualquier consola.
A continuaci\'on se detallan los par\'ametros que pueden ser m\'as
interesantes. Para la {\bf red}:

\begin{itemize}
  \item {\em default/max-lease-time} tiempos en milisegundos para las operaciones de reconocimiento.
  \item {\em option domain-name} define el nombre para la red.
  \item {\em option domain-name-server} direcci\'on del servidor.
  \item {\em option subnet-mask} m\'ascara de subred.
  \item {\em range dynamic-bootp} rango de direcciones, en este caso son 255 computadoras (de la 0 a la 254).
  \item {\em option routers} aqu\'\i\ indicaremos la direcci\'on de un nodo
  que haga de enrutador, si existe.
\end{itemize}
Para cada {\bf nodo}:
\begin{itemize}
  \item {\em host} indicar\'a el nombre del nodo.
  \item {\em  hardware-ethernet} quiz\'as haga falta decir que cada {\tt X} se refiere a un d\'\i gito hexadecimal correspondiente a la direcci\'on MAC de la targeta en concreto.
  \item {\em fixed-address} asigna al nodo la direcci\'on IP que el servidor har\'a llegar al cliente con la MAC anterior.
  \item {\bf\em filename} referencia a la {\em tagged image} (imagen de kernel modificada) para arrancar.
  \item {\em option root-path} ruta para {\em /} del nodo.
\end{itemize}

El par\'ametro {\em filename} hace referencia a una imagen del kernel distinta
a la salida del comando {\tt make bzImage} utilizado para realizar la imagen
del kernel linux. Para conocer las modificaciones necesarias a una iamgen para
obtener una {\em tagged image} cons\'ultese {\bf ROMs para arranque sin
  discos} en la pr\'oxima secci\'on.

\vspace{.2in}
\underline{{\bf\sc iii- Configuraci\'on del servicio TFTP} {\em inetd.conf}}

\vspace{.1in}
Como ya se ha mencionado, el protocolo TFTP es inseguro {\em per se},
es conveniente asegurar nuestro sistema con herramientas como {\tt
  tcp-wrapper} y alg\'un tipo de cortafuego -{\em firewall}- si queremos bajar
las probabilidades de que llegue a darse una intrusi\'on\footnote{Se
pueden cerrar los puertos de tftp -normalmente el 69 UDP- salvo para los
clientes autorizados de este servicio, i.e. las direcciones IP concedidas en
el apartado anterior.}.

Una vez hagamos hecho las modificaciones ya dadas al fichero {\em
  /etc/inetd.conf}, para relanzar el demonio {\em inetd}\footnote{Este demonio
  suele iniciarse al arranque de la computadora.} deber\'a ejecutarse:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt /etc/init.d/inetd reload}}

\vspace{.1in}
Otra opci\'on para relanzarlo es la se\~{n}al HUP. Para ello deberemos
conocer el PID del demonio y ejecutar:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt kill -HUP $<$inetd\_pid$>$}}

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

\begin{verbatim}
     /etc/host.allow
     /etc/host.deny
     /etc/syslog.conf
     /etc/inetd.conf
\end{verbatim}

\vspace{.2in}
En la l\'\i nea que hay que a\~{n}adir -o descomentar- en el {\em inetd.conf}
aparece como \'ultimo par\'ametro el directorio ra\'\i z que sirve para
encontrar los ficheros a importar. En este caso se ha considerado el directorio
{\em /tftpboot/} del servidor.
En este directorio ser\'\i a conveniente colocar todas las im\'agenes de los
clientes\footnote{Las im\'agenes de kernel linux ser\'an de tipo {\tt bzImage}
  de momento. \'Esta estructura no sirve para ser transferida por red para
  cargarse y ejecutarse desde memoria, as\'\i\ que los ficheros que deber\'an
  constar en {\em dhcpd.conf} deber\'an ser conversiones a {\em tagged images}. Para m\'as informaci\'on {\em ROMs para
    arranque sin discos}.}, para dotar al sistema de cierto criterio y
coherencia. Cabe recordar que {\bf es el fichero {\em dhcpd.conf} el que marca
qu\'e imagen debe recoger cada cliente}.

\vspace{.2in}
\underline{{\bf\sc iv- Servidor NFS}}

\vspace{.1in}
Hasta este punto los clientes tienen que poder empezar a arrancar su kernel,
no obstante no podr\'an iniciar el proceso con PID 1 , el INIT, debido a que
no deben ser capaces de poder montar ninguna unidad. Aqu\'\i\ es donde entra
el \'unico servicio que resta: el NFS. Esta secci\'on est\'a separada, seg\'un
sea el cometido:

\begin{itemize} 
  \item la exportaci\'on -por parte del servidor- de una serie de directorios
  \item o la importaci\'on del directorio {\em /} por parte del cliente.
\end{itemize}

\vspace{.2in}
\underline{{\bf\sc iv a- Exportaci\'on de directorios con NFS}}

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

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt /etc/init.d/nfsserver start}}

\vspace{.1in}
El fichero de configuraci\'on de NFS que exporta los directorios necesarios
suele estar en {\em /etc/exports}. Tiene su propio manual ({\tt man exports})
que se deber\'a leer para incluir los directorios con una sintaxis correcta y
a\~{n}adir algo de seguridad al servicio NFS. En el caso de dos clientes -{\tt
  metrakilate} y {\tt mCi}- de arranque sin discos, este fichero de configuraci\'on tendr\'\i a que ser algo
parecido a lo siguiente:


\begin{verbatim}
/tftpboot/metrakilate/  192.168.1.2/255.255.255.0(rw,no_root_squash,sync)
/tftpboot/mCi/          192.168.1.3/255.255.255.0(rw,no_root_squash,sync)
/media/dvd/             192.168.1.0/255.255.255.0(ro,no_root_squash,sync)
\end{verbatim}

En este ejemplo se indica donde se encuentra la ra\'\i z para cada una de las
dos m\'aquinas, m\'as un directorio -la unidad local de dvd- que ser\'a
exportada a cualquier nodo con IP {\tt 192.168.1.X} (siendo {\tt X} un valor entre 1
y 255).

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

\vspace{.2in}
\underline{{\bf\sc iv b- Ra\'\i z en los nodos clientes}}

\vspace{.1in}
Dentro de {\em /tftpboot/$<$directorio\_raiz\_de\_un\_nodo$>$} se debe
encontrar un sistema r\'eplica de ficheros a la distribuci\'on que queramos
utilizar. La edci\'on de ficheros para configuraciones a\~{n}adidas o la
ejecuci\'on de aplicaciones podr\'a hacerse normalmente
como si se trabajara con unidades locales, ya que la capa de VFS nos hace
transparente el proceso.

As\'\i\ pues una soluci\'on es comenzar una instalaci\'on de
linux cambiando la ruta de instalaci\'on a {\em
  /tftpboot/ $<$directorio\_raiz\_de\_un\_nodo$>$}, de manera se aseguran que todos los archivos
necesarios se encuentran en el lugar requerido.

Otra posibilidad es hacer una instalaci\'on normal en un disco conectado a la
placa madre del nodo cliente para asegurar que
todo funciona correctamente. Una vez se ha comprobado que el sistema operativo
es capaz de montar unidades por NFS y tiene capacidad de entrar en una red,
puede procederse a empaquetar su directorio {\em /} desde la m\'aquina
servidora\footnote{Habiendo montado el sistema de ficheros del cliente -{\em /}- en el servidor
-{\em $<$/directorio\_cualquiera$>$}-, con lo que ahora el servidor pasa a ser
cliente que importa el directorio y el nodo el exportador de su {\em /} .} para luego desempaquetarlo en el
  {\em /tftpboot/$<$directorio\_raiz\_de\_un\_nodo$>$} elegido.

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

\begin{itemize}
  \item {\em /bin, /sbin, /lib}. Estos directorios pueden ser copiados
  directamente del directorio ra\'\i z con {\tt cp -a /bin
  /tftpboot/$<$directorio\_comun\_a\_los\_nodos$>$/} y luego hacerlos compartirdos entre todos los
  clientes sin discos mediante enlaces duros\footnote{{\tt man ln}}.

    \item {\em /var, /tmp, /etc}. Deben ser copiados en cada cliente y
    adaptados a las necesidades de cada uno de ellos, m\'as abajo se da
    una breve descripci\'on de lo que debe ser cambiado en {\em /etc} para que
    funcione.

    \item {\em /proc, /root, /home}. Deben existir y tener los permisos
    adecuados seg\'un sea su propietario.

    \item {\em /dev}. Debe ser \'unico de cada cliente. Para crearlo se pueden
    utilizar dos opciones, {\tt devfs} o una copia del sistema y luego la
    ejecuci\'on de MAKEDEV (script) y a\~{n}adir un dispositivo {\em /nfsroot}
    al kernel que utilicemos.
\end{itemize}

Existen dos puntos que complican sensiblemente el proceso. Se detallan seguidamente.
\begin{enumerate}
  \item configuraci\'on propia de cada nodo.
  \item los dispositivos {\em /dev} .
\end{enumerate}

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

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

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt cp -a /dev /tftpboot/$<$directorio\_raiz\_de\_un\_nodo$>$}}

\hspace{1in}\colorbox{gray}{{\tt cd /tftpboot/$<$directorio\_raiz\_de\_un\_nodo$>$}}

\hspace{1in}\colorbox{gray}{{\tt ./MAKEDEV}}

\vspace{.1in}
Esto consigue que se generen los enlaces necesarios a este directorio -propio
del nodo- en lugar de a
{\em /dev/xxxx}, que es el directorio del servidor. Adem\'as hay que hacer un
nuevo dispositivo de {\tt major 0} y {\tt minor 255}, y exportarlo al kernel
para que se puedan recibir comandos de nfsroot en \'el. Esto se puede
conseguir con:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt mknod /dev/nfsroot b 0 255}}

\hspace{1in}\colorbox{gray}{{\tt rdev bzImage /dev/nfsroot}}

\vspace{.1in}
Aqu\'\i\ {\tt bzImage} tiene que ser la imagen del kernel del nodo {\em
  diskless} en cuesti\'on. Generalmente se encuentra en {\em
  /usr/src/linux-version/arch/i386/boot} tras su compilaci\'on.

\vspace{.3in}
Llegados aqu\'\i, finalmente, tus clientes {\em disk-less} deber\'\i an estar funcionando sin nig\'un problema.
