Nenhuma criação de arquivo de bloqueio na configuração do NFS

Question

Recentemente, criei um novo servidor de arquivos para o nosso grupo de pesquisa. O antigo estava rodando o SuSE linux e, apesar de pequenos discos rígidos e uma máquina lenta, funcionava bem. Os clientes são principalmente máquinas Gentoo montando os compartilhamentos NFS via autofs . Os diretórios iniciais das máquinas estão no servidor de arquivos.

O novo servidor de arquivos é uma máquina virtual em algum computador do departamento executando Debian squeeze . Após a configuração (várias vezes), tivemos grandes problemas com rpc.statd e / ou rpc.lockd não respondendo assim que mais de um computador montou seus diretórios pessoais. Atualizamos o kernel de 2.6.32 para 3.2 , o que pareceu corrigir esse problema. No entanto, parece que os arquivos de bloqueio ainda não são criados .

Por exemplo, nosso gerenciador de área de trabalho xdm nos clientes recua para criar o arquivo .Xauthority em algum lugar localmente em /tmp em vez de no diretório inicial no compartilhamento NFS. Além disso, programas pesados que usam arquivos de bloqueio, como Firefox, Thunderbird, Libreoffice etc., são um pouco lentos e o login do xdm também.

Nós usamos (pelo menos é o que eu acho) o NFS4, que, a meu conhecimento, não precisa mais de rpc.lockd e assim por diante. A única mensagem de erro relacionada a isso que eu posso encontrar desde a atualização do kernel é a seguinte:

sm-notify[540]: nsm_parse_reply: [0x515dce2e] RPC status 1

Eu não consigo descobrir na internet o que isso significa. O servidor não está (atualmente) protegido, o /etc/default/nfs-kernel-server se parece com isso

RPCNFSDCOUNT=32
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS="--manage-gids -p 32767"
NEED_SVCGSSD=
RPCSVCGSSDOPTS=

e nos clientes, o hosts.allow contém uma entrada para rpcbind do servidor.

Eu tenho várias perguntas relacionadas a isso:

• Como posso verificar, usando um pequeno script python ou bash, se a criação do arquivo de bloqueio funciona normalmente em compartilhamentos NFS?
• Como descubro qual versão do NFS um cliente usa?
• Como posso rastrear erros do NFS, quando nada aparece nos arquivos de log?
• Qual poderia ser o motivo de nossos problemas com o Xauthority e os aplicativos mencionados acima?

Answer 1

Acho que resolvi isso. O xdm cria a raiz .Xauthority as, portanto, a opção no_root_squash nas exportações NFS impede que isso aconteça. Remover essa opção permite que os clientes criem a .Xauthority apenas.

    

Answer 2

Acho que tcpdump(8) e strace(1) são seus amigos aqui.

tcpdump pode:

• mostra a versão do protocolo NFS
• diga quem está falando com quem (para solução de problemas)
• às vezes, também informam o que acontece de errado nos casos em que as mensagens de log do aplicativo são escassas

strace rastreia chamadas e sinais do sistema, que, quando anexados ao processo adequado, como um shell ou sshd , podem mostrar, por exemplo, o número de chamadas fopen() , o que poderia sugerir o problema de autoridade. .

Já aconteceu comigo várias vezes (não com o NFS, mas com a solução de problemas do cliente / servidor) que o aplicativo não funciona e nem vai dizer por quê ou dizer algo inteligente como "erro inesperado" nos arquivos de log, onde um tcpdump -A detalhado mostra as mensagens de erro do servidor (que o cliente simplesmente ignorou), então tcpdump juntamente com strace são inestimáveis ao lidar com problemas com aplicativos que você não construiu.