Network File System (NFS) es un sistema de archivos de red. Opciones de manejo de errores de NFS. Versiones y variaciones

En este punto, debería tener una conexión TCP/IP en funcionamiento a su red. Debería poder hacer ping a otras computadoras en la red y, si ha configurado la puerta de enlace correctamente, también debería poder hacer ping a las computadoras en Internet. Como sabe, el objetivo principal de conectar una computadora a una red es obtener acceso a la información. Si bien algunas personas pueden simplemente conectar una computadora a una red, a la mayoría de las personas les gustaría compartir y acceder a archivos e impresoras. Les gustaría acceder a documentos en Internet o jugar juegos en línea. Al instalar soporte TCP/IP y el software necesario en su nuevo sistema Slackware, lo obtiene todo; sin embargo, al instalar solo soporte TCP/IP, la funcionalidad será muy limitada. Para compartir y compartir archivos, necesitaremos transferirlos de un lado a otro mediante FTP o SCP. No podemos explorar el árbol de archivos en nuestra nueva computadora Slackware a través de los íconos de Entorno de red o Toda la red de las computadoras con Windows. Nos gustaría poder acceder permanentemente a archivos en otras máquinas Unix.

Idealmente nos gustaría usar sistema de archivos de red, permitiéndonos tener un acceso transparente a los archivos en las computadoras. Los programas que usamos para trabajar con la información almacenada en las computadoras ni siquiera necesitan saber en qué computadora está almacenado el archivo. Solo necesitan saber que el archivo existe y una forma de obtenerlo. El resto ya es tarea del sistema operativo, que proporciona acceso a este archivo utilizando los sistemas de archivos locales y de red disponibles. Los dos sistemas de archivos de red más utilizados son SMB (implementado a través de Samba) y NFS.

5.6.1. SMB/Samba/CIFS

SMB (Server Message Block) es un descendiente del antiguo protocolo NetBIOS desarrollado originalmente por IBM para su producto LAN Manager. Microsoft, por su parte, siempre se ha interesado por NetBIOS y sus sucesores (NetBEUI, SMB y CIFS). El proyecto Samba comenzó en 1991 cuando fue escrito para proporcionar comunicación entre una PC IBM y un servidor Unix. Hoy en día, compartir archivos y servicios de impresión a través de una red SMB es el método elegido por prácticamente todo el mundo civilizado, ya que Windows también lo admite.

El archivo de configuración de Samba /etc/samba/smb.conf es uno de los archivos de configuración mejor documentados que puede encontrar. Ya hay ejemplos listos para usar con configuraciones para compartir para que pueda revisarlos y modificarlos según sus necesidades. Si necesita aún más control, la página del manual smb.conf está a su servicio. Debido a que Samba tiene una documentación tan buena, no la volveremos a escribir aquí. Sin embargo, repasemos rápidamente los puntos principales.

smb.conf se divide en varias secciones: una sección por recurso compartido más una sección global para establecer parámetros que se utilizan en todas partes. Algunos parámetros son válidos solo en la sección global, y algunos son válidos solo fuera de ella. Recuerde que la sección global puede ser anulada por cualquier otra sección. Consulte las páginas del manual para obtener más información.

Lo más probable es que desee editar su archivo smb.conf para reflejar la configuración de su red local. Le recomendamos que cambie los siguientes elementos:

Esta será la descripción de su computadora Slackware, que se muestra en la carpeta Entorno de red (o Red completa).

Es casi seguro que querrá usar el nivel de seguridad del usuario en su sistema Slackware.

Si el cifrado de contraseña no está habilitado, no podrá usar Samba con los sistemas NT4.0, Win2k, WinXP y Win2003. Las versiones anteriores de los sistemas operativos Windows no requerían el cifrado para otorgar acceso a los recursos compartidos.

SMB es un protocolo autenticado, es decir, puede proporcionar un nombre de usuario y una contraseña para aprovechar este servicio. Le decimos al servidor samba que los nombres de usuario y contraseñas son correctos usando el comando smbpasswd. smbpasswd permite el uso de claves públicas para agregar usuarios normales y máquinas de usuario (SMB requiere que agregue los nombres NETBIOS de las computadoras como máquinas de usuario, lo que limita de qué computadoras pueden autenticarse).

Es importante tener en cuenta que este nombre de usuario o máquina ya debe existir en el archivo /etc/passwd. Puede lograr esto con el comando adduser. Tenga en cuenta que cuando usa el comando adduser para agregar un nombre de computadora, debe agregarle un signo de dólar ("$"). Sin embargo, esto no debe hacerse cuando se trabaja con smbpasswd. La utilidad smbpasswd agrega el signo de dólar. La violación de esta regla con adduser dará como resultado un error al agregar el nombre de host a samba.

5.6.2. Sistema de archivos de red (NFS)

NFS (Network File System) fue escrito originalmente por Sun para Solaris, su implementación del sistema Unix. Y aunque es mucho más fácil de instalar y configurar que SMB, NFS es mucho menos seguro. La principal debilidad de la seguridad es la facilidad de sustituir ID de usuario y grupo en una máquina por ID en otra máquina. El protocolo NFS no implementa la autenticación. Se ha dicho que las futuras versiones del protocolo NFS mejorarán la seguridad, pero esto aún no se ha hecho en el momento de escribir este artículo.

NFS se configura a través del archivo /etc/exports. Cuando cargue el archivo estándar /etc/exports en el editor, verá un archivo vacío con un comentario de dos líneas en la parte superior. Tendremos que agregar una línea al archivo de exportaciones para cada uno de los directorios que queremos exportar, enumerando las estaciones de trabajo de los clientes a las que se les permitirá acceder a ese directorio. Por ejemplo, si queremos exportar el directorio /home/foo para una estación de trabajo Bar, debemos agregar la siguiente línea a nuestro archivo /etc/exports:

Como puede ver, hay varias opciones diferentes, pero la mayoría de ellas deberían quedar claras en este ejemplo.

NFS asume que un usuario determinado de una de las máquinas de la red tiene la misma identidad en todas las demás máquinas. Cuando un cliente NFS intenta leer o escribir en un servidor NFS, el UID se pasa como parte de la solicitud de lectura/escritura. Se supone que este UID es el mismo que si la solicitud se hubiera realizado desde la máquina local. Como puede ver, si alguien puede especificar arbitrariamente un UID determinado al acceder a los recursos en una máquina remota, pueden ocurrir cosas malas, y de hecho suceden. Una forma de evitar esto en parte es montar todos los directorios con la opción root_squash. Esto reasigna el UID de cualquier usuario que se declare root a un UID diferente, evitando así el acceso de root a archivos y directorios en el directorio exportado. Parece que root_squash está habilitado de forma predeterminada por razones de seguridad, pero los autores aún recomiendan especificarlo explícitamente en su archivo /etc/exports.

También puede exportar un directorio en el servidor directamente desde la línea de comando usando el comando exportfs, como se muestra a continuación:

Este comando exporta el directorio /home/foo para la computadora "Bar" y le otorga acceso de lectura/escritura. Además, la opción root_squash no está habilitada en el servidor NFS, lo que significa que cualquier usuario en Bar con UID "0" (UID de raíz) tendrá los mismos privilegios en el servidor que la raíz. La sintaxis parece bastante extraña (generalmente cuando especifique el directorio en la forma computadora:/directorio/archivo, se refiere a un archivo en un directorio en la computadora dada).

Consulte la página del manual para obtener más información sobre el archivo de exportación.

Todo el mundo sabe que en los sistemas UNIX, un sistema de archivos es lógicamente una colección de sistemas de archivos físicos conectados a un solo punto. Una de las bellezas más básicas de una organización de este tipo, en mi opinión, es la capacidad de modificar dinámicamente la estructura de un sistema de archivos existente. Además, gracias a los esfuerzos de los desarrolladores, hoy tenemos la oportunidad de conectar un sistema de archivos de casi cualquier tipo y de cualquier manera conveniente. Hablando de "método", en primer lugar quiero enfatizar la capacidad del kernel del sistema operativo para trabajar con sistemas de archivos a través de conexiones de red.

Muchos protocolos de red nos dan la posibilidad de trabajar con archivos remotos, ya sea FTP, SMB, Telnet o SSH. Gracias a la capacidad del núcleo, al final, de no depender del tipo de sistema de archivos que se está conectando, tenemos la capacidad de conectar cualquier cosa y de cualquier manera utilizando el programa de montaje.

Hoy quiero hablar sobre NFS - Sistema de archivos de red. Esta tecnología le permite conectar puntos FS individuales en una computadora remota al sistema de archivos de la computadora local. El propio protocolo NFS le permite realizar operaciones con archivos de forma rápida, segura y fiable. ¿Que más necesitamos? :-)

Que se necesita para que esto funcione

Para no despotricar durante mucho tiempo sobre el tema de las versiones de NFS y su soporte en varios kernels, asumiremos de inmediato que la versión de su kernel es al menos 2.2.18. En la documentación oficial, los desarrolladores prometen soporte completo para la funcionalidad de la versión 3 de NFS en este kernel y posteriores.

Instalación

Para ejecutar un servidor NFS en mi Ubuntu 7.10, Gutsy Gibbon, necesitaba instalar los paquetes nfs-common y nfs-kernel-server. Si solo se necesita el cliente NFS, no es necesario instalar nfs-kernel-server.

Ajuste del servidor

Después de que todos los paquetes se hayan instalado correctamente, debe verificar si el demonio NFS se está ejecutando:

/etc/init.d/nfs-kernel-estado del servidor

Si el demonio no se está ejecutando, debe iniciarse con el comando

/etc/init.d/nfs-kernel-servidor inicio

Después de que todo haya comenzado con éxito, puede comenzar a exportar el sistema de archivos. El proceso en sí es muy simple y toma un mínimo de tiempo.

El archivo de configuración del servidor NFS principal se encuentra en /etc/exports y tiene el siguiente formato:

Directorio máquina1(opción11,opción12) máquina2(opción21,opción22)

directorio— ruta absoluta al directorio del servidor FS al que desea dar acceso

máquinaX— Nombre DNS o dirección IP de la computadora cliente desde la cual se permite el acceso

opciónXX- Parámetros de exportación de FS, los más utilizados:

• Ro- el acceso a los archivos está permitido solo para lectura
• rw- se concede acceso para lectura/escritura
• no_root_squash- de forma predeterminada, si se conecta a un recurso NFS como raíz, el servidor, por motivos de seguridad, accederá a los archivos de su lado en nombre del usuario nadie. Sin embargo, si habilita esta opción, se accederá a los archivos del lado del servidor como raíz. Ojo con esta opción.
• no_subtree_check- de forma predeterminada, si exporta no toda la partición en el servidor, sino solo una parte del sistema de archivos, el daemon verificará si el archivo solicitado se encuentra físicamente en la misma partición o no. Si está exportando la partición completa o el punto de montaje del sistema de archivos exportado no afecta los archivos de otros volúmenes físicos, entonces puede habilitar esta opción. Esto le dará un aumento en la velocidad del servidor.
• sincronizar— habilite esta opción si existe la posibilidad de una desconexión repentina o un corte de energía del servidor. Si esta opción no está habilitada, el riesgo de pérdida de datos cuando el servidor NFS se detiene repentinamente aumenta considerablemente.

