Protocolo NFS. Sistema de archivos de red (NFS): sistema de archivos de red

Network File System (NFS) es una solución para compartir archivos para organizaciones que tienen entornos de máquinas mixtos Windows y Unix/Linux. El sistema de archivos NFS le permite compartir archivos entre plataformas específicas mientras ejecuta el sistema operativo Windows Server 2012. Los servicios NFS en Windows Server 2012 incluyen las siguientes características y mejoras.

1. Búsqueda en directorio activo. Tiene la posibilidad de utilizar Windows Active Directory para acceder a archivos. La extensión del esquema Identity Management for Unix para Active Directory contiene campos de identificador de usuario (UID) y de identificador de grupo (GID) de Unix. Esto permite que el Servidor para NFS y el Cliente para NFS vean las asignaciones de cuentas de usuario de Windows en Unix directamente desde los Servicios de dominio de Active Directory. Identity Management para Unix facilita la gestión de la asignación de cuentas de usuario de Windows en Unix a los servicios de dominio de Active Directory.

2. Rendimiento mejorado del servidor. Los servicios para NFS incluyen un controlador de filtro de archivos que reduce significativamente la latencia general al acceder a archivos en el servidor.

3. Soporte para dispositivos Unix especiales. Los servicios para NFS admiten dispositivos Unix especiales (mknod).

4. Soporte Unix ampliado. Los servicios para NFS admiten las siguientes versiones de Unix: Sun Microsystems Solaris versión 9, Red Hat Linux versión 9, IBM AIX versión 5L 5.2 y Hewlett Packard HP-UX versión 11i, así como muchas distribuciones modernas de Linux.

Uno de los escenarios más comunes que crean la necesidad de NFS implica exponer un sistema de planificación de recursos empresariales (ERP) basado en Unix a los usuarios de Windows. Mientras están en el sistema ERP, los usuarios pueden crear informes y/o exportar datos financieros a Microsoft Excel para su posterior análisis. El sistema de archivos NFS permite acceder a estos archivos mientras aún se encuentran en el entorno Windows, lo que reduce la necesidad de habilidades técnicas especializadas y el tiempo dedicado a exportar archivos utilizando un script Unix y luego importarlos a una aplicación específica de Windows.

También puede darse una situación en la que tenga un sistema Unix que se utilice para almacenar archivos en algún tipo de red de área de almacenamiento (SAN). La ejecución de servicios NFS en una máquina con Windows Server 2012 permite a los usuarios de una organización acceder a los archivos almacenados allí sin la sobrecarga de las secuencias de comandos del lado Unix.

Antes de instalar los Servicios NFS, debe eliminar todos los componentes NFS instalados previamente, como los componentes NFS que se incluyeron con los Servicios para Unix.

Componentes de servicios NFS

Los siguientes dos componentes de servicios NFS están disponibles.

1. Servidor para NFS(Servidor para NFS). Normalmente, una computadora basada en Unix no puede acceder a los archivos ubicados en una computadora basada en Windows. Sin embargo, una computadora que ejecuta Windows Server 2012 R2 y Server para NFS puede actuar como servidor de archivos para computadoras Windows y Unix.

2. Cliente para NFS(Cliente para NFS). Normalmente, una computadora basada en Windows no puede acceder a los archivos ubicados en una computadora basada en Unix. Sin embargo, una computadora que ejecuta Windows Server 2012 R2 y la función Cliente para NFS puede acceder a archivos almacenados en un servidor NFS basado en Unix.

Instalación del servidor para NFS usando PowerShell

Veamos cómo usar PowerShell para instalar la función NFS en un servidor y crear un recurso compartido de archivos NFS.

1. Abra una ventana de Windows PowerShell a través de la barra de tareas como cuenta de administrador.

2. Ingrese los siguientes comandos para instalar la función NFS en el servidor:

PS C:\> Import-Module ServerManager PS C:\> Add-WindowsFeature FS-NFS-Services PS C:\> Import-Module NFS

3. Ingrese el siguiente comando para crear un nuevo recurso compartido de archivos NFS:

PS C:\> Nuevo-NfsShare -Nombre "Prueba" -Ruta "C:\Shares\Test"

4. Para ver todos los nuevos cmdlets de PowerShell específicos de NFS que están disponibles en Windows Server 2012 R2, ejecute el siguiente comando:

PS C:\>Get-Command -Módulo NFS

5. Haga clic derecho en la carpeta C:\Shares\Test, seleccione "propiedades" y luego vaya a la pestaña Compartir NFS. Haga clic en el botón Administrar uso compartido de NFS; en el cuadro de diálogo que aparece, puede administrar los permisos de acceso a las carpetas, permitir el acceso anónimo y configurar los ajustes de codificación de archivos. Puede compartir una carpeta a través de NFS usando el cuadro de diálogo Uso compartido avanzado de NFS sin usar PowerShell.

Configuración de resoluciones estándar

Ahora necesitaremos abrir algunos puertos del firewall para que funcione NFS. Los puertos necesarios para el funcionamiento normal de los servicios NFS se presentan en la siguiente tabla.

El componente más importante de cualquier sistema distribuido es el sistema de archivos, que en este caso también está distribuido. Como en los sistemas centralizados, la función del sistema de archivos es almacenar programas y datos y proporcionar acceso a los clientes. Un sistema de archivos distribuido es mantenido por 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 directorios de nivel inferior. En muchos sistemas de archivos de red, una computadora cliente puede conectar y montar estos sistemas de archivos en sus sistemas de archivos locales, proporcionando al usuario un acceso conveniente a directorios y archivos remotos. En este caso, los datos de los archivos montados no se mueven físicamente a ningún lado y permanecen 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 servicio de archivos en sí y el servicio de directorio del sistema de archivos. El primero se ocupa de operaciones en archivos individuales, como leer, escribir o agregar (modificar), y 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 un usuario, un sistema de archivos de red debería verse como el suyo en su computadora, es decir, ser completamente transparente. Sin embargo, en realidad, los sistemas de archivos en red aún no están a la altura de este ideal.

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

Sistemas de archivos locales;

Interfaces del sistema de archivos local;

Servidores de sistemas de archivos de red;

Clientes del sistema de archivos de red;

Interfaces del 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 numerosas computadoras conectadas a la red. Estos programas atienden solicitudes de aplicaciones para acceder a archivos almacenados en computadoras remotas. El cliente FS de red transmite solicitudes a través de la red a otro componente de software: el servidor FS de red que se ejecuta en una computadora remota. El servidor, al recibir una solicitud, puede ejecutarla él mismo o, lo que es más común, 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 FS de la red interactúan entre sí a través de la red utilizando un protocolo específico. Si las interfaces FS local y de red coinciden, este protocolo puede ser bastante simple. Un mecanismo utilizado para este propósito puede ser el mecanismo RPC.

En los sistemas operativos Windows, el principal servicio de archivos de red es el protocolo SMB (Server Message Block), 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 transmitir 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 utilizando otros protocolos (TCP/UDP e IPX).

SMB pertenece a la clase de protocolos orientados a conexión. Su trabajo comienza cuando el cliente envía un mensaje especial al servidor solicitando una conexión. Si el servidor está listo para establecer una conexión, responde con un mensaje de confirmación. Una vez establecida la conexión, el cliente puede contactar al servidor enviando comandos para manipular archivos y directorios en mensajes SMB. Durante el funcionamiento, pueden surgir una serie de situaciones que pueden afectar la eficacia 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 FS 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). Cuando el sistema falla, la tabla de archivos abiertos se pierde después de reiniciar la computadora servidor. En este caso, la aplicación que se ejecuta en la computadora cliente no puede continuar trabajando con los archivos que estaban abiertos antes del bloqueo.

Una solución al problema se basa en transferir la función de mantener y almacenar una tabla de archivos abiertos desde el servidor al cliente. Con esta organización se simplifica el protocolo cliente-servidor, ya que reiniciar el servidor sólo 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. Una solución al problema puede ser almacenar en caché los archivos (parcial o totalmente) en el lado del cliente. Sin embargo, en este caso, el protocolo debe tener en cuenta la posibilidad de que se formen varias copias del mismo archivo, que pueden ser modificadas de forma independiente por diferentes usuarios, es decir, el protocolo debe garantizar la coherencia entre las copias de los archivos disponibles en diferentes ordenadores.

3. Pérdida de datos y destrucción de la integridad del sistema de archivos durante fallas y fallas de las computadoras que desempeñan el papel de servidores de archivos. Para aumentar la tolerancia a fallos de un FS de red, puede almacenar varias copias de cada archivo (o del FS completo) 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 la sobrecarga de los servidores de archivos al distribuir las solicitudes de archivos entre múltiples servidores, lo que mejora el rendimiento del sistema de archivos.

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

