%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%                       Legal Notice                            %
%                                                               %
% This document is copyright (C) Olaf Kirch, okir@monad.swb.de  %
%                                                               %
% For copying conditions, please refer to the file COPYING.	%
%                                                               %
% The author is not liable for any damages, direct or indirect, %
% resulting from the use of information provided in this        %
% document.                                                     %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% When viewing this document with vi on an 80-columns screen,   %
% do a ':se nonumber' first.                                    %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Traduccion realizada por Juan Jose Amor                       %
% Envie sus comentarios a:                                      %
%       jjamor@ls.fi.upm.es (INTERNET)                          %
%       2:341/12.19         (FIDONET)                           %
%                                                               %
% Revisado en 30-Enero-1999 por:                                %
%   Juan Jose Amor <jjamor@ls.fi.upm.es>                        %
%                                                               %
% Revisado en 11-Marzo-1999 por:                                %
%   Juan Jose Amor <jjamor@ls.fi.upm.es>                        %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%               S T A R T   O F   C H A P T E R                 %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{El Sistema Ficheros en Red (NFS)}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{nfs}
\index{file sharing}
\index{remote!file access}
\index{Network File System|see {NFS}}
\index{NFS|(}

NFS, acr\'onimo de {\it Network File System}, que nosotros llamaremos
{\it Sistema de Ficheros en Red}, es probablemente el servicio m\'as
complejo de los que se ofrecen usando RPC. Permite acceder a los
ficheros remotos exactamente igual que si fueran locales. Esto se hace
programando parte de la funcionalidad a nivel del n\'ucleo (en el lado
del cliente) y la otra parte como un demonio servidor. El acceso a los
ficheros es totalmente transparente al cliente, funcionando con muchas
arquitecturas de servidores.


NFS ofrece numerosas ventajas:


\begin{itemize}
\item   Los datos accedidos por todo tipo de usuarios pueden
mantenerse en un nodo central, con clientes que montan los directorios
en el momento de arrancar. Por ejemplo, puede mantener todas las
cuentas de usuario en una m\'aquina, y hacer que las dem\'as monten dichas
cuentas en su directorio \file{/home} por NFS. Si adem\'as se instala
NIS, los usuarios podr\'{\i}an entrar y trabajar de forma transparente en
cualquiera de las m\'aquinas.

\item   Los datos que consumen grandes cantidades de espacio de disco
pueden mantenerse en un nodo. Por ejemplo, mantener una sola copia de
\LaTeX{} en lugar de copiarlo en cada nodo.

\item   Los datos de administraci\'on pueden tambi\'en mantenerse en un
solo nodo. Ya no ser\'a necesario usar \prog{rcp} para instalar el mismo
fichero en 20 m\'aquinas distintas.

\end{itemize}


El NFS de \linux{} es, principalmente, obra de Rick
Sladkey,\footnote{Puede contactar con Rick en la direcci\'on
\email{jrs@world.std.com}}, pues escribi\'o el c\'odigo que corresponde al
n\'ucleo y buena parte del c\'odigo del servidor NFS. Este \'ultimo es una
modificaci\'on del servidor \prog{unfsd} que corre en espacio de
usuario, escrito originalmente por Mark Shand, y el servidor
\file{hnfs} (Harris NFS) escrito por Donald Becker.


\index{NFS!montar un directorio}
Veamos ahora un poco c\'omo funciona NFS: un cliente puede solicitar
montar un directorio desde un servidor remoto, de forma similar a como
montar\'{\i}a un directorio local. Sin embargo, la sintaxis no es
exactamente igual. Por ejemplo, para montar el directorio \file{/home}
del nodo \host{vlager} en el directorio \file{/users} de \host{vale},
el administrador escribir\'{\i}a el siguiente comando en
\host{vale}:\footnote{Observar que puede omitirse la opci\'on \option{-t
nfs}, ya que el programa \prog{mount} sabe por la aparici\'on de los dos
puntos ({\tt:}) que se trata de un sistema NFS.}

\begin{tscreen}
 \# mount -t nfs vlager:/home /users
\end{tscreen}