Entonces, digamos que queremos dar acceso a la computadora de escritorio Ashep al directorio /var/backups en la computadora portátil Ashep. Se requiere acceso al directorio para copiar archivos respaldados desde ashep-desktop. Mi archivo es así:

/var/backups ashep-desktop(rw,no_subtree_check,sync)

Después de agregar una línea a /etc/exports, debe reiniciar el servidor NFS para que los cambios surtan efecto.

/etc/init.d/nfs-kernel-servidor reiniciar

Eso es todo. Puede comenzar a conectar el FS exportado en la computadora cliente.

Configuración del cliente

En el lado del cliente, un sistema de archivos remoto se monta de la misma manera que todos los demás: con el comando de montaje. Además, nadie le prohíbe usar /etc/fstab si necesita conectar el sistema de archivos automáticamente cuando se inicia el sistema operativo. Entonces, la opción de montaje se verá así:

Monte -t ​​nfs ashep-laptop:/var/backups/ /mnt/ashep-laptop/backups/

Si todo salió bien y necesita conectarse a un sistema de archivos remoto automáticamente al arrancar, simplemente agregue una línea a /etc/fstab:

Ashep-laptop:/var/backups /mnt/ashep-laptop/backups nfs auto 0 0

Qué otra cosa

Entonces obtuvimos una pequeña y práctica descripción general de las posibilidades de NFS. Por supuesto, esto es solo una pequeña parte de lo que NFS puede hacer. Esto es suficiente para usar en casa o en una pequeña oficina. Si esto no es suficiente para ti, te recomiendo leer primero.

El componente más importante de cualquier sistema distribuido es el sistema de archivos, que en este caso también es distribuido. Al igual que con los sistemas centralizados, la función de un sistema de archivos es almacenar programas y datos y ponerlos a disposición de los clientes. Un sistema de archivos distribuido es compatible con una o más computadoras que almacenan archivos. Los servidores de archivos suelen contener sistemas de archivos jerárquicos, cada uno con un directorio raíz y subdirectorios. Con muchos sistemas de archivos de red, una computadora cliente puede montar y montar estos sistemas de archivos en sus sistemas de archivos locales, proporcionando al usuario un acceso conveniente a directorios y archivos remotos. Al mismo tiempo, los datos de los archivos montados no se mueven físicamente a ningún lado, permaneciendo en los servidores.

Desde el punto de vista del software, un sistema de archivos distribuido (FS) es un servicio de red que incluye programas de servidor y programas de cliente que interactúan entre sí mediante un protocolo específico. El servicio de archivos en los sistemas de archivos distribuidos tiene dos partes funcionalmente distintas: el propio servicio de archivos y el servicio de directorio del sistema de archivos. El primero se ocupa de operaciones en archivos individuales, como leer, escribir o agregar (modificar), mientras que el segundo se ocupa de crear y administrar directorios, agregar y eliminar archivos de directorios, etc.

En un sistema distribuido bien organizado, los usuarios no saben cómo se implementa el sistema de archivos (cuántos servidores de archivos, dónde están ubicados, cómo funcionan). Idealmente, para el usuario, el sistema de archivos de la red debería verse como el suyo propio en su computadora, es decir, ser completamente transparente. Sin embargo, en realidad, los sistemas de archivos de red aún no se corresponden completamente con este ideal.

El sistema de archivos de red generalmente incluye los siguientes elementos:

Sistemas de archivos locales;

Interfaces de sistemas de archivos locales;

Servidores de sistemas de archivos de red;

clientes del sistema de archivos de red;

Interfaces de sistema de archivos de red;

Protocolo cliente-servidor del sistema de archivos de red.

Los clientes de Network FS son programas que se ejecutan en varias computadoras conectadas a una red. Estos programas atienden solicitudes de aplicaciones para acceder a archivos almacenados en computadoras remotas. El cliente Network FS envía solicitudes a través de la red a otro componente de software: el servidor Network FS que se ejecuta en una computadora remota. El servidor, al recibir la solicitud, puede ejecutarla por sí mismo o, más comúnmente, pasar la solicitud al sistema de archivos local para su procesamiento. Después de recibir una respuesta del FS local, el servidor la transmite a través de la red__

El cliente y el servidor de la red FS interactúan entre sí a través de la red utilizando un protocolo específico. Si las interfaces del FS local y de red coinciden, este protocolo puede ser bastante simple. Uno de los mecanismos utilizados para este fin puede ser el mecanismo RPC.

En los sistemas operativos Windows, el principal servicio de archivos de red es el protocolo SMB (Server Message Block), que fue desarrollado conjuntamente por Microsoft, Intel e IBM. Sus últimas versiones extendidas se denominan Common Internet File System, CIFS.

El protocolo opera en la capa de aplicación del modelo OSI. SMB utiliza varios protocolos de transporte para enviar sus mensajes a través de la red. Históricamente, el primer protocolo de este tipo fue NetBIOS (y su versión posterior NetBEUI), pero ahora los mensajes SMB se pueden transmitir mediante otros protocolos (TCP/UDP e IPX).

SMB pertenece a una clase de protocolos orientados a la conexión. Su trabajo comienza con el hecho de que el cliente envía un mensaje especial al servidor con una solicitud para establecer una conexión. Si el servidor está listo para establecer una conexión, responde con un mensaje de reconocimiento. Una vez establecida la conexión, el cliente puede comunicarse con el servidor enviándole comandos para manipular archivos y directorios en mensajes SMB. En el curso del trabajo, pueden surgir una serie de situaciones que pueden afectar la efectividad del acceso remoto a archivos:

1. Falla de la computadora que ejecuta el servidor del sistema de archivos de red durante una sesión de comunicación con el cliente. El sistema de archivos local recuerda el estado de las operaciones sucesivas que la aplicación realiza en el mismo archivo manteniendo una tabla interna de archivos abiertos (las llamadas al sistema abrir, leer, escribir cambian el estado de esta tabla). En un bloqueo del sistema, la tabla de archivos abiertos se pierde después de que se reinicia la computadora del servidor. En este caso, la aplicación que se ejecuta en la computadora cliente no puede continuar trabajando con archivos que estaban abiertos antes del bloqueo.

Una solución al problema se basa en transferir la función de mantenimiento y almacenamiento de una tabla de archivos abiertos del servidor al cliente. Con esta organización se simplifica el protocolo cliente-servidor, ya que reiniciar el servidor solo provoca una pausa en el servicio.

2. Grandes retrasos en el servicio debido a solicitudes de red y reinicios del servidor de archivos cuando se conecta una gran cantidad de clientes. La solución al problema puede ser el almacenamiento en caché de archivos (parcial o totalmente) en el lado del cliente. Sin embargo, en este caso, el protocolo debe tener en cuenta la posibilidad de crear varias copias de un mismo archivo, las cuales pueden ser modificadas independientemente por diferentes usuarios, es decir, el protocolo debe garantizar la consistencia de copias de archivos disponibles en diferentes computadoras.

3. Pérdida de datos y destrucción de la integridad del sistema de archivos en caso de fallas y fallas de las computadoras que desempeñan el papel de servidores de archivos. Para aumentar la tolerancia a fallas de un FS de red, puede almacenar varias copias de cada archivo (o todo el FS) en varios servidores. Estas copias de un archivo se denominan réplicas.

La replicación de archivos no solo mejora la tolerancia a fallas, sino que también resuelve el problema de sobrecargar los servidores de archivos al distribuir las solicitudes de archivos entre varios servidores, lo que mejora el rendimiento del sistema de archivos.

4. La autenticación se realiza en una computadora, por ejemplo, en un cliente, y la autorización, es decir, verificar los derechos de acceso a directorios o archivos, en otra computadora que actúa como servidor de archivos. Este problema común de todos los servicios de red debe ser tenido en cuenta por el protocolo de interacción entre clientes y servidores del servicio de archivos.

Estos problemas se solucionan de forma compleja creando un servicio de autenticación centralizada, replicación, cacheo, etc. Estos servicios adicionales se reflejan en el protocolo de interacción de clientes y servidores, por lo que se crean diversos protocolos de este tipo. que soportan uno u otro conjunto de funciones adicionales. Por lo tanto, pueden existir diferentes protocolos de FS de red para el mismo FS local (Figura 5.30). Por lo tanto, ahora se puede acceder al sistema de archivos NTFS mediante los protocolos SMB, NCP (NetWare Control Protocol) y NFS (Network File System), el protocolo del sistema de archivos de red de Sun Microsystems, utilizado en varias versiones de la familia de sistemas operativos UNIX.

Por otro lado, utilizando el mismo protocolo, se puede implementar el acceso remoto a sistemas de archivos locales de diferentes tipos. Por ejemplo, el protocolo SMB se usa para acceder no solo a FS de tipo FAT, sino también a NTFS, HPFS FS (Fig. 5.31). Estos sistemas de archivos se pueden ubicar tanto en diferentes como en la misma computadora.__

Preguntas de seguridad para el capítulo 5

1. ¿Cuáles son las ventajas de las redes sobre el uso separado de las computadoras?

2. ¿Las topologías de red física y lógica siempre coinciden?

3. ¿Cómo se clasifican las redes según el tamaño del área cubierta?

4. ¿Qué computadora puede actuar como servidor en la red?

5. ¿Qué es un servidor de archivos y un servidor de impresión?

6. ¿Qué funciones realizan los servidores de registro?

7. ¿Qué funciones realizan los servidores de acceso remoto?

8. ¿Qué es un servidor proxy?

9. Listar posibles clientes de una red informática.

10. ¿Qué son los clientes "gruesos" y "ligeros" en una red informática?

11. ¿Cómo entiende el término "segmentación" de la red?

12. ¿Qué es una dirección MAC?

13. ¿En qué se diferencia un sistema operativo distribuido de un sistema operativo de red? ¿Existen actualmente sistemas de red realmente distribuidos?

14. Enumere los principales componentes del sistema operativo de la red. ¿Qué es un servicio de red? ¿Qué servicios de red puede nombrar?

15. Parte de los servicios de la red no están dirigidos al usuario, sino al administrador. ¿Cuáles son estos servicios?

16. ¿Cuáles fueron los primeros sistemas operativos de red? ¿Qué enfoques para crear sistemas operativos de red se utilizan actualmente?

