Cómo funciona el servicio NFS

En las siguientes secciones se describen algunas de las complejas funciones del software NFS. Tenga en cuenta que algunas de las descripciones de las funciones en esta sección son exclusivas de NFS versión 4.

• Negociación de versión en NFS

• Funciones en NFS versión 4

• Negociación UDP y TCP

• Negociación de tamaño de transferencia de archivos

• Cómo se montan los sistemas de archivos

• Efectos de la opción -public y direcciones URL NFS al montar

• Conmutación por error por parte del cliente

• Archivos de gran tamaño

• Cómo funciona el registro del servidor NFS

• Cómo funciona el servicio WebNFS

• Limitaciones WebNFS con uso de explorador web

• Sistema NFS seguro

• RPC segura

Negociación de versión en NFS

El proceso de inicio de NFS incluye la negociación de los niveles de protocolo para servidores y clientes. Si no especifica el nivel de versión, se selecciona el mejor nivel de manera predeterminada. Por ejemplo, si el cliente y el servidor pueden admitir la versión 3, se utiliza la versión 3. Si el cliente o el servidor sólo pueden admitir la versión 2, se utiliza la versión 2.

Puede establecer los parámetros client_versmin, client_versmax, server_versmin y server_versmax con el comando sharectl. Los valores mínimos y máximos especificados para el servidor y el cliente sustituirían los valores predeterminados para estas palabras clave. Para el cliente y el servidor, el valor predeterminado mínimo es 2 y el valor predeterminado máximo es 4. Para encontrar la versión que admite el servidor, el cliente NFS comienza con el valor para client_versmax y prueba cada versión hasta que se alcance la configuración de versión para client_versmin. Apenas se encuentra la versión compatible, finaliza el proceso. Por ejemplo, si client_versmax=4 y client_versmin=2, el cliente prueba primero la versión 4, luego prueba la versión 3 y, por último, la versión 2. Si client_versmax y client_versmax están definidos con el mismo valor, el cliente siempre utiliza esta versión y no intenta con ninguna otra. Si el servidor no ofrece esta versión, el montaje falla.

Para obtener información de procedimiento, consulte Configuración de servicios NFS.

Funciones en NFS versión 4

Se han realizado muchos cambios en NFS versión 4. En esta sección se proporcionan descripciones de estas nuevas funciones.

• Anular el uso compartido y volver a compartir un sistema de archivos en NFS versión 4

• Espacio de nombre de sistema de archivos en NFS versión 4

• Identificadores de archivos volátiles en NFS versión 4

• Recuperación de cliente en NFS versión 4

• Compatibilidad de uso compartido OPEN en NFS versión 4

• Delegación en NFS versión 4

• ACL y nfsmapid en NFS versión 4

• Conmutación por error por parte del cliente en NFS versión 4

Para obtener información de procedimiento relacionada con el uso de NFS versión 4, consulte Configuración de servicios NFS.

Anular el uso compartido y volver a compartir un sistema de archivos en NFS versión 4

Con NFS versión 3 y versión 4, si un cliente intenta acceder a un sistema de archivos que se ha dejado de compartir, el servidor responde con un código de error. Sin embargo, con NFS versión 3 el servidor mantiene cualquier bloqueo que los clientes hayan obtenido antes de que se dejara de compartir el sistema de archivos. Por lo tanto, cuando el sistema de archivos se vuelve a compartir, los clientes NFS versión 3 pueden acceder al sistema de archivos como si éste nunca se hubiera dejado de compartir.

Con NFS versión 4, cuando anula la compartición de un sistema de archivos, se destruye todo el estado de todos los archivos abiertos o bloqueos de archivos en ese sistema de archivos. Si el cliente intenta acceder a estos archivos o bloqueos, el cliente recibe un error. Este error suele notificarse como un error I/O en la aplicación. Tenga en cuenta, sin embargo, que si vuelve a compartir un sistema de archivos que ya está compartido para cambiar las opciones no destruye ningún estado en el servidor.

Para obtener información relacionada, consulte Recuperación de cliente en NFS versión 4 o la página del comando man unshare_nfs(1M).

Espacio de nombre de sistema de archivos en NFS versión 4

Los servidores NFS versión 4 crean y mantienen un pseudosistema de archivos que proporciona a los clientes un acceso ininterrumpido a todos los objetos exportados en el servidor. Antes de la versión 4 de NFS, el pseudosistema de archivos no existía. Los clientes estaban forzados a montar cada sistema de archivos de servidor compartido para el acceso. Considere el siguiente ejemplo.

Figura 6-2 Vistas del sistema de archivos del servidor y del sistema de archivos del cliente

Tenga en cuenta que el cliente no puede ver el directorio payroll ni el directorionfs4x, ya que estos directorios no se exportan y no conducen a directorios exportados. Sin embargo, el directorio local está visible para el cliente, ya que local es un directorio exportado. El directorio projects es visible para los clientes, ya que projects conduce al directorio exportado nfs4. Por lo tanto, las partes del espacio de nombres del servidor que no están explícitamente exportadas se enlazan con un pseudosistema de archivos que visualiza sólo los directorios exportados y aquellos directorios que conducen a las exportaciones del servidor.

Un pseudosistema de archivos es una estructura que contiene sólo directorios y se crea mediante el servidor. El pseudosistema de archivos permite que un cliente examine la jerarquía de sistemas de archivos exportados. Por lo tanto, la vista que tiene el cliente del pseudosistema de archivos se limita a rutas que conducen a sistemas de archivos exportados.

Las versiones anteriores de NFS no permitían que un cliente atravesara sistemas de archivos del servidor sin montar cada sistema de archivos. Sin embargo, en la versión 4 de NFS, el espacio de nombres del servidor hace lo siguiente:

• Restringe la vista del sistema de archivos a los directorios que conduzcan a exportaciones del servidor.

• Proporciona a los clientes un acceso ininterrumpido a las exportaciones del servidor sin necesidad de que el cliente monte cada sistema de archivos subyacente. Consulte el ejemplo anterior. Tenga en cuenta, sin embargo, que diferentes sistemas operativos pueden necesitar que el cliente monte cada sistema de archivos del servidor.

Por motivos relacionados con POSIX, el cliente NFS versión 4 de Oracle Solaris no cruza los límites del sistema de archivos del servidor. Cuando se realizan tales intentos, el cliente hace que el directorio parezca estar vacío. Para solucionar esta situación, debe realizar un montaje para cada uno de los sistemas de archivos del servidor.

Identificadores de archivos volátiles en NFS versión 4

En el servidor se crean identificadores de archivos que contienen información que identifica de forma exclusiva archivos y directorios. En las versiones 2 y 3 de NFS, el servidor devolvía identificadores de archivos persistentes. Por lo tanto, el cliente podía garantizar que el servidor generara un identificador de archivo que siempre hiciera referencia al mismo archivo. Por ejemplo:

