NFSv4 mapeando UID e GID no Debian Stretch

Question

Eu uso a seguinte configuração:

Servidor NFS (Ubuntu 16.04 LTS)

• nfs-common 1: 1.2.8-6ubuntu1.2
• nfs-kernel-server 1: 1.2.8-6ubuntu1.2
• usuário: teste (uid = 1300)

Cliente NFS

• nfs-common 1: 1.3.4-2.1
• usuário: testmf (uid = 1350)

No lado do cliente, o usuário test existe com o mesmo UID do lado do servidor. Mas preciso usar o usuário testmf e não o test um.

Eu tenho lido muita documentação e respostas do StackOverflow / StackExchange e, por alguns motivos, nada funciona para mim.

Uma das muitas respostas é alterar o arquivo /etc/idmapd.conf .

Então aqui está nos dois lados:

Servidor

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

[Mapping]    
Nobody-User = nobody
Nobody-Group = nogroup

No lado do cliente:

[General]
Verbosity = 9
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if it differs from FQDN minus hostname
# Domain = localdomain
Domain = example.com

[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

[Translation]
Method = static

[Static]
[email protected] = testmf
[email protected] = testmf
test@nfsserver = testmf

E eu uso esse comando para montar o diretório no cliente:

mount 192.168.0.1:/home/test/my_exp_dir /home/testmf/my_imp_dir

E quando eu faço um ls -l /home/testmf/my_imp_dir recebo algo assim:

-rw-r--r-- 1 test test  326025780 May  9  2017 allCountries.zip

e NÃO

-rw-r--r-- 1 testmf testmf  326025780 May  9  2017 allCountries.zip

Se eu fizer esse ponto, touch testfile eu entendo:

-rw-r--r-- 1 test test  326025780 May  9  2017 allCountries.zip
-rw-r--r-- 1 testmf testmf      0 Jun  9  18:57 testfile

ou ls -ln

-rw-r--r-- 1 1300 1300  326025780 May  9  2017 allCountries.zip
-rw-r--r-- 1 1350 1350          0 Jun  9  18:57 testfile

Eu tentei aumentar o nível de detalhamento e, em nenhum dos meus logs, posso ver o mapeamento de usuários de um UID para outro, como eu vi em algumas respostas. As duas coisas que eu pude ver é que a configuração do kernel /sys/module/nfs/parameters/nfs4_disable_idmapping foi definida como Y e, mesmo depois de mudar para N , nada parece funcionar.

A segunda coisa que eu encontrei é que as duas entradas não existem no meu servidor cliente:

• /proc/net/rpc/nfs4.nametoid
• /proc/net/rpc/nfs4.idtoname

E eu não sei como adicioná-lo, especialmente se o nfsidmap não estiver disponível.

Eu li que também preciso reiniciar o serviço idmapd após essa alteração. Mas no Debian 9 lá não é possível ... Ou pelo menos eu não encontrei como fazer isso ...

Eu também alterei o arquivo /etc/default/nfs-common para definir a variável NEED_IDMAPD=yes e ela não faz nada, mesmo depois de uma reinicialização ...

Então, minha pergunta é bem burra, mas como posso ativar o nfsidmapd no Debian Stretch? Eu estou realmente fora de opção, palavras-chave de busca e a documentação oficial do Debian não é realmente útil aqui, exceto se eu for totalmente cego!

Agradecemos antecipadamente por sua ajuda.

    

Answer 1

Existe uma grande confusão com o mapeamento do id do nfs. O mapeamento usado quando uma forma de string principal, como [email protected], precisa ser convertida em uma ID numérica e vice-versa. No entanto, quando você monta com sec = sys, o que obviamente faz, todas as solicitações são autenticadas com UID e GIDs locais do cliente. IOW, no touch UID do processo do cliente, será o proprietário do arquivo no servidor.

A segunda confusão é que Static pode ser usado para definir um mapeamento estático. De acordo com a página man:

The "static" translation method uses a static list of GSS-Authenticated names to local user names.

Que literalmente espera princípios autenticados pelo GSS:

 if (strcmp(secname, "krb5") != 0 && strcmp(secname, "spkm3") != 0)
     return -EINVAL;

link

Como muitas pessoas exigem mapeamento estático, isso provavelmente terá que ser corrigido, no entanto, você não pode fixar o uso do UID do processo.

Para resolvê-lo de maneira amigável ao NFS, a melhor opção será o uso de kerberos e mount com sec = krb5. Nesse caso, o processo pode ser executado com o ticket do kerberos para um usuário, mas ainda tem um UID diferente localmente. Nesse cenário, um mapeamento estático pode ser usado para evitar o uso do LDAP.

    

Answer 2

Bem, esta é a minha resposta, talvez não exatamente o que eu queria, mas pelo menos isso resolveu o meu problema e eu continuo.

Basicamente, assegurei que todos os usuários fizessem parte do mesmo grupo com o mesmo GID em todos os servidores envolvidos. Então eu configurei o ID do grupo de todos os diretórios no diretório compartilhado com um:

find /share-dir -type d -exec chmod g+s {} \;

Eu também verifiquei que o umask foi definido como 007 em vez de 022, 027.