%% This LaTeX-file was created by <fortu> Tue Feb  9 03:02:12 1999
%% LyX 0.12 (C) 1995-1998 by Matthias Ettrich and the LyX Team

%% Do not edit this file unless you know what you are doing.
\documentclass[a4paper,spanish]{article}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage{babel}
\usepackage{verbatim}

\makeatletter


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands.
\newcommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\spacefactor1000}

\makeatother

\begin{document}


\title{Uso de un \emph{automounter} para los sistemas de archivos remotos.}

\maketitle
\begin{abstract}
Se explica sucintamente el funcionamiento de los sistemas de archivos remotos
y la función de un automounter. No se asume que el lector tenga un gran conocimiento
previo sobre el tema. En caso contrario quizás sea mejor empezar a leer a partir
de la sección \ref{sec:mecanet} en la que se comenta cómo funciona el sistema
en concreto en MecaNet.
\end{abstract}
En cada máquina existe una instalación local de Debian GNU/Linux. En el archivo
\texttt{/etc/fstab} se encuentran las particiones que se usan de los discos
locales y los lugares en el arbol de directorios dónde se montan. 

Una tabla típica es la siguiente:

\verbatiminput{fstab.txt}Al arrancar el sistema las particiones se ``montan''
una a una en los directorios que se indican en la tabla anterior. De este modo,
cuando accedemos (para, por ejemplo, copiar o editar un archivo) a un archivo
que se encuentre en el directorio \texttt{/tmp}, el sistema sabe que debe buscarlo
en la partición (lugar físico: disco y posición en el mismo) \texttt{/dev/hda3}.


\section{Discos remotos.}

Es posible que algunos directorios estén ligados a discos que no se encuentran
físicamente en la misma máquina. Si para alguno de los directorios (punto de
``montaje'' del disco) en \texttt{/etc/fstab} el tipo de la partición se indica
como NFS, a la hora de acceder a archivos que se encuentren en el mismo el sistema
accede a los mismos a través de la red. Esto se implementa mediante una serie
de protocolos (RPC?) de comunicaciones entre los ordenadores. Para que funcione
es necesario que en ambas máquinas (la que sí posee el disco físicamente y la
que realiza el montado remoto) existan unos programas que ``capturen'' las
llamadas (cliente de NFS) y que devuelvan los datos que se reclaman desde el
cliente (servidor de NFS). En GNU/Linux ambos (cliente y servidor) son procesos
que están arrancados desde el inicio esperando este tipo de llamadas (\emph{daemon}
o demonio).

Esta estrategia presenta un problema; tal y como están implementados los protocolos
de llamadas, el servidor desconoce por completo el estado del cliente (si va
a seguir accediendo al disco o no, porque, por ejemplo, el sistema se ha apagado).
Por otro lado si el servidor es el que deja de funcionar y un cliente intenta
montar un \emph{filesystem} remoto lo único que puede hacer es intentarlo cierto
número de veces y, tras un tiempo determinado (\emph{timeout}) desistir. El
resultado es que cuando alguno de los dos sistemas deja de funcionar se producen
unas esperas demasiado grandes y que afectan a todo el sistema.

En realidad no es necesario montar un filesystem desde el inicio si sólo se
va a usar esporádicamente. Es mucho más práctico montarlo mientras se vaya a
acceder a alguno de los archivos que contiene, siguiendo una estrategia más
inteligente que la anterior, y desmontarlo cuando vaya a dejar de ser usado.
Si en los intervalos en los que el filesystem no se usa el servidor, o el cliente,
se ``caen'' no ocurre nada.

Para esto último se han propuesto varios sistemas, denominados genéricamente
\emph{automounter}. Para GNU/Linux existen, al menos, ``automount'' de Sun
y el que se ha instalado en MecaNet, ``amd'' de BSD. Se implementan también
mediante demonios que ``vigilan'' los accesos al archivos del arbol de directorios
y toman las medidas oportunas en cada caso.

Ambos funcionan usando tablas funcionalmente similares al fstab en las que se
indica dónde se encuentra el sistema remoto a montar (y las acciones necesarias
en cada caso) cuando se accede a un directorio concreto. Estas tablas se denominan
\emph{key maps}. El protocolo de comunicaciones mediante el cual se montan los
directorios \textbf{sigue siendo NFS}, los automounters básicamente gestionan
el (des)montado de los filesystems, únicamente.


\section{Estructura de los sistemas de archivos.}

En cada máquina existe, al menos, una partición que está destinada a ser importada
por los clientes que necesiten los archivos que en ella residen. Obviamente
cada una de estas particiones existe físicamente en alguna máquina y en ella
posee una entrada en su \texttt{/etc/fstab}. En la tabla \ref{tbl:export} se
resume las particiones que exporta cada máquina, y el lugar dónde, localmente,
se montan.