• Si un archivo se suprimía y sustituía por otro archivo con el mismo nombre, el servidor generaba un nuevo identificador de archivos para el archivo nuevo. Si el cliente utilizaba el identificador de archivos anterior, el servidor devolvía un error que indicaba que el identificador de archivos era obsoleto.

• Si se cambiaba el nombre de un archivo, el identificador de archivos seguía siendo el mismo.

• Si tenía que reiniciar el servidor, los identificadores de archivos seguían siendo los mismos.

Por lo tanto, cuando el servidor recibía una solicitud de un cliente que incluía un identificador de archivo, la resolución era sencilla y el identificador de archivos siempre hacía referencia al archivo correcto.

Este método de identificación de archivos y directorios para las operaciones de NFS era aceptable para la mayoría de los servidores basados en UNIX. Sin embargo, el método no podía ejecutarse en servidores que dependieran de otros métodos de identificación, como el nombre de ruta de un archivo. Para resolver este problema, el protocolo NFS versión 4 permite que un servidor declare que sus identificadores de archivos son volátiles. Por lo tanto, un identificador de archivos puede cambiar. Si el identificador de archivos cambia, el cliente debe encontrar el nuevo identificador de archivos.

Como en las versiones 2 y 3 de NFS, el servidor NFS versión 4 de Oracle Solaris siempre proporciona identificadores de archivos persistentes. Sin embargo, los clientes NFS versión 4 de Oracle Solaris que accedan a servidores que no sean de NFS versión 4 de Solaris deben admitir identificadores de archivos volátiles si el servidor los utiliza. Específicamente, cuando el servidor indica al cliente que el identificador de archivos es volátil, el cliente debe almacenar en la antememoria la asignación entre el nombre de la ruta de acceso y el identificador de archivos. El cliente utiliza este identificador de archivos volátil hasta que caduque. Cuando caduca, el cliente hace lo siguiente:

• Vacía la información almacenada en la antememoria que hace referencia a ese identificador de archivo

• Busca el identificador de archivos nuevo del archivo

• Vuelve a intentar la operación

Los identificadores de archivos volátiles pueden caducar por cualquiera de estos motivos:

• Cuando cierra un archivo

• Cuando migra el sistema de archivos del identificador de archivos

• Cuando un cliente cambia el nombre de un archivo

• Cuando el servidor se reinicia

Tenga en cuenta que si el cliente no puede encontrar el nuevo identificador de archivos, se coloca un mensaje de error en el archivo syslog. Otros intentos de acceder a este archivo fallan con un error I/O.

Recuperación de cliente en NFS versión 4

El protocolo NFS versión 4 es un protocolo con estado. Un protocolo tiene estado cuando tanto el cliente como el servidor mantienen información actualizada sobre lo siguiente:

• Archivos abiertos

• Bloqueos de archivos

Cuando se produce un fallo, como un bloqueo del servidor, el cliente y el servidor trabajar juntos para restablecer los estados "abierto" y "bloqueado" que existían antes del error.

Cuando un servidor se bloquea y se reinicia, el servidor pierde su estado. El cliente detecta que el servidor se ha reiniciado y comienza el proceso de ayudar a que el servidor reconstruya su estado. Este proceso se denomina recuperación de cliente, ya que el cliente dirige el proceso.

Cuando el cliente detecta que el servidor se ha reiniciado, el cliente inmediatamente suspende su actividad actual e inicia el proceso de recuperación de cliente. Cuando el proceso de recuperación se inicia, se muestra un mensaje como el siguiente en registro de errores del sistema /var/adm/messages.

NOTICE: Starting recovery server basil.example.company.com

Durante el proceso de recuperación, el cliente envía información al servidor sobre el estado anterior del cliente. Tenga en cuenta, sin embargo, que durante este período, el cliente no envía las solicitudes nuevas al servidor. Las solicitudes nuevas para abrir archivos o establecer bloqueos de archivos deben esperar hasta que el servidor complete el período de recuperación antes de continuar.

Cuando se completa el proceso de recuperación de cliente, se muestra el siguiente mensaje en el registro de errores del sistema /var/adm/messages.

NOTICE: Recovery done for server basil.example.company.com

Ahora el cliente ha completado correctamente el envío de su información de estado al servidor. Sin embargo, aunque el cliente haya completado este proceso, es posible que otros clientes no hayan completado sus procesos de envío de información de estado al servidor. Por lo tanto, durante un período, el servidor no acepta ninguna solicitud de apertura o bloqueo. Este período, conocido como el período de gracia, se ha designado para permitir que todos los clientes completen su recuperación.

Durante el período de gracia, si el cliente intenta abrir archivos nuevos o establecer bloqueos nuevos, el servidor niega la solicitud con el código de error GRACE. Al recibir este error, el cliente debe esperar a que finalice el período de gracia y, a continuación, reenviar la solicitud al servidor. Durante el período de gracia aparece el siguiente mensaje.

NFS server recovering

Tenga en cuenta que durante el período de gracia los comandos que no abren archivos ni establecen bloqueos de archivos pueden continuar. Por ejemplo, los comandos ls y cd no abren ningún archivo ni establecen un bloqueo de archivo. Por lo tanto, estos comandos no se suspenden. Sin embargo, un comando como cat, que abre un archivo, se suspendería hasta que el período de gracia finalice.

Cuando el período de gracia termina, aparece el siguiente mensaje.

NFS server recovery ok.

El cliente ahora puede enviar nuevas solicitudes de apertura y de bloqueo al servidor.

La recuperación de cliente puede fallar por una serie de razones. Por ejemplo, si existe una partición de red después del reinicio del servidor, es posible que el cliente no pueda restablecer su estado con el servidor antes de que finalice el período de gracia. Una vez que finaliza el período de gracia, el servidor no permite que el cliente restablezca su estado, ya que un nuevo estado de operaciones puede crear conflictos. Por ejemplo, un nuevo bloqueo de archivo puede entrar en conflicto con un bloqueo de archivo anterior que el cliente está intentando recuperar. Cuando ocurre este tipo de situaciones, el servidor devuelve el código de error NO_GRACE al cliente.

Si falla la recuperación de una operación de apertura de un archivo en particular, el cliente marca el archivo como no utilizable y aparece el siguiente mensaje.