Los problemas enumerados se resuelven de manera integral mediante la creación de un servicio de autenticación centralizada, replicación, almacenamiento en caché, etc. Estos servicios adicionales se reflejan en el protocolo de interacción entre clientes y servidores, como resultado de lo cual se crean varios protocolos de este tipo que soportan uno u otro conjunto de funciones adicionales. Por lo tanto, para el mismo FS local pueden existir diferentes protocolos de FS de red (Fig. 5.30). Por lo tanto, hoy en día se puede acceder al sistema de archivos NTFS utilizando SMB, NCP (Protocolo de control NetWare) y NFS (Network File System - protocolo del sistema de archivos de red de Sun Microsystems, utilizado en varias versiones del sistema operativo 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 utiliza para acceder no solo a los sistemas de archivos FAT, sino también a los sistemas de archivos NTFS y HPFS (Fig. 5.31). Estos sistemas de archivos pueden estar ubicados en diferentes o en la misma computadora.__

Preguntas de prueba para el Capítulo 5

1. ¿Qué ventajas tienen las redes sobre el uso separado de computadoras?

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

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. Enumere los posibles clientes de la red informática.

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

11. ¿Cómo entiendes el término “segmentación” de una red?

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

13. ¿En qué se diferencia un sistema operativo distribuido de uno en red? ¿Existen hoy en día sistemas de red verdaderamente distribuidos?

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

15. Algunos servicios de red no están dirigidos al usuario, sino al administrador. ¿Qué servicios son estos?

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

17. Nombra los rasgos característicos de las redes peer-to-peer. ¿Cuál es la característica principal de una red multipar?

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

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

20. ¿Qué tiene de bueno el procesamiento de aplicaciones de dos niveles cuando el servidor y el cliente colaboran?

21. ¿Existe alguna ventaja en el esquema de procesamiento de solicitudes de tres niveles? ¿Cuáles son?

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

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

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

25. ¿Qué se entiende por llamadas a procedimientos remotos?

NFS: un sistema de archivos de red conveniente y prometedor

sistema de archivos de red es una abstracción de red sobre un sistema de archivos normal que permite que un cliente remoto acceda a él a través de la red de la misma manera que cuando accede a los sistemas de archivos locales. Aunque NFS no fue el primer sistema de archivos de red, ha evolucionado hasta convertirse en el sistema de archivos de red más capaz y popular en UNIX® en la actualidad. NFS permite que varios usuarios compartan un sistema de archivos común y centraliza los datos para minimizar el espacio en disco necesario para almacenarlos.

Este artículo comienza con una breve descripción general de la historia de NFS y luego continúa explorando la arquitectura de NFS y cómo podría evolucionar en el futuro.

Una breve historia de NFS

El primer sistema de archivos de red se llamó FAL (File Access Listener) y fue desarrollado en 1976 por DEC (Digital Equipment Corporation). Era una implementación del protocolo DAP (Protocolo de acceso a datos) y formaba parte del conjunto de protocolos DECnet. Al igual que con TCP/IP, DEC ha publicado especificaciones para sus protocolos de red, incluido el protocolo DAP.

NFS fue el primer sistema de archivos de red moderno construido sobre el protocolo IP. Su prototipo puede considerarse un sistema de archivos experimental desarrollado en Sun Microsystems a principios de los años 80. Dada la popularidad de esta solución, el protocolo NFS se introdujo como una especificación RFC y posteriormente evolucionó a NFSv2. NFS rápidamente se estableció como estándar debido a su capacidad para interoperar con otros clientes y servidores.

Posteriormente, el estándar se actualizó a NFSv3, definido en RFC 1813. Esta versión del protocolo era más escalable que las versiones anteriores y admitía archivos de mayor tamaño (más de 2 GB), escritura asíncrona y TCP como protocolo de transporte. NFSv3 marcó la dirección para el desarrollo de sistemas de archivos para redes de área amplia (WAN). En 2000, RFC 3010 (revisado como RFC 3530) introdujo NFS en el entorno empresarial. Sun introdujo un NFSv4 más seguro con soporte con estado (las versiones anteriores de NFS no admitían almacenamiento con estado, es decir, se clasificaban como sin estado). Actualmente, la última versión de NFS es la versión 4.1, definida en RFC 5661, que se suma al protocolo extendiendo pnfs Se ha agregado soporte para acceso paralelo para servidores distribuidos.

La historia de NFS, incluidos los RFC específicos que describen sus versiones, se muestra en la Figura 1.

Sorprendentemente, NFS lleva casi 30 años en desarrollo. Es un sistema de archivos de red excepcionalmente estable y portátil con excelentes características de escalabilidad, rendimiento y calidad de servicio. A medida que aumentan las velocidades y disminuye la latencia al comunicarse dentro de una red, NFS sigue siendo una forma popular de implementar un sistema de archivos dentro de una red. Incluso en el caso de las redes locales, la virtualización fomenta el almacenamiento de datos en la red para proporcionar movilidad adicional a las máquinas virtuales. NFS también admite los últimos modelos de entornos informáticos destinados a optimizar las infraestructuras virtuales.

Arquitectura NFS

NFS utiliza un modelo arquitectónico cliente-servidor estándar (como se muestra en la Figura 2). El servidor es responsable de implementar el sistema de archivos compartido y el almacenamiento al que se conectan los clientes. El cliente implementa una interfaz de usuario para un sistema de archivos compartido montado dentro del espacio de archivos local del cliente.

Figura 2. Implementación del modelo cliente-servidor en la arquitectura NFS

En Linux®, un conmutador de sistema de archivos virtual (VFS) proporciona los medios para admitir múltiples sistemas de archivos (por ejemplo, un sistema de archivos ISO 9660 en un CD-ROM y un sistema de archivos ext3fs en un disco duro local) simultáneamente en un único host. . El conmutador virtual determina a qué unidad se realiza la solicitud y, por lo tanto, qué sistema de archivos se debe utilizar para procesar la solicitud. Por tanto, NFS tiene la misma compatibilidad que otros sistemas de archivos utilizados en Linux. La única diferencia con NFS es que en lugar de procesarse localmente en el host, las solicitudes de E/S se pueden enviar a la red para su ejecución.

VFS determina que la solicitud recibida es NFS y la pasa al controlador NFS ubicado en el kernel. El controlador NFS procesa la solicitud de E/S y la traduce en un procedimiento NFS (ABRIR, ACCEDER, CREAR, LEER, CERRAR, ELIMINAR, etc.). Estos procedimientos, descritos en una especificación RFC separada, definen el comportamiento del protocolo NFS. El procedimiento requerido se selecciona según la solicitud y se ejecuta utilizando la tecnología RPC (llamada a procedimiento remoto). Como sugiere su nombre, RPC permite realizar llamadas a procedimientos entre diferentes sistemas. El servicio RPC concatena una solicitud NFS con sus argumentos y envía el resultado al host remoto apropiado, luego monitorea la recepción y el procesamiento de la respuesta para devolvérsela al solicitante.

RPC también incluye una importante capa XDR ( representación de datos externos– representación de datos independiente), asegurando que todos los usuarios de NFS utilicen el mismo formato para los mismos tipos de datos. Cuando una plataforma envía una solicitud, el tipo de datos que utiliza puede ser diferente del tipo de datos utilizado en el host que procesa la solicitud. La tecnología XDR se encarga del trabajo de convertir tipos en una representación estándar (XDR) para que las plataformas que utilizan diferentes arquitecturas puedan interoperar y compartir sistemas de archivos. XDR define el formato de bits para tipos como flotante y el orden de bytes para tipos como matrices de longitud constante y variable. Aunque XDR es conocido principalmente por su uso en NFS, esta especificación puede resultar útil en todos los casos en los que tenga que trabajar en el mismo entorno con diferentes arquitecturas.

Una vez que XDR ha traducido los datos a una representación estándar, la solicitud se envía a través de la red utilizando un protocolo de transporte específico. Las primeras implementaciones de NFS usaban UDP, pero hoy en día se usa TCP para mayor confiabilidad.

Se utiliza un algoritmo similar en el lado del servidor NFS. La solicitud sube por la pila de la red a través de la capa RPC/XDR (para convertir los tipos de datos según la arquitectura del servidor) y llega al servidor NFS, que es responsable de procesar la solicitud. Allí, la solicitud se pasa al demonio NFS para determinar el sistema de archivos de destino al que está dirigida y luego vuelve a VFS para acceder a ese sistema de archivos en el disco local. En la Figura 3 se muestra un diagrama completo de este proceso. En este caso, el sistema de archivos local del servidor es un sistema de archivos Linux estándar, por ejemplo, ext4fs. Básicamente, NFS no es un sistema de archivos en el sentido tradicional del término, sino un protocolo para el acceso remoto a sistemas de archivos.

Para redes con latencia larga, NFSv4 ofrece un procedimiento compuesto especial ( procedimiento compuesto). Este procedimiento le permite realizar múltiples llamadas RPC dentro de una sola solicitud para minimizar el costo de enviar solicitudes a través de la red. Este procedimiento también implementa un mecanismo de función de devolución de llamada para recibir respuestas.

protocolo NFS

Cuando un cliente comienza a usar NFS, la primera acción es realizar una operación de montaje, que consiste en montar el sistema de archivos remoto en el espacio del sistema de archivos local. Este proceso comienza con una llamada al procedimiento de montaje (una de las funciones del sistema Linux), que se redirige a través de VFS al componente NFS. Luego, una llamada RPC a la función get_port en el servidor remoto determina el número de puerto que se utilizará para el montaje y el cliente envía una solicitud de montaje a través de RPC. Esta solicitud en el lado del servidor es procesada por un demonio especial rpc.mountd, que es responsable del protocolo de montaje ( protocolo de montaje). El demonio verifica que el sistema de archivos solicitado por el cliente esté en la lista de sistemas disponibles en el servidor determinado. Si el sistema solicitado existe y el cliente tiene acceso a él, la respuesta de montaje RPC especifica un descriptor del sistema de archivos. El cliente conserva información sobre los puntos de montaje locales y remotos y puede realizar solicitudes de E/S. El protocolo de montaje no es seguro desde el punto de vista de la seguridad, por lo que NFSv4 utiliza llamadas RPC internas, que también pueden administrar puntos de montaje.

Para leer un archivo, primero debe abrirlo. No existe un procedimiento OPEN en RPC; en cambio, el cliente simplemente verifica que el archivo y directorio especificados existan en el sistema de archivos montado. El cliente comienza realizando una solicitud RPC GETATTR al directorio, que devuelve los atributos del directorio o un indicador de que el directorio no existe. A continuación, para comprobar la presencia del archivo, el cliente emite una solicitud LOOKUP RPC. Si el archivo existe, se realiza una solicitud GETATTR RPC para conocer los atributos del archivo. Utilizando la información obtenida de llamadas LOOKUP y GETATTR exitosas, el cliente crea un identificador de archivo que se proporciona al usuario para futuras solicitudes.

Una vez que el archivo ha sido identificado en el sistema de archivos remoto, el cliente puede emitir solicitudes RPC READ. Esta solicitud consta de un descriptor de archivo, un estado, un desplazamiento y la cantidad de bytes a leer. El cliente usa el estado ( estado) para determinar si la operación se puede realizar en el momento, es decir ¿Está el archivo bloqueado? Compensar ( compensar) indica en qué posición comenzar a leer, y el contador de bytes ( contar) determina cuántos bytes deben leerse. Como resultado de la llamada READ RPC, el servidor no siempre devuelve tantos bytes como se solicitaron, pero junto con los datos devueltos siempre informa cuántos bytes se enviaron al cliente.

Innovación en NFS

De mayor interés son las dos últimas versiones de NFS: 4 y 4.1, como ejemplos de las cuales se pueden estudiar los aspectos más importantes de la evolución de la tecnología NFS.

Antes de que NFSv4 estuviera disponible para realizar tareas de administración de archivos como montaje, bloqueo, etc. Había protocolos adicionales especiales. En NFSv4, el proceso de gestión de archivos se simplificó a un único protocolo; Además, a partir de esta versión, UDP ya no se utiliza como protocolo de transporte. NFSv4 incluye soporte para la semántica de acceso a archivos UNIX y Windows®, lo que permite que NFS se integre naturalmente en otros sistemas operativos.

NFSv4.1 introdujo el concepto de NFS paralelo(NFS paralelo - pNFS). Para proporcionar mayores niveles de escalabilidad, NFSv4.1 implementa una arquitectura en la que los datos y metadatos ( calificación) se distribuyen entre dispositivos de forma similar a como se hace en los sistemas de archivos agrupados. Como se muestra en, pNFS divide el ecosistema en tres componentes: cliente, servidor y almacenamiento. En este caso aparecen dos canales: uno para transmitir datos y otro para transmitir comandos de control. pNFS separa los datos de los metadatos que los describen, proporcionando una arquitectura de dos canales. Cuando un cliente quiere acceder a un archivo, el servidor le envía metadatos con "marcado". Los metadatos contienen información sobre la ubicación del archivo en los dispositivos de almacenamiento. Una vez que el cliente tiene esta información, puede acceder al almacenamiento directamente sin tener que interactuar con el servidor, mejorando la escalabilidad y el rendimiento. Cuando el cliente termina de trabajar con el archivo, confirma los cambios realizados en el archivo y su "marcado". Si es necesario, el servidor puede solicitar metadatos con marcado al cliente.

Con la llegada de pNFS, se agregaron varias operaciones nuevas al protocolo NFS para respaldar dicho mecanismo. El método LayoutGet se utiliza para recuperar metadatos del servidor, el método LayoutReturn "libera" los metadatos "capturados" por el cliente y el método LayoutCommit carga el "diseño" recibido del cliente en el almacenamiento para que esté disponible para otros usuarios. . El servidor puede recuperar metadatos del cliente utilizando el método LayoutRecall. Los metadatos "etiquetados" se distribuyen en múltiples dispositivos de almacenamiento para proporcionar acceso paralelo y alto rendimiento.

Los datos y metadatos se almacenan en dispositivos de almacenamiento. Los clientes pueden realizar solicitudes de E/S directas según el marcado recibido y el servidor NFSv4.1 almacena y administra los metadatos. Esta funcionalidad en sí no es nueva, pero pNFS agregó soporte para varios métodos de acceso a dispositivos de almacenamiento. Hoy en día, pNFS admite el uso de protocolos de bloque (Fibre Channel), protocolos de objetos y el propio NFS (ni siquiera en forma pNFS).

El desarrollo de NFS continúa y, en septiembre de 2010, se publicaron los requisitos para NFSv4.2. Algunas de las innovaciones están relacionadas con la migración en curso de las tecnologías de almacenamiento de datos hacia la virtualización. Por ejemplo, en entornos virtuales con un hipervisor, es muy probable que se produzca duplicación de datos (múltiples sistemas operativos leyendo/escribiendo y almacenando en caché los mismos datos). Debido a esto, es deseable que el sistema de almacenamiento en su conjunto comprenda dónde se produce la duplicación. Este enfoque ayudará a ahorrar espacio en la caché del cliente y capacidad de almacenamiento general. NFSv4.2 propone utilizar un "mapa de bloques de bloques compartidos" para resolver este problema. A medida que los sistemas de almacenamiento modernos vienen cada vez más equipados con su propia potencia informática interna, se está introduciendo la copia del lado del servidor para reducir la carga de copiar datos a través de una red interna cuando se puede hacer de manera eficiente en el propio dispositivo de almacenamiento. Otras innovaciones incluyen el almacenamiento en caché de subarchivos para memoria flash y recomendaciones de ajuste de E/S del lado del cliente (como el uso de mapadvise).

Alternativas NFS

Aunque NFS es el sistema de archivos de red más popular en UNIX y Linux, existen otros sistemas de archivos de red. En la plataforma Windows®, el más utilizado es SMB, también conocido como CIFS; sin embargo, el sistema operativo Windows también es compatible con NFS, así como Linux es compatible con SMB.

Uno de los sistemas de archivos distribuidos más nuevos compatibles con Linux, Ceph, está diseñado desde cero para ser un sistema de archivos compatible con POSIX y tolerante a fallos. Puede encontrar más información sobre Ceph en la sección.

También vale la pena mencionar los sistemas de archivos OpenAFS (una versión de código abierto del sistema de archivos distribuido Andrew, desarrollado en la Universidad Carnegie Mellon e IBM Corporation), GlusterFS (un sistema de archivos distribuido de propósito general para organizar el almacenamiento de datos escalable) y Lustre (un sistema de archivos distribuido de uso general para organizar el almacenamiento de datos escalable). sistema de archivos de red paralelo para soluciones de clúster). Todos estos sistemas de código abierto se pueden utilizar para crear almacenamiento distribuido.

