Como obter o idmap do NFSv4 trabalhando com sec = sys?

2

Eu tenho um Servidor (Debian) que está servindo algumas pastas através do NFS e um Cliente (Debian) que se conecta ao servidor NFS (com NFSv4) e monta isso pasta exportada. Até agora está tudo bem, eu posso conectar e modificar o conteúdo das pastas. Mas os usuários estão completamente confusos. Pelo que entendi isso é devido ao NFS usando os UIDs para definir as permissões, e como os UIDs dos usuários do Cliente e do Servidor diferem, isso acontece, que ainda é esperado. Mas pelo que entendi, ao habilitar o NFSv4, o IDMAPD deveria entrar e usar o nome de usuário em vez dos UIDs. Os usuários existem no lado Servidor e Cliente , eles têm apenas UIDs diferentes. Mas, por qualquer motivo, o IDMAPD não funciona ou não parece fazer nada.

Então, aqui está o que eu fiz até agora:

No lado do servidor:

  • instalado nfs-kernel-server
  • preencheu o / etc / exports com as configurações de exportação adequadas - > / ip rfolder / 24 (rw, sync, no_subtree_check, no_root_squash)
  • e alterou / etc / default / nfs-common para ter NEED_IDMAPD = sim

No lado do cliente

  • instalado nfs-common
  • e alterou / etc / default / nfs-common para ter NEED_IDMAPD = sim
  • e monte a pasta com " mount -t nfs4 ip: / rfolder / media / lfolder "

Reiniciei e reiniciei várias vezes, mas ainda nada. Quando eu crio do Servidor uma pasta com o usuário A , no Cliente vejo que o proprietário da pasta é algum usuário X . Quando eu crio um arquivo do Cliente com o usuário A , no lado Servidor ele diz que é de algum usuário Y .

Eu verifiquei com o HTOP que o processo rpc.idmap está sendo executado no Servidor e é de fato. Embora no Cliente , não parece estar em execução. Ao tentar iniciar manualmente o serviço no Cliente , acabei de receber uma mensagem de erro informando que o IDMAP requer que a dependência nfs-kernel-server seja executada. Então, instalei-o no lado Client e agora tenho o processo rpc.idmap em execução no Client e Server . Reiniciei ambos e o problema ainda persiste.

Alguma ideia do que está errado aqui? Ou como configurar isso corretamente?

    
por Robert Koszewski 20.04.2018 / 15:28

2 respostas

2

Há algumas coisas a serem observadas ao usar o mapeamento de id do NFSv4 em montagens que usam a autenticação AUTH_SYS padrão ( sec=sys mount option) em vez de Kerberos.

Em kernels recentes, somente o servidor usa rpc.idmapd (documentado em man rpc.idmapd ). Ao usar o idmap, os nomes de usuário são transmitidos no formato usuário @ domínio . A menos que um nome de domínio seja configurado em /etc/idmapd.conf , o idmapd usa o DNS do sistema nome do domínio. Para que o idmap mapeie os usuários corretamente, o nome do domínio precisa ser o mesmo no cliente e no servidor.

Em segundo lugar, o kernel desativa o mapeamento de ID para NFSv4 sec=sys mounts por padrão . A definição do parâmetro nfs4_disable_idmapping como false ativa o mapeamento de ID para sec=sys montagens.

No servidor:

echo "N" > /sys/module/nfsd/parameters/nfs4_disable_idmapping

e no (s) cliente (s):

echo "N" > module/nfs/parameters/nfs4_disable_idmapping

Você precisa limpar o cache do idmap com nfsidmap -c nos clientes para que as alterações sejam visíveis nos sistemas de arquivos NFSv4 montados.

Para tornar essas alterações permanentes , crie arquivos de configuração em /etc/modprobe.d/ ,

no servidor ( modprobe.d/nfsd.conf ):

options nfsd nfs4_disable_idmapping=N

em cliente (es) ( modprobe.d/nfs.conf ):

options nfs nfs4_disable_idmapping=N
    
por 26.08.2018 / 20:16
0

É um comportamento bastante conhecido e documentado. Se você tiver usuários diferentes no lado do servidor e no lado do cliente que compartilham o mesmo uid , os arquivos aparecerão para ter proprietários diferentes.

Além dos arquivos compartilhados, é aconselhável ter o cuidado de mapear os usuários com o mesmo id em todas as máquinas que compartilham os mesmos sistemas de arquivos.

Você pode fazer isso manualmente, algum sistema mínimo de automação / script, ou melhor ainda, ou configurar autenticação centralizada, por exemplo, com o LDAP. veja Autenticação centralizada usando o OpenLDAP

    
por 20.04.2018 / 20:55