\prog{mount} intentar\'a conectar con el demonio remoto \prog{mountd}
mediante RPC. El servidor comprobar\'a si la m\'aquina \host{vale} tiene
permiso para montar el directorio pedido, y si es as\'{\i} retornar\'a un
descriptor de fichero. Este descriptor se utilizar\'a en todas las
peticiones que sobre ficheros de \file{/users} se realicen posteriormente.


\index{servidor!nfsd@\prog{nfsd}}
\index{nfsd@\prog{nfsd}}
Cuando alguien accede a un fichero remoto, el n\'ucleo manda una llamada
RPC al programa \prog{nfsd} (demonio de NFS) del nodo remoto. Esta
llamada incluye el descriptor de fichero, el nombre del fichero a
acceder y los identificadores de usuario y de grupo del
demandante. Estos identificadores se usan para chequear permisos de
acceso en la m\'aquina remota, con lo que los usuarios de ambas m\'aquinas
deber\'{\i}an ser los mismos.


En varias implementaciones de \unix{}, las funcionalidades de cliente
y servidor NFS se realizan como demonios de nivel de n\'ucleo que se
arrancan desde el espacio de usuario al arrancar la m\'aquina. Se trata
del programa \prog{nfsd} en el servidor y del programa \prog{biod}
(\emph{Block I/O Daemon}, o demonio de E/S\footnote{N. del T.: E/S es
Entrada/Salida} por bloques) en el
cliente. Para aumentar el rendimiento, \prog{biod} realiza E/S
as\'{\i}ncrona, y a veces corren concurrentemente varios servidores de NFS.

% on the client host. To improve throughput, \prog{biod} performs
% asynchronous I/O using read-ahead and write-behind; also, several


La implementaci\'on de NFS en \linux{} es algo diferente: el c\'odigo de
cliente est\'a integrado en la capa de sistema de ficheros virtual (VFS)
y no requiere control adicional mediante el programa \prog{biod}. Por
otro lado, el c\'odigo de servidor corre totalmente en el espacio de
usuario, por lo que ejecutar varias copias del \prog{nfsd} resulta
imposible debido a los problemas de sincronizaci\'on que originar\'{\i}a.
%\linux{} NFS currently also lacks read-ahead and write-behind,
%but Rick Sladkey plans to add this someday.\footnote{
%  The problem with write-behind is that the kernel buffer cache is indexed
%  by device/inode pairs, and therefore can't be used for NFS-mounted
%  file systems.
%}


\index{NFS!limitaciones}
\index{NFS!servidor}
El mayor problema con el c\'odigo NFS de \linux{} es que el n\'ucleo 1.0
no puede manejar bloques de memoria de m\'as de 4Kb, por lo que el
c\'odigo de red no puede manejar datagramas de un tama\~no mayor que 3500
octetos una vez eliminadas las cabeceras. Esto significa que las
transferencias con servidores NFS que utilicen datagramas grandes por
defecto (por ejemplo, los 8Kb de SunOS) necesitan ser reducidos
artificialmente. Esto produce p\'erdidas de rendimiento en ciertas
circunstancias.\footnote{
	Como me explic\'o Alan Cox:
	La especificaci\'on de NFS requiere que el servidor guarde cada
escritura en disco antes de retornar un reconocimiento al cliente
(ACK). Como los n\'ucleos de BSD s\'olo manejan escrituras del tama\~no de
p\'agina (4 Kb), escribir en 4 veces 1Kb cada una en un servidor NFS
basado en BSD tiene como consecuencia hacer cuatro operaciones de
escritura de 4 Kb cada una.} Esta limitaci\'on desapareci\'o en los
n\'ucleos posteriores al 1.1, reescribi\'endose el c\'odigo del cliente para
aprovechar la nueva situaci\'on.



