Mappatura utente NFSv4


12

Questa domanda sembra essere stata già posta molte volte, ma le altre risposte in qualche modo non si applicavano a me.

Fondamentalmente ho appena impostato un nuovo server NFSv4 e sto affrontando il classico problema in cui UID e GID non corrispondono tra server e client. Tuttavia, sincronizzare / etc / passwd e / etc / group non è possibile nel mio scenario. Nota che ho gli stessi utenti su entrambe le macchine (al contrario di questa domanda ).

Quindi stavo esaminando idmap: secondo alcune fonti, sembra che NFSv4 invii nomi utente (al contrario del comportamento di NFSv3 per inviare UID / GID) e il ruolo di idmap sarebbe quello di tradurre questi nomi utente nell'UID / GID del server.

Tuttavia, questo sembra non funzionare nel mio caso (dettagli di installazione di seguito), che considero molto standard (praticamente installato solo NFS dal repository).

Mi sto perdendo qualcosa? C'è un modo per farlo funzionare senza configurare LDAP o Kerberos?


Configurazione del server

Il server è Ubuntu 16.04installato e due utenti.

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 è stato installato dal repository e configurato per esportare una cartella di prova.

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)

Poiché il server e il client hanno nomi host diversi, ho modificato il valore "Dominio" nel file di configurazione di idmapd. Altrimenti il ​​file è identico a quello installato dal gestore pacchetti. Si noti che il contenuto di questo file è identico sia sul server che sul client.

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

Configurazione del client

Il client ha anche Ubuntu 16.04e due utenti, che tuttavia hanno gli stessi nomi utente ma UID / GID diversi .

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 è stato installato dal repository e la condivisione di test è stata montata.

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

analisi

Per prima cosa creo un file sul client, e questo sembra a posto:

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

Ma quando visualizzo il file dal server, noto che il proprietario è quello sbagliato, mentre il gruppo non esiste.

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

esperimenti

Secondo questa risposta a una domanda simile, l'id-mapping dovrebbe essere attivato come segue, sul server (notare gli errori):

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

Sul client (notare l'assenza di errori):

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

Ma i risultati sono strani:

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

Un'altra risposta suggerisce di modificare la configurazione di idmapd come segue (il contenuto è lo stesso su entrambe le macchine):

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

Ma ciò non sembra fare alcuna differenza.

Risposte:


6

NFSv4 non tradurrà gli UID e i GID come potresti pensare quando non usi Kerberos e il sapore della sicurezza. Ma agisce esattamente come hai descritto. Il motivo è che NFSv4 utilizzerà la AUTH_SYSsicurezza. Una descrizione più dettagliata può essere trovata qui .


2
Grazie per la tua risposta e il link, molto istruttivo. Ma non è ancora possibile inserirlo nel contesto ... quindi qual è lo scopo di idmapping? Perché si chiama "rpcidmapd" se non funziona con rpc? E qual è l'effetto di questi comandi?
matpen

FWIW, sembra possibile abilitare la mappatura id NFSv4 anche quando si utilizza AUTH_SYSper questa domanda: unix.stackexchange.com/q/438939/111905
sxc731

@ sxc731: dalla mia esperienza e ho fatto un test oggi, usando idmapwith AUTH_SYStraduce correttamente gli UID e i GID. Ma i diritti effettivi non vengono tradotti e anche se lsmostrano directory o file propri, non sarà possibile apportare modifiche poiché gli ID numerici non corrispondono e con AUTH_SYSgli ID numerici vengono utilizzati per i diritti di accesso.
Thomas,

1
@Thomas corretto. Quando la mappatura ID viene attivata sec=sys, i file vengono visualizzati secondo la mappatura ID ma la scrittura funziona come se non ci fosse alcuna mappatura ID. Un altro riferimento : "Sebbene i numeri uid / gid non vengano più utilizzati nel protocollo NFSv4 tranne che nelle stringhe precedenti, rimarranno comunque nei campi di autenticazione RPC quando si utilizza AUTH_SYS (sec = sys), che è l'impostazione predefinita. in questo caso sia il nome utente / gruppo sia gli spazi numerici devono essere coerenti tra client e server. "
Irfan Latif
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.