Configuracion del Servidor NFS

Los paquetes necesarios para el funcionamiento del servidor son portmap, nfs-kernel-server y nfs-common.
Comenzaremos con la creación de un usuario con el comando adduser nombre

Podemos agregar los datos del usuario.

A continuación creamos un grupo con el siguiente comando addgroup nombre

 Una vez que tecleamos ENTER

 Finalmente agregamos nuestro usuario al grupo, adduser nombreUsuario nombreGrupo

Se crea el directorio a compartir mkdir nombreDirectorio

Creamos el archivo a compartir

 Ingresamos el texto de nuestra preferencia en el archivo, guardamos y salimos.

Para ver lo ingresado en el archivo

La carpeta a compartir se creó en el home del usuario creado para observarlo utilizamos el comando ls

Damos todos los permisos tanto al dueño del archivo a los usuarios del grupo y a el resto de los usuarios.

Instalamos el paquete portmap

Instalación del paquete nfs-kernel-server

 

Instalación del paquete nfs-common

Configuramos la dirección IP de nuestro equipo servidor. Si configuro una dirección IP diferente para el servicio DHCP, ignore este paso.

A continuación editamos los archivos
exports, indicaremos lo que será exportado por el servidor

Agregamos la ruta de la carpeta a compartir. Si trabaja con otra dirección IP en el servidor coloque la que está utilizando y no la que se indica a continuación.

En este caso indicamos que queremos compartir el directorio /home/rednsf/redes a los hosts de la red 192.168.100.0; home/rednsf/redes se podrá acceder como solo lectura (ro). Se respetará el protocolo NFS, ya que no se responderán a las peticiones que se hagan antes de que los cambios se hayan escrito en disco (sync). Si un usuario root (en el cliente) accede al directorio home/rednsf/redes su privilegios son los mismos que el de un usuario anónimo (root_squash).

A continuación se detallan las posibles opciones
Las opciones que nos permitirán tener acceso a esos directorios con determinados privilegios. 

*ro | rw : Con la opción ro el directorio será compartido de solo lectura. Esta opción está por defecto.y con la opción rw se permitirá tanto acceso de lectura como de escritura.

*sync | async : sync es la opción recomendada, ya que se ha de respetar el protocolo NFS, es decir, no se responden a las peticiones antes de que los cambios realizados sean escritos al disco. Con la opción async se permite mejorar el rendimiento y agilizar el funcionamiento global, pero supone un riesgo de corrupción de archivos o del sistemas de archivos en casos de caidas del servidor y/o errores de éste.

*root_squash | no_root_squash | all_squash : root_squash indica que un cliente identificado como root tendrá acceso al directorio con privilegios de un usuario anónimo. Si seleccionamos la opción no_root_squash evitaremos esto, y si indicamos all_squash, entonces aplicaremos esto último a todos los usuarios, no sólo root.

Continuamos con la configuración ahora en el archivo hosts.deny, para indicar las restricciones

En este archivo pondremos todas las restricciones posibles para hacer más seguro el sistema. Para ello denegaremos el acceso a portmap, ya que si se deniega portmap, aunque se permita nfs, no se podrá compartir porque éste depende de portmap. Por lo que solo se tendrá acceso a portmap por aquellos equipos que estén definidos en el archivo /etc/hosts.allow. El archivo /etc/hosts.deny quedará:
portmap:ALL

Ahora continuamos con la configuración del archivo hosts.allow, en este archivo se debe indicar a quienes permitiremos el acceso al servicio de nfs y portmap. Se pueden indicar nodos individuales o una red. Para ello agregamos las siguientes líneas.

portmap:192.168.100.0/255.255.255.0 

nfs:192.168.100.0/255.255.255.0

La dirección que coloquemos debe corresponder con la de nuestra red.

Configuración del cliente
En el cliente montaremos el directorio exportado para ello ejecutaremos el siguiente comando
mount –t nfs 192.168.100.2: /home/rednsf/redes

Con el comando anterior montamos el directorio /redes exportado por el nodo 192.168.100.2 en el directorio que se creó previamente.

Capas del Servidor NFS

Está compuesto de tres capas para facilitar su uso genérico a través de múltiples plataformas. Estas capas son:

