NFS - perfeccion-ar/infraestructura-clasica-y-avanzada GitHub Wiki

Fuente: https://ubuntu.com/server/docs/network-file-system-nfs

NFS es el equivalente a compartir carpetas en Windows.

Sirve no solo para backups, sino para que por ejemplo, una máquina "cliente" con poco espacio, pueda tener una carpeta en el servidor NFS, y usarla de la misma forma que si fuera una carpeta local.

Consideremos una máquina servidora llamada hetzner01, ubicada en 37.27.49.225, y una clienta llamada ecoplatonica, con ip 161.97.155.141

Queremos que la computadora clienta, pueda montar /srv en el servidor, y así tener mas espacio. Así se vería una vez terminada la configuración

root@hetzner01 ~ # apt install nfs-kernel-server

Exportamos la carpeta /srv

root@hetzner01 ~ # nano /etc/exports 

/srv    *(rw,async,no_subtree_check,no_root_squash)

Reiniciamos el servicio

root@hetzner01 ~ # exportfs -a

Guardamos un archivo allí

root@hetzner01 ~ # touch /srv/un_archivo.txt

Instalamos solo la parte cliente

root@ecoplatonica ~ # apt install nfs-common

Creamos una carpeta local donde montar la carpeta /srv del servidor

root@ecoplatonica ~ # sudo mkdir /mnt/hetzner01-srv

Montamos

root@ecoplatonica ~ # mount 37.27.49.225:/srv /mnt/hetzner01-srv

root@ecoplatonica ~ # ls /mnt/hetzner01-srv

Debería aparecer un archivo un_archivo.txt

El problema clásico se suscita cuando en el cliente no podemos escribir o borrar un archivo publicado en el server. Ej: un usuario ianr

ianr@ecoplatonica ~ # rm /mnt/hetzner01-srv/un_archivo.txt

Hay dos situaciones aquí:

1. Quien publicó en el server es el root (uid 0). Entonces en el cliente, si es un usuario quien quiere modificar el archivo (es decir, un uid mayor a 1000), entonces no queda más remedio en el server que hacer un chmod 777 /srv/un_archivo.txt

Pero 777 es un permiso demasiado alto. Otra opción es crear en el cliente un grupo, con nombre, algo así como "share"

root@ecoplatonica ~ # addgroup share
Adding group `share' (GID 1002) ...
Done.

Si prestamos atención, ese grupo tiene GID 1002. Entonces en el servidor:

Declaramos que la carpeta entera pertenece al grupo 1002, sea cual sea del lado cliente

root@hetzner01 ~ # chown root:1002 /srv -R

Damos permiso 7 al root, 7 al grupo, y 5 a others

root@hetzner01 ~ # chmod 775 /srv -R

Si ahora miramos como quedó, se ve así

root@hetzner01 ~ # ls -l /srv/
total 4
-rwxrwxr-x 1 root 1002 0 Aug 18 12:11 otro_archivo.txt
-rwxrwxr-x 1 root 1002 8 Aug 18 12:16 un_archivo.txt

Bien, ahora en el cliente, agregamos al usuario que tenía problemas, al grupo share.

root@ecoplatonica ~ # adduser ianr share

Si estamos usando ianr, salimos de su shell con exit y volvemos a entrar, o reclamamos con newgrp, haciendo newgrp share.

El comando groups nos confirmará cuando ianr ya sea miembro activo del grupo share.

Si ahora tratamos de borrar o modificar /mnt/hetzner01-srv como ianr, no debería haber problema.

ianr@ecoplatonica:~$ ll /mnt/hetzner01-srv/
total 12
-rwxrwxr-x 1 root share    8 Aug 18 12:16 un_archivo.txt*

ianr@ecoplatonica:~$ nano /mnt/hetzner01-srv/un_archivo.txt

De hecho, ya podemos agregar a todos los usuarios al grupo share 😊!

Creamos una linea como esta en el archivo /etc/fstab

37.27.49.225:/srv /mnt/hetzner01-srv nfs4 rw,relatime,_netdev 0 0

Sin estar parados encima, desmontamos el montaje que habíamos hecho manualmente

root@ecoplatonica ~ # umount /mnt/hetzner01-srv

Y ahora comprobamos la línea que habíamos puesto en /etc/fstab, con

root@ecoplatonica ~ # sudo mount -a

Si no ha dado error, podemos comprobar que está montada, con el comando mount

root@ecoplatonica ~ # mount | grep hetzner

37.27.49.225:/srv on /mnt/hetzner01-srv type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=161.97.155.141,local_lock=none,addr=37.27.49.225,_netdev)

NFS es un servicio muy atacado. Trate de hardenear un poco limitando las ips que tienen permiso para montar. Entonces, en el server, en el archivo /etc/exports cambie el * por la ip de la máquina clienta.

/srv    161.97.155.141(rw,async,no_subtree_check,no_root_squash)

Luego reinicie el servicio

systemctl restart nfs-server.service 

Controle ahora que máquinas clientas tienen permiso de montado.

root@hetzner01 ~ # exportfs

/srv          	161.97.155.141

Otras opciones para asegurar NFS es implementar Kerberos, o situar al server NFS dentro de una red privada, y accederlo por un túnel VPN, o vía SSH.

Ambos métodos exceden este artículo, pero se proponen para investigación conjunta en alguna Hackaton durante el cursado. Sin embargo, no olvide que NFS es un método elemental. Por ejemplo, no resuelve sharding ni escala bien horizontalmente, y que llegado ese punto, directamente quizás sea mejor pasar a Ceph, que ya tiene mecanismos propios de autenticación.