Remove ads
De Wikipedia, la enciclopedia libre
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 distribuido en un entorno de red de ordenadores 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).[1] El protocolo NFS está incluido por defecto en los Sistemas Operativos UNIX y la mayoría de distribuciones Linux.
Network File System (NFS) | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
Familia | Protocolos de sistema de archivos en red | |||||||||||
Función | Acceso a sistema de archivos vía red. | |||||||||||
Última versión | NFSv4 | |||||||||||
Puertos | 2049 | |||||||||||
Ubicación en la pila de protocolos* | ||||||||||||
| ||||||||||||
* según el Modelo OSI | ||||||||||||
Estándares | ||||||||||||
RFC 1094 (versión 2) RFC 1813 (versión 3) RFC 3530 (versión 4) | ||||||||||||
Todas las operaciones sobre ficheros son síncronas. Esto significa que la operación solo 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.
Suponemos que un cliente de un sistema de archivos (NFS) de red trata de montar un directorio sacado del servidor NFS a un directorio local. Para llevar a cabo esto, necesitara la siguiente orden:
# mount -t nfs maquina_remota:/home /dir_local
En esta orden especificamos el tipo de sistema de archivos que se va a montar con –t, la máquina remota y el directorio donde vamos a montarlo.
Esta orden lo que trata es conectar con el demonio rpc mountd que se está ejecutando en la máquina remota a través de RPC. El servidor comprueba los permisos del cliente sobre el directorio /home donde se va a montar y si los tiene se lleva a cabo el montaje como si fuera cualquier otro dispositivo físico. Una vez realizado el montaje, cuando se acceda al directorio del cliente se estará accediendo al directorio del servidor remoto.
Cuando el directorio /dir_local tenga ya montado el directorio /home de la máquina remota, la única protección que tienen los archivos de dicho directorio son sus permisos.
Al acceder a los archivos del directorio NFS se generará una llamada RPC al demonio rpc nfsd en el servidor, en la cual van incluidos los parámetros correspondientes al UID y el GID del usuario y el descriptor del archivo, con los que se comprobarán los permisos.
Suponiendo un escenario de estilo Unix en el que una máquina (el cliente) necesita acceder a los datos almacenados en otra máquina (el servidor NFS):
Este sistema de archivos se utiliza para que en una red local diferentes equipos puedan acceder a archivos y compartirlos, de esta manera, una equipo puede acceder a la información de otro equipo como si fuera un disco duro. NFS se centra en la consistencia, asumiendo operaciones write pesadas que probablemente no sean muy frecuentes.
Uno de los usos principales del protocolo NFS es para poder tener todos los archivos centralizados en un único servidor. Esto va a permitir prescindir de unidades de memoria en los demás equipos y poder entrar de forma remota para leer cualquier archivo o descargarlo.
Es muy útil especialmente cuando son muchos los usuarios que van a tener que entrar para modificar esos archivos
El cliente simula las funcionalidades del sistema de archivos de UNIX, integrado directamente en el kernel. Se encarga de controlar las peticiones del VFS al servidor. Manda los bloques o archivos desde el servidor y hasta el servidor. Cuando es posible almacena en la caché local los bloques.
El módulo cliente de NFS guarda en caché los resultados de las operaciones <readwritegetattlookup> y readdir. Los clientes son responsables de sondear al servidor para comprobar la actualidad de sus datos de caché.
Método de marcas temporales para mantener las cachés:
Cada elemento es etiquetado con dos tiempos diferentes, uno el de la última vez que se validó el elemento y otro la última vez que fue modificado en el servidor. Una entrada en caché es válida en un momento t si t-tiempo que se validó por última vez es menor que el intervalo de refresco tolerado. Si no es válida la entrada se obtiene el tiempo en el que se modificó por última vez en el servidor y si es igual al del cliente, entonces la entrada es válida y se actualiza el tiempo del cliente, si no la entrada es invalida.
Para minimizar las llamadas a getattr, cuando se recibe un valor del servidor de un archivo, se aplica a todas las entradas relevantes de dicho archivo.
Aún con esto habrá problemas de consistencia si tenemos escrituras en dos clientes con una diferencia de tiempo menos que el intervalo de refresco tolerado. Para solucionar este problema tendremos que usar bloqueo de archivos convirtiendo en una sección crítica el archivo, esto se consigue en NFS mediante el protocolo Network Lock Manager (NLM).
El servidor NFS es parte del núcleo Linux, en los núcleos que Debian provee está compilado como un módulo de núcleo. Su interfaz está definida en el RFC 1813.
Se encarga de recibir las peticiones, que pueden ser similares a las de modelo de archivos plano o pueden simular las del sistema de UNIX.
El servidor también ofrece servicios de montaje, de control de autenticación y acceso y una caché.
Hay dos opciones para mantener y asegurar la consistencia en escritura:
Los demonios imprescindibles del servicio NFS son los siguientes:
# portmap status
Si queremos que nuestro servicio NFS sea más seguro deberíamos tener en cuenta una serie de detalles, como son:
NFS incluye la identidad del usuario por defecto en las peticiones al servidor, pero solo para compararla con los permisos de accesos, no la valida.
Con kerberos se realiza la autenticación del usuario en el momento del montaje del sistema de archivos. Los resultados de estas autenticaciones se almacenan y se utilizan en cada petición NFS. Esto protege contra la mayoría de ataques.
Las versiones de NFS más importantes son NFSv2 (RFC 1094), NFSv3 (RFC 1813) y NFSv4 (RFC 3530).
La versión 2 de NFS es la más utilizada y soportada por los sistemas operativos, a la vez que la más antigua e insegura. La versión 3 es más potente que la 2 pero no es compatible completamente con los clientes de la versión anterior. Estas dos versiones pueden trabajar tanto con TCP como con UDP como protocolo de transporte creando conexiones de red entre cliente y servidor. La ventaja de utilizar UDP es que se minimiza el tráfico de red, pero si se cayera los clientes seguirían mandando mensaje y se saturaría.
En general las versiones 2 y 3 de NFS permiten controlar la exportación y montaje de sistemas de archivos en función del equipo que hace la solicitud, pero no del usuario. Es decir no se contempla un control de acceso al sistema de archivos por usuario. Solo para los equipos. Esto implica que si un sistema de archivos es exportado desde el servidor NFS, cualquier usuario de un equipo remoto cliente NFS podría acceder a él. Los únicos mecanismos de seguridad que quedan en este caso son los permisos de acceso (solo lectura) o utilizar un usuario y grupo únicamente. Lógicamente esto limita bastante la idea de compartición que tenemos todos.
En el caso de la versión 4 de NFS estos problemas de seguridad desaparecen pero, a cambio, tiene unos requerimientos de configuración y servicios adicionales mucho más importantes. Por ejemplo, en la versión 4 la utilización de mecanismos para la autenticación de los usuarios es obligatoria. Para ello y en función del tipo de seguridad seleccionada, se requiere la utilización del servicio Kerberos cuya misión será funcionar como servidor de entrega de tickets (KDC) y que debe estar configurado y funcionando correctamente antes de configurar el servidor NFSv4. Este requerimiento proporciona seguridad al servicio NFS a cambio de incluir mayor complejidad a su configuración y puesta a punto.
Otra característica importante de NFS4 es la utilización de ACLs (Listas de Control de Acceso) al estilo Windows y que no son soportadas por las versiones 2 y 3 de NFS. Cuando hablamos de ACLs nos referimos a los permisos o derechos de acceso que tiene cada usuario sobre un archivo o directorio y que vienen especificados a modo de listas editables por el administrador del sistema.
Inicialmente NFS soportaba 18 procedimientos para todas las operaciones básicas de E/S.[1] Los comandos de la versión 2 del protocolo son los siguientes:[2]
En la versión 3 del protocolo se eliminan los comandos STATFS, ROOT y WRITECACHE; y se agregaron los siguientes:[3]
La versión 4 fue publicada en abril de 2003 y no es compatible con las versiones anteriores. Soporta 41 comandos: NULL, COMPOUND, ACCESS, CLOSE, COMMIT, CREATE, DELEGPURGE, DELEGRETURN, GETATTR, GETFH, LINK, LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, OPEN_DOWNGRADE, PUTFH, PUTPUBFH, PUTROOTFH, READ, READDIR, READLINK, REMOVE, RENAME, RENEW, RESTOREFH, SAVEFH, SECINFO, SETATTR, SETCLIENTID, SETCLIENTID_CONFIRM, VERIFY, WRITE, RELEASE_LOCKOWNER, ILLEGAL.[4]
Temas relacionados con NFS:
Otros sistemas:
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.