\begin{table}
{\centering \begin{tabular}{|c|c|c|}
\hline 
Máquina&
Partición&
Directorio local\\
\hline 
\hline 
\texttt{filemon}&
\texttt{sda7,sdb1}&
\texttt{/export/dsk2,dsk1}\\
\hline 
\texttt{ulises}&
\texttt{hda7}&
\texttt{/export/dsk3}\\
\hline 
\texttt{taurus}&
\texttt{sda5}&
\texttt{/export/dsk4}\\
\hline 
\texttt{zape}&
\texttt{hda4}&
\texttt{/export/dsk5}\\
\hline 
\texttt{zipi}&
\texttt{-}&
\texttt{-}\\
\hline 
\end{tabular}\par}


\caption{Particiones exportadas en MecaNet.\label{tbl:export}}
\end{table} Por ejemplo, la particion \texttt{/dev/sda7} de \texttt{filemon.mecanica.upm.es}
se monta localmente en el directorio \texttt{filemon:/export/dsk2}. Cuando un
cliente quiera montar esta partición (con NFS, use un automounter o no) debe
indicar al servidor que va a montar ése directorio en concreto.

Estrictamente, las cosas pueden ser más complejas de lo que se ha explicado
(de hecho siempre lo serán :-). Se puede importar, en principio, un directorio
arbitrario de la máquina en la que reside el servidor de NFS (con algunas restricciones,
como por ejemplo que exista permiso para hacerlo o que el directorio no pertenezca
a un filesystem que ya es remoto). Por ejemplo, no tenemos que montar todo \texttt{/export/dsk2}
para acceder a un subdirectorio del mismo, bastará con montar ése directorio,
exclusivamente.

En cada máquina se ha creado un directorio \texttt{/import} cuya función es
ser el punto de montaje de \textbf{todos} los sistemas de archivos remotos que
se necesiten. Por seguir un convenio de nombres coherente (aunque podría no
haberse hecho de este modo) los sistemas remotos se montan en los clientes con
el mismo nombre que tienen en el servidor. En concreto, si en \texttt{ulises.mecanica.upm.es}
se va a montar \texttt{filemon:/export/dsk2}, el lugar en el que se hace (directorio
local en \texttt{ulises}) será \texttt{ulises:/import/dsk2}.


\section{Estructura del arbol de directorios. Enlaces simbólicos.}

Un usuario, sin embargo, no tiene por qué saber que el archivo de su proyecto
de fin de carrera se encuentra en \texttt{/import/dsk}\texttt{\emph{nosequé}}
(cualquiera que sean los procedimientos por los que se monte, que se explican
más adelante) sino que, normalmente, sabrá que se encuentra en algo parecido
a \texttt{/usr/local/projects/fulanito/miPFC}. La estrategia para conseguir
esto puede basarse en el uso de enlaces simbólicos.

Un enlace simbólico es un archivo que contiene un puntero a otro lugar (arbitrario
en principio) del sistema de archivos (se encuentre en el mismo dispositivo
o no, se trata de algo independiente de todo lo anterior). Cuando se accede
al enlace se está accediendo, en realidad, al archivo al que ``apunta'' el
enlace.

De este modo cuando nuestro proyectando quiera acceder a su PFC, en realidad
podría estar accediendo al archivo \texttt{/import/dsk}\texttt{\emph{nosequé}}
sin que tenga que preocuparse de nada más. A pesar de todo, alguien debe hacer
el enlace simbólico para que las cosas empiecen a funcionar de esta manera.

Un modo es crear un enlace simbólico de un directorio (los directorios \emph{también}
son archivos) a un directorio del sistema de archivos remoto. Siguiendo el ejemplo
anterior, el administrador del sistema podría haber creado un enlace en \texttt{ulises:/usr/local/projects/fulanito}
a un directorio remoto que, localmente, se monta en \texttt{ulises:/import/dsk2/PFCs/fulanito}.
Así, cuando el usuario acceda al archivo \texttt{miPFC} anterior (y a cualquier
otro archivo en su directorio), en realidad, estará accediendo al archivo que
reside en \\
\texttt{filemon:/export/dsk2/PFCs/fulanito/miPFC}.

Por supuesto, esta es una manera muy estática de organizar los accesos remotos.
Alguien (el administrador del sistema) se encarga de crear un océano de enlaces
simbólicos locales (¡en cada máquina!) que apuntan al sistema de archivos remoto
adecuado.

Quizás sea conveniente, plantear el problema global: lo que se desea es que
cuando un usuario accede, por ejemplo, a su cuenta (\texttt{ulises:/home/fulanito})
en realidad esté accediendo a, por ejemplo, \texttt{ulises:/import/dsk2/PFChomes/fulanito},
que es el lugar dónde se monta el sistema de archivos remotos \\
\texttt{filemon:/export/dsk2/PFChomes/fulanito}, dónde hemos hecho residir las
cuentas de los usuarios de toda la red. El ``administrador'' que se encarga
de \textbf{crear el enlace simbólico que apunta al lugar dónde se va a montar
el sistema remoto} cuando un usuario accede a su cuenta (o a cualquier otro
archivo que no sea local) es el automounter. El administrador (la persona de
carne y hueso) se encarga únicamente de indicar al automounter las reglas que
debe seguir para la construcción de los enlaces, antes de montar los sistemas.
A continuación se explica como se ha implementado esto de manera concreta en
MecaNet.