Conclusión

Continúa el desarrollo del sistema de archivos NFS. Al igual que el sistema operativo Linux, que puede admitir soluciones de gama baja, integradas y de alta gama, NFS proporciona una arquitectura para soluciones de almacenamiento escalables adecuadas tanto para individuos como para organizaciones. Si observa el camino que ya ha recorrido NFS y las perspectivas de su desarrollo futuro, queda claro que este sistema de archivos seguirá cambiando la forma en que pensamos sobre cómo se implementan y utilizan las tecnologías de almacenamiento de archivos.

Buenas tardes lectores e invitados. Hubo una pausa muy larga entre publicaciones, pero ya estoy de vuelta en acción). En el artículo de hoy miraré Operación del protocolo NFS, así como Configurar el servidor NFS y el cliente NFS en Linux.

Introducción a NFS

NFS (Sistema de archivos de red - sistema de archivos de red) en mi opinión, una solución ideal en una red local, donde se necesita un intercambio de datos rápido (más rápido en comparación con SAMBA y menos intensivo en recursos en comparación con sistemas de archivos remotos con cifrado: sshfs, SFTP, etc.) y no está en la seguridad de vanguardia de la información transmitida. protocolo NFS permite montar sistemas de archivos remotos a través de la red en un árbol de directorio local, como si fuera un sistema de archivos de disco montado. Esto permite que las aplicaciones locales funcionen con un sistema de archivos remoto como si fuera local. Pero debes tener cuidado (!) con configurando NFS, porque con una determinada configuración es posible congelar el sistema operativo del cliente esperando E/S infinitas. protocolo NFS basado en el trabajo protocolo RPC, que todavía está más allá de mi comprensión)) por lo que el material del artículo será un poco vago... Antes de poder usar NFS, ya sea un servidor o un cliente, debe asegurarse de que su kernel sea compatible con el archivo NFS. sistema. Puede comprobar si el kernel admite el sistema de archivos NFS buscando la presencia de las líneas correspondientes en el archivo. /proc/sistemas de archivos:

ARCHIVO ~ # grep nfs /proc/filesystems nodev nfs nodev nfs4 nodev nfsd

Si las líneas especificadas en el archivo /proc/sistemas de archivos no aparece, entonces necesita instalar los paquetes que se describen a continuación. Lo más probable es que esto le permita instalar módulos del kernel dependientes para admitir los sistemas de archivos necesarios. Si, después de instalar los paquetes, la compatibilidad con NFS no se muestra en el archivo especificado, deberá habilitar esta función.

Historia Sistema de archivos de red

protocolo NFS desarrollado por Sun Microsystems y cuenta con 4 versiones en su historia. NFSv1 fue desarrollado en 1989 y fue experimental, ejecutándose en el protocolo UDP. La versión 1 se describe en . NFSv2 fue lanzado en el mismo 1989, descrito por el mismo RFC1094 y también basado en el protocolo UDP, aunque no permite leer más de 2 GB de un archivo. NFSv3 finalizado en 1995 y descrito en . Las principales innovaciones de la tercera versión fueron la compatibilidad con archivos grandes, soporte adicional para el protocolo TCP y paquetes TCP de gran tamaño, lo que aceleró significativamente el rendimiento de la tecnología. NFSv4 finalizado en 2000 y descrito en RFC 3010, revisado en 2003 y descrito en . La cuarta versión incluyó mejoras de rendimiento, soporte para varios medios de autenticación (en particular, Kerberos y LIPKEY usando el protocolo RPCSEC GSS) y listas de control de acceso (tanto del tipo POSIX como de Windows). NFS versión v4.1 Fue aprobado por el IESG en 2010 y recibió el número. Una innovación importante en la versión 4.1 es la especificación de pNFS - Parallel NFS, un mecanismo para que el cliente NFS paralelo acceda a datos desde múltiples servidores NFS distribuidos. La presencia de un mecanismo de este tipo en el estándar del sistema de archivos de red ayudará a construir sistemas de información y almacenamiento distribuidos en la "nube".

servidor NFS

ya que tenemos NFS- Este red sistema de archivos, entonces necesario. (También puedes leer el artículo). Lo siguiente es necesario. En Debian este es un paquete servidor-núcleo-nfs Y nfs-común, en RedHat este es un paquete utilidades nfs. Y también, debe permitir que el demonio se ejecute en los niveles de ejecución requeridos del sistema operativo (comando en RedHat - /sbin/chkconfig nfs activado, en Debian - /usr/sbin/update-rc.d valores predeterminados del servidor kernel nfs).

Los paquetes instalados en Debian se inician en el siguiente orden:

ARCHIVO ~ # ls -la /etc/rc2.d/ | grep nfs lrwxrwxrwx 1 raíz raíz 20 18 de octubre 15:02 S15nfs-common -> ../init.d/nfs-common lrwxrwxrwx 1 raíz raíz 27 22 de octubre 01:23 S16nfs-kernel-server -> ../init.d /nfs-kernel-servidor

Es decir, comienza primero. nfs-común, entonces el servidor mismo servidor-núcleo-nfs. En RedHat la situación es similar, con la única excepción de que el primer script se llama nfslock, y el servidor se llama simplemente nfs. Acerca de nfs-común La web de Debian nos dice esto textualmente: archivos compartidos para cliente y servidor NFS, este paquete debe instalarse en la máquina que actuará como cliente o servidor NFS. El paquete incluye programas: lockd, statd, showmount, nfsstat, gssd e idmapd. Ver el contenido del script de inicio /etc/init.d/nfs-common puede realizar un seguimiento de la siguiente secuencia de trabajo: el script comprueba la presencia de un archivo binario ejecutable /sbin/rpc.statd, comprueba la presencia en archivos /etc/default/nfs-común, /etc/fstab Y /etc/exportaciones Parámetros que requieren la ejecución de demonios. idmapd Y gssd , inicia el demonio /sbin/rpc.statd , luego antes del lanzamiento /usr/sbin/rpc.idmapd Y /usr/sbin/rpc.gssd comprueba la presencia de estos archivos binarios ejecutables, luego para demonio /usr/sbin/rpc.idmapd comprueba disponibilidad sunrpc, nfs Y nfsd, así como soporte para sistemas de archivos rpc_pipefs en el kernel (es decir, tenerlo en el archivo /proc/sistemas de archivos), si todo tiene éxito, comienza /usr/sbin/rpc.idmapd . Además, para el demonio /usr/sbin/rpc.gssd cheques módulo del núcleo rpcsec_gss_krb5 y comienza el demonio.

Si ves el contenido Script de inicio del servidor NFS en Debian ( /etc/init.d/nfs-kernel-server), entonces puedes seguir la siguiente secuencia: al inicio, el script comprueba la existencia del archivo /etc/exportaciones, disponibilidad nfsd, disponibilidad de soporte sistema de archivos NFS en (es decir, en el archivo /proc/sistemas de archivos), si todo está en su lugar, entonces se inicia el demonio /usr/sbin/rpc.nfsd , luego verifica si el parámetro está especificado NECESITA_SVCGSD(establecido en el archivo de configuración del servidor /etc/default/nfs-kernel-servidor) y, si se da, inicia el demonio /usr/sbin/rpc.svcgssd , lanza el demonio por último /usr/sbin/rpc.montado . De este guión queda claro que El funcionamiento del servidor NFS consta de demonios rpc.nfsd, rpc.mountd y si se utiliza autenticación Kerberos, entonces el demonio rcp.svcgssd. En el red hat, los demonios rpc.rquotad y nfslogd siguen ejecutándose (Por alguna razón en Debian no encontré información sobre este demonio y los motivos de su ausencia, al parecer fue eliminado...).

De esto queda claro que El servidor Network File System consta de los siguientes procesos (lectura - demonios), ubicado en los directorios /sbin y /usr/sbin:

En NFSv4, cuando se utiliza Kerberos, se inician demonios adicionales:

• rpc.gssd- El demonio NFSv4 proporciona métodos de autenticación a través de GSS-API (autenticación Kerberos). Funciona en cliente y servidor.
• rpc.svcgssd- Demonio de servidor NFSv4 que proporciona autenticación de cliente del lado del servidor.

mapa de puertos y protocolo RPC (Sun RPC)

Además de los paquetes anteriores, se requiere un paquete adicional para que NFSv2 y v3 funcionen correctamente mapa de puertos(reemplazado en distribuciones más nuevas por renombrado a enlacerpc). Este paquete suele instalarse automáticamente con NFS como paquete dependiente e implementa el funcionamiento del servidor RPC, es decir, es responsable de la asignación dinámica de puertos para algunos servicios registrados en el servidor RPC. Literalmente, según la documentación, este es un servidor que convierte números de programa RPC (llamada a procedimiento remoto) en números de puerto TCP/UDP. portmap opera en varias entidades: Llamadas o solicitudes RPC, Puertos TCP/UDP,versión del protocolo(tcp o udp), números de programa Y versiones de software. El demonio portmap se inicia mediante el script /etc/init.d/portmap antes de que se inicien los servicios NFS.

En resumen, el trabajo de un servidor RPC (llamada a procedimiento remoto) es procesar llamadas RPC (los llamados procedimientos RPC) desde procesos locales y remotos. Al utilizar llamadas RPC, los servicios se registran o se eliminan de un asignador de puertos (también conocido como asignador de puertos, también conocido como portmap, también conocido como portmapper, también conocido como, en nuevas versiones, rpcbind), y los clientes usan llamadas RPC para enviar solicitudes al asignador de puertos y recibir la información necesaria. . Los nombres fáciles de usar de los servicios del programa y sus números correspondientes se definen en el archivo /etc/rpc. Tan pronto como cualquier servicio ha enviado la solicitud correspondiente y se ha registrado en el servidor RPC en el asignador de puertos, el servidor RPC asigna, asigna al servicio los puertos TCP y UDP en los que se inició el servicio y almacena en el kernel la información correspondiente sobre el servicio en ejecución (nombre), un número único de servicio (de acuerdo con /etc/rpc), sobre el protocolo y el puerto en el que se ejecuta el servicio y sobre la versión del servicio y proporciona la información especificada a los clientes que lo soliciten. El convertidor de puerto en sí tiene un número de programa (100000), un número de versión: 2, un puerto TCP 111 y un puerto UDP 111. Arriba, al especificar la composición de los demonios del servidor NFS, indiqué los números principales del programa RPC. Probablemente te he confundido un poco con este párrafo, así que diré una frase básica que debería dejar las cosas claras: la función principal del mapeador de puertos es regresar, a petición del cliente que proporcionó el número de programa RPC (o Número de programa RPC) y versión para él (el cliente) del puerto en el que se ejecuta el programa solicitado. En consecuencia, si un cliente necesita acceder a RPC con un número de programa específico, primero debe comunicarse con el proceso de mapa de puertos en la máquina del servidor y determinar el número de puerto de comunicación con el servicio RPC que necesita.

El funcionamiento de un servidor RPC se puede representar mediante los siguientes pasos:

1. El convertidor de puertos debería iniciarse primero, normalmente cuando se inicia el sistema. Esto crea un punto final TCP y abre el puerto TCP 111. También crea un punto final UDP que espera a que llegue un datagrama UDP al puerto UDP 111.
2. Al inicio, un programa que se ejecuta a través de un servidor RPC crea un punto final TCP y un punto final UDP para cada versión compatible del programa. (Un servidor RPC puede admitir varias versiones. El cliente especifica la versión requerida al realizar la llamada RPC). Se asigna un número de puerto asignado dinámicamente a cada versión del servicio. El servidor registra cada programa, versión, protocolo y número de puerto realizando la llamada RPC adecuada.
3. Cuando el programa cliente RPC necesita obtener la información necesaria, llama a la rutina de resolución de puertos para obtener un número de puerto asignado dinámicamente para el programa, versión y protocolo especificados.
4. En respuesta a esta solicitud, el norte devuelve un número de puerto.
5. El cliente envía un mensaje de solicitud RPC al número de puerto obtenido en el paso 4. Si se utiliza UDP, el cliente simplemente envía un datagrama UDP que contiene el mensaje de desafío RPC al número de puerto UDP en el que se ejecuta el servicio solicitado. En respuesta, el servicio envía un datagrama UDP que contiene un mensaje de respuesta RPC. Si se utiliza TCP, el cliente abre activamente el número de puerto TCP del servicio deseado y luego envía un mensaje de desafío RPC a través de la conexión establecida. El servidor responde con un mensaje de respuesta RPC en la conexión.

Para obtener información del servidor RPC, utilice la utilidad informaciónrpc. Al especificar parámetros -p anfitrión el programa muestra una lista de todos los programas RPC registrados en el host. Sin especificar el host, el programa mostrará los servicios en localhost. Ejemplo:

ARCHIV ~ # rpcinfo -p prog vers proto puerto 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 59451 estado 100024 1 tcp 60872 estado 100021 1 udp 44310 nlockmgr 1000 21 3 udp 44310 nlockmgr 100021 4 udp 44310 nlockmgr 100021 1 TCP 44851 nlockmgr 100021 3 tcp 44851 nlockmgr 100021 4 tcp 44851 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100003 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100005 1 udp 51306 montado 100005 1 tcp 41405 montado 100005 2 udp 51306 montado 100005 2 tcp 41405 montado 100005 3 udp 51306 montado 100005 3 tcp 41405 montado

Como puede ver, rpcinfo muestra (en columnas de izquierda a derecha) el número, la versión, el protocolo, el puerto y el nombre del programa registrado. Usando rpcinfo puedes eliminar el registro de un programa u obtener información sobre un servicio RPC específico (más opciones en man rpcinfo). Como puede ver, los demonios portmapper versión 2 están registrados en los puertos udp y tcp, rpc.statd versión 1 en los puertos udp y tcp, el administrador de bloqueo NFS versiones 1,3,4, el demonio del servidor nfs versión 2,3,4, también como las versiones 1,2,3 del demonio de montaje.

El servidor NFS (más precisamente, el demonio rpc.nfsd) recibe solicitudes del cliente en forma de datagramas UDP en el puerto 2049. Aunque NFS funciona con un solucionador de puertos, que permite al servidor utilizar puertos asignados dinámicamente, el puerto UDP 2049 es codificado en NFS en la mayoría de las implementaciones.

Operación del protocolo del sistema de archivos de red

Montaje de NFS remoto

El proceso de montaje de un sistema de archivos NFS remoto se puede representar mediante el siguiente diagrama:

Descripción del protocolo NFS al montar un directorio remoto:

1. Se inicia un servidor RPC en el servidor y el cliente (generalmente en el arranque), recibe servicio mediante el proceso portmapper y se registra en el puerto tcp/111 y udp/111.
2. Se inician los servicios (rpc.nfsd, rpc.statd, etc.), que se registran en el servidor RPC y en puertos de red arbitrarios (si no se especifica un puerto estático en la configuración del servicio).
3. el comando de montaje en la computadora cliente envía una solicitud al kernel para montar un directorio de red, indicando el tipo de sistema de archivos, host y directorio en sí, el kernel envía y forma una solicitud RPC al proceso de mapa de puertos en el servidor NFS en el puerto udp; /111 (si la opción de trabajar vía tcp no está configurada en el cliente)
4. El kernel del servidor NFS consulta al RPC por la presencia del demonio rpc.mountd y devuelve al kernel del cliente el puerto de red en el que se está ejecutando el demonio.
5. mount envía una solicitud RPC al puerto en el que se ejecuta rpc.mountd. El servidor NFS ahora puede validar un cliente según su dirección IP y número de puerto para ver si el cliente puede montar el sistema de archivos especificado.
6. El demonio de montaje devuelve una descripción del sistema de archivos solicitado.
7. El comando de montaje del cliente emite la llamada al sistema de montaje para asociar el identificador de archivo obtenido en el paso 5 con el punto de montaje local en el host del cliente. El identificador del archivo se almacena en el código del cliente NFS y, de ahora en adelante, cualquier acceso de los procesos del usuario a los archivos en el sistema de archivos del servidor utilizará el identificador del archivo como punto de partida.

Comunicación entre el cliente y el servidor NFS

Un acceso típico a un sistema de archivos remoto se puede describir de la siguiente manera:

Descripción del proceso de acceso a un archivo ubicado en un servidor NFS:

1. Al cliente (proceso de usuario) no le importa si accede a un archivo local o a un archivo NFS. El kernel interactúa con el hardware a través de módulos del kernel o llamadas al sistema integradas.
2. módulo del núcleo núcleo/fs/nfs/nfs.ko, que realiza las funciones de un cliente NFS, envía solicitudes RPC al servidor NFS a través del módulo TCP/IP. NFS normalmente usa UDP, sin embargo, las implementaciones más nuevas pueden usar TCP.
3. El servidor NFS recibe solicitudes del cliente como datagramas UDP en el puerto 2049. Aunque NFS puede funcionar con un solucionador de puertos, lo que permite al servidor utilizar puertos asignados dinámicamente, el puerto UDP 2049 está codificado para NFS en la mayoría de las implementaciones.
4. Cuando el servidor NFS recibe una solicitud de un cliente, se pasa a una rutina de acceso a archivos local, que proporciona acceso al disco local en el servidor.
5. El resultado del acceso al disco se devuelve al cliente.

Configurar un servidor NFS

Configuración del servidor en general consiste en especificar directorios locales que pueden ser montados por sistemas remotos en un archivo /etc/exportaciones. Esta acción se llama jerarquía de directorios de exportación. Las principales fuentes de información sobre catálogos exportados son los siguientes archivos:

• /etc/exportaciones- el archivo de configuración principal que almacena la configuración de los directorios exportados. Se utiliza al iniciar NFS y por la utilidad exportfs.
• /var/lib/nfs/xtab- contiene una lista de directorios montados por clientes remotos. Utilizado por el demonio rpc.mountd cuando un cliente intenta montar una jerarquía (se crea una entrada de montaje).
• /var/lib/nfs/etab- una lista de directorios que pueden ser montados por sistemas remotos, indicando todos los parámetros de los directorios exportados.
• /var/lib/nfs/rmtab- una lista de directorios que actualmente no están sin exportar.
• /proc/fs/nfsd- un sistema de archivos especial (kernel 2.6) para administrar el servidor NFS.
  • exportaciones- una lista de jerarquías exportadas activas y clientes a quienes se exportaron, así como parámetros. El kernel obtiene esta información de /var/lib/nfs/xtab.
  • trapos- contiene el número de hilos (también se puede cambiar)
  • usando filehandle puedes obtener un puntero a un archivo
  • etc...
• /proc/net/rpc- contiene estadísticas "sin procesar", que se pueden obtener utilizando nfsstat, así como varios cachés.
• /var/run/portmap_mapping- información sobre servicios registrados en RPC

Nota: En general, en Internet hay muchas interpretaciones y formulaciones sobre el propósito de los archivos xtab, etab, rmtab, no sé a quién creer. Incluso en http://nfs.sourceforge.net/ hay una interpretación. no está claro.

Configurando el archivo /etc/exports

En el caso más simple, el archivo /etc/exports es el único archivo que requiere edición para configurar el servidor NFS. Este archivo controla los siguientes aspectos:

• ¿Qué tipo de clientes? puede acceder a archivos en el servidor
• ¿Qué jerarquías? Cada cliente puede acceder a los directorios del servidor.
• ¿Cómo serán los nombres de clientes personalizados? ser mostrado a nombres de usuario locales

Cada línea del archivo de exportaciones tiene el siguiente formato:

export_point cliente1 (opciones) [cliente2(opciones) ...]

Dónde punto_exportación ruta absoluta de la jerarquía de directorios exportados, cliente1 - norte nombre de uno o más clientes o direcciones IP, separados por espacios, que pueden montar punto_exportación . Opciones describir las reglas de montaje para cliente, especificado antes opciones .

Aquí tienes uno típico. ejemplo de configuración de archivo de exportación:

ARCHIV ~ # cat /etc/exports /archiv1 archivos(rw,sync) 10.0.0.1(ro,sync) 10.0.230.1/24(ro,sync)