17. Cuáles son las características de las redes peer-to-peer. ¿Cuál es la característica principal de una red multinivel?

18. ¿Qué es un sistema operativo de servidor? ¿Qué son? ¿En qué se diferencia un sistema operativo de servidor de un sistema operativo de cliente?

19. ¿Cuántas variantes de esquemas de dos niveles se utilizan para el procesamiento de aplicaciones distribuidas?

20. ¿Qué tiene de bueno el procesamiento de aplicaciones de dos niveles en la cooperación servidor-cliente?

21. ¿Existen ventajas en el esquema de procesamiento de solicitudes de tres niveles? ¿Cuáles son?

22. ¿Cómo pueden interactuar los procesos en los sistemas distribuidos?

23. ¿Cuáles son las principales primitivas utilizadas en el sistema de transporte de red OS?

24. ¿Cómo se organiza la sincronización de procesos en la red?

25. ¿Qué se entiende por llamada a procedimiento remoto?

Las principales características del sistema de archivos NFS en la plataforma UNIX.

La felicidad es cuando nuestros deseos coinciden con las capacidades de otras personas.

"Vremechko"

Los sistemas de archivos de red han jugado, juegan y seguirán jugando un papel importante en la infraestructura de la información. A pesar de la creciente popularidad de los servidores de aplicaciones, el servicio de archivos sigue siendo un medio universal para organizar el intercambio de información. Además, muchos servidores de aplicaciones actúan simultáneamente como servidores de archivos.

El sistema operativo UNIX actualmente está experimentando una especie de renacimiento, en gran parte debido al aumento del interés en el sistema operativo libre Linux. Al mismo tiempo, varias versiones de Windows se utilizan en computadoras de escritorio, principalmente Windows 9x y Windows NT/2000, aunque las variantes de UNIX distribuidas libremente también están ganando ciudadanía aquí.

Para muchas organizaciones, alojar un servicio de archivos de red en equipos UNIX es una solución muy atractiva, siempre que dicho servicio tenga suficiente rendimiento y confiabilidad. Dadas las muchas diferencias entre los sistemas de archivos de UNIX y Windows, principalmente en los esquemas de nombres de archivos, los permisos de acceso, los bloqueos y las llamadas al sistema al acceder a los archivos, es de particular importancia garantizar la transparencia de acceso en un entorno heterogéneo de UNIX/Windows. Tampoco es raro que los servidores de archivos UNIX se instalen como una adición a los servidores Windows NT y NetWare existentes.

Para el sistema operativo UNIX, existen implementaciones de todos los sistemas de archivos de red más o menos populares, incluidos los utilizados en redes Microsoft (SMB), NetWare (NCP), Macintosh (AFP). Por supuesto, las redes UNIX tienen sus propios protocolos, principalmente NFS y DFS. Tenga en cuenta que cualquier servidor UNIX puede proporcionar servicios NFS y SMB (así como NCP y AFP) y, por lo tanto, brindar flexibilidad adicional al crear una infraestructura de red.

A pesar de la variedad de sistemas de archivos de red UNIX, los líderes indiscutibles son NFS (Network File System, traducción literal - sistema de archivos de red) y SMB (Service Message Block). Este artículo se centrará en las capacidades de NFS. Al mismo tiempo, en uno de los próximos números, planeamos considerar las características de SMB en la plataforma UNIX y, en primer lugar, el producto Samba, que ha demostrado su eficacia en redes UNIX/Windows.

VERSIONES NFS

La primera implementación del sistema de archivos de red NFS fue desarrollada por Sun Microsystems en 1985. Desde entonces, NFS se ha generalizado en el mundo UNIX, con decenas de millones de instalaciones. Además de UNIX, el sistema NFS como plataforma de servidor ha encontrado aplicación en los sistemas operativos VMS, MVS e incluso Windows.

NFS es el sistema de archivos "nativo" para UNIX y sigue la lógica de las operaciones de archivos UNIX como ningún otro. Esto se refiere al espacio de nombres y permisos del archivo. Además, la compatibilidad con NFS está integrada de forma nativa en el núcleo de todas las versiones populares de sistemas operativos similares a UNIX.

Actualmente, NFS está representado por la segunda y la tercera versión (la primera versión de NFS nunca apareció en el mercado). A pesar de una serie de limitaciones, NFS v2 es muy popular; es ella quien forma parte de UNIX distribuido libremente (en particular, Linux), así como algunos UNIX comerciales.

La tercera versión de NFS se desarrolló a mediados de los 90 gracias a los esfuerzos conjuntos de Sun, IBM, Digital y otras empresas para mejorar el rendimiento, la seguridad y la facilidad de administración del sistema de archivos de red. NFS v3 es compatible con versiones anteriores de la especificación NFS anterior, lo que significa que un servidor NFS v3 puede servir no solo a clientes NFS v3, sino también a clientes NFS v2.

A pesar de su presencia bastante larga en el mercado, NFS v3 sigue siendo inferior a NFS v2 en términos de número de instalaciones. Con base en estas consideraciones, primero nos enfocaremos en las características principales de NFS v2 y luego nos familiarizaremos con las innovaciones en la tercera versión de NFS.

Tenga en cuenta que las implementaciones específicas de la misma versión de NFS pueden diferir ligeramente entre sí. Las diferencias se relacionan principalmente con la composición de los demonios, sus nombres, ubicación y el nombre de los archivos de configuración de NFS. Además, las implementaciones de NFS dependen de las capacidades y funciones del propio UNIX. Por ejemplo, NFS v2 admite ACL, pero solo en versiones de UNIX donde dicha compatibilidad está integrada en el kernel. Por lo tanto, al describir NFS, consideraremos el caso más general.

PROTOCOLOS NFS V2

La figura 1 muestra el modelo de red NFS v2 según el modelo de referencia OSI. A diferencia de la mayoría de los servicios de red TCP/IP, NFS usa explícitamente protocolos de capa de presentación y sesión. NFS se basa en el concepto de llamadas a procedimientos remotos (RPC). De acuerdo con este concepto, al acceder a un recurso remoto (por ejemplo, un archivo), un programa en la computadora local realiza una llamada regular al sistema (digamos una llamada de función de apertura de archivo), pero de hecho el procedimiento se ejecuta de forma remota, en el servidor de recursos En este caso, el proceso de usuario no puede determinar si la llamada se realiza de forma local o remota. Habiendo establecido que el proceso está accediendo a un recurso en una computadora remota que actúa como un servidor, el núcleo o un demonio especial del sistema empaqueta los argumentos del procedimiento junto con su identificador en un paquete de red, abre una sesión de comunicación con el servidor y reenvía este paquete a él. El servidor desempaqueta el paquete recibido, determina el procedimiento y los argumentos solicitados y luego ejecuta el procedimiento. Luego, el servidor envía el código de retorno del procedimiento al cliente, que lo pasa al proceso del usuario. Por lo tanto, RPC es totalmente consistente con la capa de sesión del modelo OSI.

Surge una pregunta justa: ¿por qué el modelo de red NFS necesita un protocolo de capa de presentación especial? El punto es que Sun tuvo la intención prudente de usar NFS en redes heterogéneas donde las computadoras tienen diferentes arquitecturas de sistema, incluido un orden de bytes diferente en la palabra de la máquina, una representación diferente de números de coma flotante, límites de alineación de estructuras incompatibles, etc. Porque dado que el protocolo RPC implica la transferencia de argumentos de procedimiento, es decir, datos estructurados, entonces la presencia de un protocolo de capa de presentación es una necesidad urgente en un entorno heterogéneo. Como tal, se utiliza el protocolo de representación de datos externos (eXternal Data Representation, XDR). Describe la llamada forma canónica de representación de datos, que no depende de la arquitectura del sistema del procesador. Al transmitir paquetes RPC, el cliente convierte los datos locales en forma canónica y el servidor hace lo contrario. Tenga en cuenta que la forma XDR canónica corresponde a la representación de datos adoptada para las familias de procesadores SPARC y Motorola. En los servidores donde se implementa una forma similar de representación de datos, esto le permite lograr una ventaja de rendimiento (aunque probablemente microscópica) sobre la competencia en casos de acceso intensivo al servidor de archivos.

En NFS v2, se eligió UDP como protocolo de transporte. Los desarrolladores explican esto por el hecho de que la sesión de RPC dura poco tiempo. Además, desde el punto de vista de la ejecución de procedimientos remotos, cada paquete RPC es autónomo, es decir, cada paquete contiene información completa sobre lo que debe hacerse en el servidor o sobre los resultados del procedimiento. Los servicios RPC generalmente no tienen conexión, es decir, el servidor no almacena información sobre qué solicitudes de clientes se procesaron en el pasado: por ejemplo, en qué parte del archivo el cliente leyó los datos por última vez. Para un sistema de archivos de red, esta es una ventaja de confiabilidad definitiva, ya que el cliente puede continuar con las operaciones de archivo inmediatamente después de reiniciar el servidor. Pero este esquema está plagado de problemas al escribir y bloquear archivos, y para evitarlos, los desarrolladores de NFS se vieron obligados a utilizar varias soluciones (el uso de UDP crea otro conjunto de problemas específicos, pero los abordaremos más adelante).

Una diferencia importante entre los servicios RPC incluidos con NFS y otros servicios de servidor de red es que no utilizan el superdaemon inetd. Los servicios de red ordinarios, como telnet o rlogin, normalmente no se inician como demonios al iniciar el sistema, aunque esto no está prohibido. La mayoría de las veces, utilizan el llamado superdaemon inetd, que "escucha" en los puertos de software de los protocolos TCP y UDP. Los servicios se definen en el archivo de configuración del superdaemon (normalmente /etc/inetd.conf). Cuando se realiza una solicitud al puerto del programa desde el lado del cliente, inetd inicia el servicio de red correspondiente (por ejemplo, in.rlogind) como proceso secundario, que procesa la solicitud.

Los servicios RPC no utilizan el super daemon inetd porque, como ya se mencionó, una sesión RPC dura muy poco tiempo, de hecho, solo durante el procesamiento de una sola solicitud. Es decir, para cada solicitud, inetd se vería obligado a iniciar un nuevo proceso hijo del servicio RPC, lo cual es muy costoso para UNIX. Por razones similares, un proceso RPC no puede generar nuevos procesos y no puede atender múltiples solicitudes en paralelo. Por lo tanto, los servicios RPC se ejecutan como varias instancias de daemon simultáneas para mejorar el rendimiento. Al mismo tiempo, la cantidad de instancias de un demonio en particular no está directamente relacionada con la cantidad de clientes. Incluso un daemon puede atender a muchos clientes, pero a la vez puede procesar una sola solicitud, el resto estará en cola.