WARNING: The following NFS file could not be recovered and was marked dead 
(can't reopen:  NFS status 70):  file :  filename

Tenga en cuenta que el número 70 es sólo un ejemplo.

Si falla el restablecimiento de un bloqueo de archivo durante la recuperación, se publica el siguiente mensaje de error.

NOTICE: nfs4_send_siglost:  pid PROCESS-ID lost
lock on server SERVER-NAME

En esta situación, se publica la señal SIGLOST en el proceso. La acción predeterminada para la señal SIGLOST es terminar el proceso.

Para que pueda recuperarse de este estado, debe reiniciar todas las aplicaciones que tengan archivos abiertos en el momento del fallo. Tenga en cuenta que puede ocurrir lo siguiente.

• Algunos procesos que no volvieron a abrir el archivo pudieron recibir errores I/O.

• Otros procesos que volvieron a abrir el archivo, o que realizaron la operación de apertura después del error de recuperación, pueden acceder al archivo sin problemas.

Por lo tanto, algunos procesos pueden acceder a un archivo determinado mientras que otros procesos no pueden hacerlo.

Compatibilidad de uso compartido OPEN en NFS versión 4

El protocolo NFS versión 4 proporciona varios modos de uso compartido de archivos que el cliente puede utilizar para controlar el acceso de otros clientes. Un cliente puede especificar lo siguiente:

• El modo DENY_NONE permite que otros clientes tengan acceso de lectura y escritura para un archivo.

• El modo DENY_READ impide que otros clientes tengan acceso de lectura para un archivo.

• El modo DENY_WRITE impide que otros clientes tengan acceso de escritura para un archivo.

• El modo DENY_BOTH impide que otros clientes tengan acceso de lectura y escritura para un archivo.

El servidor NFS versión 4 de Oracle Solaris implementa todos estos modos de uso compartido de archivos. Por lo tanto, si un cliente intenta abrir un archivo de forma que entra en conflicto con el modo de uso compartido actual, el servidor impide el intento y hace fallar la operación. Cuando estos intentos fallan con el inicio de las operaciones de apertura o creación, el cliente NFS versión 4 de recibe un error de protocolo. Este error se asigna al error de aplicación EACCES.

Aunque el protocolo proporciona varios modos de uso compartido, en la actualidad, la operación de apertura en Oracle Solaris no ofrece varios modos de uso compartido. Al abrir un archivo, un cliente NFS versión 4 de Oracle Solaris sólo puede utilizar el modo DENY_NONE.

Además, aunque la llamada de sistema fcntl de tiene un comando F_SHARE para controlar el uso compartido de archivos, los comandos fcntl no pueden implementarse correctamente con la versión 4 de NFS. Si utiliza estos comandos fcntl para un cliente NFS versión 4, éste devuelve el error EAGAIN a la aplicación.

Delegación en NFS versión 4

NFS versión 4 proporciona compatibilidad de cliente y servidor para la delegación. La delegación es una técnica mediante la cual el servidor delega la gestión de un archivo a un cliente. Por ejemplo, el servidor puede conceder una delegación de lectura o una delegación de escritura a un cliente. Las delegaciones de lectura se pueden otorgar a varios clientes al mismo tiempo, ya que estas delegaciones de lectura no entran en conflicto entre ellas. Es posible otorgar una delegación de escritura a un solo cliente, ya que la delegación de escritura entra en conflicto con cualquier acceso de archivo de cualquier otro cliente. En posesión de una delegación de escritura, el cliente no enviaría diversas operaciones al servidor porque el cliente tiene acceso exclusivo garantizado a un archivo. De forma similar, el cliente no enviaría diversas operaciones al servidor mientras posee una delegación de lectura. El motivo es que el servidor garantiza que ningún cliente pueda abrir el archivo en el modo de escritura. El efecto de la delegación es reducir en gran medida las interacciones entre el servidor y el cliente para los archivos delegados. Por lo tanto, se reduce el tráfico de la red, y se mejora el rendimiento en el cliente y el servidor. Tenga en cuenta, sin embargo, que el grado de mejora del rendimiento depende del tipo de interacción de archivo utilizada por una aplicación y la cantidad de congestión en la red y el servidor.

La decisión sobre si conceder una delegación la toma completamente el servidor. Un cliente no solicita una delegación. El servidor toma decisiones acerca de si se debe otorgar una delegación o no en función de los patrones de acceso para el archivo. Si varios clientes distintos han accedido recientemente a un archivo en el modo de escritura, es posible que el servidor no otorgue una delegación. El motivo es que este patrón de acceso indica la posibilidad de conflictos futuros.

Se produce un conflicto cuando un cliente accede a un archivo de una forma que sea incoherente con las delegaciones que se han otorgado para ese archivo. Por ejemplo, si un cliente posee una delegación de escritura sobre un archivo y un segundo cliente abre ese archivo para obtener acceso de lectura o escritura, el servidor recupera la primera delegación de escritura del cliente. De manera similar, si un cliente posee una delegación de lectura y otro cliente abre el mismo archivo para escritura, el servidor recupera la delegación de lectura. Tenga en cuenta que en ambas situaciones, no se ha concedido una delegación al segundo cliente porque existe un conflicto. Cuando se produce un conflicto, el servidor utiliza un mecanismo de devolución de llamada para ponerse en contacto con el cliente que posee actualmente la delegación. Al recibir esta devolución de llamada, el cliente envía el estado actualizado del archivo al servidor y devuelve la delegación. Si el cliente no responde a la recuperación, el servidor revoca la delegación. En tales circunstancias, el servidor rechaza todas las operaciones del cliente para este archivo, y el cliente informa las operaciones solicitadas como fallos. Por lo general, estos fallos se notifican en la aplicación como errores de I/O. Para recuperarse de estos errores, el archivo se debe cerrar y, a continuación, volver a abrir. Pueden producirse fallos desde las delegaciones revocadas cuando existe una partición de red entre el cliente y el servidor mientras el cliente posee una delegación.

Tenga en cuenta que un servidor no resuelve los conflictos de acceso para un archivo almacenado en otro servidor. Por lo tanto, un servidor NFS sólo resuelve los conflictos para los archivos que almacena. Además, en respuesta a los conflictos provocados por los clientes que ejecutan varias versiones de NFS, un servidor NFS solamente puede iniciar recuperaciones para el cliente que está ejecutando NFS versión 4. Un servidor NFS no puede iniciar recuperaciones para los clientes que ejecutan versiones anteriores de NFS.

El proceso para detectar conflictos varía. Por ejemplo, a diferencia de la versión 4 de NFS, y como las versiones 2 y 3 no tienen un procedimiento abierto, el conflicto sólo se detecta después de que el cliente intenta leer, escribir o bloquear un archivo. La respuesta del servidor frente a estos conflictos también varía. Por ejemplo:

• Para NFS versión 3, el servidor devuelve el error JUKEBOX, que hace que el cliente detenga la solicitud de acceso y vuelva a intentarlo más tarde. El cliente imprime el mensaje File unavailable.

• Para NFS versión 2, como no existe un equivalente para el error JUKEBOX, el servidor no responde, lo que hace que el cliente deba esperar y volver a intentarlo. El cliente imprime el mensaje NFS server not responding.

Estas condiciones se eliminan una vez que se resuelve el conflicto de delegación.

De manera predeterminada, la delegación de servidor está habilitada. Puede deshabilitar la delegación si establece el parámetro server_delegation en "none". Para obtener información de procedimiento, consulte Cómo seleccionar diferentes versiones de NFS en un servidor.

No se requieren palabras clave para la delegación de cliente. El daemon de devolución de llamadas NFS versión 4, nfs4cbd, proporciona el servicio en el cliente. El daemon se inicia automáticamente siempre que haya un montaje para la versión 4 de NFS habilitado. De manera predeterminada, el cliente ofrece la información de devolución de llamada necesaria al servidor para todos los transportes de Internet que se muestran en el archivo de sistema /etc/netconfig. Tenga en cuenta que si el cliente está habilitado para IPv6 y la dirección IPv6 para el nombre del cliente se puede determinar, el daemon de devolución de llamadas acepta las conexiones IPv6.

El daemon de devolución de llamadas utiliza un número de programa transitorio y un número de puerto asignado de forma dinámica. Esta información se proporciona al servidor, y el servidor prueba la ruta de devolución de llamadas antes de conceder delegaciones. Si la ruta de devolución de llamadas no es correcta, el servidor no otorga las delegaciones, lo cual es el único comportamiento externamente visible.

Tenga en cuenta que, debido a la información de devolución de llamadas integrada en una solicitud de NFS versión 4, el servidor no puede establecer contacto con el cliente a través de un dispositivo que utiliza traducción de direcciones de red (NAT). Además, el daemon de devolución de llamadas utiliza un número de puerto dinámico. Por lo tanto, es posible que el servidor no pueda atravesar un cortafuegos, incluso si el cortafuegos permite el tráfico NFS normal en el puerto 2049. En tales situaciones, el servidor no otorga delegaciones.

ACL y nfsmapid en NFS versión 4

Una lista de control de acceso (ACL) proporciona una mejor seguridad de archivos al habilitar al responsable de un archivo para que defina los permisos para el responsable del archivo, el grupo u otros usuarios o grupos específicos. En sistemas de archivos ZFS, las ACL se establecen en el servidor y el cliente mediante el comando chmod. Para sistemas de archivos UFS, utilice el comando setfacl. Consulte las páginas del comando man chmod(1) y setfacl(1) para obtener más información. En la versión 4 de NFS, el asignador de ID nfsmapid se utiliza para asignar los ID de usuario o de grupo en las entradas de la ACL de un servidor a los ID de usuario o de grupo en las entradas de ACL de un cliente. Lo contrario también es cierto. Los ID de grupo y de usuario en las entradas de la ACL deben existir en el cliente y el servidor.

Motivos de falla de la asignación de ID

Las siguientes situaciones pueden originar una falla en la asignación de ID:

• Si el usuario o grupo que existe en una entrada de la ACL en el servidor no se puede asignar a un usuario o grupo válidos en el cliente, el usuario puede leer la ACL, pero algunos de los usuarios o grupos se mostrarán como “desconocidos”.

  Por ejemplo, cuando emite el comando ls -lv o ls -lV, en algunas de las entradas de ACL, se mostrará el grupo o el usuario como “unknown”. Para obtener más información sobre este comando, consulte la página del comando man ls(1).

• Si el ID de usuario o grupo en cualquier entrada de la ACL establecida en el cliente no se puede asignar a un ID de usuario o grupo válido en el servidor, el comando setfacl o chmod puede fallar y devolver el mensaje de error Permission denied.

• Si el cliente y el servidor no hacen coincidir correctamente los valores nfsmapid_domain, la asignación de ID falla. Para obtener más información, consulte Daemon nfsmapid.

Cómo evitar problemas de asignación de ID con las ACL

Para evitar problemas de asignación de ID, realice lo siguiente:

• Asegúrese de que el valor de nfsmapid_domain esté definido correctamente.

• Asegúrese de que todos los ID de usuario y de grupo en las entradas de la ACL existan tanto en el cliente como en el servidor de NFS versión 4.

Comprobación de ID de usuario o de grupo sin asignar

Para determinar si un usuario o grupo no se pueden asignar al servidor o el cliente, utilice la siguiente secuencia de comandos:

#! /usr/sbin/dtrace -Fs

sdt:::nfs4-acl-nobody
{
     printf("validate_idmapping: (%s) in the ACL could not be mapped!", 
stringof(arg0));
}

Información adicional sobre las ACL o nfsmapid

Consulte lo siguiente:

• Capítulo 8, Uso de listas de control de acceso y atributos para proteger archivos Oracle Solaris ZFS de Administración de Oracle Solaris: sistemas de archivos ZFS

• Daemon nfsmapid

Negociación UDP y TCP

Durante el inicio, también se negocia el protocolo de transporte. De manera predeterminada, se selecciona el primer transporte orientado a la conexión que se admite tanto en el cliente como en el servidor. Si esta selección no se realiza correctamente, se utiliza el primer protocolo de transporte sin conexión disponible. Los protocolos de transporte que se admiten en un sistema se muestran en /etc/netconfig. TCP es el protocolo de transporte orientado a la conexión que es compatible con la versión. UDP es el protocolo de transporte sin conexión.

Cuando la versión del protocolo NFS y el protocolo de transporte se determinan mediante negociación, la versión del protocolo NFS tiene prioridad sobre el protocolo de transporte. El protocolo NFS versión 3 que utiliza UDP tiene mayor prioridad que el protocolo NFS versión 2 que está utilizando TCP. Puede seleccionar de forma manual tanto la versión del protocolo NFS como el protocolo de transporte con el comando mount. Consulte la página del comando man mount_nfs(1M). En la mayoría de las condiciones, permita que la negociación seleccione las opciones más adecuadas.

Negociación de tamaño de transferencia de archivos

El tamaño de transferencia del archivo establece el tamaño de las memorias intermedias que se utilizan al transferir datos entre el cliente y el servidor. En general, mientras mayor sea el tamaño de la transferencia, mejor. El protocolo NFS versión 3 tiene tamaño de transferencia ilimitado. El cliente puede pedir un tamaño menor de transferencia en el momento del montaje si es necesario, pero en la mayoría de los casos esto no es necesario.

El tamaño de transferencia no se negocia con sistemas que utilizan el protocolo NFS versión 2. En este caso, el tamaño de transferencia máximo se establece en 8 Kbytes.

Puede utilizar las opciones -rsize y -wsize para establecer el tamaño de transferencia manualmente con el comando mount. Es posible que necesite reducir el tamaño de transferencia para algunos clientes de PC. Además, puede aumentar el tamaño de transferencia si el servidor NFS está configurado para utilizar tamaños de transferencias más grandes.

Cómo se montan los sistemas de archivos

La siguiente descripción se aplica a los montajes de NFS versión 3. El proceso de montaje de NFS versión 4 no incluye el servicio de asignación de puerto ni incluye el protocolo MOUNT.

Si un cliente necesita montar un sistema de archivos desde un servidor, el cliente debe obtener un identificador de archivos del servidor. El identificador de archivos debe corresponderse con el sistema de archivos. Este proceso exige que varias transacciones ocurran entre el cliente y el servidor. En este ejemplo, el cliente intenta montar /home/terry desde el servidor. A continuación sigue un rastreo snoop para esta transacción.

client -> server PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP
server -> client PORTMAP R GETPORT port=33492
client -> server MOUNT3 C Null
server -> client MOUNT3 R Null 
client -> server MOUNT3 C Mount /export/home9/terry
server -> client MOUNT3 R Mount OK FH=9000 Auth=unix
client -> server PORTMAP C GETPORT prog=100003 (NFS) vers=3 proto=TCP
server -> client PORTMAP R GETPORT port=2049
client -> server NFS C NULL3
server -> client NFS R NULL3 
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

En este rastreo, el cliente primero solicita el número de montaje de puerto del servicio de asignación de puerto en el servidor NFS. Después de que el cliente recibe el número de puerto montaje (33492), el número se utiliza para probar la disponibilidad del servicio en el servidor. Después de que el cliente haya determinado que un servicio se está ejecutando en ese número de puerto, el cliente realiza una solicitud de montaje. Cuando el servidor responde a esta solicitud, el servidor incluye el identificador de archivo para el sistema de archivos (9000) que se está montando. A continuación, el cliente envía una solicitud para el número de puerto NFS. Cuando el cliente recibe el número del servidor, el cliente prueba la disponibilidad del servicio NFS (nfsd). También, el cliente solicita a NFS información sobre el sistema de archivos que utiliza el identificador de archivos.

En el siguiente rastreo, el cliente monta el sistema de archivos con la opción public.

client -> server NFS C LOOKUP3 FH=0000 /export/home9/terry
server -> client NFS R LOOKUP3 OK FH=9000
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

Al utilizar el identificador de archivos público predeterminado (que es 0000), se omiten todas las transacciones para obtener información del servicio de asignación de puerto y para determinar el número de puerto NFS.

Efectos de la opción -public y direcciones URL NFS al montar

Mediante la opción -public, puede crear condiciones que hagan que falle un montaje. Si agrega una URL de NFS también puede confundir la situación. La siguiente lista describe los aspectos concretos de cómo se monta un sistema de archivos al utilizar estas opciones.

• Opción pública con URL de NFS: fuerza el uso del identificador de archivos público. El montaje falla si el identificador de archivos público no es compatible.

• Opción pública con ruta de acceso regular: fuerza el uso del identificador de archivos público. El montaje falla si el identificador de archivos público no es compatible.

• Sólo URL de NFS: use el identificador de archivos público si el identificador de archivos está habilitado en el servidor NFS. Si el montaje falla cuando se utiliza el identificador de archivos público, pruebe el montaje con el protocolo MOUNT.

• Sólo ruta de acceso normal: no utilice el identificador de archivos público. Se utiliza el protocolo MOUNT.

Conmutación por error por parte del cliente

Mediante la conmutación por error por parte del cliente, un cliente NFS puede estar al tanto de varios servidores que hacen que los mismos datos estén disponibles y puede cambiar a un servidor alternativo cuando el servidor actual no está disponible. El sistema de archivos puede llegar a no estar disponible si se produce una de las siguientes opciones.

• Si el sistema de archivos está conectado a un servidor que se bloquea

• Si el servidor está sobrecargado

• Si se produce una falla en la red

En estas condiciones, la conmutación por error es normalmente transparente para el usuario. Por lo tanto, la conmutación por error puede ocurrir en cualquier momento sin interrumpir los procesos que se están ejecutando en el cliente.

La conmutación por error requiere que el sistema de archivos sea montado como de sólo lectura. Los sistemas de archivos deben ser idénticos para que la conmutación por error se produzca correctamente. Consulte ¿Qué es un sistema de archivos replicado? para obtener una descripción de qué es lo que hace que un sistema de archivos sea idéntico. Un sistema de archivos estático o un sistema de archivos que no se cambia frecuentemente es el mejor candidato para la conmutación por error.

No puede utilizar CacheFS y conmutación por error por parte del cliente en el mismo montaje NFS. Se almacena información adicional para cada sistema de archivos CacheFS. Esta información no se puede actualizar durante la conmutación por error, por lo que sólo una de estas dos funciones se puede utilizar para montar un sistema de archivos.

El número de réplicas que es necesario establecer para cada sistema de archivos depende de muchos factores. En una situación ideal, debe tener un mínimo de dos servidores. Cada servidor debe admitir varias subredes. Esta configuración es mejor que tener un único servidor en cada subred. El proceso requiere que se compruebe cada servidor que figure. Por lo tanto, si figuran más de un servidor, cada montaje es más lento.

Terminología de conmutación por error

Para comprender completamente el proceso, debe comprender dos términos.

• Conmutación por error: el proceso de seleccionar un servidor de una lista de servidores que admiten un sistema de archivos replicado. Normalmente, se utiliza el siguiente servidor de la lista ordenada, a menos que no responda.

• Reasignar: utilizar un servidor nuevo. Normalmente, los clientes almacenan el nombre de ruta de acceso de cada archivo activo en el sistema de archivos remoto. Durante la reasignación, estos nombres de ruta se evalúan para localizar los archivos en el nuevo servidor.

¿Qué es un sistema de archivos replicado?

Para la conmutación por error, un sistema de archivos puede llamarse réplica cuando cada archivo es del mismo tamaño y tiene el mismo tamaño de archivo o tipo de archivo que el sistema de archivos original. Los permisos, fechas de creación y otros atributos de los archivos no se toman en consideración. Si el tamaño de archivo o los tipos de archivo son diferentes, la reasignación falla y el proceso se bloquea hasta que el antiguo servidor esté disponible. En NFS versión 4, el comportamiento es diferente. Consulte Conmutación por error por parte del cliente en NFS versión 4.

Puede mantener un sistema de archivos replicado si utiliza rsync, cpio u otro mecanismo de transferencia de archivos. Como la actualización de los sistemas de archivos replicados causa incoherencia, para obtener mejores resultados tenga en cuenta estas precauciones:

• Cambie el nombre de la versión anterior del archivo antes de instalar una nueva versión del archivo.

• Ejecute las actualizaciones de noche, cuando el uso del cliente es bajo.

• Mantenga actualizaciones pequeñas.

• Minimice el número de copias.

Conmutación por error y bloqueo NFS

Algunos paquetes de software requieren bloqueos de lectura en los archivos. Para evitar que estos productos se interrumpan, los bloqueos de lectura de los sistemas de archivos de sólo lectura se permiten, pero sólo son visibles para el lado del cliente. Los bloqueos persisten durante la reasignación, ya que el servidor no “conoce” los bloqueos. Como los archivos no deben cambiar, no necesita bloquear el archivo por parte del servidor.

Conmutación por error por parte del cliente en NFS versión 4

En la versión 4 de NFS, si no se puede establecer una réplica porque los tamaños de archivo son diferentes o los tipos de archivo no son los mismos, ocurre lo siguiente.

• El archivo se marca como inoperativo.

• Se imprime una advertencia.

• La aplicación recibe un fallo en la llamada de sistema.

En la versión 4 de NFS, dejará de recibir errores de replicación para los directorios de diferentes tamaños. En versiones anteriores de NFS, esta condición se trataba como error e impedía el proceso de reasignación.

Además, en la versión 4 de NFS, si una operación de lectura no es correcta, la operación es realizada por el siguiente servidor en la lista. En versiones anteriores de NFS, las operaciones de lectura incorrectas hacían que la reasignación fallara y el proceso se bloqueara hasta que el servidor original estuviera disponible.

Archivos de gran tamaño

El SO admite archivos de más de 2 Gbytes. De manera predeterminada, los sistemas de archivos UFS se montan con la opción -largefiles para admitir la nueva capacidad. Si es necesario, consulte Cómo deshabilitar archivos grandes en un servidor NFS para obtener instrucciones.

Si el sistema de archivos del servidor se monta con la opción -largefiles, un cliente puede acceder a archivos de gran tamaño sin necesidad de cambios. Sin embargo, no todos los comandos pueden manejar estos archivos grandes. Consulte largefile(5) para obtener una lista de los comandos que pueden manejar archivos grandes. Los clientes que no son compatibles con el protocolo NFS versión 3 con grandes extensiones de archivos no pueden acceder a ningún archivo grande.

Cómo funciona el registro del servidor NFS

El registro del servidor NFS registra lecturas y escrituras de NFS, así como operaciones que modifican el sistema de archivos. Estos datos se pueden utilizar para realizar un seguimiento del acceso a la información. Además, los registros pueden proporcionar una forma cuantitativa de medir su interés por la información.

Cuando se accede a un sistema de archivos con registro habilitado, el núcleo escribe los datos sin formato en un archivo de memoria intermedia. Entre estos elementos, se incluyen:

• Una indicación de hora

• La dirección IP del cliente

• El UID del solicitante

• El identificador de archivo del archivo o el objeto de directorio al que se accede

• El tipo de operación que se ha producido

El daemon nfslogd convierte estos datos sin formato en registros ASCII que se almacenan en los archivos de registro. Durante la conversión, las direcciones IP se modifican por nombres de host y los UID se modifican por inicios de sesión si el servicio de nombres que está habilitado puede encontrar coincidencias. Los identificadores de archivos también se convierten en nombres de ruta. Para realizar la conversión, el daemon realiza un seguimiento de los identificadores de archivos y almacena información en una tabla independiente de identificador de archivo a ruta. De esa manera, la ruta no tiene que ser identificada de nuevo cada vez que se accede a un identificador de archivos. Como no se realizan cambios en las asignaciones en la tabla de identificador de archivo a rutas, si el comando nfslogd está desactivado, debe mantener el daemon en ejecución.

Cómo funciona el servicio WebNFS

El servicio WebNFS hace que los archivos de un directorio estén disponibles para los clientes mediante un identificador de archivos público. Un identificador de archivos es una dirección generada mediante el núcleo que identifica un archivo para los clientes NFS. El identificador de archivos público tiene un valor predefinido, por lo que no es necesario que el servidor genere un identificador de archivos para el cliente. La posibilidad de utilizar este identificador de archivos predefinido reduce el tráfico de red mediante la eliminación del protocolo MOUT. Esta capacidad debería acelerar los procesos para los clientes.

De manera predeterminada, el identificador de archivos público en un servidor NFS se establece en el sistema de archivos root. Este valor predeterminado proporciona acceso WebNFS a los clientes que ya tienen los privilegios de montaje en el servidor. Puede cambiar el identificador de archivos público para que señale a cualquier sistema de archivos mediante el comando share.

Cuando el cliente tiene el identificador de archivos para el sistema de archivos, se ejecuta un comando LOOKUP para determinar el identificador de archivos del archivo al que se va a acceder. El protocolo NFS permite la evaluación de sólo un componente de nombre de ruta a la vez. Cada nivel adicional de jerarquía de directorios requiere otro comando LOOKUP. Un servidor WebNFS puede evaluar todo un nombre de ruta con una sola transacción de consulta multicomponente cuando el comando LOOKUP es relativo al identificador de archivos público. La consulta multicomponente permite que el servidor WebNFS envíe el identificador de archivos al archivo deseado sin necesidad de intercambiar identificadores de archivos para cada nivel del directorio en el nombre de la ruta.

Además, un cliente NFS puede iniciar descargas simultáneas a través de una única conexión TCP. Esta conexión proporciona acceso rápido sin la carga adicional del servidor provocada por la configuración de múltiples conexiones. Aunque las aplicaciones de exploradores web admiten la descarga simultánea de varios archivos, cada archivo tiene su propia conexión. Mediante una conexión, el software WebNFS reduce la carga en el servidor.

Si el componente final en el nombre de ruta es un enlace simbólico a otro sistema de archivos, el cliente puede acceder al archivo si el cliente ya tiene acceso mediante actividades de NFS normales.

Normalmente, una URL de NFS se evalúa en relación con el identificador de archivos público. La evaluación se puede cambiar para que sea relativa al sistema de archivos root del servidor al agregar una barra diagonal adicional al comienzo de la ruta de acceso. En este ejemplo, estas dos URL de NFS son equivalentes si el identificador de archivos público que se ha establecido en el sistema de archivos /export/ftp.

nfs://server/junk
nfs://server//export/ftp/junk

Cómo funciona la negociación de seguridad WebNFS

El servicio NFS incluye un protocolo que permite que un cliente WebNFS negocie un mecanismo de seguridad seleccionado con un servidor WebNFS. El nuevo protocolo utiliza consulta multicomponente de negociación de seguridad, que es una extensión de la consulta multicomponente que se había utilizado en versiones anteriores del protocolo WebNFS.

El cliente WebNFS inicia el proceso al realizar una solicitud de consulta multicomponente regular mediante el identificador de archivos público. Como el cliente no tiene constancia de cómo el servidor protege la ruta, se utiliza el valor del mecanismo de seguridad predeterminado. Si el valor predeterminado del mecanismo de seguridad no es suficiente, el servidor responde con un error AUTH_TOOWEAK. Esta respuesta indica que el mecanismo predeterminado no es válido. El cliente debe utilizar un mecanismo predeterminado más fuerte.

Cuando el cliente recibe el error AUTH_TOOWEAK, el cliente envía una solicitud al servidor para determinar qué mecanismos de seguridad son necesarios. Si la solicitud se realiza correctamente, el servidor responde con una matriz de los mecanismos de seguridad que son necesarios para la ruta especificada. Según el tamaño de la matriz de los mecanismos de seguridad, es posible que el cliente tenga que realizar más solicitudes para obtener la matriz completa. Si el servidor no admite la negociación de seguridad WebNFS, la solicitud falla.

Después de una solicitud correcta, el cliente WebNFS selecciona el primer mecanismo de seguridad de la matriz que el cliente admite. A continuación, el cliente emite una solicitud de consulta multicomponente regular mediante el mecanismo de seguridad seleccionado para adquirir el identificador de archivos. Las siguientes peticiones NFS se realizan mediante el mecanismo de seguridad seleccionado y el identificador de archivos.

Limitaciones WebNFS con uso de explorador web

Muchas de las funciones que puede proporcionar un sitio web que utiliza HTTP no son compatibles con el software WebNFS. Estas diferencias provienen del hecho de que el servidor NFS sólo envía el archivo, por lo que cualquier procesamiento especial debe realizarse en el cliente. Si necesita tener un sitio web configurado para acceso WebNFS y HTTP, tenga en cuenta las siguientes cuestiones:

• La exploración NFS no ejecuta secuencias de comandos CGI. Por lo tanto, un sistema de archivos con un sitio web activo que utiliza muchas secuencias de comandos CGI podría no ser apropiado para la exploración NFS.

• El explorador podría iniciar diferentes visores para manejar archivos en formatos de archivo diferentes. El acceso a estos archivos a través de una URL de NFS inicia un visor externo si el tipo de archivo puede determinarse por medio del nombre del archivo. El explorador debe reconocer cualquier extensión de nombre de archivo para un tipo MIME estándar cuando se utiliza una URL de NFS. El software WebNFS no comprueba dentro del archivo para determinar el tipo de archivo. Por lo tanto, la única manera de determinar un tipo de archivo es la extensión del nombre del archivo.

• La exploración NFS no puede utilizar los mapas de imágenes por parte del servidor (imágenes interactivas). Sin embargo, la exploración NFS puede utilizar mapas de imágenes por parte del cliente (imágenes interactivas) porque las direcciones URL se definen con la ubicación. No se necesitan respuestas adicionales del servidor de documentos.

Sistema NFS seguro

El entorno NFS es una forma poderosa y conveniente de compartir sistemas de archivos en una red de distintas arquitecturas de equipos y sistemas operativos. Sin embargo, las mismas funciones que hacen que el uso compartido de sistemas de archivos a través de la operación NFS sea cómodo, también plantean algunos problemas de seguridad. Históricamente, la mayoría de las implementaciones NFS han utilizado autenticación UNIX (o AUTH_SYS) pero también ha habido métodos de autenticación más seguros, como AUTH_DH, disponibles. Al utilizar autenticación UNIX, un servidor NFS autentica una solicitud de archivo al autentificar el equipo que formula la solicitud, pero no el usuario. Por lo tanto, un usuario cliente puede ejecutar su y suplantar al responsable de un archivo. Si se utiliza la autenticación DH, el servidor NFS autentica el usuario, lo cual hace que este tipo de suplantación sea mucho más difícil.

Con acceso root y conocimiento de programación de red, cualquier usuario puede introducir datos arbitrarios en la red y extraer cualquier dato de ella. Los ataques más peligrosos son los que implican la introducción de datos. Un ejemplo es la suplantación de un usuario mediante la generación de paquetes correctos o mediante la grabación de “conversaciones” y su posterior reproducción. Estos ataques afectan la integridad de los datos. Los ataques que implican intrusiones pasivas, es decir, recibir el tráfico de la red sin suplantar a nadie, no son tan peligrosos, porque integridad de los datos no queda comprometida. Los usuarios pueden proteger la privacidad de la información confidencial mediante el cifrando de los datos que se envían a través de la red.

Un enfoque común para los problemas de seguridad de la red es dejar la solución a cada aplicación. Un mejor enfoque es implementar un sistema de autenticación estándar en un nivel que cubra todas las aplicaciones.

El sistema operativo Oracle Solaris incluye un sistema de autenticación en el nivel de llamada de procedimiento remoto (RPC), que es el mecanismo en el que se crea la operación NFS. Este sistema, conocido como RPC seguras, mejora mucho la seguridad de los entornos de red y proporciona seguridad adicional a los servicios como, por ejemplo, el sistema NFS. Cuando el sistema NFS utiliza las utilidades que se proporcionan con RPC seguras, esto se conoce como sistema NFS seguro.

RPC segura

Las RPC seguras son fundamentales para un sistema NFS seguro. El objetivo de las RPC seguras es crear un sistema que sea tan seguro, como mínimo, como un sistema de tiempo compartido. En un sistema de tiempo compartido, todos los usuarios comparten un único equipo. Un sistema de tiempo compartido autentifica un usuario mediante una contraseña de conexión. Con la autenticación estándar de cifrado de datos (DES), se completa el mismo proceso de datos de autenticación. Los usuarios pueden iniciar sesión en cualquier equipo remoto al igual que los usuarios pueden iniciar sesión en una terminal local. Las contraseñas de inicio de sesión de los usuarios son sus garantías de seguridad de la red. En un entorno de tiempo compartido, el administrador del sistema tiene una obligación ética de no cambiar una contraseña para sustituir a alguien. En las RPC seguras, se confía que el administrador de la red no modificará entradas en una base de datos que almacena las claves públicas.

Debe conocer dos términos para entender un sistema de autenticación RPC: credenciales y verificadores. Con las insignias de ID como ejemplo, la credencial es lo que identifica una persona: un nombre, dirección y fecha de nacimiento. El verificador es la fotografía que se adjunta a la insignia. Puede tener la certeza de que la insignia no se ha robado al comprobar la fotografía que aparece en ella con la persona que la lleva. En RPC, el proceso del cliente envía una credencial y un verificador al servidor con cada solicitud de RPC. El servidor vuelve a enviar sólo un verificador porque el cliente ya "conoce" las credenciales del servidor.

La autenticación de RPC es abierta, lo que significa que es posible conectar una variedad de sistemas de autenticación, como UNIX, DH y KERB.

Cuando un servicio de red usa la autenticación UNIX, las credenciales contienen el nombre de host del cliente, UID, GID y la lista de acceso de grupos. Sin embargo, el verificador no contiene nada. Como no existe un verificador, un superusuario puede falsificar las credenciales adecuadas mediante comandos como su. Otro problema con la autenticación UNIX es que asume que todos los equipos de una red son equipos UNIX. La autenticación UNIX se desglosa cuando se aplica a otros sistemas operativos en una red heterogénea.

Para superar los problemas de autenticación UNIX, las RPC seguras utilizan autenticación DH.

Autenticación DH

La autenticación DH utiliza el estándar de cifrado de datos (DES) y criptografía por clave pública Diffie-Hellman para autenticar a los usuarios y los equipos en la red. DES es un mecanismo de cifrado estándar. La criptografía por clave pública Diffie-Hellman es un sistema de cifrado que involucra dos claves: una pública y una secreta. Las claves públicas y las claves secretas se almacenan en el espacio de nombres. NIS almacena las claves en el mapa de claves públicas. Estos mapas contienen la clave pública y la clave secreta de todos los usuarios potenciales. Consulte Oracle Solaris Administration: Naming and Directory Services para obtener más información sobre cómo configurar los mapas.

La seguridad de la autenticación DH se basa en la capacidad del remitente de cifrar la hora actual, que el receptor luego puede descifrar y verificar con su propio reloj. La indicación de hora se cifra con DES. Los requisitos para que este esquema funcione son los siguientes:

• Los dos agentes deben coincidir en el tiempo actual.

• El emisor y el receptor deben utilizar la misma clave de cifrado.

Si una red ejecuta un programa de sincronización de tiempo, el tiempo del cliente y el servidor se sincronizan automáticamente. Si un programa de sincronización de tiempo no está disponible, los indicadores de tiempo se pueden calcular utilizando el horario del servidor en lugar del de la red. El cliente pregunta la hora al servidor antes de iniciar la sesión RPC y, luego, calcula la diferencia de tiempo entre reloj del servidor y su propio reloj. Esta diferencia se utiliza para compensar el reloj del cliente al calcular los indicadores de fecha y hora. Si los relojes del cliente y el servidor dejan de estar sincronizados, el servidor empieza a rechazar las solicitudes del cliente. El sistema de autenticación DH en el cliente se vuelve a sincronizar con el servidor.

El cliente y el servidor llegan a la misma clave de cifrado al generar una clave de conversación aleatoria, también conocida como clave de sesión y al usar criptografía por clave pública para deducir una clave común. La clave común es una clave que sólo el cliente y el servidor son capaces de deducir. La clave de conversación se utiliza para cifrar y descifrar la indicación de hora del cliente. La clave común se emplea para cifrar y descifrar la clave de conversación.

Autenticación KERB

Kerberos es un sistema de autenticación desarrollado en el MIT. Kerberos ofrece una gran variedad de tipos de cifrado, incluidos DES. La compatibilidad con Kerberos ya no es proporcionada como parte de RPC seguras, pero se incluye una implementación por parte del servidor y por parte del cliente en la versión. Consulte Capítulo 19, Introducción al servicio Kerberos de Administración de Oracle Solaris: servicios de seguridad para obtener más información sobre la implementación de la autenticación Kerberos.

Uso de RPC seguras con NFS

Tenga en cuenta los siguientes puntos si tiene planificado utilizar RPC seguras:

• Si un servidor se bloquea cuando no hay nadie cerca (después de un fallo de energía, por ejemplo), se eliminan todas las claves secretas almacenadas en el sistema. Entonces no hay ningún proceso que pueda acceder a los servicios de red seguros o montar un sistema de archivos NFS. Los procesos importantes durante un reinicio se ejecutan normalmente como root. Por lo tanto, estos procesos funcionarían si la clave secreta root se hubiera almacenado en otro lugar, pero nadie estaría disponible para escribir la contraseña que los descifra. keylogin -r permite que root almacene la clave secreta borrada en /etc/.rootkey, que keyserv lee.

• Algunos sistemas se inician en modo de usuario único, con un shell de inicio de sesión root en la consola y sin solicitud de contraseña. La seguridad física es imperativa en estos casos.

• El inicio de equipos sin disco no es totalmente seguro. Otra persona puede conectarse como el servidor de inicio e iniciar un núcleo ilícito que, por ejemplo, haga un registro de la clave secreta en un equipo remoto. El sistema NFS seguro proporciona protección sólo después de que el núcleo y el servidor de claves se ejecuten. De lo contrario, no hay forma de autenticar las respuestas que son dadas por el servidor de inicio. Esta limitación podría ser un problema grave, pero la limitación requiere un ataque sofisticado, utilizando código fuente del núcleo. Además, el delito dejaría evidencia. Si sondea la red para los servidores de inicio, detectaría la ubicación del servidor de inicio ilícito.

• La mayoría de los programas setuid son responsabilidad de root. Si la clave secreta de root se almacena en /etc/.rootkey, estos programas se comportan como siempre. Si un programa setuid es responsabilidad de un usuario, es posible que no siempre funcione el programa setuid. Por ejemplo, supongamos que un programa setuid es responsabilidad de dave y dave no ha iniciado sesión en el equipo desde que se inició. El programa no podría acceder a los servicios de red segura.

• Si inicia sesión en un equipo remoto (con login, rlogin o telnet) y usa keylogin para obtener acceso, otorga acceso a su cuenta. El motivo es que su clave secreta se transfiere al servidor de ese equipo, que luego almacena la clave secreta. Este proceso sólo es una preocupación si no confía en el equipo remoto. Si tiene dudas, sin embargo, no inicie sesión en un equipo remoto si éste requiere una contraseña. En su lugar, utilice el entorno NFS para montar los sistemas de archivos que compartirá el equipo remoto. Como alternativa, puede utilizar keylogout para suprimir la clave secreta del servidor de claves.

• Si un directorio principal se comparte con la opción -o sec=dh, los inicios de sesión remotos pueden ser un problema. Si los archivos /etc/hosts.equiv o ~/.rhosts no están configurados para solicitar una contraseña, el inicio de sesión se realiza correctamente. Sin embargo, los usuarios no pueden acceder a sus directorios principales porque no se ha producido la autenticación localmente. Si se le pide una contraseña al usuario, el usuario tiene acceso a su directorio principal si la contraseña coincide con la contraseña de la red.