serviço de rede com falha na inicialização no SLES 10.2, possivelmente levando a problemas do cliente NFS

2

Em uma caixa recentemente atualizada do SLES 9.3 para 10.2, estou vendo o seguinte problema:

Antes da atualização, uma montagem NFS (definida via yast, por exemplo, aparecia em /etc/fstab ) funcionava corretamente. Após a atualização, no entanto, está falhando. Um rastreamento de rede mostra que está fazendo a conexão inicial com o servidor NFS sobre TCP (para o portmapper RPC), mas depois passa para UDP para a chamada MOUNT subseqüente; já que o servidor NFS não permite o UDP (por um bom motivo, devido a possíveis problemas com corrupção de dados, como em nfs(5) ), a conexão não passará.

Adicionar a opção TCP (seja no fstab ou na linha de comando, etc.) não tem efeito.

Durante a solução de problemas, descobri que / var / adm / messages está relatando o seguinte como ocorrendo durante a inicialização:

Failed services in runlevel 3: network

(devo observar que, apesar dessa mensagem de erro, aparentemente pelo menos alguns serviços de rede foram iniciados, já que a caixa é acessível via SSH.)

Minhas perguntas, então:

  1. O que devo verificar para determinar a causa da falha de inicialização do serviço?
  2. Isso realmente causaria o problema com o NFS descrito acima?
  3. Se a resposta para (2) for não, então alguma sugestão sobre o que procurar?

Editando para adicionar algumas informações relacionadas às respostas abaixo.

Acontece que o serviço de rede está falhando na inicialização porque uma das interfaces (há duas nesta caixa) usa o DHCP, e isso ainda não está disponível no momento. Então, eu o desativei por enquanto, parei / reiniciei o serviço de rede e os serviços do cliente NFS, mas ainda obtive os mesmos resultados.

Não há firewall no lado do cliente. Além disso, iptables -L no lado do cliente mostra que tudo é aceito; e não há entradas em /etc/hosts.allow ou /etc/hosts.deny.

No lado do servidor NFS, nada foi alterado. O nfsserver remoto é, de fato, publicidade que permite TCP e UDP para todos os serviços NFS (embora haja uma regra de iptables bloqueando UDP).

A entrada do / etc / fstab é bem básica - o que você gostaria de fazer no yast:

x.x.x.x:/volume      /localdir   nfs     defaults 0 0

rpcinfo -p para a caixa do cliente mostra apenas o portmapper v2 em execução, anunciando tanto o TCP quanto o UDP. Para o servidor, mostra todos os serviços habituais:

   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp   4047  status
    100024    1   tcp   4047  status
    100011    1   udp   4049  rquotad
    100021    1   udp   4045  nlockmgr
    100021    3   udp   4045  nlockmgr
    100021    4   udp   4045  nlockmgr
    100021    1   tcp   4045  nlockmgr
    100021    3   tcp   4045  nlockmgr
    100021    4   tcp   4045  nlockmgr
    100005    1   udp   4046  mountd
    100005    1   tcp   4046  mountd
    100005    2   udp   4046  mountd
    100005    2   tcp   4046  mountd
    100005    3   udp   4046  mountd
    100005    3   tcp   4046  mountd
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs

A chamada de montagem, com a entrada / etc / fstab acima, é simplesmente:

mount /localdir

embora eu também tenha tentado com várias opções, como tcp, v3, etc.

Tanto a entrada / etc / fstab (daí a montagem) quanto a chamada rpcinfo -p estão usando o endereço IP, portanto não há problemas de resolução de DNS envolvidos.

    
por Alex 29.01.2010 / 20:48

6 respostas

0

Para referência, caso alguém encontre essa pergunta e queira uma resposta:

Eu finalmente abri um ticket com a Novell sobre isso. Acontece que este é um bug conhecido no SLES 10.2 (491140: mount ignores "proto=" for "nfs"), e há um patch para ele (util-linux-2.12r-35.35.2.x86_64.rpm) . Com isso instalado, a montagem funciona conforme o esperado e todas as solicitações são feitas através do TCP. (O suporte da Novell também me informou que isso é mesclado no SLES 10.3.)

    
por 01.03.2010 / 23:47
1

Verifique se /etc/hosts.deny não contém uma entrada para mountd e verifique hosts.allow , por motivos semelhantes. Por que vale a pena, eu geralmente limpo hosts.deny e uso iptables para controlar o acesso.

Use rpcinfo -p nfsserver para garantir que mountd esteja realmente anunciando TCP - existe uma opção -n para desabilitar a escuta TCP, que (IIRC no SuSE) provavelmente seria definida em /etc/sysconfig/nfs ou por aí.

    
por 01.02.2010 / 18:58
1

Pelo que entendi, você pode fazer o seguinte:

  • ssh para o seu sistema cliente nfs
  • "conectar" com rpcinfo do cliente ao servidor
  • você desequilibrou a interface do dhcp, então todo tráfego está passando por uma interface e não há outras rotas

mas você não pode montar um sistema de arquivos do servidor nfs no cliente nfs e você não recebe nenhuma mensagem de erro.

qual é a diferença entre suas chamadas rpcinfo e mount ? você usa ip address em um e fqdn no outro? você poderia por favor postar os dois comandos com saída e returncode?

    
por 02.02.2010 / 17:01
1

Algumas coisas. Primeiramente, você declara no início que since the NFS server doesn't allow UDP e, em sua edição, menciona The remote nfsserver is indeed advertising that it allows both TCP and UDP for all of the NFS services . Isso parece um pouco estranho. Por que o servidor anuncia algo que não permite?

Em segundo lugar, você está tentando usar o NFS versão 2 ou versão 3? A versão 2 suporta apenas o UDP, enquanto você precisa da versão 3 para o TCP. Talvez especificar manualmente a versão 3 nas opções de montagem ajudará? (vers = 3) Se o padrão é 2, então até mesmo especificar TCP não fará nenhum bem a você.

Eu também tive problemas com clientes mais novos tentando usar a versão 4, quando o servidor não suportava muito. Sua atualização do SLES pode ter resultado em uma versão padrão diferente. Mais uma razão para especificá-lo explicitamente.

Por que você não publica a entrada em / etc / fstab também?

    
por 03.02.2010 / 22:48
0
  1. Experimente iniciar o serviço manualmente com service network restart e ver quais mensagens você recebe. Deve haver alguma informação lá.
  2. Possivelmente ...
  3. Verifique se há algum firewall ativado por padrão em seu sistema, isso pode estar causando problemas. Especialmente se o início de rede com falha não carregar corretamente as regras de firewall.
por 01.02.2010 / 18:42
0

Tente definir as coisas explicitamente e veja onde isso acontece. Por exemplo, em / etc / fstab:

x.x.x.x:/vol /local nfs proto=tcp,port=2049,mountport=4046,nfsvers=3 0 0

Isso deve pelo menos ignorar o portmapper e explicitamente tentar conectar as portas TCP listadas acima e facilitar o tcpdump rastrear cada canal durante a depuração.

    
por 06.02.2010 / 19:52