Otra diferencia importante entre los servicios RPC y los servicios de red normales es que no utilizan puertos de software UDP predefinidos. En su lugar, se utiliza el llamado sistema de traducción de puertos portmapper. Para admitirlo, se inicializa un demonio de mapa de puertos especial en el arranque del sistema. Dentro del sistema de traducción de puertos, a cada servicio RPC se le asigna un número de programa, número de versión, número de procedimiento y protocolo (UDP o TCP). El número de programa identifica de forma única un servicio RPC en particular. La relación entre los nombres de los servicios RPC y los números de los programas se puede ver en el contenido del archivo /etc/rpc. Cada programa RPC admite un conjunto de procedimientos, que se identifican por sus números. Los números de procedimiento se pueden encontrar en los archivos de encabezado correspondientes: por ejemplo, para el servicio NFS, se especifican en el archivo /usr/include/nfs/nfs.h.

En particular, el servicio NFS tiene el número de programa 100003 e incluye procedimientos como "abrir archivo", "leer bloque", "crear archivo", etc. número de procedimiento y número de versión. El número de versión se utiliza para identificar las capacidades del servicio. El hecho es que los desarrolladores mejoran constantemente el servicio NFS, mientras que cada nueva versión es totalmente compatible con versiones anteriores.

El principio de funcionamiento del traductor portmap es bastante simple. Al inicializar (en particular, en el momento del arranque del sistema operativo) cualquier servicio RPC, se registra utilizando el demonio portmap. Cuando se inicia en un servidor, el servicio RPC busca un puerto de software desocupado, lo reserva para sí mismo e informa el número de puerto al demonio portmap. Para comunicarse con un servidor, un cliente RPC primero debe mirar el mapa de puertos del servidor y preguntarle qué puerto de software está ocupado por un servicio RPC en particular en el servidor. Solo entonces el cliente puede contactar directamente con el servicio. En algunos casos, el cliente se comunica indirectamente con el servicio deseado, es decir, primero contacta con el daemon portmap, que solicita el servicio RPC en nombre del cliente. A diferencia de los servicios RPC, el traductor de puertos del mapa de puertos siempre se vincula al puerto 111 predefinido, por lo que el cliente se comunica con el mapa de puertos de la forma estándar.

COMPOSICIÓN NFS V2

En general, además del mapa de puertos, el servidor NFS incluye los demonios rpc.mountd, nfsd, rpc.lockd, rpc.statd. Un cliente NFS que se ejecuta en una plataforma UNIX debe tener los demonios biod (opcional), rpc.lockd y rpc.statd en ejecución.

Como se mencionó anteriormente, la compatibilidad con NFS se implementa en UNIX a nivel de kernel, por lo que no se necesitan todos los demonios, pero pueden mejorar significativamente el rendimiento de las operaciones con archivos y permitirle bloquear archivos al escribir.

El demonio rpc.mountd maneja las solicitudes de los clientes para montar sistemas de archivos. El servicio de montaje se implementa como un demonio separado porque el protocolo de montaje no forma parte de NFS. Esto se debe a que la operación de montaje está estrechamente ligada a la sintaxis del nombre de archivo, y los principios para nombrar archivos difieren entre UNIX y, por ejemplo, VMS.

El demonio nfsd acepta y atiende solicitudes NFS RPC. Es común ejecutar varias instancias de nfsd en un servidor para mejorar el rendimiento.

El demonio rpc.lockd, que se ejecuta tanto en el cliente como en el servidor, está diseñado para bloquear archivos, mientras que el demonio rpc.statd (que también se ejecuta en el servidor y el cliente) mantiene estadísticas de bloqueo en caso de que sea necesario restaurarlas automáticamente si el El servicio NFS falla.

El demonio biod que se ejecuta en el cliente es capaz de realizar operaciones de lectura anticipada y escritura diferida, lo que mejora considerablemente el rendimiento. Sin embargo, no se requiere la presencia de biod para que el cliente funcione. Para mejorar aún más el rendimiento en la máquina cliente, se pueden cargar varios demonios biod.

Otro demonio que se ejecuta en el servidor es responsable de los servicios de autenticación e impresión para clientes DOS/Windows, en algunos sistemas se llama pcnfsd, en otros se llama in.pcnfsd.

Además, el paquete NFS incluye varias utilidades del sistema y programas de diagnóstico (showmount, rpcinfo, exportfs, nfsstat).

REGLAS DE EXPORTACIÓN

Los sistemas de archivos y directorios que los clientes pueden montar de forma remota en el servidor NFS deben especificarse explícitamente. Este procedimiento se denomina "exportación" de recursos en NFS. Al mismo tiempo, un servidor NFS, a diferencia de, digamos, un servidor SMB, no transmite una lista de sus recursos exportados. Sin embargo, el cliente puede solicitar dicha lista al servidor. En el lado del servidor, el daemon rpc.mountd es responsable de atender las solicitudes de montaje.

La exportación de recursos compartidos de archivos NFS sigue cuatro reglas básicas.

1. El sistema de archivos se puede exportar en su totalidad o en partes, que son directorios y archivos. Tenga en cuenta que la unidad exportada más grande es el sistema de archivos. Si un sistema de archivos (/usr/bin) está montado debajo de otro sistema de archivos (/usr) en el servidor, la exportación del sistema /usr no afectará al sistema /usr/bin.
2. Solo puede exportar recursos de archivos locales, en otras palabras, si un sistema de archivos externo está montado en el servidor, es decir, ubicado en otro servidor, entonces no se puede volver a exportar.
3. No puede exportar subdirectorios de un sistema de archivos ya exportado, a menos que sean sistemas de archivos independientes.
4. No puede exportar los directorios principales de un directorio ya exportado, a menos que el directorio principal sea un sistema de archivos independiente.

Cualquier violación de estas reglas resultará en un error en el funcionamiento de NFS.

La tabla de recursos exportados se encuentra en el archivo /etc/exports. Lamentablemente, la sintaxis de este archivo es específica de UNIX, por lo que usaremos Solaris como ejemplo. El archivo /etc/exports consta de líneas de texto con el formato:

-,...

Algunas de las opciones más populares se enumeran en la Tabla 1. De hecho, las opciones describen los derechos de acceso a los recursos exportados por parte de los clientes. Es importante recordar que los permisos enumerados durante la exportación de ninguna manera anulan los permisos que están en vigor en el propio sistema de archivos. Por ejemplo, si el sistema de archivos se exporta como escribible y un archivo en particular es de solo lectura, entonces no será posible modificarlo. Así, al exportar, los derechos de acceso actúan como un filtro adicional. Además, si, por ejemplo, el sistema de archivos se exporta con la opción ro (solo lectura), el cliente tiene derecho a montarlo con la opción rw (lectura/escritura), pero un intento de escritura generará un mensaje de error. .

La opción de acceso le permite especificar hosts con permiso para montar el recurso. En consecuencia, ningún otro host, excepto los mencionados en él, tiene la capacidad de montar y, por lo tanto, realizar operaciones en el recurso.

La lista de hosts que pueden escribir información se especifica con la opción rw. Si la lista de hosts no se especifica en la opción rw, entonces cualquier host tiene derecho a escribir.

La opción raíz le permite especificar los hosts donde los superusuarios raíz locales obtienen los privilegios raíz del servidor en el recurso exportado. De lo contrario, incluso si al host se le otorgan derechos rw, el usuario raíz en él se equipara al usuario de nadie (uid=-2), es decir, al usuario con derechos de acceso mínimos. Lo anterior se aplica específicamente a los derechos de acceso al recurso remoto y no afecta los derechos de acceso a los recursos locales del cliente.

Las opciones anónimas y seguras se analizarán al describir el esquema de autenticación NFS.

REGLAS DE MONTAJE

Si para el servidor los recursos exportados pueden actuar como un sistema de archivos o un directorio separado, entonces para el cliente siempre se ven como sistemas de archivos. Dado que la compatibilidad con NFS está integrada en el kernel de UNIX, la operación de montaje de sistemas de archivos NFS la realiza la utilidad de montaje estándar (no se requiere un demonio separado para montar NFS), y solo es necesario estipular que el sistema de archivos que se está montando es NFS. Otra forma de montar es con el archivo /etc/fstab (/etc/filesystems en algunas versiones de UNIX). En este caso, los sistemas NFS remotos (así como los locales) se montan en la etapa de arranque del sistema operativo. Los puntos de montaje pueden ser cualquiera, incluso como parte de otros sistemas de archivos NFS, es decir, los sistemas NFS se pueden "encadenar" uno encima del otro.

Las principales opciones de montaje de NFS se enumeran en la Tabla 2.

La opción bg le permite montar en segundo plano, en cuyo caso puede ejecutar otros comandos de montaje.

Un par de opciones hard/soft parecen muy interesantes. Con un montaje "duro", el cliente intentará montar el sistema de archivos pase lo que pase. Si el servidor está inactivo, esto hará que todo el servicio NFS se cuelgue, por así decirlo: los procesos que acceden al sistema de archivos entrarán en un estado de espera a que las solicitudes RPC terminen de ejecutarse. Desde el punto de vista de los procesos de usuario, el sistema de archivos parecerá un disco local muy lento. Cuando el servidor vuelve a funcionar, el servicio NFS seguirá funcionando como si nada. El uso de la opción intr permite que la señal del sistema INTERRUPT cancele el proceso de montaje.

Con un montaje suave, el cliente NFS realizará varios intentos para conectarse al servidor, según lo especificado por las opciones de retans y timeo (algunos sistemas también admiten una opción de reintento especial). Si el servidor no responde, el sistema emite un mensaje de error y deja de intentar montar. Desde el punto de vista de la lógica de las operaciones de archivos, cuando falla un servidor, un montaje suave emula una falla del disco local. Si no se especifica la opción retrans (reintentar), el número de reintentos se limita al valor predeterminado para este sistema UNIX. Las opciones retrans y timeo se aplican no solo a los montajes, sino también a cualquier operación RPC realizada en el sistema de archivos NFS. Es decir, si el cliente realiza una operación de escritura y en ese momento falla la red o el servidor, el cliente intentará volver a intentar las solicitudes.

La pregunta de cuál de los modos, "suave" o "duro", es mejor, no puede responderse sin ambigüedades. Si los datos en el servidor deben ser consistentes cuando falla temporalmente, entonces es preferible un montaje "duro". Este modo también es indispensable en los casos en que los sistemas de archivos montados contienen programas y archivos que son vitales para que el cliente funcione, en particular para máquinas sin disco. En otros casos, especialmente cuando se trata de sistemas de solo lectura, el modo de montaje suave parece ser más preferible.

AUTENTICACIÓN Y SEGURIDAD

