NFS, acrónimo de Network File System, que nosotros llamaremos Sistema de Ficheros en Red, es probablemente el servicio más 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úcleo (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:

El NFS de Linux es, principalmente, obra de Rick Sladkey,1, pues escribió el código que corresponde al núcleo y buena parte del código del servidor NFS. Este último es una modificación del servidor unfsd que corre en espacio de usuario, escrito originalmente por Mark Shand, y el servidor hnfs (Harris NFS) escrito por Donald Becker.

_____________________________________________
1 Puede contactar con Rick en la dirección jrs@world.std.com

Veamos ahora un poco como funciona NFS: un cliente puede solicitar montar un directorio desde un servidor remoto, de forma similar a como montaría un directorio local. Sin embargo, la sintaxis no es exactamente igual. Por ejemplo, para montar el directorio /home del nodo vlager en el directorio /users de vale, el administrador escribiría el siguiente comando en vale:2

mount intentará conectar con el demonio remoto mountd mediante RPC. El servidor comprobará si la máquina vale tiene permiso para montar el directorio pedido, y si es así retornará un descriptor de fichero. Este descriptor se utilizará en todas las peticiones que sobre ficheros de /users se realicen posteriormente.

Cuando alguien accede a un fichero remoto, el núcleo manda una llamada RPC al programa 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áquina remota, con lo que los usuarios de ambas máquinas deberían ser los mismos.

En varias implementaciones de UNIX, las funcionalidades de cliente y servidor NFS se realizan como demonios de nivel de núcleo que se arrancan desde el espacio de usuario al arrancar la máquina. Se trata del programa nfsd en el servidor y del programa biod (Block I/O Daemon, o demonio de E/S3 por bloques) en el cliente. Para aumentar el rendimiento, biod realiza E/S asíncrona, y a veces corren concurrentemente varios servidores de NFS.

La implementación de NFS en Linux es algo diferente: el código de cliente está integrado en la capa de sistema de ficheros virtual (VFS) y no requiere control adicional mediante el programa biod. Por otro lado, el código de servidor corre totalmente en el espacio de usuario, por lo que ejecutar varias copias del nfsd resulta imposible debido a los problemas de sincronización que originaría.

El mayor problema con el código NFS de Linux es que el núcleo 1.0 no puede manejar bloques de memoria de mas de 4Kb, por lo que el código de red no puede manejar datagramas de un tamaño 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 perdidas de rendimiento en ciertas circunstancias.4 Esta limitación desapareció en los núcleos posteriores al 1.1, reescribiéndose el código del cliente para aprovechar la nueva situación.

_____________________________________________
2 Observar que puede omitirse la opción -t nfs, ya que el programa mount sabe por la aparición de los dos puntos (:) que se trata de un sistema NFS.
3 N. del T.: E/S es Entrada/Salida
4 Como me explicó Alan Cox: La especificación de NFS requiere que el servidor guarde cada escritura en disco antes de retornar un reconocimiento al cliente (ACK). Como los núcleos de BSD solo manejan

Antes de usar NFS, sea en cliente o servidor, debe asegurarse de que el núcleo tiene el soporte incluido. Los núcleos modernos informan de ello a través del sistema /proc, con un comando como el siguiente:

Si no aparece la palabra nfs, tendrá que recompilar el núcleo con el soporte NFS habilitado. Sobre como configurar el núcleo hablamos en la sección "Configuración del Núcleo" del capítulo 3.

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

Si el comando mount falla con el mensaje "fs type nfs no supported by kernel" (sistema tipo NFS no soportado por el núcleo), deberá recompilar el núcleo habilitando NFS. Otro tipo de errores no implican recompilar el núcleo, ya que se producen al no estar corriendo el programa nfsd.

Los volúmenes NFS5 se montan como los sistemas de ficheros usuales. Se trata de llamar al comando mount con la sintaxis:

_____________________________________________

5 Hablamos de volúmenes, y no de sistemas de ficheros, porque no lo son realmente: pueden ser solo directorios de un sistema.

La parte volumen_nfs se especifica con la sintaxis "nodo_remoto :directorio_remoto".

Dado que esta notación es propia del NFS, la opción -t nfs resulta redundante.

Hay otras opciones que pueden incluirse en el programa mount, que van tras el modificador -o en la línea de comando o en el campo de opciones de la entrada correspondiente en el fichero /etc/fstab. En ambos casos, las distintas opciones deben separarse por comas.

Las opciones que se especifiquen en la línea de comandos tendrán preferencia sobre otras que se indiquen en /etc/fstab.

Una entrada de ejemplo del fichero /etc/fstab podría ser

Ahora el volumen anterior puede montarse con la orden

Ante la ausencia de una entrada en fstab, las llamadas al programa mount se hacen más incómodas. Por ejemplo, puede que tenga que teclear cosas como ésta, para especificar que se limite el tamaño del datagrama a 2 Kb:

La lista de todas las opciones válidas para mount se encuentra descrita en la página de ayuda nfs(5) que viene con la utilidad de montaje de Rick Sladkey, que forma parte del paquete util-linux de Rik Faith. Las opciones más interesantes son las siguientes:

Cuando el cliente realiza una petición al servidor NFS, esperará un tiempo máximo (el que se especifica en la opción timeout). Si no hay confirmación tras ese tiempo (tiempo que se denomina "de expiración" o timeout) tiene lugar otra espera, "de expiración secundaria" o minor timeout, en el que la operación se reintenta pero doblando el tiempo de expiración inicial. Tras 60 segundos, se retorna a la expiración principal o major timeout.

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

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

Normalmente, el demonio mountd llevará de alguna forma un registro de que directorios están montados desde que máquinas. El programa showmount, incluido en el paquete de aplicaciones NFS, permite consultar esta información. De todas formas, el mountd de Linux aun no lleva estos registros.

Si desea proporcionar un servicio NFS a otras máquinas, deberá ejecutar en el servidor los programas nfsd y mountd. Son programas basados en RPC, por lo que no son arrancados desde el 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 rpc.portmap. Normalmente, esto implica las siguientes líneas en los scripts de arranque rc:

La información de propiedad de los ficheros que un servidor NFS proporciona a sus clientes viene dada en valores numéricos de identificador de usuario (uid) y de grupo (gid).

Por lo tanto, esto resultará útil 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 ugidd para hacer este trabajo. Utilizando la opción map_daemon explicada después, se indicará a nfsd que establezca una correspondencia entre uid/gid del servidor y del cliente, con la ayuda, en el cliente, de ugidd.

ugidd es un servidor basado en RPC, y se inicia también en los scripts rc, con una línea:

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

Por defecto, mountd no permitirá a nadie montar directorios de su máquina. Para permitir que algún nodo monte un directorio, éste debe estar exportado, es decir, especificado en el fichero de exportación. Un ejemplo de dicho fichero es el siguiente:

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

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

_____________________________________________
6 Ver capítulo 6

Cualquier error analizando el fichero de exportaciones durante el arranque del servidor nfsd o mountd será enviado a nivel de notificación (notice) al registro del sistema (syslogd).

Obsérvese que los nombres de los nodos se obtienen a partir de las direcciones IP mediante resolución inversa, con lo que el sistema de resolución deberá tener una adecuada configuración en este punto. Si utiliza BIND y la seguridad le preocupa especialmente, deberá activar chequeo de nombres falsos (spoofing) en el fichero host.conf.

A veces es ineficiente mantener montados todos los volúmenes NFS de uso potencial. Una alternativa es usar un demonio de automontado. Se trata de un demonio que automáticamente monta los volúmenes cuando se necesitan y los desmonta tras un tiempo de inactividad.

Además, 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.

El programa de automontado para Linux se llama amd. Ha sido escrito inicialmente por Jan-Simon Pendry para luego encargarse Rick Sladkey de portarlo a Linux. La versión actual es la 5.3.

Explicar el uso de amd excede los objetivos de este capítulo. El mejor manual se encuentra en las fuentes: un fichero texinfo con información muy detallada.