La capa RPC (llamada a procedimiento remoto)

Pasa la data entre los nodos, está diseñada para permitir el desarrollo de aplicaciones generales cliente/servidor.

Componentes de la estructura RPC

Uno o varios programas que se ejecutan en un servidor implementan un servicio de RPC, cada programa puede ejecutar varios procedimientos. Ya que existen diferentes procedimientos en NFS para leer, escribir, cambiar el nombre y borrar. Cada programa tiene un identificador numérico asignado. Y finalmente cada procedimiento de un programa tiene un identificador numérico asignado.

Acceso de una aplicación cliente a un proceso remoto

Una petición de un cliente RPC identifica al programa y al procedimiento a ejecutar. Si se desea leer un programa, la petición RPC solicitará el programa 100003 (NFS) y el procedimiento 6 (read). Cabe destacar que con el tiempo los programas cambian, los procedimientos se mejoran y se añaden otros nuevos por lo que la llamada RPC debe identificar también la versión del programa, ya que es usual encontrar varias versiones de un programa de RPC ejecutándose en un nodo servidor.

Sistema de transporte en RPC 

En TCP/IP el RPC se ejecuta tanto sobre TCP como sobre UDP, pero puede estar implementado sobre otros sistemas de transporte. Si se basa en TCP, las peticiones y las respuestas se entregan de forma fiable. En cambio si el servicio se basa en UDP, el cliente y el servidor deben proporcionar sus propias estrategias de temporización, retransmisión y detección de duplicados. Las peticiones de RPC también pueden ser de multienvio o de difusión.

Programas que implementan RPCNFS 

es el programa con RPC más conocido, sin embargo hay otros como rusers que averigua quien está conectado, bien a los nodos de una lista seleccionada, o a todos los nodos de la red local. Un rusers cliente difunde su llamada de RPC por la LAN. Las respuestas contienen el nombre del host y los usuarios conectados a ese nodo.

Gestor de puertos RPC 

utiliza un método para descubrir de forma dinámica el puerto por el que se puede acceder a un servicio determinado. En cada nodo servidor existe un programa llamado gestor de puertos (portmapper o el rpcbind) que mantiene una lista de programas locales de RPC activos, el número de versión de los programas, el protocolo o protocolo de transporte, puertos en los que se ejecutan los programas.
El programa portmapper, arranca al inicializarse el computador servidor de RPC. Cuando un programa de RPC arranca, toma un puerto sin usar del sistema operativo y le dice al portmapper que está preparado para el trabajo, es decir, registra en el portmapper su puerto, número de programa y versión. El portmapper escucha en el puerto público 111. Cuando un cliente quiere acceder a un servicio de RPC, envía un mensaje de RPC al portmapper por el puerto 111, el mensaje contiene el número de programa, versión y protocolo de transporte (UDP o TCP) del servicio. El portmapper reenvía la petición al servicio y reenvía de nuevo la respuesta al cliente, indicando el puerto actual para el servicio para que las llamadas futuras se puedan enviar directamente.
El portmapper permite que algunos servicios de RPC sean de difusión. En este caso el cliente difunde una petición de RPC en un enlace. Por ejemplo el rusers que pide a todas las máquinas de una LAN que informen de los usuarios conectados. El rusers puede ejecutarse en un puerto diferente en cada nodo.

Autenticación de RPC

Hay servicios que no requieren ninguna protección de seguridad, sin embargo existen casos donde si es necesario incluir información de autenticación tanto en las peticiones como en las respuestas. La información de autenticación aparece en dos campos:
- El campo credenciales, contiene la información de identificación.

- El campo comprobador (verifier), contiene información adicional y valida la identidad.

No existe un estándar único para autenticación. Cada diseñador debe decidir las necesidades de sus programas. A cada método de autenticación se le llama sabor (flavor). Los campos de credencial y de comprobador comienzan con un número de sabor, se pueden registrar valores nuevos de sabores de autenticación de la misma forma que se registran los programas nuevos.

Autenticación nula

Tanto la credencial y el comprobador del mensaje de llamada como el comprobador de la respuesta tienen un 0 como número de sabor, lo que quiere decir que no se incluye más información.