Como ya se señaló, cada paquete RPC es autónomo. Además, en general, NFS no proporciona estado, es decir, no mantiene un registro de las solicitudes realizadas previamente por los clientes y tampoco realiza un seguimiento del trabajo de los clientes. Por lo tanto, en sistemas donde se utilizan llamadas a procedimientos remotos, el problema de seguridad resulta sumamente relevante.

En NFS, la autenticación se realiza exclusivamente en la etapa de montaje del sistema de archivos y solo en función del nombre de dominio (o dirección IP) de la máquina cliente. Es decir, si un cliente NFS (aquí nos referimos a una computadora, no a un usuario de la computadora) accede al servidor con una solicitud de montaje, entonces el servidor determina los derechos de acceso de la tabla /etc/exports, mientras que el cliente se identifica por el nombre ( dirección IP) de la computadora. Si el cliente puede realizar ciertas operaciones en el recurso exportado, se informa al cliente de un cierto "número mágico" (cookie mágica). Luego, el cliente debe incluir este número en cada solicitud de RPC para demostrar su autoridad.

Aquí, de hecho, está todo el conjunto simple de herramientas de autenticación de clientes, pero los usuarios no están autenticados de ninguna manera. Sin embargo, cada solicitud de RPC contiene el uid del usuario que inició la solicitud y una lista de identificadores de grupo, gid, a los que pertenece el usuario. Pero estos identificadores no se utilizan para la autenticación, sino para determinar los derechos de acceso de un usuario en particular a archivos y directorios.

Tenga en cuenta que uid y gid se definen en el lado del cliente, no en el lado del servidor. Por lo tanto, los administradores enfrentan el problema de coordinar los contenidos de /etc/passwd (y /etc/group) entre clientes y servidores NFS para que al usuario Vasya en el servidor no se le asignen los derechos del usuario Petya. Para redes grandes, esto presenta serias dificultades. Puede garantizar la coherencia de la base de datos del usuario, así como de los archivos del sistema, como /etc/hosts, /etc/rpc, /etc/services, /etc/protocols, /etc/aliases, etc., utilizando el Servicio de información de red. (Network Information System, NIS), desarrollado por Sun en 1985 e incluido en la mayoría de las versiones de UNIX (su versión más avanzada NIS+ no ha encontrado un uso generalizado). NIS es un servicio de información, similar al servicio de directorio de Windows NT, que le permite almacenar y procesar archivos del sistema de forma centralizada. Por cierto, NIS se basa en el mismo principio que NFS, en particular, utiliza los protocolos RPC y XDR.

Otra característica importante de NFS es que se pasa una lista del gid del usuario en cada solicitud de RPC. Para limitar el tamaño del paquete RFC, la mayoría de las implementaciones de NFS limitan la cantidad de grupos a más de 8 o 16. Si un usuario es miembro de más grupos, esto puede generar errores al determinar los derechos de acceso en el servidor. Este problema es muy relevante para los servidores de archivos corporativos. Una solución radical es usar ACL, pero desafortunadamente no todas las versiones de UNIX las admiten.

El sistema de autenticación adoptado en NFS es muy deficiente y no brinda una protección confiable. Cualquiera que haya tratado con NFS sabe lo fácil que es eludir su sistema de seguridad. Para ello, ni siquiera es necesario utilizar los métodos de falsificación de direcciones IP (IP-spoofing) o nombres (DNS-spoofing). Basta con que un atacante intercepte el "número mágico" y, en el futuro, puede realizar acciones en nombre del cliente. Además, el "número mágico" no cambia hasta el próximo reinicio del servidor.

En numerosos servidores de Internet, puede encontrar otras formas, incluso muy exóticas, de descifrar NFS. El número de "agujeros" descubiertos es de miles. Por lo tanto, se recomienda utilizar NFS v.2 solo dentro de redes seguras.

En base a estas consideraciones, Sun desarrolló el protocolo SecureRPC utilizando claves de cifrado asimétricas y simétricas. Al mismo tiempo, se utilizan métodos criptográficos para autenticar no solo a los hosts, sino también a los usuarios. Sin embargo, los datos en sí no están encriptados. Desafortunadamente, debido a las restricciones de exportación del gobierno de EE. UU., no todos los UNIX se envían con soporte SecureRPC. Por lo tanto, no nos detendremos en las capacidades de este protocolo. Sin embargo, si su versión de UNIX es compatible con SecureRPC, el libro de Hal Stein "Managing NFS and NIS" de O'Reilly & Associates será de gran ayuda para configurarlo.

Otro problema es con los clientes NFS en las plataformas MS-DOS y Windows 3.x/9x. Estos sistemas son de un solo usuario y no es posible identificar a un usuario utilizando herramientas NFS convencionales. Con el fin de autenticar a los usuarios de DOS/Windows, el daemon pcnfsd se inicia en el servidor. Al conectar (montar) unidades NFS en una máquina cliente, solicita un nombre de usuario y una contraseña, lo que permite no solo identificar, sino también autenticar a los usuarios.

Aunque Windows NT es un sistema operativo multiusuario, su base de datos de usuarios y su esquema de autenticación de usuarios son incompatibles con los de UNIX. Por lo tanto, los clientes NFS basados ​​en Windows NT también están obligados a utilizar las funciones de pcnfsd.

Además de la autenticación de usuarios, pcnfs permite la impresión UNIX desde sitios de clientes DOS/Windows. Es cierto que Windows NT incluye inicialmente el programa LPR.EXE, que también le permite imprimir en servidores UNIX.

Para acceder a los servicios de archivos y NFS en máquinas DOS/Windows, debe instalar un software de cliente especial, y estos productos son muy costosos.

Sin embargo, volvamos a las opciones para exportar archivos NFS (ver Tabla 1). La opción anon especifica el identificador de usuario uid en caso de que el usuario de DOS/Windows no pueda autenticarse a sí mismo (dada la contraseña incorrecta) o cuando el usuario del host conectado a través de SecureRPC no se haya autenticado. Por defecto, anon tiene uid=-2.

La opción segura se usa cuando se usa el protocolo SecureRPC.

CARACTERÍSTICAS ARQUITECTÓNICAS NFS V2

Los sistemas de archivos NFS deben cumplir con dos condiciones (por cierto, estos requisitos se aplican no solo a NFS, sino también a otros sistemas de archivos de red).

1. Desde el punto de vista de los programas de usuario del cliente, el sistema de archivos NFS se encuentra, por así decirlo, en un disco local. Los programas no tienen forma de distinguir los archivos NFS de los archivos normales.
2. El cliente NFS no puede determinar qué plataforma se está utilizando como servidor. Puede ser UNIX, MVS e incluso Windows NT. Las diferencias en la arquitectura del servidor afectan solo el nivel de operaciones específicas y no en términos de capacidades NFS. Para el cliente, la estructura de archivos NFS es similar al sistema local.

El primer nivel de transparencia se logra mediante el uso del sistema de archivos virtual UNIX (Sistema de archivos virtual, VFS). VFS es responsable de interactuar no solo con NFS, sino también con sistemas locales como UFS, ext2, VxFS, etc.

El segundo nivel de transparencia se proporciona mediante el uso de los llamados nodos virtuales (virtual nodes, vnodes), cuya estructura se puede correlacionar con los inodos en los sistemas de archivos UNIX.

Las operaciones en los sistemas de archivos NFS son operaciones VFS, mientras que las interacciones con archivos y directorios individuales están definidas por operaciones vnode. El protocolo RPC de NFS v2 describe 16 procedimientos relacionados con operaciones no solo en archivos y directorios, sino también en sus atributos. Es importante comprender que las llamadas RPC y la interfaz de vnode son conceptos diferentes. Las interfaces de vnode definen los servicios del sistema operativo para acceder a los sistemas de archivos, ya sean locales o remotos. RPC de NFS es una implementación específica de una de las interfaces de vnode.

Las operaciones de lectura/escritura se almacenan en caché en el lado del cliente, es decir, el cliente almacena en caché el contenido de archivos y directorios. Normalmente, el tamaño del búfer de caché NFS es de 8 KB. Si los demonios biod se están ejecutando en el cliente, la lectura se realiza con anticipación y la escritura se realiza en modo diferido. Por ejemplo, si un proceso de usuario escribe información, los datos se acumulan en el búfer de caché y solo entonces se envían, generalmente en un paquete RPC. En el momento de la operación de escritura, el kernel devuelve inmediatamente el control al proceso y las funciones de reenvío de solicitudes RPC se transfieren a biod. Si los demonios biod no se están ejecutando y el kernel no admite el procesamiento RPC de subprocesos múltiples, entonces el kernel debe manejar el reenvío de paquetes RPC en modo de subproceso único y el proceso de usuario ingresa al estado de espera hasta el final de la transferencia. Pero en este caso, todavía se usa el caché NFS.

Además del contenido de los archivos y directorios NFS, los atributos de archivos y directorios se almacenan en caché en el lado del cliente, y la caché de atributos se actualiza periódicamente (generalmente cada pocos segundos). Esto se debe al hecho de que el valor de los atributos se puede utilizar para juzgar el estado de un archivo o directorio. Expliquemos este enfoque con un ejemplo. Cuando un usuario realiza una operación de lectura de un archivo, el contenido del archivo se coloca en la memoria caché de NFS, pero al mismo tiempo, los atributos del archivo (hora de creación/actualización, tamaño, etc.) se colocan en el atributo cache. Si en este momento otro cliente está escribiendo en el mismo archivo, esto puede generar una inconsistencia de contenido en los cachés de diferentes clientes. Sin embargo, dado que el primer cliente actualiza la caché de atributos cada pocos segundos, puede detectar que los atributos han cambiado (en este caso, el tiempo de actualización del archivo), por lo que el cliente debe realizar una operación de actualización de caché de contenido de archivo (esta operación es se realiza automáticamente).

Los demonios nfsd deben estar ejecutándose en el servidor para atender las solicitudes de los clientes. Al mismo tiempo, los daemons guardan en caché la información cuando leen los discos del servidor. Todos los demonios atienden la misma cola de solicitudes de clientes, lo que permite un uso óptimo de los recursos del procesador.

Desafortunadamente, determinar el número óptimo de demonios biod y nfsd es muy difícil. Por un lado, cuanto mayor sea el número de demonios en ejecución, mayor será el número de solicitudes que se pueden procesar simultáneamente; por otro lado, aumentar la cantidad de demonios puede afectar negativamente el rendimiento del sistema debido a una mayor sobrecarga de conmutación de procesos. Ajustar NFS es un procedimiento muy tedioso y requiere tener en cuenta no solo la cantidad de clientes y procesos de usuario, sino también características como el tiempo de cambio de contexto del proceso (es decir, características de la arquitectura del procesador), tamaño de RAM, carga del sistema, etc. Estas configuraciones son las mejores determinado experimentalmente, aunque la configuración predeterminada funcionará en la mayoría de los casos (por lo general, 8 demonios nfsd se ejecutan en el servidor y 4 demonios biod en los clientes).