\section{Funcionamiento del automounter en MecaNet.\label{sec:mecanet}}

El automounter que se ha elegido es ``amd'' ya que permite construir mapas
más flexibles que los del ``automount'' de Sun. En concreto, permiten tomar
decisiones acerca de qué sistemas de archivos se deben importar, en función
de, por ejemplo, el nombre de la máquina. Esto permite que los archivos de configuración
de amd sean \textbf{los mismos en todas las máquinas}, ya que en cada una de
ellas se ejecutan configuraciones distintas según se indica en el mapa de montado.

Todos los archivos de configuración se encuentran, en cada máquina, en \texttt{/etc/amd}.
El archivo ``principal'' es \texttt{/etc/amd/amd.master}. En él se indican
los mapas a utilizar cuando algún proceso accede al interior de una lista de
directorios. 

El listado típico de \texttt{amd.master} es:

\verbatiminput{amdmaster.txt}

Es decir, cuando se acceda a un archivo en \texttt{/home} la secuencia de acciones
a realizar por parte del demonio de amd se indica en \texttt{/etc/amd/amd.home}.

Nótese que también hay un mapa en el caso de que se acceda al directorio \texttt{/import}
que hemos dicho que ningún usuario tendrá el mal gusto de usar. En realidad
sí va a acceder ``alguien''. Ésto quedará claro un poco más adelante.


\subsection{Los mapas de montado.}

De lo anterior se deduce que el listado de archivos de configuración que habrá
en \texttt{/etc/amd} debe ser parecido al siguiente:

\verbatiminput{etcamd.txt}

El aspecto del mapa que controla los accesos a \texttt{/home} (para otros directorios
es similar) es el siguiente (listado de \texttt{amd.home}):

\verbatiminput{amdhome.txt}

Cuando se produzca un acceso al archivo \texttt{/home/fulanito} se leerá este
archivo y en el mismo se indica (\texttt{type:}=\texttt{link)}que debe montarse
un sistema de archivos mediante un enlace (en cristiano: \textbf{hacer un enlace
simbólico}, sin más). Este enlace será el archivo al que se accede, el directorio
\texttt{/home/fulanito}, que apunta a \texttt{/import/home2/fulanito}.

Ahora se puede entender el por qué de un mapa en el caso de que se realice un
acceso al directorio \texttt{/import} (y por lo tanto existe el mapa \texttt{amd.import}).
Al realizarse el acceso al directorio \texttt{/home/fulanito} en realidad se
está accediendo a \texttt{/import/home2/...} que, en principio, no existe, hay
que montarlo. Se produce una nueva llamada a amd para realizar el montado del
filesystem remoto en \texttt{/import/home2}.


\subsection{\texttt{amd.import}}

Al fin, todo se reduce a resolver el problema de montar los directorios remotos
en \texttt{/import} cuando se produce algún acceso dentro de este directorio.
Otros mapas se encargan de que los accesos a los directorios ``habituales''
terminen siendo, a través de enlaces simbólicos que se crean dinámicamente,
accesos a \texttt{/import}.

El listado típico de \texttt{amd.import} es:

\verbatiminput{amdimport.txt}

Dijimos que al acceder a~\texttt{/home/fulanito} se realizaba en realidad (a
través de un enlace simbólico) un acceso a \texttt{/import/home2} cuyo nombre
no se corresponde con ninguno de los sistemas de archivos que se importan (\texttt{dsk}\texttt{\emph{nosequé}}\emph{).}
En \texttt{amd.import} encontramos una entrada que nos dice que hace amd cuando
se accede a \texttt{/import/home2}, en concreto se hace un nuevo enlace simbólico
a \texttt{/import/dsk3}.

El acceso a \texttt{/import/dsk3} provoca la lectura de la entrada correspondiente
en el mismo archivo y que indica que la secuencia de acciones a realizar es:

\begin{itemize}
\item Si el nombre de la máquina en la que se ejecuta amd (el cliente de NFS) es \texttt{ulises}
basta con hacer un enlace simbólico que apunte a \texttt{/export/dsk3}. Lógico,
puesto que ese disco \textbf{ya sería local} y se puede acceder a él sin tener
que montar nada.
\item Si el nombre de la máquina no es \texttt{ulises} hay que montar el filesystem
remoto (\texttt{rfs}) correspondiente: \texttt{/export/dsk3}. Y \textbf{ya se
han completado todos los pasos}. 
\end{itemize}
Los accesos a \texttt{/home/fulanito} se transforman en accesos a \texttt{/import/dsk3}
a través de dos enlaces simbólicos: \texttt{/home/fulanito} que apunta a \texttt{/import/home2}
que apunta a su vez a \texttt{/import/dsk3} que puede ser otro enlace o el sistema
de archivos remotos en sí mismo. Un esquema de la situación es el siguiente:

{\centering \texttt{/home/fulanito~\( \longrightarrow  \)~/import/home2~\( \longrightarrow  \)~}\par}

{\centering \texttt{\( \longrightarrow  \)~/import/dsk3~\( \longrightarrow  \)
ulises:/export/dsk3}\par}

\end{document}
