Mapeamento de Usuário NFSv4


12

Parece que essa pergunta já foi feita muitas vezes, mas as outras respostas de alguma forma não se aplicavam a mim.

Basicamente, acabei de configurar um novo servidor NFSv4 e estou enfrentando o problema clássico em que UIDs e GIDs não correspondem entre servidor e cliente. No entanto, a sincronização de / etc / passwd e / etc / group não é viável no meu cenário. Observe que eu tenho os mesmos usuários nas duas máquinas (em oposição a esta pergunta ).

Portanto, eu estava olhando para o idmap: de acordo com algumas fontes, parece que o NFSv4 envia nomes de usuários (em oposição ao comportamento do NFSv3 para enviar UID / GID) e o papel do idmap seria traduzir esses nomes de usuário nos UID / GIDs do servidor.

No entanto, isso parece não funcionar no meu caso (detalhes de configuração abaixo), que considero muito padrão (praticamente apenas o NFS instalado no repo).

Estou esquecendo de algo? Existe uma maneira de fazer isso funcionar sem configurar o LDAP ou o Kerberos?


Configuração do servidor

O servidor está Ubuntu 16.04instalado e dois usuários.

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)

O NFS foi instalado a partir do repositório e configurado para exportar uma pasta de teste.

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 o servidor e o cliente têm nomes de host diferentes, alterei o valor "Domínio" no arquivo de configuração do idmapd. Caso contrário, o arquivo é idêntico ao instalado pelo gerenciador de pacotes. Observe que o conteúdo deste arquivo é idêntico no servidor e no 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

Configuração do cliente

O cliente também tem Ubuntu 16.04e dois usuários, que, no entanto, têm os mesmos nomes de usuário, mas UID / GIDs diferentes .

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)

O NFS foi instalado a partir do repositório e o compartilhamento de teste foi montado.

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

Teste

Primeiro, crio um arquivo no cliente, e isso parece bom:

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

Mas quando visualizo o arquivo no servidor, percebo que o proprietário é o errado, enquanto o grupo não existe.

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

Experiências

De acordo com esta resposta a uma pergunta semelhante, o mapeamento de identificação deve ser ativado da seguinte maneira, no servidor (observe os erros):

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

Enquanto estiver no cliente (observe a ausência de erros):

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

Mas os resultados são estranhos:

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

Outra resposta sugere alterar a configuração do idmapd da seguinte maneira (o conteúdo é o mesmo nas duas 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

Mas isso não parece fazer nenhuma diferença.

Respostas:


6

O NFSv4 não converterá os UIDs e GIDs como você imagina quando não estiver usando o Kerberos e o sabor de segurança. Mas ele age exatamente como você descreveu. O motivo é que o NFSv4 usará AUTH_SYSsegurança. Uma descrição mais detalhada pode ser encontrada aqui .


2
Obrigado pela sua resposta e pelo link, muito informativo. Mas ainda não pode encaixá-lo no contexto ... então, qual é o objetivo do mapeamento de id? Por que é chamado "rpcidmapd" se não funciona com o rpc? E qual é o efeito desses comandos?
matpen 4/11/16

FWIW, parece possível habilitar o mapeamento ID NFSv4 mesmo quando se usa AUTH_SYSpor esta pergunta: unix.stackexchange.com/q/438939/111905
sxc731

@ sxc731: da minha experiência, e fiz um teste hoje, usando idmapcom AUTH_SYSo tradutor UIDs e GIDs corretamente. Mas os direitos efetivos não são traduzidos e, mesmo lsque mostrem seus próprios diretórios ou arquivos, você não poderá fazer alterações porque os IDs numéricos não correspondem e AUTH_SYSos IDs numéricos são usados ​​para direitos de acesso.
Thomas

1
@ Thomas correto. Quando o mapeamento de ID é ativado sec=sys, os arquivos aparecem de acordo com o mappig de ID, mas a gravação funciona como se não houvesse nenhum mapeamento de ID. Outra referência : "Embora os números uid / gid não sejam mais usados ​​no protocolo NFSv4, exceto opcionalmente nas seqüências de caracteres acima, eles ainda estarão nos campos de autenticação RPC ao usar AUTH_SYS (sec = sys), que é o padrão. Como tal, nesse caso, o nome do usuário / grupo e os espaços numéricos devem ser consistentes entre o cliente e o servidor. "
Irfan Latif
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.