567

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 losusuarios y no pierde información cuando falla un servidor. Los clientes esperarán a queel servidor se recupere y continúe con su trabajo, como si nada hubiese pasado.

NFS lo presentó Sun Microsystems en 1985. Originalmente se implementó comouna prolongación de los sistemas de archivos para los clientes que no tenían unidadesde 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ómoera la vida antes de la aparición de NFS. Todas las distribuciones completas de Linuxpueden trabajar con él.

Información general sobre NFS

En la actualidad, NSF sólo se utiliza para compartir archivos entre sistemas Linux yUNIX. Los clientes de Windows deberían utilizar CFIS/Samba. (Los veremos al finaldel libro.) NFS cuenta con varios componentes, incluyendo un protocolo para montarelementos, un servidor de montaje, demonios encargados de coordinar el servicio dearchivos 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, desdeel punto de vista del administrador, son completamente transparentes.

568

Versiones del protocolo en NFS

El protocolo NFS ha permanecido estable a lo largo de todo este tiempo. La primeraversión que se publicó fue NFS 2. A principios de la década de los 90, una serie decambios generaron la versión 3, que mejoró el rendimiento y su capacidad para trabajarcon 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 lolargo 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óndeberán modificar los bloques del disco antes de contestar a los clientes. Así evitaránque 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 deentrada de la memoria caché.

La versión 3 de NFS elimina este cuello de botella utilizando un sistema coherenteque 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 redde la versión 3 es algo más rápida que la de la versión 2. El software de la versión 3puede 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. Entrelas 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 detalleen 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 laversión 4 sea lo suficientemente longeva para que todas estas especificaciones prometi-das lleguen a ver la luz.

569

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 deUDP o de TCP como protocolo de transporte.

Originalmente, NFS utilizaba UDP porque era el protocolo que mejor funcionabasobre 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 controlde 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 vezque se utilizó esta opción fue para buscar un sistema que ayudase a NFS a través de losrouters y a través de Internet. Sin embargo, parece que hay consenso que determina queTCP es la mejor opción para controlar el tráfico local de NFS. Con el paso del tiempo, lamayoría de las razones que inicialmente daban su apoyo a UDP se han ido evaporandoa favor de TCP. Y es que ahora nos encontramos con unas CPU muy rápidas, con unosmódulos de memoria muy baratos y con unos sistemas inteligentes capaces de controlarlas 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á TCPo UDP. El cliente especificará su preferencia como una opción del comando mount o atravé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 desistema flock, lockf y/o fcntl) ha sido uno de los puntos débiles de los sistemasUnix durante mucho tiempo. En los sistemas de archivos locales, su funcionamiento hadistado mucho de ser perfecto. En el contexto de NFS, aún no podemos decir que nosmovamos sobre un terreno firme. Por diseño, los servidores NFS carecen de estado: nosaben 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 deNFS. La mayoría de los sistemas proporcionan dos demonios, lockd y statd, que seencargan de hacerlo. Desgraciadamente, esta tarea es difícil por muchas razones, por loque 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 conseguircon un servidor como rquotad. Los servidores NFS, cuando el sistema de archivoscon 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 seejecute rquotad en el servidor remoto.

570

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 deestas organizaciones, conviene que consulte la documentación sobre los límites de losdiscos 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 montarlodel mismo modo que lo hace con los sistemas de archivos de su disco duro local. Sinembargo, 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 revelaruna cookie secreta cuando se completa la negociación sobre el proceso de montaje. Lacookie identifica el directorio que se ha montado en el servidor NFS y proporciona unsistema para que el cliente pueda acceder a su contenido.

Cuando se desmonta y se vuelve a montar un sistema de archivos en el servidor, lonormal es que se cambie su cookie. Como caso especial, las cookies se conservan despuésde 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 volvera revisar el sistema. Este proceso elimina las cookies y hace que los clientes no puedanacceder 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 deasegurarse de que el servidor acepte las peticiones de escritura antes de borrar su propiacopia 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 nombrespara cada uno de los servidores remotos (como, por ejemplo, /anchor/tools paralos sistemas de archivos que se encuentran en el ordenador anchor), la gestión delsistema NFS es muy sencilla.

Estos nombres son de gran utilidad porque permiten que los usuarios traduzcanmensajes 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 archivosde 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 sistemascon un demonio especializado en efectuar montajes automáticamente, como se verádentro de unas cuantas secciones.

