NFSv4

Estas son notas sobre la puesta en marcha de un servidor NFS, versión 4, en Debian Etch.

Características

Estas son las características más sobresalientes de la versión cuatro del protocolo (no son las únicas, desde luego, porque aún estoy verificando su funcionamiento en explotación):

• Empleo de un único puerto de red, el 2049 y mediante TCP, por lo que facilita mucho la configuración de cortafuegos.
• portmap ya no es necesario.
• Se refuerza la seguridad mediante mecanismos como kerberos, aunque se puede seguir empleando la seguridad básica del sistema.
• La exportación de directorios está basada en un sistema de archivos virtual, al estilo de los que emplean los servidores de páginas Web ó los servidores de archivos FTP, por lo que es mucho más fácil su administración y uso.

[!] Nota: en Debian he observado que los montajes no suelen fallar por problemas de seguridad. La operación se lleva a cabo con aparente normalidad, pero no se vé archivo alguno en el punto de montaje, por lo que puede confundir bastante si no se tiene en cuenta.

Instalando en el servidor

Los requerimientos principales, para una instalación sin mecanismos avanzados de seguridad como Kerberos, sería la siguiente:

• Un núcleo de la rama 2.6
• El paquete nfs-kernel-server
• El programa idmapd (ver más abajo) funcionando.
• Tráfico abierto en el cortafuegos para el puerto 2049, el único empleado por NFS4 si el tipo de autentificación es el de sistema (sec=sys).
• Ajustar los accesos a los protocolos TCP (TCP Wrappers en los archivos /etc/hosts.allow y /etc/hosts.deny, sobre todo si queremos disponer de soporte simultáneo para NFS3 y NFS4.

Para poner en marcha NFS v4 se necesita un sistema de archivos virtual a partir del cual presentar los puntos exportables al exterior. Esto es, las máquinas cliente ya no tendrán que saber la ruta física de los directorios que montan, al contrario que en versiones anteriores, donde era necesario indicar por completo el punto de montaje.

En esto, como he dicho, se imita a los servidores Web, capaces de abstraer la capa física de archivos de los recursos accesibles, aunque como contrapartida tenemos algo más de lo que preocuparnos, y es de si localmente el montaje es correcto, antes de comprobar que los permisos son adecuados.

Así pues, lo que antes en el archivo /etc/fstab era:

myserver:/var/db/docs  /mnt/docs  nfs rw,auto 0 0

ahora sería

myserver:/docs /mnt/docs nfs4 rw,auto 0 0

El sistema de archivos exportable

Creamos el punto de acceso con permisos de acceso a todo el mundo y el sticky bit activo:

# mkdir -m 1777 /srv/nfsv4

y lo añadimos a la lista de exportación con una línea como ésta en el archivo /etc/exports:

/srv/nfsv4      192.168.0.0/24(ro,sync,insecure,root_squash,no_subtree_check,fsid=0)

que viene a decir que toda la red 192.168 tiene acceso como sólo lectura al raíz del sistema de exportación. Éste se identifica mediante el parámetro fsid con valor cero (0).

A partir de aquí se deben crear los directorios exportables que se van a presentar al exterior mediante montajes de tipo bind.

Supongamos que tenemos varios directorios para exportar:

• /var/db/docs: para documentos que todos pueden leer y modificar.
• /srv/images: para imágenes que sólo pueden leer.

Los pasos a seguir serían:

1. Creamos los puntos de montaje:

   # cd /srv/nfsv4
   # mkdir -m 1777 docs
   # mkdir -m 1777 images
   

2. Los enlazamos a los directorios reales añadiendo estas líneas al archivo /etc/fstab:

   # <file system> <mount point>       <type>  <options>       <dump>  <pass>
   /var/db/docs    /srv/nfsv4/docs     none    rw,bind         0       0
   /srv/images     /srv/nfsv4/images   none    rw,bind         0       0
   

3. Forzamos el montaje:

   # mount -a
   

   Esto es muy importante, porque si el servidor no tiene acceso al pseudo sistema de archivos el resto no funcionará.

4. Exportamos los datos como sigue:

   1. Añadimos en /etc/exports el directorio de documentos con permiso de escritura y el directorio de imágenes sin él. La opción nohide es importante, porque sin ella los directorios no se verán desde el exterior.

      /srv/nfsv4/docs 192.168.0.0/24(rw,nohide,sync,insecure,root_squash,no_subtree_check)
      /srv/nfsv4/images 192.168.0.0/24(ro,nohide,insecure,all_squash,no_subtree_check)
      

   2. Actualizamos el servidor NFS con la nueva disposición:

      # exportfs -rv
      

   3. Comprobamos la lista de exportación:

      # showmount -e 
      /srv/nfsv4         192.168.0.0/24
      /srv/nfsv4/docs    192.168.0.0/24
      /srv/nfsv4/images  192.168.0.0/24
      

Configurando en el cliente

En la parte cliente, que ya he comprobado que puede ser Debian Sid sin problemas, únicamente debemos asegurarnos que el demonio idmapd está funcionando, y que el núcleo tiene soporte para esta versión del protocolo.

En el archivo /etc/default/nfs-common activamos la opción NEED_IDMAPD y reiniciamos el servicio con /etc/init.d/nfs-common restart para asegurarnos de que toma en cuenta este cambio.

Una vez que comprobemos manualmente que el montaje es posible, lo registramos en la tabla de montajes para que esté siempre disponible (si es eso lo que pretendemos):

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
myserver:/docs  /var/docs       nfs4    rw,defaults     0       0
myserver:/docs  /var/images     nfs4    ro,defaults     0       0

Si necesitamos saber con mayor exactitud cómo están montado los directorios podemos hacer lo siguiente:

$ cat /proc/mounts
...
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
myserver:/docs /var/docs nfs4 rw,vers=4,rsize=32768,wsize=32768,namlen=255,hard,intr,proto=tcp,timeo=600,retrans=3,sec=sys,clientaddr=192.168.0.1,addr=192.168.0.23 0 0
...

La línea que comienza por myserver: nos proporciona varios datos interesantes:

• nfs4: sistema de archivos
• vers=4: versión NFS en uso en el montaje
• rsize y wsize: tamaños de lectura y escritura negociados entre las partes; si no se indica ninguno en las opciones de montaje este es el comportamiento esperado.
• proto=tcp: emplea el protocolo TCP en lugar de UDP, lo que parece aumentar el rendimiento según algunas fuentes consultadas, además de ser obligatorio en la versión 4 de NFS.
• sec=sys: El tipo de autentificación empleado es el del sistema, esto es, usa identificadores UID y GID para las conexiones NFS.

rpc_pipefs

Este punto de montaje es imprescindible para la versión 4, puesto que establece un lugar donde se almacenan las tuberías (pipes) que sirven para comunicación entre procesos.

En las distribuciones modernas, incluída Debian, el montaje es configurado automáticamente, pero en caso de tener que hacerlo manualmente:

1. Se añade una línea a /etc/fstab:

   # <file system> <mount point>           <type>      <options>       <dump>  <pass>
   rpc_pipefs      /var/lib/nfs/rpc_pipefs rpc_pipefs  defaults        0       0
   

2. Se crea un directorio /var/lib/nfs/rpc_pipefs si es necesario

3. Se anota ese directorio en el archivo de configuración /etc/idmapd.conf

4. Se monta como de costumbre:

   # mount rpc_pipefs
   

idmapd

Este programa debe estar funcionando en ambos lados de la conexión: en el cliente y en el servidor. Su función principal es traducir entre los nombres de usuario y los identificadores de usuario en ambos sentidos.

Su funcionamiento se define en el archivo /etc/idmapd.conf:

    1 [General]
    2 
    3 Verbosity = 0
    4 Pipefs-Directory = /var/lib/nfs/rpc_pipefs
    5 Domain = localdomain
    6 
    7 [Mapping]
    8 
    9 Nobody-User = nobody
   10 Nobody-Group = nogroup

Aunque el paquete Debian se encarga de proporcionar una versión adecuada para comenzar a usar, puede ser bueno saber algo más sobre alguna de sus opciones:

• Verbosity: Nivel de locuacidad del programa, útil para comprobar su funcionamiento.
• Pipefs-Directory: ruta al directorio donde se guardan las tuberías de comuncación; debe estar en concordancia con el sistema de archivos rpc_pipefs.

• Domain: Dominio a emplear cuando se traducen usuarios, dado que éstos se transfieren empleando la expresión usuario@dominio y deben convertirse en la parte local en UID reales. El valor predeterminado es localdomain lo que significa que entre los clientes y el servidor debe existir una base de datos sincronizada; para aquellos que estén empleando NIS ó LDAP no es necesario hacer nada más.

  Nota: este último detalle es importante tenerlo en cuenta, dado que es muy sencillo instalar un nuevo cliente y olvidarse de sincronizar dicho dominio entre el servidor y él. En este caso es habitual encontrarse en los registros del sistema (/var/log/daemon.log) quejas como la siguiente:

  Sep 22 19:12:12 cimitarra rpc.idmapd[2471]: nss_getpwnam: name 'victor@taquiones.net' does not map into domain 'localdomain'
  Sep 22 19:18:16 cimitarra rpc.idmapd[2471]: nss_getpwnam: name 'mamen@taquiones.net' does not map into domain 'localdomain'
  

Enlaces y referencias

• Setting up NFSv4
• Wiki sobre NFSv4
• NFS Home Page
• General Information and References for the NFSv4 protocol
• On migrating from NFSv3 to NFSv4.