En este ejemplo, los archivos de las computadoras y 10.0.0.1 tienen acceso al punto de exportación /archiv1, mientras que los archivos del host tienen acceso de lectura/escritura, y el host 10.0.0.1 y la subred 10.0.230.1/24 tienen acceso de solo lectura.

Se permiten descripciones de host en /etc/exports en el siguiente formato:

• Los nombres de los nodos individuales se describen como archivos o archivos.DOMINIO.local.
• La máscara de dominio se describe en el siguiente formato: *DOMAIN.local incluye todos los nodos del dominio DOMAIN.local.
• Las subredes se especifican como pares de dirección IP/máscara. Por ejemplo: 10.0.0.0/255.255.255.0 incluye todos los nodos cuyas direcciones comienzan con 10.0.0.
• Especificar el nombre del grupo de red @myclients que tiene acceso al recurso (cuando se utiliza un servidor NIS)

Opciones generales para exportar jerarquías de directorios

El archivo de exportaciones utiliza las siguientes opciones generales(Las opciones utilizadas de forma predeterminada en la mayoría de los sistemas se enumeran primero, las no predeterminadas entre paréntesis):

• auth_nlm (no_auth_nlm) o cerraduras_seguras (cerraduras_inseguras)- especifica que el servidor debe requerir autenticación de las solicitudes de bloqueo (utilizando el protocolo NFS Lock Manager).
• no ocultar (ocultar)- si el servidor exporta dos jerarquías de directorios, una anidada (montada) dentro de la otra. El cliente necesita montar explícitamente la segunda jerarquía (secundaria); de lo contrario, el punto de montaje de la jerarquía secundaria aparecerá como un directorio vacío. La opción nohide da como resultado una segunda jerarquía de directorios sin un montaje explícito. ( nota: No pude hacer funcionar esta opción...)
• ro(rw)- Sólo permite solicitudes de lectura (escritura). (En última instancia, si es posible leer/escribir o no se determina en función de los derechos del sistema de archivos, y el servidor no puede distinguir una solicitud para leer un archivo de una solicitud para ejecutar, por lo que permite la lectura si el usuario ha leído o ejecutar derechos.)
• seguro (inseguro)- requiere que las solicitudes NFS provengan de puertos seguros (< 1024), чтобы программа без прав root не могла монтировать иерархию каталогов.
• subtree_check (no_subtree_check)- Si se exporta un subdirectorio del sistema de archivos, pero no todo el sistema de archivos, el servidor comprueba si el archivo solicitado está en el subdirectorio exportado. Deshabilitar la verificación reduce la seguridad pero aumenta la velocidad de transferencia de datos.
• sincronización (asíncrono)- especifica que el servidor debe responder a las solicitudes solo después de que los cambios realizados por esas solicitudes se hayan escrito en el disco. La opción asíncrona le dice al servidor que no espere a que la información se escriba en el disco, lo que mejora el rendimiento pero reduce la confiabilidad porque En caso de interrupción de la conexión o falla del equipo, se puede perder información.
• wdelay (no_wdelay)- indica al servidor que retrase la ejecución de solicitudes de escritura si hay una solicitud de escritura posterior pendiente, escribiendo datos en bloques más grandes. Esto mejora el rendimiento al enviar grandes colas de comandos de escritura. no_wdelay especifica no retrasar la ejecución de un comando de escritura, lo que puede resultar útil si el servidor recibe una gran cantidad de comandos no relacionados.

Exporte enlaces simbólicos y archivos de dispositivos. Al exportar una jerarquía de directorios que contiene enlaces simbólicos, el objeto de enlace debe ser accesible para el sistema cliente (remoto), es decir, una de las siguientes reglas debe ser verdadera:

El archivo del dispositivo pertenece a la interfaz. Cuando exporta un archivo de dispositivo, esta interfaz se exporta. Si el sistema cliente no tiene un dispositivo del mismo tipo, el dispositivo exportado no funcionará. En el sistema cliente, al montar objetos NFS, puede utilizar la opción nodev para que no se utilicen los archivos de dispositivo en los directorios montados.

Las opciones predeterminadas pueden variar entre sistemas y se pueden encontrar en /var/lib/nfs/etab. Después de describir el directorio exportado en /etc/exports y reiniciar el servidor NFS, todas las opciones faltantes (léase: opciones predeterminadas) se reflejarán en el archivo /var/lib/nfs/etab.

Opciones de visualización (coincidencia) de ID de usuario

Para comprender mejor lo siguiente, le aconsejo que lea el artículo. Cada usuario de Linux tiene su propio UID y GID principal, que se describen en los archivos /etc/contraseña Y /etc/grupo. El servidor NFS supone que el sistema operativo del host remoto ha autenticado a los usuarios y les ha asignado el UID y GID correctos. La exportación de archivos brinda a los usuarios del sistema cliente el mismo acceso a esos archivos como si hubieran iniciado sesión directamente en el servidor. En consecuencia, cuando un cliente NFS envía una solicitud al servidor, el servidor utiliza el UID y el GID para identificar al usuario en el sistema local, lo que puede provocar algunos problemas:

• Es posible que un usuario no tenga los mismos identificadores en ambos sistemas y, por lo tanto, pueda acceder a los archivos de otro usuario.
• porque Si el ID del usuario raíz es siempre 0, entonces este usuario se asigna al usuario local según las opciones especificadas.

Las siguientes opciones establecen las reglas para mostrar usuarios remotos en locales:

• root_squash (sin_root_squash)- Con la opción especificada calabaza_raíz, las solicitudes del usuario raíz se asignan al uid/gid anónimo o al usuario especificado en el parámetro anonuid/anongid.
• no_all_squash (todo_squash)- No cambia el UID/GID del usuario que se conecta. Opción todo_squash establece la visualización de TODOS los usuarios (no solo root), como anónimos o especificados en el parámetro anonuid/anongid.
• anónimo= UID Y anónimo= GID - Establece explícitamente el UID/GID para el usuario anónimo.
• mapa_estático= /etc/file_maps_users - Especifica un archivo en el que puede configurar la asignación de UID/GID remoto a UID/GID local.

Ejemplo de uso de un archivo de mapeo de usuarios:

ARCHIV ~ # cat /etc/file_maps_users # Mapeo de usuarios # uid de comentario local remoto 0-50 1002 # mapeo de usuarios con UID remoto 0-50 a UID local 1002 gid 0-50 1002 # mapeo de usuarios con/span GID remoto 0-50 a GID local 1002

Gestión del servidor NFS

El servidor NFS se gestiona mediante las siguientes utilidades:

• nfsstat
• montaje showmsecure (inseguro)

nfsstat: estadísticas NFS y RPC

La utilidad nfsstat le permite ver estadísticas de servidores RPC y NFS. Las opciones del comando se pueden encontrar en man nfsstat.

showmount: muestra información de estado de NFS

utilidad de montaje de exhibición consulta al demonio rpc.mountd en el host remoto sobre los sistemas de archivos montados. De forma predeterminada, se devuelve una lista ordenada de clientes. Llaves:

• --todo- Se muestra una lista de clientes y puntos de montaje que indica dónde el cliente montó el directorio. Es posible que esta información no sea confiable.
• --directorios- se muestra una lista de puntos de montaje
• --exportaciones- se muestra una lista de sistemas de archivos exportados desde el punto de vista de nfsd

Cuando ejecuta showmount sin argumentos, la información sobre los sistemas que pueden montarse se imprimirá en la consola. local catálogos. Por ejemplo, el host ARCHIV nos proporciona una lista de directorios exportados con las direcciones IP de los hosts que pueden montar los directorios especificados:

ARCHIVOS ~ # showmount --exports archive Lista de exportación para archivo: /archiv-big 10.0.0.2 /archiv-small 10.0.0.2

Si especifica el nombre de host/IP en el argumento, se mostrará información sobre este host:

ARCHIV ~ # showmount files clnt_create: RPC: Programa no registrado # este mensaje nos dice que el demonio NFSd no se está ejecutando en el host de ARCHIVOS

exportfs: administrar directorios exportados

Este comando sirve a los directorios exportados especificados en el archivo. /etc/exportaciones, sería más exacto escribir que no sirve, pero se sincroniza con el archivo /var/lib/nfs/xtab y elimina los que no existen de xtab. exportfs se ejecuta cuando el demonio nfsd se inicia con el argumento -r. La utilidad exportfs en modo kernel 2.6 se comunica con el demonio rpc.mountd a través de archivos en el directorio /var/lib/nfs/ y no se comunica directamente con el kernel. Sin parámetros, muestra una lista de los sistemas de archivos exportados actualmente.

Parámetros de exportación:

• [cliente:nombre-directorio] - agrega o elimina el sistema de archivos especificado para el cliente especificado)
• -v - muestra más información
• -r - reexportar todos los directorios (sincronizar /etc/exports y /var/lib/nfs/xtab)
• -u - eliminar de la lista de exportados
• -a: agrega o elimina todos los sistemas de archivos
• -o - opciones separadas por comas (similar a las opciones utilizadas en /etc/exports; es decir, puede cambiar las opciones de los sistemas de archivos ya montados)
• -i: no use /etc/exports al agregar, solo las opciones de línea de comando actuales
• -f: restablece la lista de sistemas exportados en el kernel 2.6;

Cliente NFS