\section{Preparaci\'on de NFS}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{nfs.nfsd}

Antes de usar NFS, sea en cliente o servidor, debe asegurarse de que el
n\'ucleo tiene el soporte incluido. Los n\'ucleos modernos informan de
ello a trav\'es del sistema \file{/proc}, con un comando como el siguiente:


\begin{tscreen}
\begin{verbatim}
$ cat /proc/filesystems
	minix
	ext2
	msdos
nodev	proc
nodev	nfs
\end{verbatim}
\end{tscreen}


Si no aparece la palabra \keyword{nfs}, tendr\'a que recompilar el
n\'ucleo con el soporte NFS habilitado. Sobre c\'omo configurar el n\'ucleo
hablamos en la secci\'on ``Configuraci\'on del N\'ucleo'' del
cap\'{\i}tulo~\ref{hardware}.


Con versiones del n\'ucleo anteriores a la 1.1, la forma de comprobarlo
es intentar montar un sistema NFS de prueba, de la siguiente forma:


\begin{tscreen}
 \# mkdir /tmp/test \\
 \# mount localhost:/etc /tmp/test
\end{tscreen}


Si el comando \prog{mount} falla con el mensaje ``\term{fs
type nfs no supported by kernel}'' ({\it sistema tipo NFS no soportado
por el n\'ucleo}), deber\'a recompilar el n\'ucleo habilitando NFS. Otro
tipo de errores no implican recompilar el n\'ucleo, ya que se producen
al no estar corriendo el programa \prog{nfsd}.




\section{Montaje de un volumen NFS}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{nfs.mountd}
\index{remote!file system}
\index{mounting!an NFS volume}
\index{acessing!remote files}
\index{NFS!mounting a volume}

Los vol\'umenes NFS\footnote{
 Hablamos de vol\'umenes, y no de sistemas de ficheros, porque no lo son
realmente: pueden ser sólo directorios de un sistema.
} se montan como los sistemas de ficheros usuales. Se trata de llamar
al comando \prog{mount} con la sintaxis:


\begin{tscreen}
\# mount -t nfs \var{volumen\_nfs directorio\_local opciones} 
\end{tscreen}


La parte \var{volumen\_nfs} se especifica con la sintaxis
``\var{nodo\_remoto}\file{:}\var{directorio\_remoto}''. Dado que esta
notaci\'on es propia del NFS, la opci\'on \option{-t nfs} resulta redundante.


\index{fstab@\file{fstab}}
\index{fstab@\file{fstab}}
Hay otras opciones que pueden incluirse en el programa \prog{mount},
que van tras el modificador \option{-o} en la l\'{\i}nea de comando o en el
campo de opciones de la entrada correspondiente en el fichero
\file{/etc/fstab}. En ambos casos, las distintas opciones deben
separarse por comas. Las opciones que se especifiquen en la l\'{\i}nea de
comandos tendr\'an preferencia sobre otras que se indiquen en
\file{/etc/fstab}.


Una entrada de ejemplo del fichero \file{/etc/fstab} podr\'{\i}a ser

\begin{tscreen}
\begin{verbatim}
# volumen             directorio        tipo  opciones
news:/usr/spool/news  /usr/spool/news   nfs   timeo=14,intr
\end{verbatim}
\end{tscreen}


Ahora el volumen anterior puede montarse con la orden

\begin{tscreen}
\# mount news:/usr/spool/news
\end{tscreen}

Ante la ausencia de una entrada en \file{fstab}, las llamadas al
programa \prog{mount} se hacen m\'as inc\'omodas. Por ejemplo, puede que
tenga que teclear cosas como \'esta, para especificar que se limite el
tama\~no del datagrama a 2 Kb:


\begin{tscreen}
\# mount moonshot:/home /home -o rsize=2048,wsize=2048
\end{tscreen}


\index{NFS!restricciones del tama\~no del bloque}
La lista de todas las opciones v\'alidas para \prog{mount} se encuentra
descrita en la p\'agina de ayuda \file{nfs(5)} que viene con la utilidad
de montaje de Rick Sladkey, que forma parte del paquete
\file{util-linux} de Rik Faith. Las opciones m\'as interesantes son las
siguientes:

\begin{dispitems}
 \ditem[\keyword{rsize=}\var{n} y \keyword{wsize=}\var{n}]
        Especifican el tama\~no de datagrama utilizado por el cliente
NFS en las peticiones de lectura y escritura, respectivamente. Por
defecto, cada una de ellas vale 1024 octetos, dados los l\'{\i}mites del
tama\~no de datagrama UDP ya comentados.

 \ditem[\keyword{timeo=}\var{n}]
        Esta opci\'on establece el tiempo m\'aximo de espera de respuesta
a una petici\'on del cliente NFS; en cent\'esimas de segundo. Por defecto,
este valor es de 0.7 segundos.

 \ditem[\keyword{hard}]
        Marca el montaje del volume como f\'{\i}sico. Es un valor por defecto.

 \ditem[\keyword{soft}]
        Hace que el montaje sea s\'olo l\'ogico (opuesto al anterior).

 \ditem[\keyword{intr}]
        Esta opci\'on habilita la posibilidad de que una se\~nal
interrumpa una espera por NFS. Es \'util para poder abortarla cuando el
servidor no responde.

\end{dispitems}



% Except for \keyword{rsize} and \keyword{wsize}, all of these options
% apply to the client's behavior if the server should become inaccessible
% temporarily. They play together in the following way: whenever the
% client sends a request to the NFS server, it expects the operation to
% have finished after a given interval (specified in the \keyword{timeout}
% option). If no confirmation is received within this time, a so-called
% \emph{minor timeout} occurs, and the operation is retried with the
% timeout interval doubled. After reaching a maximum timeout of 60
% seconds, a \emph{major timeout} occurs.
% Traduccion parcial:

Cuando el cliente realiza una petici\'on al servidor NFS, esperar\'a un
tiempo m\'aximo (el que se especifica en la opci\'on
\keyword{timeout}). Si no hay confirmaci\'on tras ese tiempo (tiempo que
se denomina ``de expiraci\'on'' o {\it timeout}) tiene lugar otra
espera, ``de expiraci\'on secundaria'' o {\it minor timeout}, en el que la
operaci\'on se reintenta pero doblando el tiempo de expiraci\'on
inicial. Tras 60 segundos, se retorna a la expiraci\'on principal o {\it
major timeout}.