571

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 hafallado en la seguridad de Unix y Linux. El protocolo se diseñó originalmente sin teneren cuenta a los sistemas de seguridad (premiaba más su precio). Afortunadamente, Linuxpuede 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/exportsque enumera los nombres de los host (o sus direcciones IP) de los sistemas que deberíanpoder 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 quese identifiquen. Y ya sabemos lo fácil que es conseguir que un cliente mienta sobre suidentidad. 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 queconfiemos, 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 delos archivos y con los identificadores UID y GID. Pero una vez más, el servidor de NFSse 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 losarchivos NFS del otro. Además, los usuarios que tengan un acceso root a un sistemapodrá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 encarecidamenteque 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 utilizaresta 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 incidentey volver a levantar las máquinas.

Si su sistema cuenta con un firewall de red, será conveniente que bloquee el accesoa 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 pasapor el puerto 111 de TCP y UDP. Aunque la siguiente afirmación está implícita dentrode estas precauciones, tenemos que recordar que no se debe exportar ningún sistema dearchivos NFS a una máquina que no sea local, y mucho menos a un ordenador que seencuentra 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.

572

Por defecto, el servidor NFS de Linux intercepta las peticiones entrantes que se generancon 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 unusuario corriente.

Se define una cuenta llamada "nobody" para que actúe como un pseudousuario quecamuflará al usuario root remoto de un servidor NFS. Tradicionalmente, el identificadorUID 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á todaslas distinciones existentes entre los usuarios y creará un tipo de sistema de archivos parael acceso público.