Antes de acceder a un archivo en un sistema de archivos remoto, el cliente (SO del cliente) debe montarlo y recibir del servidor puntero a ello. Montaje NFS se puede hacer con o utilizando uno de los montadores automáticos que proliferan (amd, autofs, automount, supermount, superpupermount). El proceso de instalación se demuestra bien en la ilustración anterior.

En Clientes NFS no es necesario ejecutar ningún demonio, funciones del cliente ejecuta un módulo del kernel núcleo/fs/nfs/nfs.ko, que se utiliza al montar un sistema de archivos remoto. Los directorios exportados desde el servidor se pueden montar en el cliente de las siguientes maneras:

• manualmente usando el comando de montaje
• automáticamente en el arranque, al montar sistemas de archivos descritos en /etc/fstab
• automáticamente usando el demonio autofs

No consideraré el tercer método con autofs en este artículo debido a su voluminosa información. Quizás haya una descripción separada en artículos futuros.

Montar el sistema de archivos de red con el comando mount

En la publicación se presenta un ejemplo del uso del comando de montaje. Aquí veremos un ejemplo del comando mount para montar un sistema de archivos NFS:

ARCHIVOS ~ # mount -t nfs archiv:/archiv-small /archivs/archiv-small ARCHIVOS ~ # mount -t nfs -o ro archiv:/archiv-big /archivs/archiv-big ARCHIVOS ~ # mount ..... .. archiv:/archiv-small en /archivs/archiv-small tipo nfs (rw,addr=10.0.0.6) archiv:/archiv-big en /archivs/archiv-big tipo nfs (ro,addr=10.0.0.6)

El primer comando monta el directorio exportado. /archivo-pequeño en el servidor archivo al punto de montaje local /archivs/archiv-pequeño con opciones predeterminadas (es decir, leer y escribir). A pesar de comando de montaje en las últimas distribuciones puede entender qué tipo de sistema de archivos se utiliza incluso sin especificar el tipo, pero aún así indicar el parámetro -t nfs deseable. El segundo comando monta el directorio exportado. /archivo-grande en el servidor archivo al directorio local /archivos/archivo-grande con opción de solo lectura ( ro). comando de montaje sin parámetros, nos muestra claramente el resultado del montaje. Además de la opción de sólo lectura (ro), es posible especificar otras Opciones básicas al montar NFS:

• nosuido- Esta opción prohíbe ejecutar programas desde el directorio montado.
• nodev(sin dispositivo - no es un dispositivo): esta opción prohíbe el uso de caracteres y bloquea archivos especiales como dispositivos.
• bloquear (no bloquear)- Permite el bloqueo NFS (predeterminado). nolock deshabilita el bloqueo NFS (no inicia el demonio lockd) y es útil cuando se trabaja con servidores antiguos que no admiten el bloqueo NFS.
• host de montaje = nombre- El nombre del host en el que se ejecuta el demonio de montaje NFS: mountd.
• puerto de montaje = n - Puerto utilizado por el demonio mountd.
• puerto=n- puerto utilizado para conectarse al servidor NFS (el valor predeterminado es 2049 si el demonio rpc.nfsd no está registrado en el servidor RPC). Si n=0 (predeterminado), NFS consulta el mapa de puertos en el servidor para determinar el puerto.
• tamañor=n(leer tamaño de bloque - leer tamaño de bloque): el número de bytes leídos a la vez desde el servidor NFS. Estándar - 4096.
• wtamaño=n(tamaño de bloque de escritura - tamaño de bloque de escritura): el número de bytes escritos a la vez en el servidor NFS. Estándar - 4096.
• TCP o udp- Para montar NFS, utilice el protocolo TCP o UDP, respectivamente.
• bg- Si pierde el acceso al servidor, intente nuevamente en segundo plano para no bloquear el proceso de inicio del sistema.
• fg- Si pierde el acceso al servidor, vuelva a intentarlo en modo prioridad. Esta opción puede bloquear el proceso de inicio del sistema repitiendo los intentos de montaje. Por este motivo, el parámetro fg se utiliza principalmente para depurar.

Opciones que afectan el almacenamiento en caché de atributos en montajes NFS

Atributos de archivo, almacenados en (inodos), como la hora de modificación, el tamaño, los enlaces físicos, el propietario, normalmente cambian con poca frecuencia para archivos normales y aún menos frecuentemente para directorios. Muchos programas, como ls, acceden a archivos de sólo lectura y no cambian los atributos ni el contenido del archivo, pero desperdician recursos del sistema en costosas operaciones de red. Para evitar desperdiciar recursos, puede almacenar en caché estos atributos. El kernel utiliza la hora de modificación de un archivo para determinar si el caché está desactualizado comparando el tiempo de modificación en el caché y el tiempo de modificación del archivo en sí. La caché de atributos se actualiza periódicamente de acuerdo con los parámetros especificados:

• aire acondicionado (noac) (caché de atributos- almacenamiento en caché de atributos): permite el almacenamiento en caché de atributos (predeterminado). Aunque la opción noac ralentiza el servidor, evita el estancamiento de los atributos cuando varios clientes escriben activamente información en una jerarquía común.
• acdirmax=n (archivo de directorio de caché de atributos máximo- almacenamiento en caché máximo de atributos para un archivo de directorio) - El número máximo de segundos que NFS espera antes de actualizar los atributos del directorio (predeterminado 60 segundos).
• acdirmin=n (archivo mínimo del directorio de caché de atributos- almacenamiento en caché de atributos mínimo para un archivo de directorio) - Número mínimo de segundos que NFS espera antes de actualizar los atributos del directorio (predeterminado 30 segundos).
• acregmax=n (caché de atributos archivo normal máximo- máximo de almacenamiento en caché de atributos para un archivo normal) - El número máximo de segundos que NFS espera antes de actualizar los atributos de un archivo normal (predeterminado 60 segundos).
• acregmin=n (caché de atributos archivo regular mínimo- almacenamiento en caché de atributos mínimo para un archivo normal) - Número mínimo de segundos que NFS espera antes de actualizar los atributos de un archivo normal (3 segundos predeterminados)
• actimeo=n (tiempo de espera de caché de atributos- tiempo de espera de almacenamiento en caché de atributos): reemplaza los valores de todas las opciones anteriores. Si no se especifica actimeo, los valores anteriores adoptan los valores predeterminados.

Opciones de manejo de errores de NFS

Las siguientes opciones controlan lo que hace NFS cuando no hay respuesta del servidor o cuando ocurren errores de E/S:

• fg(bg) (primer plano- primer plano, fondo- fondo): intenta montar un NFS fallido en primer plano/fondo.
• duro (suave)- muestra el mensaje "el servidor no responde" a la consola cuando se alcanza el tiempo de espera y continúa intentando montar. Con opción dada suave- durante un tiempo de espera, informa al programa que llamó a la operación sobre un error de E/S. (se recomienda no utilizar la opción suave)
• noint (intr) (sin interrupción- no interrumpir): no permite que las señales interrumpan las operaciones de archivos en una jerarquía de directorios montada de forma física cuando se alcanza un tiempo de espera grande. intro- permite la interrupción.
• retransmisión=n (valor de retransmisión- valor de retransmisión): después de n tiempos de espera pequeños, NFS genera un tiempo de espera grande (predeterminado 3). Un tiempo de espera prolongado detiene las operaciones o imprime un mensaje de "el servidor no responde" en la consola, dependiendo de si se especifica la opción hardware/soft.
• reintentar=n (valor de reintento- valor de reintento): la cantidad de minutos que el servicio NFS repetirá las operaciones de montaje antes de darse por vencido (predeterminado 10000).
• tiempo=n (valor de tiempo de espera- valor de tiempo de espera): la cantidad de décimas de segundo que el servicio NFS espera antes de retransmitir en caso de RPC o un tiempo de espera pequeño (predeterminado 7). Este valor aumenta con cada tiempo de espera hasta un máximo de 60 segundos o hasta que se produzca un tiempo de espera grande. Si la red está ocupada, el servidor es lento o la solicitud pasa por varios enrutadores o puertas de enlace, aumentar este valor puede mejorar el rendimiento.

Montaje automático de NFS al arrancar (descripción de los sistemas de archivos en /etc/fstab)

Puede seleccionar el tiempo óptimo para un valor específico del paquete transmitido (valores rsize/wsize) usando el comando ping:

ARCHIVOS ~ # ping -s 32768 archiv PING archiv.DOMAIN.local (10.0.0.6) 32768(32796) bytes de datos. 32776 bytes de archiv.domain.local (10.0.0.6): icmp_req=1 ttl=64 tiempo=0,931 ms 32776 bytes de archiv.domain.local (10.0.0.6): icmp_req=2 ttl=64 tiempo=0,958 ms 32776 bytes desde archiv.domain.local (10.0.0.6): icmp_req=3 ttl=64 tiempo=1,03 ms 32776 bytes desde archiv.domain.local (10.0.0.6): icmp_req=4 ttl=64 tiempo=1,00 ms 32776 bytes desde archivo .domain.local (10.0.0.6): icmp_req=5 ttl=64 time=1.08 ms ^C --- archive.DOMAIN.local estadísticas de ping --- 5 paquetes transmitidos, 5 recibidos, 0% de pérdida de paquetes, tiempo 4006ms rtt mín/promedio/máx/mdesv = 0,931/1,002/1,083/0,061 ms