Una característica muy importante de NFS v2 es que las operaciones de escritura no se almacenan en caché en el lado del servidor (consulte la Figura 2). Esto se hizo para garantizar una alta confiabilidad del servicio NFS y para garantizar la integridad de los datos después de reiniciar el servidor en caso de falla del servidor. La falta de almacenamiento en caché de escritura es el mayor problema con NFS v2. En las operaciones de escritura, NFS es significativamente inferior a las tecnologías de la competencia, aunque en las operaciones de lectura pierde poco frente a ellas. La única forma de lidiar con un rendimiento de escritura deficiente es usar subsistemas de disco con caché incorporado independiente de la energía, como en arreglos RAID bastante costosos.

Cuando se trabaja en redes distribuidas y globales, NFS v2 tiene otro inconveniente debido a la elección de UDP como protocolo de transporte para el servicio. Como usted sabe, UDP no garantiza la entrega de paquetes, además, el orden en que se reciben los paquetes puede no corresponder con el orden en que se enviaron.

Esto puede conducir a las siguientes dos consecuencias desagradables: pérdida de paquetes y un gran retraso en su procesamiento. Imagine que el cliente realiza una operación de lectura de algún archivo grande. En este caso, el servidor necesita enviar varios paquetes para llenar el búfer de caché del cliente. Si uno de los paquetes se pierde, entonces el cliente tendrá que repetir la solicitud nuevamente, y el servidor tendrá que generar respuestas, etc.

La situación de retrasar el procesamiento de solicitudes RPC debido, por ejemplo, a una gran carga del servidor o problemas de red también es bastante desagradable. Si se supera el límite de tiempo especificado, el cliente considerará que el paquete se ha perdido e intentará repetir la solicitud. Para muchas operaciones NFS, esto no es un problema, ya que el servidor puede repetir incluso la operación de escritura. Pero, ¿qué pasa con operaciones como "eliminar directorio" o "renombrar archivo"? Afortunadamente, la mayoría de las implementaciones de NFS admiten el almacenamiento en caché de solicitudes duplicadas en el lado del servidor. Si el servidor recibe una solicitud repetida para cualquier operación dentro de un período corto de tiempo, dicha solicitud se ignora.

El sistema RPC no realiza un seguimiento del estado de la conexión, lo que crea problemas cuando varios clientes acceden al mismo archivo al mismo tiempo. Hay dos dificultades aquí:

• cómo bloquear un archivo, en particular al escribir en él;
• ¿Cómo garantizar la integridad de los bloqueos en caso de bloqueo y reinicio del servidor o cliente NFS?

Para hacer esto, NFS usa dos demonios especiales: rpc.lockd es responsable de bloquear archivos y rpc.statd es responsable de monitorear el estado de los bloqueos (ver Figura 3). Estos demonios se ejecutan tanto en el lado del cliente como en el lado del servidor. Los demonios rpc.lockd y rpc.statd tienen dos directorios especiales (sm y sm.bak) donde se almacena la información de bloqueo.

Un servicio adicional de montaje automático peculiar y bastante conveniente le permite montar automáticamente sistemas de archivos cuando los procesos de usuario acceden a ellos. En el futuro, el montador automático intentará periódicamente (una vez cada cinco minutos de forma predeterminada) desmontar el sistema. Si está ocupado (por ejemplo, hay un archivo abierto), el servicio continúa funcionando como de costumbre. Si no hay más accesos al sistema de archivos, se desmontará automáticamente. La función automounter implementa varios programas, siendo amd y autofs especialmente populares.

CARACTERÍSTICAS DE NFS V3

La versión 3 de NFS es totalmente compatible con la versión 2, es decir, el servidor NFS v3 "entiende" los clientes NFS v2 y NFS v3. De manera similar, un cliente NFS v3 puede acceder a un servidor NFS v2.

Una innovación importante en NFS v3 es la compatibilidad con el protocolo de transporte TCP. UDP es excelente para redes de área local, pero no para enlaces globales lentos y no siempre confiables. En NFS v3, todo el tráfico del cliente se multiplexa en una sola conexión TCP.

En NFS v3, el tamaño del búfer de caché se ha aumentado a 64 KB, lo que tiene un efecto beneficioso sobre el rendimiento, especialmente a la luz del uso activo de las tecnologías de red de alta velocidad Fast Ethernet, Gigabit Ethernet y ATM. Además, NFS v3 le permite almacenar información almacenada en caché en el cliente no solo en la RAM, sino también en el disco local del cliente (para ser justos, debe tenerse en cuenta que algunas implementaciones de NFS v2 también brindan esta posibilidad). Esta tecnología se conoce como CacheFS.

Pero quizás aún más importante que NFS v3 es el aumento radical en el rendimiento de escritura. Ahora el almacenamiento en caché de la información que se escribe también se realiza en el lado del servidor, mientras que el registro y la confirmación del hecho de escribir datos en el disco se realizan mediante una solicitud de compromiso especial (consulte la Figura 4). Esta tecnología se denomina escritura asíncrona segura. Una vez que los datos se han transferido a la memoria caché del servidor, el cliente le envía una solicitud de confirmación, que inicia una operación de escritura en el disco del servidor. A su vez, cuando la información se escribe en el disco, el servidor envía al cliente una confirmación de su finalización exitosa.

Lo nuevo en NFS v3 es el soporte para sistemas de archivos de 64 bits y soporte mejorado para ACL.

De cara al futuro, Sun ahora está promocionando la tecnología WebNFS, que permite acceder a los sistemas de archivos desde cualquier navegador web oa través de aplicaciones escritas en Java. No es necesario instalar ningún software de cliente. WebNFS es (según Sun) una mejora de rendimiento de tres a cinco veces sobre ftp o HTTP.

CONCLUSIÓN

Conociendo los principios de los protocolos NFS, el administrador puede realizar las mejores configuraciones para el servicio. El sistema de archivos de red NFS es ideal para redes UNIX, ya que viene con casi todas las versiones de este sistema operativo. Además, la compatibilidad con NFS se implementa a nivel del kernel de UNIX. A medida que Linux gana terreno lentamente a nivel de escritorio, NFS también tiene la oportunidad de ponerse al día aquí. Desafortunadamente, el uso de NFS en las computadoras cliente de Windows crea ciertos problemas asociados con la necesidad de instalar un software de cliente especializado y bastante costoso. En tales redes, el uso del servicio SMB, en particular el software Samba, parece ser más preferible. Sin embargo, volveremos a los productos SMB para UNIX en uno de los próximos números de LAN.

El protocolo Network File Server (NFS) es un estándar abierto para proporcionar a un usuario acceso remoto a los sistemas de archivos. Según esto, los sistemas de archivos centralizados facilitan la realización de tareas diarias, como copias de seguridad o controles de virus, y las particiones de disco concatenadas son más fáciles de mantener que muchas pequeñas y distribuidas.

Además de proporcionar almacenamiento centralizado, NFS ha demostrado ser muy útil para otras aplicaciones, incluidos clientes ligeros y sin disco, clústeres de red y middleware colaborativo.

Una mejor comprensión tanto del protocolo en sí como de los detalles de su implementación facilitará el manejo de problemas prácticos. Este artículo está dedicado a NFS y consta de dos partes lógicas: primero, se describe el protocolo en sí y los objetivos establecidos durante su desarrollo, y luego la implementación de NFS en Solaris y UNIX.

DONDE EMPEZÓ TODO...

El protocolo NFS fue desarrollado por Sun Microsystems y apareció en Internet en 1989 como RFC 1094 con el siguiente título: Network File System Protocol Specification (NFS). Es interesante notar que la estrategia de Novell en ese momento era mejorar aún más los servicios de archivos. Hasta hace poco, mientras el movimiento de código abierto aún estaba en pleno apogeo, Sun no quería revelar los secretos de sus soluciones de red, pero incluso entonces la empresa entendió la importancia de garantizar la interoperabilidad con otros sistemas.

RFC 1094 contenía dos especificaciones originales. En el momento de su publicación, Sun estaba desarrollando la próxima tercera versión de la especificación, que se establece en RFC 1813 "Especificación del protocolo NFS, versión 3" (Especificación del protocolo NFS versión 3). La versión 4 de este protocolo se define en RFC 3010 NFS Protocol Specification Version 4 (NFS Version 4 Protocol).

NFS se utiliza ampliamente en todo tipo de hosts UNIX, redes Microsoft y Novell y soluciones IBM como AS400 y OS/390. Desconocido fuera del ámbito de la red, NFS es posiblemente el sistema de archivos de red independiente de la plataforma más utilizado.

UNIX FUE EL GENERADOR

Aunque NFS es un sistema independiente de la plataforma, UNIX es su antecesor. En otras palabras, la arquitectura jerárquica y los métodos para acceder a los archivos, incluida la estructura del sistema de archivos, las formas en que se identifican los usuarios y grupos y cómo se manejan los archivos, son todos muy similares al sistema de archivos UNIX. Por ejemplo, el sistema de archivos NFS, al ser idéntico en estructura al sistema de archivos UNIX, se monta directamente en él. Cuando se trabaja con NFS en otros sistemas operativos, se asignan las identidades de usuario y los permisos de archivo.

NFS

El sistema NFS está diseñado para ser utilizado en una arquitectura cliente-servidor. El cliente accede al sistema de archivos exportado por el servidor NFS a través de un punto de montaje en el cliente. Dicho acceso suele ser transparente para la aplicación cliente.

A diferencia de muchos sistemas cliente/servidor, NFS utiliza llamadas de procedimiento remoto (RPC) para intercambiar información. Normalmente, el cliente establece una conexión a un puerto conocido y luego, de acuerdo con el protocolo, envía una solicitud para realizar una determinada acción. En el caso de una llamada a procedimiento remoto, el cliente crea una llamada a procedimiento y luego la envía al servidor para su ejecución. A continuación se presenta una descripción detallada de NFS.

Como ejemplo, suponga que un cliente ha montado el directorio usr2 en el sistema de archivos raíz local:

/raíz/usr2/ -> remoto:/raíz/usr/

Si una aplicación cliente necesita los recursos de este directorio, simplemente envía una solicitud al sistema operativo y el nombre del archivo, que proporciona acceso a través del cliente NFS. Por ejemplo, considere el simple comando cd de UNIX, que "no sabe nada" acerca de los protocolos de red. Equipo

CD /raíz/usr2/

colocará el directorio de trabajo en el sistema de archivos remoto sin "ni siquiera saber" (el usuario tampoco necesita saber) que el sistema de archivos es remoto.

Al recibir la solicitud, el servidor NFS verificará si el usuario dado tiene derecho a realizar la acción solicitada y, si la respuesta es positiva, la realizará.

