Configurando um cliente NFS Mac Mountain Lion para acessar com segurança o servidor Debian NFS

Question

Ok, estou ficando louco aqui.

Tentando configurar um cliente NFS do OS X (10.8.2) para conectar ao servidor nfs do Debian (6.0.6). Eu tenho seguido a maior parte das instruções aqui: link , que é muito completo. No entanto, dois problemas:

• Quando eu não uso o Kerberos, o desempenho é péssimo (acho que algo deve estar expirando) e todos os arquivos aparentemente são de propriedade de nobody: nobody. Fazer um ls do diretório montado leva dezenas de segundos.
• Quando eu faço tentar usar o Kerberos, com uma entidade criada para o servidor e para o cliente, não consigo montar o compartilhamento. O cliente reclama: mount_nfs: can't mount /mnt from servername.domain onto /home: Permission denied

Eu configurei dois principais, nfs/servername@REALM e nfs/clientname@REALM e copiei para /etc/krb5.keytab no cliente e no servidor.

O servidor está (de acordo com os logs do Kerberos) recebendo tickets para nfs/servername.REALM , então minha suspeita é que o cliente OS X NFS não está usando seu principal de alguma forma.

Alguma idéia?

Atualização: /var/log/daemon.log reports:

Oct  7 19:12:43 servername rpc.svcgssd[19635]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): Unspecified GSS failure.  Minor code may provide more information - No supported encryption types (config file error?)

De acordo com esta página: link eu removi tudo, menos o Opções de criptografia DES nos arquivos cliente e servidor krb5.keytab. E adicionado allow_weak_crypto no arquivo /etc/krb5.conf . E reiniciado hfs-kernel-server e ainda não funciona. Suspiro.

Na verdade, agora é reportado:

Oct  7 19:26:55 servername rpc.svcgssd[19721]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): Unspecified GSS failure.  Minor code may provide more information - Wrong principal in request

Será que "Principal errado no pedido" significa que o cliente está passando o principal krb5 errado? Posso controlar isso no OS X?

    

Answer 1

O NFSv4 parece estar bem quebrado no Mac OS X 10.8.
A palavra não oficial é que a Apple está ciente do problema, mas não tem um prazo para corrigi-lo. Enquanto isso, o consenso é que o opendirectoryd está bastante quebrado.

Alguns lugares que você pode verificar para obter melhores informações de depuração:

1. # sysctl -w vfs.generic.nfs.client.idmap_ctrl=127
   Observe a saída de /var/log/system.log enquanto você está tentando executar o comando ls .

2. # odutil set log debug
   Assista a saída de /var/log/opendirectoryd.log

3. Use dtrace para descobrir onde está o hangup.
   Nossa experiência tem sido que nfs4_id2guid está expirando porque o opendirectoryd nem sempre está se registrando adequadamente com o kernel.

Answer 2

Acho que você deve tentar criar dois outros principais com o nome do seu domínio adicionado ao nome do seu servidor.

Como nfs/mysername.example.com@REALM e host/myclientname.example.com@REALM

Mas de qualquer forma, no MacOSX você tem que ter um TGT ANTES de tentar montar.

Portanto, antes da montagem, tente um kinit (qualquer principal é ok).

Pessoal, eu consegui ter um nfs + kerberos no MacOSX. Mas no NFSV3.

No NFSV4 eu consegui montá-lo, mas é lento ... muito lento.