Como puede ver, al enviar un paquete de tamaño 32768 (32 Kb), su tiempo de viaje desde el cliente al servidor y viceversa flota alrededor de 1 milisegundo. Si este tiempo supera los 200 ms, entonces debería pensar en aumentar el valor del tiempo para que supere el valor de cambio de tres a cuatro veces. En consecuencia, es recomendable realizar esta prueba durante una carga de red intensa.

Iniciar NFS y configurar Firewall

La nota fue copiada del blog http://bog.pp.ru/work/NFS.html, ¡¡¡muchas gracias!!!

Ejecute el servidor NFS, monte, bloquee, establezca cuotas y establezca el estado con los puertos "correctos" (para firewall)

• Es recomendable desmontar primero todos los recursos de los clientes.
• detenga y deshabilite el inicio de rpcidmapd si no planea usar NFSv4: chkconfig --level 345 rpcidmapd off service rpcidmapd stop
• si es necesario, permita que se inicien los servicios portmap, nfs y nfslock: chkconfig --levels 345 portmap/rpcbind on chkconfig --levels 345 nfs on chkconfig --levels 345 nfslock on
• si es necesario, detenga los servicios nfslock y nfs, inicie portmap/rpcbind, descargue los módulos debe iniciarse rmmod nfs rmmod nfs_acl rmmod lockd
• abrir puertos en
  • para RPC: UDP/111, TCP/111
  • para NFS: UDP/2049, TCP/2049
  • para rpc.statd: UDP/4000, TCP/4000
  • para bloqueado: UDP/4001, TCP/4001
  • para montaje: UDP/4002, TCP/4002
  • para rpc.rquota: UDP/4003, TCP/4003
• para el servidor rpc.nfsd, agregue la línea RPCNFSDARGS="--port 2049" a /etc/sysconfig/nfs
• para el servidor de montaje, agregue la línea MOUNTD_PORT=4002 a /etc/sysconfig/nfs
• Para configurar rpc.rquota para nuevas versiones, debe agregar la línea RQUOTAD_PORT=4003 a /etc/sysconfig/nfs
• para configurar rpc.rquota es necesario para versiones anteriores (sin embargo, debe tener el paquete de cuota 3.08 o posterior) agregar a /etc/services rquotad 4003/tcp rquotad 4003/udp
• comprobará la idoneidad de /etc/exports
• ejecute los servicios rpc.nfsd, mountd y rpc.rquota (rpcsvcgssd y rpc.idmapd se inician al mismo tiempo, si recuerda eliminarlos) service nfsd start o en nuevas versiones service nfs start
• para el servidor de bloqueo para sistemas nuevos, agregue las líneas LOCKD_TCPPORT=4001 LOCKD_UDPPORT=4001 a /etc/sysconfig/nfs
• para el servidor de bloqueo para sistemas más antiguos, agregue directamente a /etc/modprobe[.conf]: opciones lockd nlm_udpport=4001 nlm_tcpport=4001
• vincule el servidor de estado rpc.statd al puerto 4000 (para sistemas más antiguos, ejecute rpc.statd con el modificador -p 4000 en /etc/init.d/nfslock) STATD_PORT=4000
• inicie el servicio lockd y rpc services.statd nfslock start
• asegúrese de que todos los puertos estén vinculados normalmente usando "lsof -i -n -P" y "netstat -a -n" (algunos de los puertos son utilizados por módulos del kernel que lsof no ve)
• Si antes de la "reconstrucción" el servidor era utilizado por los clientes y no se podían desmontar, entonces tendrá que reiniciar los servicios de montaje automático en los clientes (am-utils, autofs).

Ejemplo de configuración de cliente y servidor NFS

Configuración del servidor

Si desea que su directorio compartido NFS sea público y escribible, puede usar la opción todo_squash en combinación con opciones anónimo Y anónimo. Por ejemplo, para establecer permisos para el usuario "nadie" en el grupo "nadie", puedes hacer lo siguiente:

ARCHIV ~ # cat /etc/exports # Acceso de lectura y escritura para el cliente en 192.168.0.100, con acceso rw para el usuario 99 con gid 99 /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99) ) # Acceso de lectura y escritura para el cliente en 192.168.0.100, con acceso rw para el usuario 99 con gid 99 /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99))

Esto también significa que si desea permitir el acceso al directorio especificado, nadie debe ser el propietario del directorio compartido:

hombre monte
el hombre exporta
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/nfs_perf.htm: rendimiento de NFS de IBM.

¡Saludos cordiales, McSim!

En este punto, debería tener una conexión TCP/IP funcional a su red. Debería poder hacer ping a otras computadoras en la red y, si ha configurado la puerta de enlace adecuadamente, 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 conectar una computadora a una red simplemente porque sí, a la mayoría le 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 tendrá todo; sin embargo, al instalar sólo soporte TCP/IP, la funcionalidad será muy limitada. Para proporcionar y compartir archivos, necesitaremos transferirlos de un lado a otro mediante FTP o SCP. No podemos ver el árbol de archivos en nuestra nueva computadora con Slackware a través de los íconos de “Entorno de red” o “Red completa” desde computadoras con Windows. Nos gustaría poder tener acceso constante a archivos en otras máquinas Unix.

Idealmente nos gustaría utilizar sistema de archivos de red, permitiéndonos tener un acceso transparente a los archivos de los ordenadores. Los programas que utilizamos para trabajar con información almacenada en las computadoras ni siquiera necesitan saber en qué computadora está almacenado el archivo requerido. Sólo necesitan saber que el archivo existe y una forma de obtenerlo. El resto 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 mediante 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 ha estado interesada en 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 preferido para casi todo el mundo civilizado, ya que Windows lo admite.

El archivo de configuración de Samba /etc/samba/smb.conf es uno de los archivos de configuración mejor documentados que encontrará. Hay ejemplos listos para usar con configuraciones de recursos compartidos a su disposición, para que pueda verlos y cambiarlos según sus necesidades. Si desea tener aún más control, la página de manual de smb.conf está a su disposición. Dado que Samba tiene una documentación tan buena, no la reescribiremos aquí. Sin embargo, repasemos rápidamente los puntos principales.

smb.conf está dividido en varias secciones: una sección por recurso compartido, más una sección global para configurar los parámetros que se utilizan en todas partes. Algunos parámetros solo son válidos en la sección global y otros solo son válidos fuera de ella. Recuerde que una 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 cambiar los siguientes puntos:

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

Es casi seguro que querrás utilizar el nivel de seguridad de usuario en tu sistema Slackware.

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

SMB es un protocolo autenticado, es decir. puede proporcionar un nombre de usuario y 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 regulares y usuarios de máquinas (SMB requiere que agregue los nombres NETBIOS de las máquinas como usuarios de máquinas, lo que limita la cantidad de máquinas desde las cuales se puede realizar la autenticación).

Es importante tener en cuenta que el nombre de usuario o nombre de la máquina proporcionado ya debe existir en el archivo /etc/passwd. Puede lograr esto usando el comando adduser. Tenga en cuenta que cuando utilice 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 añade el propio signo de dólar. La violación de esta regla usando adduser resultará en un error al agregar el nombre de la máquina a samba.

#máquina adduser$

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 en comparación con SMB, NFS es mucho menos seguro. La principal debilidad de la seguridad es la facilidad para reemplazar los identificadores de usuario y grupo de una máquina con identificadores de otra máquina. El protocolo NFS no implementa autenticación. Se ha afirmado que las versiones futuras del protocolo NFS mejorarán la seguridad, pero al momento de escribir esto aún no se ha hecho.

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 en las dos líneas superiores. Necesitaremos agregar una línea al archivo de exportaciones para cada uno de los directorios que queramos exportar, enumerando las estaciones de trabajo cliente a las que se les permitirá acceder a ese directorio. Por ejemplo, si necesitáramos exportar el directorio /home/foo para la estación de trabajo Bar, necesitaríamos 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 supone que un usuario determinado en una máquina 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 envía como parte de la solicitud de lectura/escritura. Este UID se considera el mismo que si la solicitud se realizara desde la máquina local. Como puede ver, si alguien puede especificar arbitrariamente un UID determinado al acceder a recursos en una máquina remota, pueden ocurrir problemas, y de hecho ocurren. Un remedio para evitar esto parcialmente es montar todos los directorios con la opción root_squash. Esto anula el UID de cualquier usuario que afirme ser root por un UID diferente, impidiendo así el acceso de root a los archivos y directorios del 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:

# exportfs -o rw,no_root_squash Barra:/home/foo

Este comando exporta el directorio /home/foo para la computadora “Bar” y le otorga acceso de lectura/escritura. Además, el servidor NFS no tiene habilitado el parámetro root_squash, lo que significa que cualquier usuario en Bar con UID “0” (UID root) tendrá los mismos privilegios en el servidor que root. La sintaxis parece bastante extraña (normalmente cuando se especifica). directorio en el formato computadora:/directorio/archivo, se refiere a un archivo en un directorio en la computadora especificada).

Puede encontrar más información sobre el archivo de exportaciones en la página de manual.