VAMOS A CONOCERME MEJOR

Desde el punto de vista del cliente, el proceso de montar un sistema de archivos remoto localmente mediante NFS consta de varios pasos. Como ya se mencionó, el cliente NFS enviará una llamada de procedimiento remoto para ejecutarlo en el servidor. Tenga en cuenta que en UNIX el cliente es un solo programa (el comando de montaje), mientras que el servidor en realidad se implementa como varios programas con el siguiente conjunto mínimo: servicio de asignación de puertos (port mapper), demonio de montaje (mount daemon) y servidor NFS.

El comando de montaje del cliente primero se comunica con el servicio de traducción de puertos del servidor, que escucha las solicitudes en el puerto 111. La mayoría de las implementaciones del comando de montaje del cliente admiten varias versiones de NFS, lo que hace más probable que el cliente y el servidor encuentren una versión de protocolo común. La búsqueda se realiza a partir de la versión más antigua, por lo que cuando se encuentra una común, se convierte automáticamente en la versión más nueva soportada por el cliente y el servidor.

(Este material se centra en la tercera versión de NFS, ya que es la más común en este momento. La cuarta versión aún no es compatible con la mayoría de las implementaciones).

El servicio de traducción del puerto del servidor responde a las solicitudes de acuerdo con el protocolo admitido y el puerto en el que se ejecuta el demonio de montaje. El programa de montaje del cliente primero establece una conexión con el demonio de montaje del servidor y luego le envía el comando de montaje a través de RPC. Si este procedimiento se completa con éxito, la aplicación cliente se conecta al servidor NFS (puerto 2049) y, utilizando uno de los 20 procedimientos remotos que se definen en RFC 1813 y se enumeran en la Tabla 1, accede al sistema de archivos remoto.

El significado de la mayoría de los comandos es intuitivo y no causa ninguna dificultad a los administradores del sistema. La siguiente lista, producida usando tcdump, ilustra el comando de lectura usado por el comando cat de UNIX para leer un archivo llamado archivo de prueba:

10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 búsqueda fh 32.0/ 224145 "archivo de prueba" 10:30:16.012010 eth0 > 192.168.1.254. 3476097947> 192.168.1.252.2049: 144 Búsqueda FH 32.0/ 224145 "File de prueba" 10: 30: 16.012729 ETH0 192.168.1.254.3476097947: Respuesta OK 128 Buscar FH 32.0/ 224 307 (DF0) 16.01222222222. : responder ok 128 buscar fh 32.0/224307 (DF) 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 leer fh 32.0/ 224307 4096 bytes @ 0 10:30:16.013124 eth0 > 192.168.1.254. 3492875163> 192.168.1.252.2049: 140 Read FH 32.0/ 224307 4096 bytes @ 0 10: 30.013650 Eth0 192.168.1.254.3492875163: Respuesta ok 108 Leer (DF) 10: 30.013650 Eth0 192.168. .16LA : respuesta ok 108 lectura (DF)

NFS se ha implementado tradicionalmente sobre UDP. Sin embargo, algunas versiones de NFS admiten TCP (la compatibilidad con TCP se define en la especificación del protocolo). La principal ventaja de TCP es un mecanismo de retransmisión más eficiente en redes poco fiables. (En el caso de UDP, si se produce un error, se retransmite el mensaje RPC completo, que consta de varios paquetes UDP. Con TCP, solo se retransmite el fragmento corrupto).

ACCESO A NFS

Las implementaciones de NFS suelen admitir cuatro métodos para otorgar derechos de acceso: a través de atributos de usuario/archivo, a nivel de recurso compartido, a nivel de nodo principal y como una combinación de otros métodos de acceso.

El primer método se basa en el sistema UNIX integrado de permisos de archivo para un usuario o grupo individual. Para simplificar el mantenimiento, la identificación de usuarios y grupos debe ser coherente en todos los clientes y servidores NFS. La seguridad debe considerarse cuidadosamente: NFS puede otorgar acceso a archivos sin darse cuenta que no estaba previsto cuando se crearon.

El acceso a recursos compartidos le permite restringir los derechos solo a ciertas acciones, independientemente de la propiedad del archivo o los privilegios de UNIX. Por ejemplo, trabajar con el sistema de archivos NFS puede limitarse a solo lectura. La mayoría de las implementaciones de NFS le permiten restringir aún más el acceso a nivel de recursos compartidos a usuarios y/o grupos específicos. Por ejemplo, el grupo de Recursos Humanos puede ver información y nada más.

El acceso de nivel maestro le permite montar un sistema de archivos solo en nodos específicos, lo que generalmente es una buena idea, ya que los sistemas de archivos se pueden crear fácilmente en cualquier nodo que admita NFS.

El acceso combinado simplemente combina los tipos anteriores (por ejemplo, acceso de nivel compartido con acceso otorgado a un usuario específico) o permite que los usuarios accedan a NFS solo desde un host específico.

ESTILO PINGÜINO NFS

El material relacionado con Linux que se presenta aquí se basa en un sistema Red Hat 6.2 con kernel versión 2.4.9, que se envía con la versión 0.1.6 del paquete nfs-utils. También existen versiones más nuevas: en el momento de escribir este artículo, la actualización más reciente del paquete nfs-utils es 0.3.1. Se puede descargar en: .

El paquete nfs-utils contiene los siguientes binarios: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount y statd.

Desafortunadamente, la compatibilidad con NFS a veces es confusa para los administradores de Linux, ya que la disponibilidad de una función en particular depende directamente de los números de versión del kernel y del paquete nfs-utils. Afortunadamente, las cosas están mejorando en esta área ahora: los últimos kits de distribución incluyen las últimas versiones de ambos. Para versiones anteriores, la sección 2.4 de NFS-HOWTO proporciona una lista completa de la funcionalidad del sistema disponible para cada combinación de kernel y paquete nfs-utils. Los desarrolladores mantienen la retrocompatibilidad del paquete con versiones anteriores, prestando mucha atención a la seguridad y corrigiendo errores de software.

La compatibilidad con NFS debe iniciarse en el momento de la compilación del kernel. Si es necesario, también se debe agregar al kernel la capacidad de trabajar con NFS versión 3.

Para distribuciones que soportan linuxconf, es fácil configurar servicios NFS para clientes y servidores. Sin embargo, la forma rápida de configurar NFS usando linuxconf no brinda información sobre qué archivos se crearon o editaron, lo cual es muy importante que el administrador sepa para comprender la situación en caso de una falla del sistema. La arquitectura de NFS en Linux está ligeramente acoplada a la versión BSD, por lo que los archivos y programas de soporte necesarios son fáciles de encontrar para los administradores que ejecutan BSD, Sun OS 2.5 o versiones anteriores de NFS.

