MATERIAL

NFS

Compartición de archivos en Linux mediante NFS 1.

¿Qué es NFS?

El NFS o Network File System es un sistema de archivos virtual que permite que una máquina UNIX conectada a una red pueda montar un sistema de archivos de otra máquina e interactuar sobre él como si fuera propio.

De esta manera, constituye un medio de compartición de archivos totalmente transparente para el usuario de la máquina cliente. NFS no es en realidad un sistema de archivos físico, sino una capa de abstracción del sistema de archivos real (ext2, UFS, FFS, etc...) que permite el montaje de éste remotamente.

Por ejemplo, si nuestro servidor es una máquina Linux que exporta por NFS un directorio llamado, pongamos, /usr/export cuyo sistema de archivos es ext3, y tenemos un cliente FreeBSD que quiere montar de manera remota ese directorio como /mnt/external, no será necesario que nuestro FreeBSD tenga soporte para ext3, sino que simplemente lo tenga para ser cliente NFS. 2.

¿Para qué necesito NFS?

Los posibles escenarios en los que la compartición de directorios mediante NFS se podría aplicar son casi infinitos. Veamos algunos ejemplos típicos:

1. Tenemos una red con varias estaciones de trabajo y queremos que todas ellas posean el mismo software y la misma configuración: Exportamos mediante NFS los directorios /usr (para los programas) y /etc (para la configuración) desde un servidor común y conseguiremos una red uniforme.

2. Necesitamos tener una única copia de los archivos de un proyecto: creamos dicho proyecto en un directorio de un servidor y exportamos ese directorio a todas las estaciones de trabajo desde las que se use.

3. Tenemos clientes con poco espacio en disco y necesitan correr aplicaciones grandes: Se comparten los directorios de dichas aplicaciones desde un servidor mediante NFS y podremos ejecutarlas localmente en cada cliente sin problemas. En este artículo nos centraremos en el siguiente supuesto:

4. Tenemos una máquina, llamada sinope, con NetBSD, a la que deseamos recompilar el kernel. Dado que sinope es una máquina muy antigua con un disco duro de sólo 200 megabytes, de los cuales sólo nos restan libres 30, no tenemos espacio en nuestro disco duro para poder descomprimir el código fuente del kernel de NetBSD. Pero tenemos también, conectada a la misma red que sinope, a una máquina Linux llamada europa, que tiene espacio de sobra en su disco duro y que posee en su kernel la capacidad de ser servidor NFS. Dado que en la máquina NetBSD, el código fuente del kernel deberá quedar instalado en el directorio /usr/src/sys, y que el directorio de europa donde descomprimiremos dichas fuentes será /usr/export/sinope/sys, tendremos que realizar el montaje que se puede ver en el siguiente diagrama:

5. Configuración del servidor. Lo primero que tendremos que hacer para europa pueda exportar su directorio /usr/export/sinope/sys será configurar ese directorio como exportable por NFS. Esto lo haremos en el archivo /etc/exports, en el que cada línea configura un directorio exportable (ver man exports), añadiendo una línea como la siguiente: /usr/export/sinope/sys sinope(rw,no_root_squash) Veamos lo que significa esta línea: · /usr/export/sinope/sys es el directorio a exportar.

6. sinope([opciones]) es el nombre de la máquina a la que permitiremos montar este directorio por NFS según las condiciones que detallamos en las opciones que van entre paréntesis. · rw, no_root_squash son las opciones con las que sinope podrá montar este directorio. En este caso permitiremos que desde el cliente se puedan leer y escribir archivos, y además, permitiremos que los accesos realizados como root desde el cliente sean también de root en el servidor (lo cual vale para nuestro ejemplo pero podría ser un problema de seguridad en muchos casos).

7. Especificando los clientes autorizados Para especificar las máquinas autorizadas a montar un directorio de nuestro servidor existen varias posibilidades:

8. Poner un nombre o IP de host: para especificar una única máquina, podremos hacerlo poniendo simplemente su nombre DNS o dirección IP, como hemos hecho en el caso de sinope.

9. Especificar un grupo de red NIS, de la manera @grupo.