\index{NFS!montaje f\'{\i}sico vs. montaje l\'ogico}
\index{NFS!timeout}
\index{NFS!expiraci\'on}
Por defecto, la expiraci\'on principal har\'a que el cliente
env\'{\i}e un mensaje a la consola y empiece de nuevo, con una
expiraci\'on del doble de tiempo. Potencialmente, esto podr\'{\i}a
mantenerse eternamente. En este caso se habla de montaje f\'{\i}sico o
{\it hard-mount}. La otra variedad,
el montaje l\'ogico o {\it soft-mount}, genera un mensaje de error de
E/S al proceso llamante cuando se produce la expiraci\'on principal. El
error no se propaga al proceso hasta que hace una nueva llamada a
\func{write(2)}, por lo que esto, junto con la pol\'{\i}tica de escritura
desde la cache, hace que no se sepa realmente si una operaci\'on de
escritura ha tenido \'exito o no, a menos que el volumen est\'e montado de
forma f\'{\i}sica.

En general, se recomienda el montaje f\'{\i}sico salvo en caso de tratarse
de informaci\'on no cr\'{\i}tica, como la de servidores de FTP o particiones
de noticias. En entornos cr\'{\i}ticos (por ejemplo, estaciones de trabajo
X con dependencia de servidores de aplicaciones X~Window) no debe
usarse el montaje l\'ogico a riesgo de perder las conexiones si en un
momento se satura o desactiva la red por alg\'un motivo. Una soluci\'on
alternativa a usar montajes f\'{\i}sicos es aumentar el valor de la opci\'on
\keyword{timeo}, o bien usar montajes f\'{\i}sicos pero permitiendo el
env\'{\i}o de se\~nales para interrumpir las esperas en caso de necesidad.

% Lo anterior es traduccion/interpretacion libre de:
%Whether you hard- or soft-mount a volume is not simply a question of
%taste, but also has to do with what sort of information you want to
%access from this volume. For example, if you mount your X~programs by
%NFS, you certainly would not want your X~session to go berserk just
%because someone brought the network to a grinding halt by firing up
%seven copies of \prog{xv} at the same time, or by pulling the Ethernet
%plug for a moment.  By hard-mounting these, you make sure that your
%computer will wait until it is able to re-establish contact with your
%NFS-server.  On the other hand, non-critical data such as NFS-mounted
%news partititons or FTP archives may as well be soft-mounted, so it
%doesn't hang your session in case the remote machine should be
%temporarily unreachable, or down. If your network connection to the
%server is flakey or goes through a loaded router, you may either
%increase the initial timeout using the \keyword{timeo} option, or
%hard-mount the volumes, but allow for signals interrupting the NFS call
%so that you may still abort any hanging file access.


Normalmente, el demonio \prog{mountd} llevar\'a de alguna forma un
registro de qu\'e directorios est\'an montados desde qu\'e m\'aquinas. El
programa \prog{showmount}, incluido en el paquete de aplicaciones NFS,
permite consultar esta informaci\'on. De todas formas, el \prog{mountd}
de \linux{} aun no lleva estos registros.




\section{Demonios de NFS}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{nfs.daemons}
\index{NFS!servidor}
\index{rc.inet@\file{rc.inet}}
\index{mountd@\prog{mountd}}
\index{nfsd@\prog{nfsd}}

Si desea proporcionar un servicio NFS a otras m\'aquinas, deber\'a
ejecutar en el servidor los programas \prog{nfsd} y
\prog{mountd}. Son programas basados en RPC, por lo que no son
arrancados desde el \prog{inetd}, sino lanzados como demonios en
tiempo de arranque, y registrados en el mapeador de puertos de
RPC. Por lo tanto, debe
asegurarse que previamente ha sido lanzado el programa
\prog{rpc.portmap}. Normalmente, esto implica las siguientes l\'{\i}neas en
los {\it scripts} de arranque \file{rc}:


\begin{tscreen}
\begin{verbatim}
if [ -x /usr/sbin/rpc.mountd ]; then
        /usr/sbin/rpc.mountd; echo -n " mountd"
fi
if [ -x /usr/sbin/rpc.nfsd ]; then
        /usr/sbin/rpc.nfsd; echo -n " nfsd"
fi
\end{verbatim}
\end{tscreen}


\index{NFS!comprobaci\'on de uids y gids}
La informaci\'on de propiedad de los ficheros que un servidor NFS
proporciona a sus clientes viene dada en valores num\'ericos de
identificador de usuario ({\it uid}) y de grupo ({\it gid}). Por lo
tanto, esto resultar\'a \'util si clientes y servidores tienen el mismo
mapa de usuarios y grupos, lo que sucede cuando dicho mapa se obtiene
en todos los nodos desde un servidor NIS central.

Sin embargo, hay veces que esto no sucede. En lugar de actualizar los
uids y gids del cliente para ponerse de acuerdo con los del servidor,
puede usarse el demonio \prog{ugidd} para hacer este
trabajo. Utilizando la opci\'on \keyword{map\_daemon} explicada despu\'es,
se indicar\'a a \prog{nfsd} que establezca una correspondencia entre
uid/gid del servidor y del cliente, con la ayuda, en el cliente, de
\prog{ugidd}.

\prog{ugidd} es un servidor basado en RPC, y se inicia tambi\'en en
los scripts \file{rc}, con una l\'{\i}nea:


\begin{tscreen}
\begin{verbatim}
if [ -x /usr/sbin/rpc.ugidd ]; then
        /usr/sbin/rpc.ugidd; echo -n " ugidd"
fi
\end{verbatim}
\end{tscreen}



\section{El fichero \file{exports}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{nfs.exports}
\index{NFS!exportar un volumen}
\index{NFS!exports@\file{exports}}
\index{exportar un volumen NFS}
\index{acceso!concesi\'on}
\index{mountd@\prog{mountd}}
\index{exports@\file{exports}}

Mientras que las opciones anteriores se aplican a la configuraci\'on del
cliente NFS, hay otras opciones que se aplican al servidor, que
afectan a su relaci\'on con cada posible cliente. Estas opciones se
incluyen en el fichero de sistemas exportados \file{/etc/exports}.


Por defecto, \prog{mountd} no permitir\'a a nadie montar directorios de
su m\'aquina. Para permitir que alg\'un nodo monte un directorio, \'este
debe estar \emph{exportado}, es decir, especificado en el fichero de
exportaci\'on. Un ejemplo de dicho fichero es el siguiente:


\begin{tscreen}
\begin{verbatim}
# Fichero de exportacion para vlager (/etc/exports)
/home             vale(rw) vstout(rw) vlight(rw)
/usr/X386         vale(ro) vstout(ro) vlight(ro)
/usr/TeX          vale(ro) vstout(ro) vlight(ro)
/                 vale(rw,no_root_squash)
/home/ftp         (ro)
\end{verbatim}
\end{tscreen}


Cada l\'{\i}nea define un directorio, y la lista de m\'aquinas que pueden
acceder a \'el por NFS. Un nombre de m\'aquina puede especificarse con su
nombre internet completo, aunque tambi\'en se permite el uso de los
comodines \keyword{*} y \keyword{?}, que se interpretan como en el
shell de Bourne. Por ejemplo, \host{lab*.prueba.com} encaja con cualquier
nodo con nombre similar a \host{laboratorio.prueba.com} o
\host{lab12.prueba.com}, etc. Cuando en una l\'{\i}nea de \file{/etc/exports}
no se indique el nombre del nodo, se asume que cualquier m\'aquina podr\'a
montar el directorio (as\'{\i} sucede en nuestro ejemplo con \file{/home/ftp}).


\prog{mountd} usa la llamada \func{gethostbyaddr(2)} para comprobar si
el cliente demandante tiene un nombre de los que aparecen en
\file{/etc/exports}. Con DNS, la llamada retorna el nombre can\'onico
con lo que debe evitar usar nombres de alias en el fichero de
exportaci\'on\footnote{Ver cap\'{\i}tulo~\ref{resolv}}. Si no usa DNS, el
nombre devuelto por la llamada anterior
ser\'a el primer nombre que coincida con el IP del demandante, en el
fichero \file{/etc/hosts}.


Tras el nombre del nodo autorizado, se puede encerrar entre par\'entesis
un conjunto de opciones separadas por comas. Dichas opciones son:


\begin{dispitems}
\ditem[\keyword{insecure}]
        Permitir acceso no autentificado desde ese nodo.

\ditem[\keyword{unix-rpc}]
        Requerir autentificaci\'on RPC del dominio Unix para este
nodo. Se trata simplemente de que las peticiones se originen en un
puerto reservado (es decir, inferior al 1024). Esta opci\'on est\'a activa
por defecto.

%% Not implemented:
\ditem[\keyword{secure-rpc}]
        Requerir autentificaci\'on RPC segura para este nodo. A\'un no
est\'a implementado. Se sugiere ver la documentaci\'on de Sun al respecto
(v\'ease, ``Secure RPC'').

\ditem[\keyword{kerberos}]
        Requerir autentificaci\'on Kerberos. Tampoco se ha implementado
a\'un. Se sugiere consultar la documentaci\'on del MIT.

\ditem[\keyword{root\_squash}]
        \index{restringir acceso del superusuario@restringir acceso al
usuario \user{root}}
        \index{acceso!restricci\'on}
        Se trata de una opci\'on de seguridad que deniega acceso a
nivel de superusuario, traduciendo el identificador uid recibido (0)
al del usuario \user{nobody}. Es decir, cualquier petici\'on NFS
del usuario \user{root} ser\'a tomada como si fuera del usuario
\user{nobody}.
% VERSION ANTIGUA:
%        Se trata de una opci\'on de seguridad que deniega acceso a
% ficheros del superusuario a las peticiones con uid 0 o 65534 (-2)
% (este \'ultimo se suele asociar al usuario \user{nobody}).

\ditem[\keyword{no\_root\_squash}]
        Evita la restricci\'on anterior. Es una opci\'on por defecto.

\ditem[\keyword{ro}]
        \index{montaje!solo lectura}
        \index{volumen NFS de solo lectura}
        \index{NFS!volumen de solo lectura}
        Monta la jerarqu\'{\i}a de ficheros en modo de s\'olo
lectura. Es una opci\'on por defecto.

\ditem[\keyword{rw}]
        Monta el directorio con permiso para leer y escribir en \'el.

\ditem[\keyword{link\_relative}]
        Convierte enlaces simb\'olicos absolutos (que empiezan con una
barra de directorio, ``/'') en enlaces relativos colocando los
prefijos ``\file{../}'' que sean necesarios para hacer que apunten a la
ra\'{\i}z del servidor. Esta opci\'on s\'olo tiene sentido cuando se monta
un sistema de ficheros completo y no s\'olo un directorio. As\'{\i}, si
montamos dicho sistema bajo \file{/mnt} y existe en \file{/mnt/sub} un
enlace \file{fichero $\rightarrow$ /tmp/fichero} se convertir\'a a
\file{fichero $\rightarrow$ ../tmp/fichero} logrando as\'{\i} que el
enlace sirva para algo. 

        Es una opci\'on activa por defecto.

\ditem[\keyword{link\_absolute}]
        Deja los enlaces absolutos como estaban (es la opci\'on habitual
en servidores NFS de Sun).

\ditem[\keyword{map\_identity}]
        \index{NFS!comparaci\'on de uids y gids}
        La opci\'on \keyword{map\_identity} indica al servidor que asuma
que el cliente utiliza el mismo mapa de uids y gids que el
servidor. Es una opci\'on por defecto.

\ditem[\keyword{map\_daemon}]
        Esta opci\'on indica al servidor NFS que no comparte el mapa de
usuarios con el del cliente. Con ello, las comparaciones de uids y
gids se har\'an mediante una lista de mapeado entre ambos que se
construir\'a llamando al demonio \prog{ugidd} del cliente.

\end{dispitems}


\index{syslog@\prog{syslog}}
Cualquier error analizando el fichero de exportaciones durante el
arranque del servidor \prog{nfsd} o \prog{mountd} ser\'a enviado a nivel
de notificaci\'on (\keyword{notice}) al registro del sistema (\prog{syslogd}).


Obs\'ervese que los nombres de los nodos se obtienen a partir de las
direcciones~IP mediante resoluci\'on inversa, con lo que el sistema de
resoluci\'on deber\'a tener una adecuada configuraci\'on en este punto. Si
utiliza BIND y la seguridad le preocupa especialmente, deber\'a activar
chequeo de nombres falsos ({\it spoofing}) en el fichero \file{host.conf}.



\section{El sistema de automontado en \linux{}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{nfs.automounter}
\index{NFS!automountado}
\index{montaje!autom\'atico}
\index{automontado}
\index{amd@\prog{amd}}

A veces es ineficiente mantener montados todos los vol\'umenes NFS de
uso potencial. Una alternativa es usar un demonio de
\emph{automontado}. Se trata de un demonio que autom\'aticamente monta
los vol\'umenes cuando se necesitan y los desmonta tras un tiempo de
inactividad. Adem\'as, sirve para poder montar los mismos ficheros de un
lugar diferente. Por ejemplo, puede mantener varias copias de las
utilidades de X~Window y a la hora de ser necesitadas, intentar montar
cada copia hasta conseguirlo.


% At startup,
% it reads some so-called \emph{map files} that specify directory
% access points, along with the NFS volumes to be mounted on them.
% The automounter monitors these directories, and whenever an attempt is
% made to access one of them, or a file below, it mounts the corresponding
% NFS volume.


El programa de automontado para \linux{} se llama \prog{amd}. Ha sido
escrito inicialmente por Jan-Simon Pendry para luego encargarse Rick
Sladkey de portarlo a \linux{}. La versi\'on actual es la {\it 5.3}.


Explicar el uso de \prog{amd} excede los objetivos de este
cap\'{\i}tulo. El mejor manual se encuentra en las fuentes: un fichero {\it
texinfo} con informaci\'on muy detallada.


\index{NFS|)}