El archivo /etc/exports, como en versiones anteriores de BSD, especifica los sistemas de archivos a los que pueden acceder los clientes NFS. Además, contiene una serie de funciones adicionales relacionadas con cuestiones de gestión y seguridad, lo que proporciona al administrador una herramienta para realizar ajustes. Este es un archivo de texto que consta de entradas, líneas en blanco o líneas comentadas (los comentarios comienzan con #).

Digamos que queremos dar a los clientes acceso de solo lectura al directorio /home en el host Lefty. Esto correspondería a la siguiente entrada en /etc/exports:

/casa (ro)

Aquí necesitamos decirle al sistema qué directorios vamos a hacer disponibles usando el demonio de montaje rpc.mountd:

# exportfs -r exportfs: No se especificó ningún nombre de host en /home (ro), escriba *(ro) para evitar la advertencia #

Cuando se ejecuta, el comando exportfs advierte que /etc/exports no restringe el acceso a un nodo en particular y crea una entrada correspondiente en /var/lib/nfs/etab desde /etc/exports que indica qué recursos se pueden ver con cat:

# cat /var/lib/nfs/etab /home (ro,async,wdelay,hide,secure,root_squash, no_all_squash,subtree_check, secure_locks, mapping=identity,anonuid= -2,anongid=-2)

Otras opciones enumeradas en etab incluyen los valores predeterminados utilizados por NFS. Los detalles se describirán a continuación. Para otorgar acceso al directorio /home, se deben iniciar los servicios NFS apropiados:

# mapa de puertos # rpc.mountd # rpc.nfsd # rpc.statd # rpc.rquotad

En cualquier momento después de que se haya iniciado el demonio de montaje (rpc.mountd), puede consultar los archivos individuales disponibles para salida al ver el contenido del archivo /proc/fs/nfs/exports:

# cat /proc/fs/nfs/exports # Versión 1.0 # Path Client (Flags) # IPs /home 192.168.1.252(ro,root_squash,async, wdelay) # 192.168.1.252 #

Lo mismo se puede ver usando el comando showmount con la opción -e:

# showmount -e Exportar lista para zurdos: /home (todos) #

Avanzando un poco, el comando showmount también se puede usar para determinar todos los sistemas de archivos montados o, en otras palabras, para averiguar qué hosts son clientes NFS para el sistema que ejecuta el comando showmount. El comando showmount -a enumerará todos los puntos de montaje del cliente:

# showmount -a Todos los puntos de montaje en lefty: 192.168.1.252:/home #

Como se indicó anteriormente, la mayoría de las implementaciones de NFS admiten varias versiones de este protocolo. La implementación de Linux le permite limitar la lista de versiones de NFS que se ejecutarán especificando la opción -N para el demonio de montaje. Por ejemplo, para iniciar la versión 3 de NFS y solo la versión 3, ingrese el siguiente comando:

# rpc.montaje -N 1 -N 2

Los usuarios fastidiosos pueden encontrar inconveniente que en Linux el demonio NFS (rpc.nfsd) está esperando los paquetes de la versión 1 y la versión 2, aunque esto logra el efecto deseado de no soportar el protocolo correspondiente. Esperemos que los desarrolladores de las próximas versiones hagan las correcciones necesarias y puedan lograr una mayor consistencia entre los componentes del paquete en relación a las diferentes versiones del protocolo.

"NADAR CON PINGÜINOS"

El acceso al sistema de archivos exportable NFS basado en Linux de Lefty, configurado anteriormente, depende del sistema operativo del cliente. El estilo de instalación para la mayoría de los sistemas operativos de la familia UNIX es el mismo que el de los sistemas Sun OS y BSD originales o el Solaris más nuevo. Dado que este artículo se centra tanto en Linux como en Solaris, veamos la configuración del cliente de Solaris 2.6 desde el punto de vista del establecimiento de una conexión con la versión de NFS para Linux que describimos anteriormente.

Con funciones heredadas de Solaris 2.6, es fácil configurarlo para que actúe como un cliente NFS. Esto requiere solo un comando:

# montaje -F nfs 192.168.1.254:/inicio /tmp/tmp2

Suponiendo que el comando de montaje anterior tuvo éxito, entonces el comando de montaje sin opciones generará lo siguiente:

# mount / on /dev/dsk/c0t0d0s0 lectura/escritura/setuid/ archivos grandes el lunes 3 de septiembre 10:17:56 2001 ... ... /tmp/tmp2 en 192.168.1.254:/home read/ write/remote on lun 3 sep 23:19:25 2001

Analicemos la salida de tcpdump en el host Lefty después de que el usuario haya ingresado el comando ls /tmp/tmp2 en el host Sunny:

# tcpdump anfitrión zurdo y anfitrión soleado -s512 06:07:43.490583 soleado.2191983953 > zurdo.mcwrite.n.nfs: 128 getattr fh Desconocido/1 (DF) 06:07:43.490678 zurdo.mcwrite.n.nfs > soleado. 2191983953: responder ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:07:43.491397 mcwrite.n.nfs > sunny.2191983954: responder ok 120 acceso c0001 (DF) 06:07:43.8.4925296 lefty > .mcwrite.n.nfs: 152 readdirplus fh 0.1/16777984 1048 bytes @ 0x000000000 (DF) 06:07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: responder bien 1000 readdirplus (DF)

Vemos que el nodo Sunny solicita un descriptor de archivo (fh) para ls, a lo que el nodo Lefty envía OK en respuesta y devuelve la estructura del directorio. Sunny luego verifica el permiso para el contenido del directorio (132 access fh) y recibe una respuesta de permiso de Lefty. A continuación, el Sunny Node lee el contenido completo del directorio mediante el procedimiento readdirplus. Las llamadas a procedimientos remotos se describen en RFC 1813 y se enumeran al principio de este artículo.

Aunque la secuencia de comandos para acceder a los sistemas de archivos remotos es muy simple, varias circunstancias pueden hacer que el sistema se monte incorrectamente. Antes de montar un directorio, el punto de montaje ya debe existir; de lo contrario, debe crearse con el comando mkdir. Por lo general, la única causa de errores en el lado del cliente es la falta de un directorio de montaje local. Sin embargo, la mayoría de los problemas asociados con NFS tienen su origen en una falta de coincidencia entre el cliente y el servidor, o en una configuración incorrecta del servidor.

La forma más fácil de solucionar problemas en un servidor es desde el host donde se ejecuta el servidor. Sin embargo, cuando otra persona administra el servidor en lugar de usted, esto no siempre es posible. Una forma rápida de asegurarse de que los servicios de servidor apropiados estén configurados correctamente es usar el comando rpcinfo con la opción -p. Desde el host Solaris Sunny, puede determinar qué procesos RPC están registrados en el host Linux:

# Rpcinfo -p 192.168.1.254 vers ver servicio de puerto proto 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 UDP 692 status 100024 1 tcp 694 status 1024 muuntd /100005 3 tcp 1024 muudd /100005 3 udp 2049 nfs 100021s 100021 nlockmgr 100021 3 udp 1026 nlockmgr 100021 4 udp 1026 nlockmgr #

Tenga en cuenta que aquí también se proporciona información sobre la versión, lo cual es bastante útil cuando el sistema requiere soporte para varios protocolos NFS. Si algún servicio no se está ejecutando en el servidor, esta situación debe corregirse. Si el montaje falla, el siguiente comando rpcinfo -p le indicará que el servicio de montaje en el servidor está inactivo:

# rpcinfo -p 192.168.1.254 programa vers proto puerto servicio 100000 2 tcp 111 rpcbind ... ... 100021 4 udp 1026 nlockmgr #

El comando rpcinfo es muy útil para saber si un proceso remoto en particular está activo. La opción -p es la más importante de las opciones. Consulte la página del manual para conocer todas las características de rpcinfo.

Otra herramienta útil es el comando nfsstat. Con su ayuda, puede averiguar si los clientes realmente están accediendo al sistema de archivos exportado, así como mostrar información estadística de acuerdo con la versión del protocolo.

Finalmente, otra herramienta bastante útil para determinar las causas de las fallas del sistema es tcpdump:

# tcpdump anfitrión zurdo y anfitrión soleado -s512 tcpdump: escuchando en eth0 06:29:51.773646 soleado.2191984020 > zurdo.mcwrite.n.nfs: 140 búsqueda fh Desconocido/1"prueba.c" (DF) 06:29:51.773819 lefty.mcwrite.n.nfs > sunny.2191984020: responde bien 116 ERROR de búsqueda: No existe tal archivo o directorio (DF) 06:29:51.774593 sunny.2191984021 > lefty.mcwrite.n.nfs: 128 getattr fh Desconocido/1 ( DF) 06:29:51.774670 lefty.mcwrite.n.nfs > sunny.2191984021: responder bien 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:29:51.775289 sunny.2191984022 > lefty.mcwrite.n.nfs : 140 búsqueda fh Desconocido/1"test.c" (DF) 06:29:51.775357 lefty.mcwrite.n.nfs > sunny.2191984022: respuesta ok 116 búsqueda ERROR: No existe tal archivo o directorio (DF) 06:29: 51.776029 sunny.2191984023 > lefty.mcwrite.n.nfs: 184 crear fh Desconocido/1 "test.c" (DF) 06:29:51.776169 lefty.mcwrite.n.nfs > sunny.2191984023: responder ok 120 crear ERROR: Permiso denegado (DF)

El listado anterior, obtenido después de ejecutar la declaración touch test.c, muestra la siguiente secuencia de acciones: primero, el comando touch intenta acceder a un archivo llamado test.c, luego busca un directorio con el mismo nombre y luego no tiene éxito. intentos, intenta crear el archivo test.c , que también falla.

Si el sistema de archivos está montado, la mayoría de los errores comunes están relacionados con los permisos normales de UNIX. El uso de uid o NIS+ por parte de Sun evita establecer permisos globalmente en todos los sistemas de archivos. Algunos administradores practican directorios "abiertos", donde se otorgan permisos para leerlos a "todo el mundo". Sin embargo, esto debe evitarse por razones de seguridad. Dejando a un lado las preocupaciones de seguridad, esta sigue siendo una mala práctica porque los usuarios rara vez crean datos con la intención de que todos puedan leerlos.

Los accesos de un usuario privilegiado (raíz) a los sistemas de archivos montados en NFS se tratan de manera diferente. Para evitar otorgar acceso sin restricciones a un usuario privilegiado, las solicitudes del usuario privilegiado se tratan como si fueran del usuario "nadie". Este poderoso mecanismo restringe el acceso de usuarios privilegiados a archivos de lectura y escritura global.

SERVIDOR NFS, VERSIÓN SOLARIS

Configurar Solaris para que actúe como un servidor NFS es tan fácil como con Linux. Sin embargo, los comandos y las ubicaciones de los archivos son algo diferentes. Cuando se inicia Solaris, cuando se alcanza el nivel de inicio 3, los servicios NFS se inician automáticamente y todos los sistemas de archivos se exportan. Para iniciar estos procesos manualmente, ingrese el comando:

#/usr/lib/nfs/montar

Para iniciar el demonio de montaje y el servidor NFS, escriba:

#/usr/lib/nfs/nfsd

A partir de la versión 2.6, Solaris ya no usa un archivo de exportación para especificar qué sistemas de archivos exportar. Los archivos ahora se exportan usando el comando compartir. Supongamos que queremos permitir que los hosts remotos monten /export/home. Para hacer esto, ingrese el siguiente comando:

Compartir -F nfs /exportar/inicio

Medidas de seguridad

SEGURIDAD EN LINUX

Algunos servicios del sistema NFS basados ​​en Linux tienen un mecanismo adicional para restringir el acceso a través de tablas o listas de control. A nivel interno, este mecanismo se implementa mediante la biblioteca tcp_wrapper, que utiliza dos archivos para formar listas de control de acceso: /etc/hosts.allow y /etc/hosts/deny. Una descripción general exhaustiva de las reglas para trabajar con tcp_wrapper está más allá del alcance de este artículo, pero el principio básico es el siguiente: la coincidencia se realiza primero con etc/hosts.allow y luego con /etc/hosts. negar. Si no se encuentra la regla, no se presenta el servicio del sistema solicitado. Para sortear el último requisito y brindar un alto nivel de seguridad, puede agregar la siguiente entrada al final de /etc/hosts.deny:

Todo todo

Después de eso, /etc/hosts.allow se puede usar para configurar este o aquel modo de operación. Por ejemplo, el archivo /etc/hosts. allow , que utilicé al escribir este artículo, contenía las siguientes líneas:

lockd:192.168.1.0/255.255.255.0 mountd:192.168.1.0/255.255.255.0 portmap:192.168.1.0/255.255.255.0 rquotad:192.168.1.0/255.255.255.0

Esto permite algún tipo de acceso a los nodos antes de otorgar acceso a la capa de aplicación. En Linux, el acceso a nivel de aplicación está controlado por el archivo /etc/exports. Consta de entradas en el siguiente formato:

Exportar directorio (espacio) host|red (opciones)

Un "directorio exportado" es un directorio para el que el demonio nfsd puede procesar una solicitud. "Host|network" es el host o la red que tiene acceso al sistema de archivos exportado, y "opciones" determina qué restricciones impone el daemon nfsd sobre el uso de este recurso compartido: acceso de solo lectura o asignación de ID de usuario.

El siguiente ejemplo otorga a todo el dominio mcwrite.net acceso de solo lectura a /home/mcwrite.net:

/inicio/mcwrite.net *.mcwrite.net(ro)

Se pueden encontrar más ejemplos en la página del manual de exportaciones.

SEGURIDAD NFS EN SOLARIS

En Solaris, la capacidad de proporcionar acceso NFS es similar a la de Linux, pero en este caso, las restricciones se establecen usando ciertas opciones en el comando compartir con el modificador -o. El siguiente ejemplo muestra cómo habilitar el montaje de solo lectura de /export/mcwrite.net en cualquier host en el dominio mcwrite.net:

#share -F nfs -o ro=.mcwrite.net/ export/ mcwrite.net

La página man de share_nfs detalla cómo otorgar acceso mediante listas de control en Solaris.

recursos de Internet

NFS y RPC no estaban exentos de "agujeros". En términos generales, NFS no debe usarse en Internet. No puede "agujerear" los cortafuegos al permitir el acceso de cualquier tipo a través de NFS. Todos los parches de RPC y NFS deben monitorearse cuidadosamente, y numerosas fuentes de información de seguridad pueden ayudar. Las dos fuentes más populares son Bugtraq y CERT:

El primero se puede ver regularmente en busca de la información necesaria o utilizar una suscripción a un boletín periódico. El segundo proporciona, quizás, información no tan rápida en comparación con otros, pero en un volumen bastante completo y sin el asomo de sensacionalismo, característico de algunos sitios dedicados a la seguridad de la información.