Autenticación del sistema

Proporciona información según el modelo de información del usuario. Las credenciales del sistema incluyen:
Stamp (sello), ID arbitrario generado por la computadora que llama.
Machinename, nombre de la máquina que llama.
Uid, número de ID de usuario efectivo del que llama.
Gid, número de ID de grupo efectivo del que llama.
Gids, lista con los grupos a los que pertenece el que llama.
El comprobador del que llama es nulo. El comprobador que devuelve el servidor puede ser nulo o puede tener un sabor “corto”, es decir, que devuelve una cadena de octetos específica del sistema. En algunas implementaciones, el que llama utiliza esta cadena de octetos como credencial en los mensajes siguientes, en vez de la información de usuario y grupo. Cabe destacar que este método no ofrece ningún tipo de seguridad.

Autenticación DES (estándar de cifrado de datos)

Es un algoritmo de cifrado simétrico. Se basa en una mezcla de claves asimétricas públicas y privadas y un cifrado DES simétrico: se asocia un nombre de usuario a una clave pública, el servidor cifra la clave de la sesión DES con la clave pública y se la envía al proceso cliente del usuario, se usa la clave se sesión DES para cifrar la información de autenticación del cliente y del servidor.

Autenticación de Kerberos
Se basa en el uso de un servidor de seguridad de Kerberos en el que se almacenan los usuarios y las claves de servidores, basadas en contraseñas. Kerberos autentica un servicio de RPC utilizando las claves secretas de cliente y servidor registradas en el servidor de seguridad de Kerberos para distribuir una clave de sesión DES al cliente y al servidor. También puede autenticar un servicio utilizando la clave de sesión DES para cifrar la información de autenticación del cliente y el servidor.

La capa XDR (representación externa de datos) 

La cual provee independencia de la data, incluye un lenguaje de definición de tipos de datos y un método de codificación de los mismos con un formato normalizado para su transmisión.

Lenguaje de descripción de datos XDR
Las definiciones de XDR son similares a los tipos de datos de los lenguajes de programación y son muy sencillas de entender. Algunos tipos de datos básicos de XDR son: enteros con signo y sin signo, enteros enumerados, cadenas ASCII, booleanos y números coma flotante. A partir de los tipos de datos básicos se construyen otros más complicados como arrays, estructuras y uniones. Un ejemplo del tipo entero enumerado es el tipo mensaje (msg-type), que indica si un mensaje es una llamada o una respuesta.
Enum msg_type {
CALL = 0,
REPLY = 1
};

Codificación de XDR
Los mensajes de llamada y respuesta de una versión determinada de programa y de procedimiento tienen un formato fijo. Se conoce el tipo de datos que habrá en un campo por su posición en el mensaje. El tamaño de cada campo debe ser un múltiplo de 4 bytes. Tiene como ventaja que los datos se codifican con muy pocos.

Comandos del Servidor NFS

NULL: no hace nada, pero sirve para hacer ping al server y medir tiempos.
CREATE :crea un nuevo archivo
LOOKUP: busca un fichero en el directorio actual y si lo encuentra, devuelve un descriptor a ese fichero más información sobre los atributos del fichero.
READ y WRITE: primitivas básicas para acceder el fichero.
RENAME: renombra un fichero.
REMOVE: borra un fichero.
MKDIR y RMDIR: creación/borrado de subdirectorios.
READDIR: para leer la lista de directorios.
GETATTR y SETATTR: devuelve conjuntos de atributos de ficheros.
LINK: crea un archivo, el cual es un enlace a un archivo en un directorio, especificado.
SYMLINK y READLINK: para la creación y lectura, respectivamente, de enlaces simbólicos (en un "string") a un archivo en un directorio.
STATFS: devuelve información del sistema de archivos.
ROOT:  para ir a la raíz (obsoleta en la versión 2).
WRITECACHE: reservado para un uso futuro 

 

En la versión 3 del protocolo se eliminan los comandos se STATFS, ROOT y WRITECACHE; y se agregaron los siguiente:

ACCESS: Para verificar permisos de acceso.
MKNOD: Crea un dispositivo especial.
READDIRPLUS: una versión mejorada de READDIR.
FSSTAT: devuelve información del sistema de archivos en forma dinámica.
FSINFO: devuelve información del sistema de archivos en forma estática.
PATHCONF: Recupera información POSIX.
COMMIT: Enviar datos de caché sobre un servidor un sistema de almacenamiento estable.

Ventajas del Servidor NFS

*Los datos accedidos por todo tipo de usuarios pueden mantenerse en un nodo central, con clientes que montan los directorios en el momento de arrancar. 

*Los datos que consumen grandes cantidades de espacio de disco pueden mantenerse en un nodo. 

*Los datos de administración pueden también mantenerse en un solo nodo. Ya no será necesario usar rcp para instalar el mismo fichero en 20 máquinas distintas. 

*El NFS de Linux es, principalmente, obra de Rick Sladkey,1, pues escribió el código que corresponde al núcleo y buena parte del código del servidor NFS. Este último es una modificación del servidor unfsd que corre en espacio de usuario, escrito originalmente por Mark Shand, y el servidor hnfs (Harris NFS) escrito por Donald Becker.

Versiones del Servidor NFS

Hay tres versiones de NFS actualmente en uso:

* La versión 2 del protocolo es la primera versión publicada y sigue la siendo la más extendida en nuestros días.
Existen implementaciones sobre varias plataformas diferentes y se han descrito pocos problemas de compatibilidad. 

*La versión 3 del protocolo data de 1992 y presenta varias mejoras . 
- Mejora del rendimiento debido a la reescritura del código de la red, y al uso de paquetes de datos mayores. 
- Mejora en la seguridad con las Listas de ACL (Listas de control de acceso) que permiten definir acceso a los recursos por UID y fichero a fichero. 
- Implementación de un sistema de autentificación basado en contraseña. 
- Por desgracia, la versión 3 de NFS para Linux esta todavía en pañales. NFS para GNU/Linux es intrínsecamente inseguro y peligroso si se administra mal. 

·         *La versión 4 del protocolo Incluye seguridad Kerberos, trabaja con cortafuegos, permite ACLs y utiliza operaciones con descripción del estado

Caracteristicas de los Servidores NFS

*El sistema NFS está dividido al menos en dos partes principales: un servidor y uno o más clientes. Los clientes acceden de forma remota a los datos que se encuentran almacenados en el servidor. 

  

*Las estaciones de trabajo locales utilizan menos espacio de disco debido a que los datos se encuentran centralizados en un único lugar pero pueden ser accedidos y modificados por varios usuarios, de tal forma que no es necesario replicar la información. 

*Los usuarios no necesitan disponer de un directorio “home” en cada una de las máquinas de la organización. Los directorios “home” pueden crearse en el servidor de NFS para posteriormente poder acceder a ellos desde cualquier máquina a través de la infraestructura de red. 

*También se pueden compartir a través de la red dispositivos de almacenamiento como disqueteras, CD-ROM y unidades ZIN. Esto puede reducir la inversión en dichos dispositivos y mejorar el aprovechamiento del hardware existente en la organización. 

Todas las operaciones sobre ficheros son síncronas. Esto significa que la operación sólo retorna cuando el servidor ha completado todo el trabajo asociado para esa operación. En caso de una solicitud de escritura, el servidor escribirá físicamente los datos en el disco, y si es necesario, actualizará la estructura de directorios, antes de devolver una respuesta al cliente. Esto garantiza la integridad de los ficheros.

¿Que es un Servidor NFS?

El Network File System (Sistema de archivos de red), o NFS, es un protocolo de nivel de aplicación, según el Modelo OSI. Es utilizado para sistemas de archivos distribuidos en un entorno de red de computadoras de área local. Posibilita que distintos sistemas conectados a una misma red accedan a ficheros remotos como si se tratara de locales. Originalmente fue desarrollado en 1984 por Sun Microsystems, con el objetivo de que sea independiente de la máquina, el sistema operativo y el protocolo de transporte, esto fue posible gracias a que está implementado sobre los protocolos XDR (presentación) y ONC RPC (sesión) . El protocolo NFS está incluido por defecto en los Sistemas Operativos UNIX y la mayoría de distribuciones Linux.