Asignación de usuarios NFSv4

12

Parece que esta pregunta ya se ha hecho muchas veces, pero las otras respuestas de alguna manera no se aplicaron a mí.

Básicamente, acabo de configurar un nuevo servidor NFSv4 y me enfrento al clásico problema de que los UID y GID no coinciden entre el servidor y el cliente. Sin embargo, sincronizar / etc / passwd y / etc / group no es factible en mi escenario. Tenga en cuenta que tengo los mismos usuarios en ambas máquinas (a diferencia de esta pregunta ).

Por lo tanto, estaba buscando en idmap: según algunas fuentes, parece que NFSv4 envía nombres de usuario (a diferencia del comportamiento de NFSv3 para enviar UID / GID) y la función de idmap sería traducir estos nombres de usuario a los UID / GID del servidor.

Sin embargo, esto parece no funcionar en mi caso (detalles de configuración a continuación), que considero muy estándar (prácticamente solo instaló NFS desde el repositorio).

¿Me estoy perdiendo de algo? ¿Hay alguna manera de hacer que esto funcione sin configurar LDAP o Kerberos?


Configuración del servidor

El servidor está Ubuntu 16.04instalado y dos usuarios.

user1@server:~$ id user1
uid=1000(user1) gid=1000(user1) groups=1000(user1),27(sudo)
user1@server:~$ id user2
uid=1001(user2) gid=1001(user2) groups=1001(user2)

NFS se instaló desde el repositorio y se configuró para exportar una carpeta de prueba.

user1@server:~$ sudo apt-get install nfs-kernel-server

user1@server:~$ sudo cat /proc/fs/nfsd/versions 
+2 +3 +4 +4.1 +4.2

user1@server:~$ ls -ld /srv/nfs/test/
drwxrwxrwx 2 nobody nogroup 4096 nov  2 17:34 /srv/nfs/test/

user1@server:~$ cat /etc/exports 
"/srv/nfs/test" 192.168.x.x(rw,sync,no_subtree_check)

Como el servidor y el cliente tienen diferentes nombres de host, cambié el valor de "Dominio" en el archivo de configuración de idmapd. De lo contrario, el archivo es idéntico al instalado por el administrador de paquetes. Tenga en cuenta que el contenido de este archivo es idéntico tanto en el servidor como en el cliente.

user1@server:~$ cat /etc/idmapd.conf
[General]

Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if id differs from FQDN minus hostname
Domain = mydomain

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

Configuración del cliente

El cliente también tiene Ubuntu 16.04y dos usuarios, que sin embargo tienen los mismos nombres de usuario pero diferentes UID / GID .

user1@client:~$ id user1
uid=1001(user1) gid=1002(user1) groups=1002(user1),27(sudo)
user1@client:~$ id user2
uid=1000(user2) gid=1000(user2) groups=1000(user2),27(sudo)

NFS se instaló desde el repositorio y se montó el recurso compartido de prueba.

user1@client:~$ sudo apt-get install nfs-common

user1@client:~$ mkdir ./test
user1@client:~$ sudo mount -t nfs4 192.168.x.x:/srv/nfs/test ./test

Pruebas

Primero creo un archivo en el cliente, y esto parece estar bien:

user1@client:~$ touch test/testfile
user1@client:~$ ls -l ./test
total 0
-rw-rw-r-- 1 user1 user1 0 nov  2 17:24 testfile

Pero cuando veo el archivo desde el servidor, noto que el propietario es el incorrecto, mientras que el grupo no existe.

user1@server:~$ ls -l /srv/nfs/test
total 0
-rw-rw-r-- 1 user2 1002 0 nov  2 17:24 testfile

Los experimentos

De acuerdo con esta respuesta a una pregunta similar, la asignación de id debe activarse de la siguiente manera, en el servidor (observe los errores):

user1@server:~$ sudo tee /sys/module/nfsd/parameters/nfs4_disable_idmapping <<< "N"
user1@server:~$ sudo nfsidmap -c
nfsidmap: 'id_resolver' keyring was not found.
user1@server:~$ sudo service rpcidmapd restart
Failed to restart rpcidmapd.service: Unit rpcidmapd.service not found.
user1@server:~$ sudo service nfs-kernel-server restart

Mientras está en el cliente (observe la ausencia de errores):

user1@client:~$ sudo tee /sys/module/nfs/parameters/nfs4_disable_idmapping <<< "N"
user1@client:~$ sudo nfsidmap -c

Pero los resultados son extraños:

user1@client:~$ touch test/testfile
user1@client:~$ ls -l test
total 0
-rw-rw-r-- 1 user2 4294967294 0 nov  2 19:16 testfile
user1@server:~$ ls -l /srv/nfs/project/
total 0
-rw-rw-r-- 1 user2 1002 0 nov  2 19:16 prova

Otra respuesta sugiere modificar la configuración de idmapd de la siguiente manera (el contenido es el mismo en ambas máquinas):

user1@server:~$ cat /etc/idmapd.conf 
[General]

Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if id differs from FQDN minus hostname
Domain = mydomain

[Translation]
   Method=static
[Static]
   user1@mydomain = user1

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

Pero eso no parece hacer ninguna diferencia.

madurar
fuente

Respuestas:

6

NFSv4 no traducirá los UID y GID como podría pensar cuando no usa Kerberos y sabor de seguridad. Pero sí actúa exactamente como lo describiste. La razón es que NFSv4 usará AUTH_SYSseguridad. Una descripción más detallada se puede encontrar aquí .

Thomas
fuente
2
Gracias por su respuesta y el enlace, muy informativo. Pero todavía no puede encajar en el contexto ... entonces, ¿cuál es el propósito de idmapping? ¿Por qué se llama "rpcidmapd" si no funciona con rpc? ¿Y cuál es el efecto de estos comandos?
maduran el
FWIW, parece posible habilitar el mapeo de id NFSv4 incluso cuando se usa AUTH_SYSsegún esta pregunta: unix.stackexchange.com/q/438939/111905
sxc731
@ sxc731: desde mi experiencia, e hice una prueba hoy, usar idmapcon AUTH_SYStraduce los UID y GID correctamente. Pero los derechos efectivos no se traducen e incluso si lsmuestra sus propios directorios o archivos, no podrá realizar cambios porque las ID numéricas no coinciden y con AUTH_SYSlas ID numéricas se utilizan para los derechos de acceso.
Thomas
1
@Thomas correcto. Cuando el mapeo de ID se activa con sec=sys, los archivos aparecen según el mappig de ID, pero la escritura funciona como si no hubiera ningún mapeo de ID. Otra referencia : "Aunque los números uid / gid ya no se usan en el protocolo NFSv4, excepto opcionalmente en las cadenas anteriores, seguirán estando en los campos de autenticación RPC cuando se utiliza AUTH_SYS (sec = sys), que es el valor predeterminado. Como tal, en este caso, tanto el nombre del usuario / grupo como los espacios numéricos deben ser coherentes entre el cliente y el servidor " .
Irfan Latif