Por otro lado, tenemos la opción no_root_squash que desactiva la conversiónde los identificadores UID del usuario root. A veces se tiene que utilizar esta opciónpara poder trabajar con clientes que no tienen unidad de disco duro o con software quetiene que acceder al sistema de archivos como usuario root. Pero, en general, no es unabuena idea activar esta propiedad porque permitirá que todos los usuarios que tenganprivilegios de administradores en un cliente modifiquen archivos que cuenten con unsistema 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 suverdadero valor no es tan bueno como parece. Recuerde que un usuario root de un clienteNFS puede utilizar el comando su para asignarse el identificador UID que quiera, porlo que los archivos del usuario nunca estarán realmente protegidos. Los registros desistemas como bin y sys no cuentan con el sistema de conversión UID, por lo que susarchivos (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 deusuarios.

NFS del lado del servidor

Se dice que un servidor exporta un directorio cuando permite que lo utilicen otrasmáquinas. En la versión 3 de NFS, el proceso que utilizaban los clientes para montarun 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 seencargaba 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 utilizael protocolo RPC (y por lo tanto requieren que se esté ejecutando portmap). Nosotrosvamos 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ánautomá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.

573

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 quedeterminará qué sistemas de archivos se han de exportar y cuáles han de montar losclientes. 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 seha 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 eliminarentradas 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 directoresque se han exportado y tiene un formato que permite que lo pueda leer un humano. Pordefecto, todos los sistemas de archivos de /etc/exports se exportarán durante elarranque del sistema. También podremos exportar manualmente todos los sistemas dearchivos que aparezcan en la lista /etc/exports usando el comando exportfs -a.Deberemos utilizar este comando después de modificar el archivo exports. Tambiénpodemos 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ízde 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 cadadispositivo 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 deun directorio que se ha exportado, aunque el protocolo no necesite. Por ejemplo, si unservidor 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 exportadocon diferentes opciones, pero Linux sí.

El archivo exports

El archivo /etc/exports enumera los sistemas de archivos que se han exportadoa través de NFS y los clientes que pueden acceder a cada uno de ellos. Utiliza espaciosen blanco para separar los sistemas de archivos de la lista de clientes, y a cada cliente lesigue una lista (que aparece entre paréntesis) con todas las opciones que han de usar.

574

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 quepueden 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.

575

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 lossubdirectorios de los directorios que se han exportado tengan distintas opciones. Con laopción noaccess marcaremos subdirectorios como "no exportables" para que no sepuedan 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 sitiodonde no podrán acceder será a /home/boggs. La ausencia de un nombre de un clienteen la segunda línea indica que la opción se aplicará a todos los host. Es posible que coneste sistema tengamos una mayor seguridad.

La opción subtree_check (predeterminada) verifica que todos los archivos a losque ha accedido el cliente se encuentran dentro del subdirectorio que se ha exportado.

576

Si desactivamos esta opción, sólo se comprobará que el archivo se encuentra dentro delsistema de archivos que se ha exportado. La comprobación dentro del subárbol puedeocasionar problemas cuando se modifica el nombre del archivo que se ha solicitadomientas el cliente lo tiene abierto. Si estima que puede encontrarse con esta situaciónen 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 contodos aquellos archivos que se hayan bloqueado. Algunos clientes NFS no envían suscredenciales con las consultas bloqueadas por lo que no pueden funcionar con la opciónsecure_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 otrosque puedan trabajar con credenciales. Sin embargo, siempre puede utilizar la opcióninsecure_locks como una solución de emergencia.

No se olvide de ejecutar exportfs -a después de actualizar el archivo exportspara 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 operacionesNFS. No hará falta ejecutar nfsd en la máquina del cliente NFS a menos que exporteel sistema de archivos por su cuenta.

nfsd tomó un argumento numérico que especifica el número de hilos (thread) deejecución del servidor que usará. Es muy importante seleccionar un número apropiadoy, 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 seusen con poca frecuencia. Además, este valor es lo suficientemente bajo para evitar queaparezcan 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 queaú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 unvalor 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 queutiliza 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 deejecución de nfsd están ocupados. Para ver el número de saturaciones que han tenidolugar deberemos usar el comando netstat -s. Añada más demonios nfsd hasta queel número de sobrecargas de la conexión UDP llegue a cero. La sobrecarga indica unafalta 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íneade comandos cuando se inicie nfsd manualmente. Para conocer el nombre del script

que debe editar consulte la tabla 16.1.

577

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:directorioseñ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 elproceso de montaje, el acceso al sistema de archivos NFS es igual al local. El comandomount y las extensiones NFS que tiene asociadas representan algunos de los temasmás importantes del cliente NFS para el administrador del sistema.

Antes de montar el sistema de archivos NFS, se debe exportar correctamente. Paraverificar 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 coyoteExport list for coyote:/home/boggs inura.toadranch.com

Este ejemplo informa de que el directorio /home/boggs del servidor coyote se haexportado al sistema del cliente inura.toadranch.com. Si el proceso de montajede NFS no se completase rectamente, lo primero que deberíamos hacer será comprobarla salida que genera showmount. Además, se deberían comprobar todos los sistemasde 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 comprobarque 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 permitenel 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.

578

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 secuelguen cuando su servidor se cae. Este comportamiento puede ser muy peligroso cuandoel 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, estasopciones 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 enla red. Hay otro tipo de soluciones, como los montajes automáticos que veremos mástarde 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, perosu valor óptimo varía. Como podemos confiar en que el protocolo TCP transferirá losdatos de una forma eficiente, los valores que utilicemos con él podrán ser más altos. Porejemplo, 32K es un buen valor. Para UDP, cuando el servidor y el cliente se encuentrenen 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 predeterminadopara 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 empiecea rechazar las peticiones entrantes. Por lo tanto, sólo deberemos aumentar el tamaño de

579

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 paramodificar el tamaño de las colas de entrada. El siguiente ejemplo asigna un tamaño de256K 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_defaultecho 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_defaultecho $rmem_max > /proc/sys/net/core/rmem_max

Puede utilizar df para comprobar cómo ha ido el proceso de montaje, exactamenteigual 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, obtendremosun 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á montarmientras alguien lo esté utilizando. Utilice lsof para localizar los procesos que esténtrabajando 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 montarautomáticamente durante su inicio. Como alternativa, los montajes se pueden efectuarautomá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

580

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 losmontajes NFS. Estas opciones son las mismas que se pueden especificar desde la líneade 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 (sonaquellos puertos cuya enumeración es inferior a 1.024) cuando el sistema de archivosse 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 puertosprivilegiados 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 efectuarla 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, mientrasque nfsstat -c muestra información relacionada con las operaciones del lado delcliente. 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 3por 100 de las llamadas son defectuosas, es muy probable que el problema se encuentreen 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ónsobre pérdida de paquetes, fragmentación de datos o saturación en las colas de la redque afectan al rendimiento del sistema NFS.

581

Acostúmbrese a ejecutar de vez en cuando los comandos nfsstat y netstat parair 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 deun entorno de producción informática. Aunque podemos crear nuestro propio servidorpartiendo de una estación de trabajo Linux y apoyarnos en una serie de discos duros, elhecho 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 rendimientosNFS posibles.

• Según aumenten los requisitos de almacenamiento, se podrán ir ampliando sinningú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 muysencillo, 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 comprobacionesque 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 losmás pequeños hasta los más grandes y no están nada mal de precio. Otra empresa a teneren cuenta en este mundo es EMS. Los servidores SAN (Storage Area Network) tambiénson muy populares. Se diferencian de los servidores de archivos NFS dedicados en queno entienden nada de los sistemas de archivos. Simplemente se dedican a servir bloquesde disco. Es decir, que estos servidores no sufren las limitaciones de tener que trabajarcon 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 muyextendidos dentro del mundo de la producción. Su integración puede llegar a ser muycompleja 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 dearchivos uno a uno según se van encontrando en la lista /etc/fstab puede generar

582

muchos problemas. En primer lugar, el mantenimiento de la lista /etc/fstab en unsistema formado por miles de máquinas puede ser algo completamente tedioso. Cadauna 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 ordenadoresdiferentes, 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 montajefallará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 unacopia de la partición en un servidor de soporte.

Los demonios especializados en los montajes automáticos pueden montar sistemasde archivos siempre que se lo pidamos y desmontarlos cuando dejen de utilizarse. Esteprocedimiento reduce al mínimo el número de puntos de montajes activos y suele sertransparente para la mayoría de los usuarios. Casi todos ellos trabajan con la lista quele proporcionaremos, con una réplica de todos los sistemas de archivos para que la redpueda 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 sehací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 endía. En la actualidad, se utilizan una serie de controladores de sistemas de archivos quese 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. Eldispositivo 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 programade 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 ejecutaautomount 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ésdel 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, autofsacepta que se le envíe, desde la línea de comandos, un único parámetro, que puede serstart, stop, reload, restart o status. Siempre que se efectúe algún cambioen la configuración del programa encargado de efectuar los montajes automáticamente,deberemos ejecutar el comando autofs reload para asegurarnos de que se apliquende inmediato. Para conocer el estado de los montajes automáticos existentes deberemosutilizar el comando autofs status. El archivo auto.master asocia un punto de

583

montaje con un mapa de conversión. Estos mapas traducen el nombre del directorio alque se ha accedido (conocido como clave) a la línea de comandos que puede utilizarmount para llevar a cabo el montaje real. Un mapa puede ser un archivo de texto, unprograma 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 procesoautomount 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 lossistemas 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 archivosautomount(pid8359) on /misc type autofs

(rw,fd=5,pgrp=8359,minproto=2,maxproto=4)// proceso encargado de montar automáticamente el sistema// de archivosautomount(pid8372) on /net type autofs

(rw,fd=5,pgrp=8372,minproto=2,maxproto=4)

$ ps auxw | grep automountroot 8359 0.0 1.0 1360 652 ? S Dec27 0:00

/usr/sbin/automount /misc file /etc/auto.miscroot 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 conautofs en /misc y /net. Estos sistemas de archivos virtuales se han relacionadocon 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/autofsaparecerán en la salida que genera el comando ps. auto.misc es un archivo mapanormal y corriente, y auto.net es un programa ejecutable. Estos mapas se describenmá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 elnombre de los mapas, podemos utilizar opciones con el formato -o para que las utiliceel comando mount. Estas opciones se aplicarán a todas y cada una de las entradas delmapa. Los convenios que usa Linux varían de los que sigue Sun, ya que estos últimostoman 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.

584

El aspecto que tendrá un archivo master, que utiliza un archivo mapa como el quese 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 através de NIS. El origen de la información de automount del sistema se especifica através del campo automount de /etc/nsswitch.conf.

Los archivos de mapas

Los archivos de mapas (también conocidos como "conversiones indirectas" en otrossistemas) 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 archivode 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 siguienteaspecto:

users chimchim:/chimchim/usersdevel -soft,nfsproto=3 chimchim:/chimchim/develinfo -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 elproceso 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 develtendrá 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. Sinembargo, 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 unprograma que genera dinámicamente la información de automount. En vez de leer elmapa 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 quiereacceder 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 elextraño sistema de configuración de automount. Efectivamente, nos permite definirun 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 globalen cada máquina. Algunos sistemas cuentan con un mapa ejecutable /etc/auto.net

585

muy útil que toma el nombre del host como una llave y monta todos los sistemas dearchivos 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 unsistema 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í. Nopodemos consultar su contenido utilizando un explorador GUI para sistemas de archi-vos. Un ejemplo:

$ ls /portal$ ls /portal/photosart_class_2004 florissant_1003 rmnp03blizzard2003 frozen_dead_guy_Oct2004 rmnp_030806boston021130 greenville.021129 steamboat2002

El sistema de archivos photos está vivo y coleando y se ha montado automáticamentedentro 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. Simontamos 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 yaparecerá (visible) como miembro del directorio padre. Una forma de solucionar esteproblema 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 queseñ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 deautomount. Desgraciadamente, estos vínculos simbólicos requieren ciertas labores demantenimiento 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