10. Especificar patrones, usando * y ?, de igual modo que se puede hacer con los nombres de archivo en un ls. De esta manera, *.midominio.priv se referiría a todas las máquinas de midominio.priv (pero atención, los puntos no se incluyen en *, de modo que esto no incluiría a, por ejemplo mimaquina.servidores.midominio.priv).

11. Especificar una red o subred IP, mediante el típico par dirección / máscara de red, por ejemplo: 192.168.0.0/255.255.0.0192.168.0.0/16 Todas estas opciones podrían combinarse, especificando varios host o grupos de hosts separándolos por espacios. Opciones para cada cliente autorizado Para cada host o grupo de hosts que se especifique, se pueden declarar (entre paréntesis, como ya se ha visto) varias opciones. Veamos algunas de las más importantes (en negrita las opciones por defecto):

    1. · secure / insecure: La opción secure hace que las peticiones de conexión tengan que provenir obligatoriamente de un puerto inferior a 1024 (los usuarios convencionales no pueden usar estos puertos, sólo root).

    2. · ro / rw: Permite (rw) o no (ro) que se realicen modificaciones en el directorio exportado desde el cliente.

    3. · async / sync: La opción sync provoca que todas las escrituras a disco desde el cliente NFS sean síncronas, y por tanto ofrece mayor seguridad ante caídas del sistema, aunque también puede reducir el rendimiento. Mención aparte merecen las opciones referidas al tratamiento de los usuarios que acceden a los directorios exportados:

    4. · root_squash: Se intentan conservar los uid y gid, de modo que se interpreta que cada usuario del cliente lo es también del servidor con sus mismos identificadores de usuario y grupo. Pero en el caso de que el usuario del cliente sea root, el uid y gid con el que trabajará en el servidor será el del usuario anónimo, nobody.

    5. · no_root_squash: El mismo comportamiento que con root_squash, pero no se aplica el cambio a los accesos del usuario root y por tanto trabaja como root también en el servidor.

    6. · all_squash: No se intentan mantener los identificadores de usuario y grupo, sino que se cambian siempre a los del usuario anónimo.

       1. En el caso de que se utilice alguna de las opciones de squash, se puede modificar el uid y gid del usuario anónimo para que en vez de nobody sea cualquiera que nosotros deseemos con las opciones anonuid y anongid, por ejemplo: /usr/export/otroexport unamaquina(ro,all_squash,anonuid=1004,anongid=1030)

12. Puesta en marcha del servidor Una vez hayamos configurado nuestro servidor, será necesario ponerlo en marcha. La forma en que haremos esto diferirá dependiendo de la distribución que usemos. Si usamos Red Hat Linux, sólo tendremos que ejecutar como root:

    1. $ service portmap start $ service nfs start

       1. Con la primera orden arrancamos el servidor portmap que se encarga de llevar cuenta de los servicios RPC que tenemos arrancados (uno de ellos será NFS).

       2. Con la segunda orden, arrancamos el servidor nfsd. Para pararlo, tendremos que hacer: $ service nfs stop Podemos hacer que el servidor NFS arranque cada vez que iniciamos el sistema marcándolo como servicio de inicio en la herramienta gráfica de configuración serviceconf.

       3. Con esta herramienta también podríamos haber arrancado los servicios en vez de usar la línea de comandos, si hubiésemos querido.

       4. En caso de que nuestra distribución no sea Red Hat, es muy probable que en el directorio /etc/init.d o /etc/rc.d/init.d encontremos scripts ya preparados para iniciar tanto portmap como nfsd.

13. Montaje del sistema de archivos desde el cliente Una vez tenemos el servidor listo y funcionando, el montaje del sistema de archivos exportado desde el cliente es muy sencillo. Basta con ejecutar como root la orden mount con los parámetros adecuados y especificando que el tipo de sistema de archivos es nfs. En nuestro caso, desde sinope ejecutaremos:

    1. $ mount -t nfs europa:/usr/export/sinope/sys /usr/src/sys ...y ya está.

    2. Podremos usar el directorio /usr/src/sys en nuestro cliente sin problemas y sin que nuestros programas se den cuenta de que no está en el disco duro local.