El Sistema de Archivos de Red 16
El Sistema de Archivos de Red, también conocido como NFS, permite que dos orde- nadores compartan sistemas de archivos. NFS prácticamente es transparente para los usuarios y no pierde información cuando falla un servidor. Los clientes esperarán a que el servidor se recupere y continúe con su trabajo, como si nada hubiese pasado.
NFS lo presentó Sun Microsystems en 1985. Originalmente se implementó como una prolongación de los sistemas de archivos para los clientes que no tenían unidades de disco. Pero el protocolo demostró que estaba muy bien diseñado y que era una solu- ción excelente cuando había que compartir archivos. De hecho, es difícil imaginar cómo era la vida antes de la aparición de NFS. Todas las distribuciones completas de Linux pueden trabajar con él.
Información general sobre NFS
En la actualidad, NSF sólo se utiliza para compartir archivos entre sistemas Linux y UNIX. Los clientes de Windows deberían utilizar CFIS/Samba. (Los veremos al final del libro.) NFS cuenta con varios componentes, incluyendo un protocolo para montar elementos, un servidor de montaje, demonios encargados de coordinar el servicio de archivos básico y varias utilidades de diagnosis. Una parte del software reside en el kernel.
Sin embargo, estas partes del sistema NFS no necesitan ninguna configuración y, desde el punto de vista del administrador, son completamente transparentes.
Versiones del protocolo en NFS
El protocolo NFS ha permanecido estable a lo largo de todo este tiempo. La primera versión que se publicó fue NFS 2. A principios de la década de los 90, una serie de cambios generaron la versión 3, que mejoró el rendimiento y su capacidad para trabajar con archivos grandes. Ahora, tenemos a nuestra disposición las primeras implementacio- nes de la versión 4. Esta última versión incluye muchas mejoras que iremos viendo a lo largo del capítulo.
Como los clientes de NFS 2 no pueden asumir que una operación de escritura esté completa hasta que reciben la confirmación del servidor, los servidores de esta versión deberán modificar los bloques del disco antes de contestar a los clientes. Así evitarán que haya discrepancias en el caso de que falle el sistema.
Esta limitación representa un retraso importante en el proceso de escritura del sis- tema NFS ya que los bloques que se modifican tan sólo se pueden escribir en el búfer de entrada de la memoria caché.
La versión 3 de NFS elimina este cuello de botella utilizando un sistema coherente que permite realizar escrituras asíncronas. También actualiza otros aspectos del proto- colo que causaban ciertos problemas en su rendimiento. El resultado final es que la red de la versión 3 es algo más rápida que la de la versión 2. El software de la versión 3 puede trabajar con el software de la versión 2, aunque no siempre le guste tener que tra- bajar con protocolos anteriores.
NFS 4 es cada vez más estable y ya se incluye en algunas versiones de Linux. Nece- sita un kernel 2.6.1, o superior, y se ha de activar manualmente desde el kernel. Entre las propiedades que se han mejorado se incluyen las siguientes:
• Compatibilidad y capacidad para trabajar con firewalls así como los dispositi- vos NAT.
• Integración con los protocolos de montaje y bloqueo del núcleo de NFS.
• Operaciones de estado.
• Un sistema de seguridad integrado y robusto.
• Capacidad para trabajar con réplicas y migración de datos.
• Capacidad para trabajar con clientes Unix y Windows.
• Listas para el control de acceso.
• Capacidad para trabajar con los nombres de archivos Unicode.
• Buen rendimiento incluso con conexiones con poco ancho de banda.
Si desea más información sobre el estado de NFS 4 en Linux, y quiere conocer las últimas versiones de software publicadas, consulte nfs.sourceforge.net.
Como la versión 4 de NFS aún se está desarrollando, no la vamos a ver con detalle en este capítulo. Pero no lo pierda de vista. Muchas de las propiedades que se están pla- nificando ahora representan soluciones para los problemas de NFS. Esperemos que la versión 4 sea lo suficientemente longeva para que todas estas especificaciones prometi- das lleguen a ver la luz.
Una opción de transporte
NFS se ejecuta encima del protocolo RPC (Remote Procedure Call) de Sun. Este he- cho define un sistema para comunicarse a través de la red independiente del sistema.
Uno de los efectos secundarios positivos de esta arquitectura es que permite el uso de UDP o de TCP como protocolo de transporte.
Originalmente, NFS utilizaba UDP porque era el protocolo que mejor funcionaba sobre las redes LAN existentes en la década de los 80. Aunque NFS cuenta con su pro- pio sistema de comprobación de errores y sistema de reensamblamiento para las secuen- cias de paquetes, tanto UDP como el propio NFS, no tienen algoritmos para el control de la congestión del tráfico que tan bien están funcionando en las grandes redes IP.
Para solucionar estos problemas, todos los sistemas modernos nos permitirán utili- zar TCP en vez de UDP como protocolos de transporte del sistema NFS. La primera vez que se utilizó esta opción fue para buscar un sistema que ayudase a NFS a través de los routers y a través de Internet. Sin embargo, parece que hay consenso que determina que TCP es la mejor opción para controlar el tráfico local de NFS. Con el paso del tiempo, la mayoría de las razones que inicialmente daban su apoyo a UDP se han ido evaporando a favor de TCP. Y es que ahora nos encontramos con unas CPU muy rápidas, con unos módulos de memoria muy baratos y con unos sistemas inteligentes capaces de controlar las redes. A partir de la versión 2.4 del kernel de Linux, NFS puede trabajar con TCP.
La mayoría de los servidores que admiten TCP suelen aceptar conexiones con cual- quier modo de transporte, por lo que será el cliente quien determinará si utilizará TCP o UDP. El cliente especificará su preferencia como una opción del comando mount o a través de un archivo de configuración como /etc/fstab.
El bloqueo de archivos
La capacidad para bloquear archivos (que se implementó a través de las llamadas de sistema flock, lockf y/o fcntl) ha sido uno de los puntos débiles de los sistemas Unix durante mucho tiempo. En los sistemas de archivos locales, su funcionamiento ha distado mucho de ser perfecto. En el contexto de NFS, aún no podemos decir que nos movamos sobre un terreno firme. Por diseño, los servidores NFS carecen de estado: no saben qué ordenadores están utilizando un archivo en particular. Sin embargo, esta in- formación es necesaria para poder bloquearlo. ¿Cómo se puede hacer? La respuesta tra- dicional ha sido implementar un sistema para el bloqueo de archivos independiente de NFS. La mayoría de los sistemas proporcionan dos demonios, lockd y statd, que se encargan de hacerlo. Desgraciadamente, esta tarea es difícil por muchas razones, por lo que el sistema para bloquear archivos de NFS no ha sido muy consistente.
Límites de disco
Acceder a la información sobre la capacidad de un disco remoto se puede conseguir con un servidor como rquotad. Los servidores NFS, cuando el sistema de archivos con el que trabajan se lo permite, obligan a trabajar con limitaciones en los discos, aun- que los usuarios no puedan ver esta información. Sólo podrán acceder a ella cuando se ejecute rquotad en el servidor remoto.
En nuestra opinión, los límites de disco hace mucho tiempo que quedaron obsoletos.
Sin embargo, algunas organizaciones aún dependen de ellos para evitar que sus usua- rios se apoderen de todo el espacio de disco disponible. Si trabaja dando soporte a una de estas organizaciones, conviene que consulte la documentación sobre los límites de los discos que se suministra con su distribución de Linux. Nosotros no lo vamos a ver más.
Las cookies y los montajes sin estado
Antes de poder utilizar un sistema de archivos NFS, un cliente tendrá que montarlo del mismo modo que lo hace con los sistemas de archivos de su disco duro local. Sin embargo, como NFS no tiene estado, el servidor no guardará un registro con los clien- tes que han montado el sistema de archivos. En vez de eso, el servidor se limita a revelar una cookie secreta cuando se completa la negociación sobre el proceso de montaje. La cookie identifica el directorio que se ha montado en el servidor NFS y proporciona un sistema para que el cliente pueda acceder a su contenido.
Cuando se desmonta y se vuelve a montar un sistema de archivos en el servidor, lo normal es que se cambie su cookie. Como caso especial, las cookies se conservan después de iniciar un servidor que se ha caíd y ha tenido que recuperar su estado. Pero no inten- te revisar el sistema como un usuario, jugar con los sistemas de archivos y luego volver a revisar el sistema. Este proceso elimina las cookies y hace que los clientes no puedan acceder a los sistemas de archivos que han montado hasta que vuelvan a reiniciar o mon- tar sus máquinas.
Una vez que un cliente tiene una cookie, utiliza el protocolo RPC para solicitar ope- raciones relacionadas con el sistema de archivos, como crear un archivo o leer un blo- que de datos. Como NFS es un protocolo sin estado, el cliente será el responsable de asegurarse de que el servidor acepte las peticiones de escritura antes de borrar su propia copia de los datos que se han de escribir.
Convenciones de nombres para los sistemas de archivos compartidos
Cuando el sistema de nombres que utilizamos con los montajes incluye nombres para cada uno de los servidores remotos (como, por ejemplo, /anchor/tools para los sistemas de archivos que se encuentran en el ordenador anchor), la gestión del sistema NFS es muy sencilla.
Estos nombres son de gran utilidad porque permiten que los usuarios traduzcan mensajes como "anchor estará apagado el sábado para actualizar su software" a una in- formación más útil como "no podré utilizar /anchor/tools/TeX el sábado para ter- minar mi tesis, así que lo mejor que puede hacer es ir al campo".
Desgraciadamente, este sistema requiere que el directorio /anchor exista en el di- rectorio raíz de todas las máquinas clientes. Si un cliente obtiene los sistemas de archivos de varias máquinas, nos podemos encontrar con que el root pueda llegar a desordenarse.
Considere utilizar un sistema de jerarquías muy profundo (como, por ejemplo, /home/
anchor, /home/rastadon, etc.). Le aconsejamos que utilice este tipo de sistemas con un demonio especializado en efectuar montajes automáticamente, como se verá dentro de unas cuantas secciones.
Seguridad y NFS
NFS proporciona un sistema muy interesante para acceder a los archivos de una red.
Precisamente por eso, se convierte en un peligro potencial para su seguridad. En mu- chos aspectos, la versión 3 de NFS ha sido un representante perfecto de todo lo que ha fallado en la seguridad de Unix y Linux. El protocolo se diseñó originalmente sin tener en cuenta a los sistemas de seguridad (premiaba más su precio). Afortunadamente, Linux puede trabajar con una gran cantidad de propiedades que reducen y aíslan los proble- mas de seguridad que ha sufrido tradicionalmente NFS.
El acceso a los volúmenes NFS lo garantiza un archivo llamado /etc/exports que enumera los nombres de los host (o sus direcciones IP) de los sistemas que deberían poder acceder al sistema de archivos del servidor. Desgraciadamente, esto puede repre- sentar un fallo en la seguridad porque el servidor confiará en todos aquellos clientes que se identifiquen. Y ya sabemos lo fácil que es conseguir que un cliente mienta sobre su identidad. Por eso, este mecanismo no es de gran confianza. Independientemente, debe- remos recordar que tan sólo exportaremos sistemas de archivos a los clientes en los que confiemos, y que siempre deberemos comprobar que no hayamos exportado accidental- mente un sistema de archivos a todo el mundo exterior.
Siempre se ha de restringir firmemente el acceso a los puertos NFS. Afortunadamen- te, todas las versiones de Linux incluyen un firewall capaz de encargarse de esta tarea.
Al igual que ocurre con los sistemas de archivos locales, el control de acceso de cin- co niveles de los sistemas de archivos NFS se gestionará de acuerdo con los permisos de los archivos y con los identificadores UID y GID. Pero una vez más, el servidor de NFS se fiará de aquellos clientes que se identifiquen. Si los ordenadores Juan y Pepe com- parten el mismo identificador UID en dos ordenadores distintos, podrán acceder a los archivos NFS del otro. Además, los usuarios que tengan un acceso root a un sistema podrán cambiar cualquier identificador UID que quieran. Y es que el servidor les ga- rantizará el acceso a los archivos. Por estas razones, le aconsejamos encarecidamente que utilice identificadores UID únicos, junto con la opción root_squash que vere- mos en la siguiente sección.
Una institución educativa muy grande que conocemos apoyaba la idea de no utilizar esta opción. Como resultado de esta política, se encontraron con que cinco de sus prin- cipales servidores, y hasta 60 estaciones de trabajo, vieron comprometida su seguridad.
Su gente de sistemas tuvo que trabajar todo un fin de semana para contener el incidente y volver a levantar las máquinas.
Si su sistema cuenta con un firewall de red, será conveniente que bloquee el acceso a los puertos 2049 UDP y TCP, que son los que utilizan el sistema NFS. También debe- ría bloquear el acceso al demonio portmap que suele escuchar todo el tráfico que pasa por el puerto 111 de TCP y UDP. Aunque la siguiente afirmación está implícita dentro de estas precauciones, tenemos que recordar que no se debe exportar ningún sistema de archivos NFS a una máquina que no sea local, y mucho menos a un ordenador que se encuentra conectado en algún punto de Internet.
El acceso root y la cuenta nobody
Aunque generalmente todos los usuarios tendrán los mismos privilegios, tradicio- nalmente se ha evitado que la cuenta root se ejecute en los sistemas de archivos NFS.
Por defecto, el servidor NFS de Linux intercepta las peticiones entrantes que se generan con el identificador UID 0 y las modifica para que parezca que proceden de otro usua- rio. Esta modificación se la conoce como squashing root (algo así como "anular root").
No es que se anule la cuenta root, más bien se limita su capacidad y se la trata como un usuario corriente.
Se define una cuenta llamada "nobody" para que actúe como un pseudousuario que camuflará al usuario root remoto de un servidor NFS. Tradicionalmente, el identificador UID de nobody es 65534. Para cambiar las conversiones predeterminadas de los identifi- cadores UID y GID utilizaremos las opciones de exportación anonuid y anongid.
También podemos utilizar la opción all_squash para convertir todos los identifica- dores UID del cliente en el mismo UID del servidor. Esta configuración eliminará todas las distinciones existentes entre los usuarios y creará un tipo de sistema de archivos para el acceso público.
Por otro lado, tenemos la opción no_root_squash que desactiva la conversión de los identificadores UID del usuario root. A veces se tiene que utilizar esta opción para poder trabajar con clientes que no tienen unidad de disco duro o con software que tiene que acceder al sistema de archivos como usuario root. Pero, en general, no es una buena idea activar esta propiedad porque permitirá que todos los usuarios que tengan privilegios de administradores en un cliente modifiquen archivos que cuenten con un sistema de protección. En cualquier otro caso, la opción estará disponible.
La intención que se esconde detrás de todas estas precauciones es buena, pero su verdadero valor no es tan bueno como parece. Recuerde que un usuario root de un cliente NFS puede utilizar el comando su para asignarse el identificador UID que quiera, por lo que los archivos del usuario nunca estarán realmente protegidos. Los registros de sistemas como bin y sys no cuentan con el sistema de conversión UID, por lo que sus archivos (como los sistemas binarios o aplicaciones de terceros) pueden sufrir ataques.
El único efecto real de la conversión UID es evitar que se acceda a archivos que per- tenezcan al usuario root y que estén protegidos de lectura y escritura ante el resto de usuarios.
NFS del lado del servidor
Se dice que un servidor exporta un directorio cuando permite que lo utilicen otras máquinas. En la versión 3 de NFS, el proceso que utilizaban los clientes para montar un sistema de archivos (es decir, para conocer cuál era la cookie secreta) era indepen- diente del proceso que se utilizaba para acceder al archivo. Las operaciones utiliza- ban protocolos separados y las peticiones las atendían distintos demonios: mountd se encargaba del montaje y nfsd de servicios de archivo. En realidad, el verdadero nom- bre de estos demonios es rpc.nfsd y rpc.mountd, como recordatorio de que utiliza el protocolo RPC (y por lo tanto requieren que se esté ejecutando portmap). Nosotros vamos a omitir el prefijo rpc para mejorar su lectura.
En un servidor NFS, los demonios mountd y nfsd se deberían iniciar con el arran- que del sistema, y deberían permanecer ejecutándose siempre que sistema esté encendi- do. Si configuramos algún tipo de exportación, los scripts de arranque no se iniciarán automáticamente. La tabla 16.1 muestra los nombres de los scripts de arranque del ser- vidor NFS de las distintas distribuciones de Linux que estamos viendo en este libro.
Tabla 16.1. Scripts de arranque del servidor NFS.
Distribución Ruta de los scripts de arranque
Red Hat Enterprise /etc/rc.d/init.d/nfs
Fedora /etc/rc.d/init.d/nfs
SUSE /etc/init.d/nfsboot
Debian /etc/init.d/nfs-kernel-server
/etc/init.d/nfs-common
Ubuntu /etc/init.d/nfs-kernel-server
/etc/init.d/nfs-common
mountd y nfsd comparten una misma base de datos para el control de acceso que determinará qué sistemas de archivos se han de exportar y cuáles han de montar los clientes. La copia funcional de esta base de datos se guarda en un archivo que se llama /usr/lib/nfs/xtab, aparte de en las tablas internas del kernel. Como xtab no se ha diseñado para que lo lean los humanos, tendremos que utilizar un comando de ayuda (exportfs) para agregar entradas nuevas y modificar las ya existentes. Para eliminar entradas de la tabla de exportación tendremos que utilizar el comando exportfs -u.
En la mayoría de los sistemas, /etc/exports es la lista de todos los directores que se han exportado y tiene un formato que permite que lo pueda leer un humano. Por defecto, todos los sistemas de archivos de /etc/exports se exportarán durante el arranque del sistema. También podremos exportar manualmente todos los sistemas de archivos que aparezcan en la lista /etc/exports usando el comando exportfs -a.
Deberemos utilizar este comando después de modificar el archivo exports. También podemos exportar los sistemas de archivos especificando el cliente, la ruta y las opcio- nes directamente desde la línea de comandos, con exportfs.
El sistema NFS trabaja con la capa lógica del sistema de archivos. Se puede expor- tar cualquier directorio. No es necesario que tenga un punto de montaje o que sea la raíz de un sistema de archivos físico. Sin embargo, por razones de seguridad, NFS no pres- tará atención a los límites existentes entre los sistemas de archivos y requerirá que cada dispositivo se exporte por separado. Por ejemplo, en una máquina que tenga una parti- ción /users, podremos exportar el directorio raíz sin exportar /users.
Generalmente, siempre que los clientes lo deseen, podrán montar subdirectorios de un directorio que se ha exportado, aunque el protocolo no necesite. Por ejemplo, si un servidor exporta /chimchim/users, un cliente puede limitarse a montar /chim- chim/users/joe e ignorar el resto del directorio users. La mayoría de las versio- nes de UNIX no permiten exportar subdirectorios de un directorio que se haya exportado con diferentes opciones, pero Linux sí.
El archivo exports
El archivo /etc/exports enumera los sistemas de archivos que se han exportado a través de NFS y los clientes que pueden acceder a cada uno de ellos. Utiliza espacios en blanco para separar los sistemas de archivos de la lista de clientes, y a cada cliente le sigue una lista (que aparece entre paréntesis) con todas las opciones que han de usar.
Las opciones aparecerán separadas por comas. Las líneas pueden continuar con una ba- rra invertida. Éste es el aspecto que tiene el formato:
/home/boggs inura(rw,no_root_squash) lappie(rw) /usr/share/man *.toadranch.com(ro)
No hay ninguna forma de asignar un grupo de clientes a un mismo conjunto de op- ciones, aunque las especificaciones de algunos clientes hacen referencia a varios orde- nadores. La tabla 16.2 muestra los cuatro tipos de especificaciones para los clientes que pueden aparecer en los archivos de exportación.
Tabla 16.2. Especificaciones para el cliente del archivo /etc/exports.
Tipo Sintaxis Significado
Nombre del host hostname Host individuales.
Grupo de red @groupname Grupos de red NIS.
Comodines * y ? FQDN con comodines. "*" no puede compor- tarse como un punto.
Redes IP ipaddr/mask Especificaciones del estilo CIDR (por ejem- plo, 128.138.92.128/25).
La tabla 16.3 muestra las opciones que más se utilizan en la exportación.
Tabla 16.3. Opciones más comunes de la exportación.
Opción Descripción
ro Exporta con permisos sólo de lectura.
rw Exporta con permisos de lectura y escritura (opción prede- terminada).
rw=list Exporta casi todo con permisos sólo de lectura. list enu- mera los host que tendrán privilegios para montar con permi- sos de escritura. El resto de ordenadores sólo podrán montar con permisos de lectura.
root_squash Convierte UID 0 y GID 0 en aquellos valores que especifi- can anonuid y anongid. Es el comportamiento predeter- minado.
no_root_squash Permite que los usuarios normales accedan con los privile- gios del root. Es peligroso.
all_squash Convierte todos los identificadores UID y GID en sus versio- nes anónimas. Es muy útil para dar soporte a ordenadores y a host que no sean de confianza.
anonuid=xxx Especifica el UID que deberían de tener los root remotos.
anongid=xxx Especifica el GID que deberían de tener los root remotos.
Opción Descripción
secure Requerirá un acceso remoto para crear un puerto con privi- legios.
insecure Permite que se establezca un acceso remoto desde cual- quier puerto.
noaccess Evita que se pueda acceder a este directorio y a sus subdi- rectorios (se utiliza con las exportaciones anidadas).
wdelay Retrasa las escrituras esperando a que se agrupen varias actualizaciones.
no_wdelay Escribe los datos en el disco tan pronto como le es posible.
async Hace que el servidor repita las peticiones de escritura an- tes de proceder a guardar los datos en el disco.
nohide Muestra los sistemas de archivos que están montados den- tro de los árboles de directorios que se han exportado.
hide Contrario a nohide.
subtree_check Verifica que todos los archivos solicitados se encuentren dentro del árbol que se ha exportado.
no_subtree_check Se limita a comprobar que las peticiones de un archivo ha- cen referencia al sistema de archivos que se ha exportado.
secure_locks Solicita una autorización para todas aquellas consultas blo- queadas.
insecure_locks Especifica un criterio de bloqueo menos riguroso (puede trabajar con clientes antiguos).
auth_nlm Sinónimo de secure_locks.
no_auth_nlm Sinónimo de insecure_locks.
El servidor NFS de Linux tiene una propiedad un tanto particular: permite que los subdirectorios de los directorios que se han exportado tengan distintas opciones. Con la opción noaccess marcaremos subdirectorios como "no exportables" para que no se puedan compartir con otros usuarios.
Por ejemplo, la configuración
/home *.toadranch.com(rw)
/home/boggs (noaccess)
permite que los ordenadores que se encuentran en el dominio toadranch.com pue- dan acceder al contenido de /home a través del proceso de montaje. Al único sitio donde no podrán acceder será a /home/boggs. La ausencia de un nombre de un cliente en la segunda línea indica que la opción se aplicará a todos los host. Es posible que con este sistema tengamos una mayor seguridad.
La opción subtree_check (predeterminada) verifica que todos los archivos a los que ha accedido el cliente se encuentran dentro del subdirectorio que se ha exportado.
Si desactivamos esta opción, sólo se comprobará que el archivo se encuentra dentro del sistema de archivos que se ha exportado. La comprobación dentro del subárbol puede ocasionar problemas cuando se modifica el nombre del archivo que se ha solicitado mientas el cliente lo tiene abierto. Si estima que puede encontrarse con esta situación en más de una ocasión, considere utilizar la opción no_subtree_check.
La opción secure_locks necesitará una autorización y una autentificación con todos aquellos archivos que se hayan bloqueado. Algunos clientes NFS no envían sus credenciales con las consultas bloqueadas por lo que no pueden funcionar con la opción secure_locks. En estos casos, sólo podemos bloquear los archivos que tengan per- miso de lectura. Generalmente, la mejor solución será sustituir estos clientes por otros que puedan trabajar con credenciales. Sin embargo, siempre puede utilizar la opción insecure_locks como una solución de emergencia.
No se olvide de ejecutar exportfs -a después de actualizar el archivo exports para que los cambios tengan efecto.
nfsd
Una vez que mountd ha validado la petición de montaje de un cliente, éste podrá lanzar las operaciones relacionadas con los sistemas de archivos. El encargado de con- trolar estas peticiones desde el lado del servidor es nfsd, el demonio de operaciones NFS. No hará falta ejecutar nfsd en la máquina del cliente NFS a menos que exporte el sistema de archivos por su cuenta.
nfsd tomó un argumento numérico que especifica el número de hilos (thread) de ejecución del servidor que usará. Es muy importante seleccionar un número apropiado y, desgraciadamente, tiene algo de magia negra. Si el número es muy grande o muy pe- queño, el rendimiento de NFS se verá mermado.
Generalmente, bastará con asignar ocho hilos a nfsd en aquellos servidores que se usen con poca frecuencia. Además, este valor es lo suficientemente bajo para evitar que aparezcan problemas de rendimiento. Sin embargo, si trabajamos con un servidor dedi- cado a la producción, deberemos utilizar un número comprendido entre 12 y 20. Si ob- serva que ps indica que el estado del demonio nfsd es D la mayoría del tiempo y que aún dispone de cierta capacidad de la CPU, puede ser conveniente aumentar estos nú- meros. Si se encuentra con que la carga media (la puede descubrir usando uptime) aumenta según va añadiendo nuevos nfsd, será que se ha pasado de valor. Utilice un valor ligeramente más pequeño. Debería ejecutar nfsstat con regularidad para com- probar los problemas de rendimiento que pueden estar asociados al número de hilos que utiliza nfsd. En un servidor NFS cargado que atienda muchos clientes UDP, las co- nexiones UDP pueden llegar a saturarse si se recibe una petición mientras los hilos de ejecución de nfsd están ocupados. Para ver el número de saturaciones que han tenido lugar deberemos usar el comando netstat -s. Añada más demonios nfsd hasta que el número de sobrecargas de la conexión UDP llegue a cero. La sobrecarga indica una falta de demonios en el servidor, por lo que deberíamos añadir más de lo que pueda lle- gar a indicar esta medida.
Para cambiar el número de procesos nfsd deberemos editar el script de inicio corres- pondiente que se encuentra en /etc/init.d o especificar un número desde la línea de comandos cuando se inicie nfsd manualmente. Para conocer el nombre del script que debe editar consulte la tabla 16.1.
NFS del lado del cliente
Los sistemas de archivos NFS se montan del mismo modo que los sistemas de archi- vos de disco. El comando mount entiende que la anotación nombrehost:directorio señala la ruta directorio del ordenador _nombrehost. Al igual que ocurre con los sis- temas de archivos locales, mount traduce el directorio del ordenador remoto en un di- rectorio que se encuentra dentro del árbol de archivos local. Después de completar el proceso de montaje, el acceso al sistema de archivos NFS es igual al local. El comando mount y las extensiones NFS que tiene asociadas representan algunos de los temas más importantes del cliente NFS para el administrador del sistema.
Antes de montar el sistema de archivos NFS, se debe exportar correctamente. Para verificar que, desde el punto de vista del cliente, el servidor ha exportado correctamen- te sus sistemas de archivos, deberemos utilizar el comando showmount:
$ showmount -e coyote Export list for coyote:
/home/boggs inura.toadranch.com
Este ejemplo informa de que el directorio /home/boggs del servidor coyote se ha exportado al sistema del cliente inura.toadranch.com. Si el proceso de montaje de NFS no se completase rectamente, lo primero que deberíamos hacer será comprobar la salida que genera showmount. Además, se deberían comprobar todos los sistemas de archivos que se han exportado de una manera correcta desde el servidor con el co- mando exportfs. Si el directorio se ha exportado correctamente desde el servidor, pero showmount muestra un error o una lista vacía, deberíamos volver a comprobar que se están ejecutando todo los procesos necesarios en el servidor (portmap, mountd, nfsd, statd y lockd), que los archivos hosts.allow y hosts.deny permiten el acceso a estos demonios y que estamos en el cliente correcto del sistema.
Para montar el sistema de archivos deberemos utilizar un comando como éste:
# mount -o rw,hard,intr,bg coyote:/home/boggs /coyote/home/boggs
Las opciones que aparecen detrás de -o indican que el sistema de archivos se deberá montar con los permisos de lectura y escritura, que se podrán interrumpir las operacio- nes y que todos los reintentos se tendrán que hacer en un segundo plano. Estas etique- tas son estándar. El resto de etiquetas comunes aparecen en la tabla 16.4.
Tabla 16.4. Opciones/etiquetas para montar NFS.
Etiqueta Descripción
rw Monta el sistema de archivos con los permisos de lectura y escritura (se ha de exportar de esta misma forma).
ro Monta el sistema de archivos sólo con los permisos de lectura.
bg Si falla el montaje (porque el servidor no responde) seguirá intentán- dolo en segundo plano y continuará con otras peticiones de montaje.
Etiqueta Descripción
hard Si un servidor se cae, esta etiqueta bloqueará todos los intentos de acceso al servidor que estén en marcha hasta que se restituya la má- quina.
soft Si un servidor se cae, esta etiqueta hace que todos los intentos de acceso al servidor fallen y se devuelva un mensaje de error. Esta pro- piedad es muy útil porque evita que se queden procesos colgados o que se ejecuten montajes innecesarios.
intr Permite que los usuarios interrumpan las operaciones que se han bloqueado (y obtengan un mensaje de error).
nointr No permite que los usuarios efectúen ninguna interrupción.
retrans=n Especifica el número de veces que se repetirá una petición antes de que aparezca un mensaje de error en un sistema que se haya monta- do de forma soft.
timeo=n Determina el período de caducidad de las peticiones (se mide en dé- cimas o en segundos).
rsize=n Ajusta el tamaño del búfer de lectura a n bytes.
wsize=n Ajusta el tamaño del búfer de escritura a n bytes.
nfsvers=n Selecciona la versión 2 ó 3 del protocolo NFS (generalmente de for- ma automática).
tcp Hace que la vía de transporte sea TCP. Por defecto se utiliza UDP.
async Hace que el servidor conteste a las peticiones de escritura antes de escribir datos en el disco.
Los sistemas de archivos que se montan hard (por defecto) hacen que los procesos se cuelguen cuando su servidor se cae. Este comportamiento puede ser muy peligroso cuando el proceso en cuestión es un demonio estándar, por lo que no recomendamos servir sis- temas críticos a través de NFS. En general, el uso de las opciones soft e intro redu- ce el número de problemas relacionados con NFS que pueden surgir. Sin embargo, estas opciones también tienen sus efectos secundarios, como tener que suspender una simu- lación de 20 horas después de llevar trabajando 18 horas, porque ha habido un fallo en la red. Hay otro tipo de soluciones, como los montajes automáticos que veremos más tarde dentro de este mismo capítulo, que proporcionan soluciones válidas.
El tamaño del búfer de lectura y escritura se aplica a los montajes UDP y TCP, pero su valor óptimo varía. Como podemos confiar en que el protocolo TCP transferirá los datos de una forma eficiente, los valores que utilicemos con él podrán ser más altos. Por ejemplo, 32K es un buen valor. Para UDP, cuando el servidor y el cliente se encuentren en la misma red, deberemos usar un valor de 8K. Su valor predeterminado es 1K, aun- que en las páginas de ayuda también se recomienda aumentar este valor hasta 8K.
Debido a la herencia de los núcleos 2.2 y 2.4 de Linux, el tamaño predeterminado para la cola de entrada es 64K. Con ocho hilos de ejecución nfsd corriendo en un ser- vidor NFS, deberá haber una petición por cada uno de ellos antes de que nfsd empiece a rechazar las peticiones entrantes. Por lo tanto, sólo deberemos aumentar el tamaño de
la cola de recepción volviendo a asignarle su valor predeterminado después de comple- tar la ejecución de nfsd. Así, los cambios no afectarán negativamente al resto de pro- cesos. También podemos utilizar procfs desde los scripts de inicio del sistema para modificar el tamaño de las colas de entrada. El siguiente ejemplo asigna un tamaño de 256K a la cola, que tiene un tamaño más que razonable:
rmem_default='cat /proc/sys/net/core/rmem_default' rmem_max='cat /proc/sys/net/core/rmem_max'
echo 262144 > /proc/sys/net/core/rmem_default echo 262144 > /proc/sys/net/core/rmem_max
Ejecute o reinicie rpc.nfsd y luego vuelva a asignar sus valores originales:
echo $rmem_default > /proc/sys/net/core/rmem_default echo $rmem_max > /proc/sys/net/core/rmem_max
Puede utilizar df para comprobar cómo ha ido el proceso de montaje, exactamente igual que haría con el sistema de archivos local:
$ df /coyote/home/boggs
Filesystem 1k-blocks Used Available Use% Mounted on
coyote:/home/boggs 17212156 1694128 14643692 11% /coyote/home/boggs
Para desmontar las particiones NFS deberá utilizar el comando umount. Si inten- tamos desmontar el sistema de archivos cuando alguien lo está utilizando, obtendremos un mensaje de error como éste:
umount: /coyote/home/boggs: device is busy
Al igual que ocurre con cualquier otro sistema de archivos, NFS no se podrá montar mientras alguien lo esté utilizando. Utilice lsof para localizar los procesos que estén trabajando con archivos. Elimínelos o, en el caso de estar trabajando con el shell, cam- bie de directorio. Si todas estas soluciones fallasen o si el servidor se cayese, deberá utilizar el comando mount -f para forzar a que se desmonte el sistema de archivos.
Montar sistemas de archivos remotos durante el arranque del sistema
Puede utilizar el comando mount para establecer montajes de red de forma tempo- ral, pero deberá utilizar /etc/fstab para especificar una lista con todos los monta- jes que formen parte de la configuración permanente del sistema. Así se podrán montar automáticamente durante su inicio. Como alternativa, los montajes se pueden efectuar automáticamente a través de un servicio como autofs.
Las siguientes entradas fstab montan los sistemas de archivos /home y /usr/
local de los ordenadores coyote e inura:
# filesystem mountpoint fstype flags dump fsck
coyote:/home /coyote/home nfs rw,bg,intr,hard,nodev,nosuid 0 0 inura:/usr/local /usr/local nfs ro,bg,intr,soft,nodev,nosuid 0 0
Cuando se añade una entrada a fstab, deberemos usar mkdir para crear los pun- tos de montaje apropiados a cada directorio. Podemos hacer que los cambios tengan efec- to inmediato (sin necesidad de reiniciar el sistema). Basta usar el comando mount -a -t nfs para montar todos los sistemas de archivos del tipo nfs en fstab.
El campo flags de /etc/fstab especifica las opciones que se utilizan con los montajes NFS. Estas opciones son las mismas que se pueden especificar desde la línea de comandos con mount.
Prohibir las exportaciones a través de puertos inseguros
Los clientes NFS son libres de usar cualquier puerto TCP o UDP que quieran cuan- do establecen una conexión con un servidor NFS. Sin embargo, los servidores Linux ha- cen especial hincapié en que las peticiones provengan de puertos con privilegios (son aquellos puertos cuya enumeración es inferior a 1.024) cuando el sistema de archivos se exporta utilizando la opción secure (que es la opción predeterminada). En el mun- do de los ordenadores personales y de las estaciones de trabajo Linux, el uso de puertos privilegiados otorga cierto nivel de seguridad.
Los clientes NFS de Linux siguen el sistema tradicional (de hecho, aún es el recomen- dado) de utilizar por defecto un puerto privilegiado, con lo que se evitan posibles con- flictos. Para acceder a montajes procedentes de puertos sin privilegios deberemos efectuar la exportación del sistema de archivos utilizando la opción insecure.
NFSSTAT: Las estadísticas de NFS
El comando nfsstat muestra alguna de las estadísticas que guarda el sistema NFS.
Así, nfsstat -s muestra las estadísticas de los procesos del servidor NFS, mientras que nfsstat -c muestra información relacionada con las operaciones del lado del cliente. Por ejemplo:
$ nfsstat -s Server rpc stats:
calls badcalls badauth badclnt xdrcall
24314112 311 9 302 0
Server nfs v2:
getattr null setattr root lookup readlink
8470054 34% 58 0% 55199 0% 0 0% 1182897 4% 917 0%
read wrcache link create remove rename
6602409 27% 0 0% 7452 0% 61544 0% 46712 0% 11537 0%
write symlink mkdir rmdir readdir fsstat
7785789 32% 744 0% 3446 0% 2539 0% 13614 0% 69201 0%
Estos ejemplos se han extraído de un servidor NFS relativamente sano. Si más del 3 por 100 de las llamadas son defectuosas, es muy probable que el problema se encuentre en el servidor NFS o en la red. Deberemos comprobar la salida que genera el coman- do netstat -s para conocer el estado de la red general. Nos puede dar información sobre pérdida de paquetes, fragmentación de datos o saturación en las colas de la red que afectan al rendimiento del sistema NFS.
Acostúmbrese a ejecutar de vez en cuando los comandos nfsstat y netstat para ir conociendo la información que generan. Le ayudará a descubrir problemas relaciona- dos con el sistema NFS antes de que sus usuarios se percaten de su existencia.
Servidores de archivos NFS dedicados
Un servicio de archivos rápido y fiable es uno de los elementos más importantes de un entorno de producción informática. Aunque podemos crear nuestro propio servidor partiendo de una estación de trabajo Linux y apoyarnos en una serie de discos duros, el hecho cierto es que este sistema no es el mejor garante de un buen rendimiento. De he- cho, ni siquiera es la solución más fácil de administrar (aunque sí es la más barata).
Los servidores de archivos NFS dedicados llevan funcionando más de una década.
Ofrecen a sus clientes una serie de ventajas importantes:
• Están optimizados para servir archivos y suelen alcanzar los mejores rendimientos NFS posibles.
• Según aumenten los requisitos de almacenamiento, se podrán ir ampliando sin ningún problema. De hecho, pueden trabajar con varios terabytes de almace- namiento y miles de usuarios.
• Son más fiables que los sistemas Linux porque cuentan con un software muy sencillo, un hardware redundante y utilizan un sistema de mirror en los discos.
• Suelen proporcionar servicio a clientes Linux y Windows. Incluso, algunos con- tienen servidores Web y FTP integrados.
• Son más fáciles de administrar que los servidores de archivos Linux.
• También incluyen elementos para efectuar copias de seguridad y comprobaciones que son mejores que aquellos "descafeinados" que incluyen los sistemas Linux.
Algunos de nuestros servidores NFS dedicados favoritos los fabrica Network Applian- ce, Inc. (www.netapp.com). Tienen productos para todas las necesidades, desde los más pequeños hasta los más grandes y no están nada mal de precio. Otra empresa a tener en cuenta en este mundo es EMS. Los servidores SAN (Storage Area Network) también son muy populares. Se diferencian de los servidores de archivos NFS dedicados en que no entienden nada de los sistemas de archivos. Simplemente se dedican a servir bloques de disco. Es decir, que estos servidores no sufren las limitaciones de tener que trabajar con un sistema operativo por lo que pueden llegar a alcanzar unas velocidades de lectu- ra y escritura muy rápidos. Aunque, a decir verdad, hemos de decir que no están muy extendidos dentro del mundo de la producción. Su integración puede llegar a ser muy compleja y parece que necesitan mucho tiempo de soporte.
Montajes automáticos
Cuando se trabaja con grandes redes, el hecho de tener que montar los sistemas de archivos uno a uno según se van encontrando en la lista /etc/fstab puede generar
muchos problemas. En primer lugar, el mantenimiento de la lista /etc/fstab en un sistema formado por miles de máquinas puede ser algo completamente tedioso. Cada una de ellas puede ser diferente a las anteriores y requerir cierto grado de atención per- sonalizada. En segundo lugar, si los sistemas de archivos se montan desde ordenadores diferentes, en el momento en que uno de estos servidores falle, nos encontraremos su- midos en un auténtico caos. Todos los comandos que accedan a los puntos de montaje fallarán. En tercer lugar, cuando el servidor importante falla, puede dejar tirado a mu- chos usuarios al hacer que particiones tan importantes como /usr/share/man que- den inservibles. En esta situación, lo mejor será intentar montar temporalmente una copia de la partición en un servidor de soporte.
Los demonios especializados en los montajes automáticos pueden montar sistemas de archivos siempre que se lo pidamos y desmontarlos cuando dejen de utilizarse. Este procedimiento reduce al mínimo el número de puntos de montajes activos y suele ser transparente para la mayoría de los usuarios. Casi todos ellos trabajan con la lista que le proporcionaremos, con una réplica de todos los sistemas de archivos para que la red pueda seguir funcionando cuando no se pueda acceder a uno de estos servidores.
Para llevar a cabo este montaje y desmontaje entre bastidores, el programa montará un sistema de archivos virtual en los directorios que le asignemos. Este montaje tendrá lugar siempre que se active el montaje automático. En el pasado, estas aplicaciones se hacían pasar por servidores NFS, pero este tipo de actuaciones tiene limitaciones im- portantes que ha hecho que estos sistemas no se encuentren entre los sistemas de hoy en día. En la actualidad, se utilizan una serie de controladores de sistemas de archivos que se encuentran dentro del kernel llamados autofs.
automount: montar sistemas de archivos bajo demanda
La idea de crear un dispositivo automático de montaje la tuvo originalmente Sun. El dispositivo automático de Linux, llamado autofs, imita al de Sun aunque es una im- plementación independiente del concepto y difiere del original en varios aspectos.
automount es un proceso que se ejecuta en segundo plano y que configura un úni- co punto de montaje para autofs, la parte del kernel que tiene asignado el programa de montaje automático de Linux. El script de inicio /etc/init.d/autofs anali- za el contenido de un archivo maestro (generalmente /etc/auto.master) y ejecuta automount con cada uno de los puntos de montaje de la lista. Es típico ver un auto- mount por cada uno de los puntos de montaje que se han configurado.
No es muy normal que tengamos que ejecutar el comando automount directamen- te, porque casi todas las labores de administración de este comando se efectúan a través del script /etc/init.d/autofs (o, en el caso de Red Hat y Fedora, /etc/rc.d/
init.d/autofs). Al igual que ocurre con la mayoría de los scripts de inicio, autofs acepta que se le envíe, desde la línea de comandos, un único parámetro, que puede ser start, stop, reload, restart o status. Siempre que se efectúe algún cambio en la configuración del programa encargado de efectuar los montajes automáticamente, deberemos ejecutar el comando autofs reload para asegurarnos de que se apliquen de inmediato. Para conocer el estado de los montajes automáticos existentes deberemos utilizar el comando autofs status. El archivo auto.master asocia un punto de
montaje con un mapa de conversión. Estos mapas traducen el nombre del directorio al que se ha accedido (conocido como clave) a la línea de comandos que puede utilizar mount para llevar a cabo el montaje real. Un mapa puede ser un archivo de texto, un programa ejecutable o una base de datos de NIS o LDAP.
Siempre que un usuario haga una referencia a un directorio que será montado utili- zando el módulo autofs del sistema de archivos del kernel, dicho módulo notificará el proceso automount del cliente que se utilizará para facilitar el acceso. El proceso automount se hace una idea de qué sistema de archivos se ha de montar. Para ello, consulta el archivo mapa o el programa pertinente. Efectuará el montaje antes de devol- ver el control al usuario que lanzó la búsqueda. Para ver los procesos automount y los sistemas de archivos autofs deberá utilizar los comandos mount y ps:
$ mount
/dev/hda3 on / type ext2 (rw) proc on /proc type proc (rw) /dev/hda1 on /boot type ext2 (rw)
// proceso encargado de montar automáticamente el sistema // de archivos
automount(pid8359) on /misc type autofs (rw,fd=5,pgrp=8359,minproto=2,maxproto=4)
// proceso encargado de montar automáticamente el sistema // de archivos
automount(pid8372) on /net type autofs (rw,fd=5,pgrp=8372,minproto=2,maxproto=4)
$ ps auxw | grep automount
root 8359 0.0 1.0 1360 652 ? S Dec27 0:00 /usr/sbin/automount /misc file /etc/auto.misc
root 8372 0.0 1.0 1360 652 ? S Dec27 0:00 /usr/sbin/automount /net program /etc/auto.net
Aquí tenemos dos sistemas de archivos que se han montado automáticamente con autofs en /misc y /net. Estos sistemas de archivos virtuales se han relacionado con los procesos automount a través de los identificadores PID 8359 y 8372, respec- tivamente. Los comandos automount que ejecuta el script /etc/init.d/autofs aparecerán en la salida que genera el comando ps. auto.misc es un archivo mapa normal y corriente, y auto.net es un programa ejecutable. Estos mapas se describen más abajo en detalle.
El archivo master
El archivo /etc/auto.master muestra una lista con los directorios que debe- rían tener los sistemas de archivos montados automáticamente con autofs y los ma- pas que hay asociados a cada directorio. Además de especificar el directorio raíz y el nombre de los mapas, podemos utilizar opciones con el formato -o para que las utilice el comando mount. Estas opciones se aplicarán a todas y cada una de las entradas del mapa. Los convenios que usa Linux varían de los que sigue Sun, ya que estos últimos toman las opciones del archivo maestro y las unen a aquellas que tiene asignado el ma- pa. Se utilizarán los dos conjuntos de opciones para controlar el proceso de montaje.
El aspecto que tendrá un archivo master, que utiliza un archivo mapa como el que se verá en la siguiente sección, será similar a éste:
# Directorio Mapa Opciones
/chimchim /etc/auto.chim -secure,hard,bg,intr El archivo master se puede sustituir o argumentar con una versión compartida a través de NIS. El origen de la información de automount del sistema se especifica a través del campo automount de /etc/nsswitch.conf.
Los archivos de mapas
Los archivos de mapas (también conocidos como "conversiones indirectas" en otros sistemas) se usan para montar varios sistemas de archivos que comparten un mismo direc- torio. La ruta del directorio se especifica en el archivo master, no en el propio archivo de mapas. Por ejemplo, un mapa para el sistema de archivos montado en /chimchim (que se corresponde con el ejemplo que hemos visto anteriormente) tendría el siguiente aspecto:
users chimchim:/chimchim/users
devel -soft,nfsproto=3 chimchim:/chimchim/devel info -ro chimchim:/chimchim/info
La primera columna nombra los subdirectorios en los que se instalará cada instan- cia de automount. El resto de elementos muestran las opciones que se utilizarán en el proceso de montaje y la ruta donde se encuentra el sistema de archivos. Este ejemplo (guardado en /etc/auto.chim) indica a automount que puede montar los direc- torios /chimchim/users, /chimchim/devel y /chimchim/info del host chim- chim. En este proceso de montaje, a info se aplicarán permisos de lectura y devel tendrá un montaje soft para la cual se utilizará la versión 3 del protocolo NFS.
En esta configuración, las rutas de chimchim y las del host local son idénticas. Sin embargo, tenga en cuenta que esta equivalencia no es necesaria.
Los mapas ejecutables
Si un archivo de mapas es ejecutable, se asumirá que se trata de un script o de un programa que genera dinámicamente la información de automount. En vez de leer el mapa como un archivo de texto, el programa encargado de proceder con el montaje auto- mático lo ejecuta como un argumento (la llave) que le indica a qué subdirectorio quiere acceder el usuario. El script es el responsable de imprimir la entrada apropiada del ma- pa. Si la llave que se especifica no es válida, el script abandonará su ejecución sin im- primir nada.
Esta propiedad tan interesante maquilla muchas de las deficiencias que presenta el extraño sistema de configuración de automount. Efectivamente, nos permite definir un archivo de configuración para automount usando el formato que más nos guste. Po- demos escribir un script en Perl que se encargue de descodificar la configuración global en cada máquina. Algunos sistemas cuentan con un mapa ejecutable /etc/auto.net
muy útil que toma el nombre del host como una llave y monta todos los sistemas de archivos que se hayan exportado a dicho ordenador.
El sistema de montaje automático tiene una característica un tanto confusa que me- rece que la mencionemos aquí. Cuando listamos el contenido del directorio padre de un sistema de archivos que se montará automáticamente, aparecerá vacío independien- temente del tipo de sistemas de archivos que se haya montado automáticamente allí. No podemos consultar su contenido utilizando un explorador GUI para sistemas de archi- vos. Un ejemplo:
$ ls /portal
$ ls /portal/photos
art_class_2004 florissant_1003 rmnp03
blizzard2003 frozen_dead_guy_Oct2004 rmnp_030806
boston021130 greenville.021129 steamboat2002
El sistema de archivos photos está vivo y coleando y se ha montado automáticamente dentro de /portal. Se puede acceder a él utilizando el nombre completo de su ruta.
Sin embargo, al revisar el contenido del directorio /portal no indica que exista. Si montamos este sistema de archivos a través del fichero /etc/fstab o bien manual- mente con el comando mount, se comportará como si fuese un directorio distinto y aparecerá (visible) como miembro del directorio padre. Una forma de solucionar este problema es crear un directorio que contenga vínculos simbólicos a los puntos de mon- taje automático. Por ejemplo, si /automounts/photos es un vínculo simbólico que señala a /portal/photos, podemos utilizar ls /automounts para descubrir que, en realidad, photos es un directorio que se ha montado automáticamente. Las referen- cias que se dirijan a /automounts/photos se procesarán correctamente a través de automount. Desgraciadamente, estos vínculos simbólicos requieren ciertas labores de mantenimiento y, a no ser que las reconstruyamos periódicamente a través de un script, es muy probable que terminen quedándose desfasadas.
Lecturas recomendadas
Hal Stern, Mike Eisler y Ricardo Labiaga: Managing NFS and NIS (2nd edition).
O´Reilly, 2001.
Tabla 16.5. Documentos RFC relacionados con NFS.
RFC Título Autor Fecha
1094 Network File System protocol Specification Sun Microsystems marzo 1989 1813 NFS Version 3 Protocol Specification B. Callaghan et al. junio 1995 2623 NFS Version 2 and Version 3 Security M. Eisler junio 1999
Issues
2624 NFS Version 4 Design Considerations S. Shepler junio 1999 3530 NFS Version 4 Protocol S. Shepler et al. abril 2003
