Solucionar problemas de descoberta de agente UNIX/Linux no Operations Manager

  • Artigo

Este artigo ajuda você a solucionar erros comuns que podem ser encontrados durante o processo de descoberta de computadores UNIX ou Linux.

Versão original do produto: System Center Operations Manager
Número de KB original: 4490426

Para monitorar computadores UNIX ou Linux no OpsMgr (System Center Operations Manager), os computadores devem primeiro ser descobertos e o agente OpsMgr deve ser instalado. O Assistente de Computador e Gerenciamento de Dispositivos é usado para descobrir e instalar agentes em computadores UNIX e Linux. No entanto, o processo de descoberta pode falhar devido a problemas de configuração, credenciais ou privilégios ou problemas de resolução de rede e nome.

Erros de certificado ou erros de assinatura de certificado

A operação de verificação de certificado assinada não foi bem-sucedida

Quando a verificação de certificado falha, normalmente você recebe um erro que se assemelha ao seguinte:

Falha na verificação do agente. Detalhe do erro: o certificado do servidor no computador de destino (lx1.contoso.com:1270) tem os seguintes erros:
O certificado SSL não pôde ser verificado para revogação. O servidor usado para marcar para revogação pode ser inacessível.
O certificado SSL contém um CN (nome comum) que não corresponde ao nome do host.
É possível que:

  1. O certificado de destino é assinado por outra autoridade de certificado não confiável pelo servidor de gerenciamento.
  2. O destino tem um certificado inválido, por exemplo, seu CN (nome comum) não corresponde ao FQDN (nome de domínio totalmente qualificado) usado para a conexão. O FQDN usado para a conexão é: lx1.contoso.com.
  3. Os servidores no pool de recursos não foram configurados para confiar em certificados assinados por outros servidores no pool.

  • Uma causa comum é que o valor CN (nome comum) do certificado do agente não corresponde ao FQDN (nome de domínio totalmente qualificado) fornecido ou resolvido.

    Para verificar isso, confirme se o nome do host do agente e o nome do domínio correspondem ao FQDN resolvido por meio do DNS.

    Você pode exibir os detalhes básicos do certificado no computador UNIX ou Linux executando o seguinte comando:

    openssl x509 -noout -in /etc/opt/microsoft/scx/ssl/scx.pem -subject -issuer -dates

    Ao fazer isso, você verá uma saída semelhante à seguinte:

    subject= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name
    issuer= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name
    notBefore=Mar 25 05:21:18 2008 GMT
    notAfter=Mar 20 05:21:18 2029 GMT

    Use essas informações para validar os nomes e datas do host, verifique se eles correspondem ao nome que está sendo resolvido pelo servidor de gerenciamento do Operations Manager.

    Se os nomes do host não corresponderem, use uma das seguintes ações para resolve o problema:

    • Se o nome do host UNIX ou Linux estiver correto, mas o servidor de gerenciamento do Operations Manager estiver resolvendo-o incorretamente, modifique a entrada DNS para corresponder ao FQDN correto ou adicione uma entrada ao arquivo hosts no servidor do Operations Manager.
    • Se o nome do host UNIX ou Linux estiver incorreto, faça um dos seguintes procedimentos:
      • Altere o nome do host no host UNIX ou Linux para o correto e crie um novo certificado.
      • Crie um novo certificado com o nome do host desejado.

    Para alterar o nome no certificado:

    Se o certificado foi criado com um nome incorreto, você poderá alterar o nome do host e recriar o certificado e a chave privada. Para fazer isso, execute o seguinte comando no computador UNIX ou Linux:

    /opt/microsoft/scx/bin/tools/scxsslconfig -f -v

    A -f opção força os arquivos em /etc/opt/microsoft/scx/ssl a serem substituídos.

    Você também pode alterar o nome do host e o nome do domínio no certificado usando o -h e -d alterna, como no exemplo a seguir:

    /opt/microsoft/scx/bin/tools/scxsslconfig -f -h <hostname> -d <domain.name>

    Reinicie o agente executando o seguinte comando:

    /opt/microsoft/scx/bin/tools/scxadmin -restart

    Para adicionar uma entrada ao arquivo hosts:

    Se o FQDN não estiver no DNS Reverso, você poderá adicionar uma entrada ao arquivo hosts localizado no servidor de gerenciamento para fornecer resolução de nomes. O arquivo hosts está localizado na \Windows\System32\Drivers\etc pasta. Uma entrada no arquivo hosts é uma combinação do endereço IP e do FQDN.

    Por exemplo, para adicionar uma entrada para o host chamado newhostname.newdomain.name com um endereço IP de 192.168.1.1, adicione o seguinte ao final do arquivo hosts:

    192.168.1.1 newhostname.newdomain.name

  • Outra causa comum desse erro é que o certificado foi assinado por autoridade não confiável, como quando vários servidores de gerenciamento são membros do pool de recursos usado para descoberta, mas a confiança do certificado não foi configurada entre os servidores de gerenciamento.

    Para verificar isso, confirme se todos os servidores de gerenciamento no pool de recursos usados para descoberta confiam no certificado do servidor.

    Para obter mais informações sobre como gerenciar pools de recursos para computadores UNIX e Linux, consulte Gerenciando pools de recursos para computadores UNIX e Linux.

O nome de usuário ou senha está incorreto

Você pode ver o erro ao tentar descobrir agentes UNIX/Linux. A falha pode ocorrer durante a etapa de verificação de certificado ao descobrir um computador UNIX/Linux.

Possíveis causas

  • A autenticação básica é definida como false em um ou mais servidores de gerenciamento no pool de recursos UNIX/Linux quando o agente UNIX/Linux não está ingressado no domínio e não pode utilizar a autenticação Kerberos. Você pode verificar as configurações atuais do WinRM executando o seguinte comando: winrm get winrm/config/client.
  • O nome de usuário ou senha está incorreto.

Resolução

Você pode atualizar a configuração do WinRM nos servidores de gerenciamento no pool de recursos UNIX/Linux para permitir a autenticação básica executando o seguinte comando ou definir a configuração por meio de Política de Grupo:

winrm set winrm/config/client/auth @{Basic="true"}

Observação

O comando acima define um valor de registro DWORD (32 bits) (AllowBasic) na seguinte chave do registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WinRM\Client

O AllowBasic permite 1 valores decimais (habilitados) ou 0 (desabilitados).

A operação de assinatura de certificado não foi bem-sucedida

Possíveis causas

  • A conta de usuário especificada para descoberta não tem privilégios suficientes para executar operações de arquivo envolvidas na assinatura.
  • Os privilégios de elevação do Sudo para a conta de usuário especificada para descoberta não foram configurados corretamente.

Resolução

Para corrigir o problema, verifique a conta de usuário inspecionando a saída do StdErr nos detalhes do erro para identificar a causa da falha. Verifique também a configuração de privilégio sudo para a conta usada para assinatura de certificado.

Erros de resolução de nomes de rede

O endereço de destino não é resolvível

Esses problemas normalmente se enquadram em uma das seguintes categorias:

  • Descrição do erro

    Falha ao resolve endereço IP do endereço <> IP para o nome

    Causa

    Esse erro ocorre quando um endereço IP do host foi inserido para descoberta, mas o endereço IP não é resolvível para um nome no DNS (pesquisa inversa).

    Resolução

    Para corrigir esse problema, a configuração de DNS (resolução de nomes) correta para a zona de pesquisa reversa, verifique se existe um endereço IP para o mapeamento de nomes para o host afetado.

  • Descrição do erro

    Falha ao resolve nome server.contoso.com para endereço IP

    Causa

    Esse erro ocorrerá se um FQDN para o host foi inserido para descoberta, mas o nome não é resolvível para endereço IP no DNS (pesquisa avançada).

    Resolução

    Para corrigir esse problema, a configuração de DNS (resolução de nomes) correta para pesquisa avançada, verifique se existe um nome de host para mapeamento de endereço IP para o host.

Configuração DNS: a resolução DNS avançada não corresponde à resolução DNS reversa

Descrição do erro

Nessa situação, normalmente você recebe um erro que se assemelha ao seguinte:

O nome de host fornecido ServerName foi resolvido para o endereço IP de 10.137.216.x. O nome do host ServerName.contoso.com retornado por pesquisa reversa do endereço IP 192.168.x.x não correspondeu ao nome de host fornecido. Verifique a configuração DNS e tente a solicitação novamente.

Causa

A causa mais comum é que os registros do host nas zonas de pesquisa DNS para frente e reversa não correspondem.

Resolução

Para corrigir esse problema, corrija os registros nas zonas de pesquisa avançada e reversa no DNS para que os nomes do host e o endereço IP correspondam.

O endereço de destino é inacessível

Descrição do erro

Nessa situação, normalmente você recebe um erro que se assemelha ao seguinte:

O cliente WinRM não pode concluir a operação dentro do tempo especificado. Verifique se o nome do computador é válido e é acessível na rede e a exceção de firewall para o serviço de Gerenciamento Remoto do Windows está habilitada.

Possíveis causas

  • O host é inacessível devido à resolução de nomes incorreta, interrupção de rede ou interrupção do host.
  • Um firewall baseado em rede ou host está bloqueando a conectividade da porta TCP 1270 com o host de destino.

Resolução

Para corrigir esse problema, verifique se o servidor de gerenciamento pode pingar o host do agente usando seu FQDN. Verifique também se nenhum firewall de rede ou firewall de host está bloqueando a porta TCP 1270.

Tipo discoveryResult.ErrorData inesperado. Relatório de bug de arquivo – Nome do parâmetro: s

Descrição do erro

Tipo DiscoveryResult.ErrorData inesperado. Por favor, relatório de bug de arquivo.
ErrorData: System.ArgumentNullException
O valor não pode ser nulo.
Nome do parâmetro: s
em System.Activities.WorkflowApplication.Invoke(Atividade, entradas IDictionary'2, WorkflowInstanceExtensionManager extensions, timeSpan timeout)
em System.Activities.WorkflowInvoker.Invoke(Fluxo de trabalho de atividade, entradas IDictionary'2, tempo limite do TimeSpan, extensões WorkflowInstanceExtensionManager)
em Microsoft.SystemCenter.CrossPlatform.ClientActions.DefaultDiscovery.InvokeWorkflow(IManagedObject managementActionPoint, DiscoveryTargetEndpoint criteria, IInstallableAgents installableAgents)

Causa

Esse erro ocorre porque as configurações de proxy WinHTTP foram configuradas nos servidores de gerenciamento no pool de recursos UNIX ou Linux e o FQDN do agente UNIX ou Linux que você está tentando descobrir não está incluído na lista de bypass de proxy WinHTTP.

Resolução

Para corrigir esse problema, adicione o UNIX ou o Linux FQDN à lista de bypass de proxy do WinHTTP.

Nos servidores de gerenciamento no pool de recursos UNIX ou Linux, execute o seguinte comando em um prompt de comando elevado para verificar a configuração de proxy atual:

netsh winhttp show proxy

Se um servidor proxy WinHTTP estiver configurado, adicione o FQDN do servidor que você está tentando descobrir para a lista de bypass executando o seguinte comando:

netsh winhttp set proxy proxy-server="<proxyserver:port>" bypass-list="*.ourdomain.com;*.yourdomain.com*;<serverFQDN>"

Depois que a lista de bypass estiver configurada, marcar se a descoberta do agente for bem-sucedida.

Observação

Você pode executar o netsh winhttp reset proxy comando para desabilitar o proxy WinHTTP. Esse comando removerá o servidor proxy e configurará o acesso direto.

Tipo discoveryResult.ErrorData inesperado. Relatório de bug de arquivo – Nome do parâmetro: lhs

Descrição do erro

Descoberta não bem-sucedida
Mensagem: falha não especificada
Detalhes: tipo DiscoveryResult.ErrorData inesperado. Por favor, relatório de bug de arquivo.
ErrorData: System.ArgumentNullException
O valor não pode ser nulo.
Nome do parâmetro: lhs
em System.Activities.WorkflowApplication.Invoke(Atividade, entradas IDictionary'2, WorkflowInstanceExtensionManager extensions, timeSpan timeout)
em System.Activities.WorkflowInvoker.Invoke(Fluxo de trabalho de atividade, entradas IDictionary'2, tempo limite do TimeSpan, extensões WorkflowInstanceExtensionManager)
em Microsoft.SystemCenter.CrossPlatform.ClientActions.DefaultDiscovery.InvokeWorkflow(IManagedObject managementActionPoint, DiscoveryTargetEndpoint criteria, IInstallableAgents installableAgents)

Causa

Esse erro ocorre devido aos arquivos de shell omsagent na pasta kits instalados.

Resolução

Navegue até o seguinte diretório no Explorador de Arquivos:

C:\Program Files\Microsoft System Center\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits

Se houver arquivos omsagent listados, mova-os para um diretório temporário fora dos arquivos SCOM (System Center Operations Manager).

Confira a captura de tela a seguir para obter um exemplo:

Captura de tela que mostra arquivos omsagent na pasta DownloadedKits.

Depois de serem movidos da pasta DownloadedKits , tente novamente a descoberta. A descoberta deve ter êxito agora.

Observação

A descoberta pode falhar com um erro diferente. O erro indica que é necessário mais solução de problemas, como sudoers, conectividade e assim por diante.

Erros de conectividade SSH

Falha durante a descoberta do SSH. Código de saída: -1073479162

Descrição do erro

Saída Padrão:
Erro Padrão:
Mensagem de exceção:uma exceção (-1073479162) fez com que o comando SSH falhasse - nenhuma conexão poderia ser feita porque o computador de destino o recusou ativamente.

Possíveis causas

  • O daemon SSH não está em execução no sistema de destino.
  • Um firewall baseado em rede ou host está impedindo conexões SSH na porta TCP 22.

Resoluções

  • Verifique se o daemon SSH está em execução.
  • Verifique se nenhum firewall de rede ou firewall de host está bloqueando a porta TCP 22.

Falha durante a descoberta do SSH. Código de saída: -1073479118

Descrição do erro

Falha durante a descoberta do SSH. Código de saída: -1073479118
Saída Padrão:
Erro Padrão:
Mensagem de exceção:uma exceção (-1073479118) fez com que o comando SSH falhasse - Mensagem de desconexão enviada pelo servidor: tipo 2 (erro de protocolo : muitas falhas de autenticação para raiz)

Possíveis causas

  • A conta de usuário especificada para descoberta não tem permissão para entrar por meio do SSH.
  • A conta de usuário especificada para descoberta foi a entrada com um nome de usuário ou senha inválido

Resoluções

  • Verifique se o usuário tem permissão para entrar por meio do SSH.
  • Verifique as credenciais de entrada e se o usuário está definido no host de destino.

Falha durante a descoberta do SSH. Código de saída: 1

Descrição do erro

Falha durante a descoberta do SSH. Código de saída: 1
Saída Padrão: caminho do Sudo: /usr/bin/
Erro Padrão: sudo: desculpe, você deve ter um tty para executar o sudo
Mensagem de exceção:

Causa

A elevação do Sudo foi selecionada na entrada de credencial do usuário, no entanto, a opção requiretty não foi desabilitada para o usuário em sudoers.

Resolução

Edite o arquivo sudoers no host de destino usando o visudo comando e adicione a seguinte linha:

Padrões: <nome de> usuário!requiretty

Para obter mais informações, consulte Como configurar as teclas de elevação e SSH do sudo.

Senha su inválida

Descrição do erro

. [?1034hopsuser@lx1:~> su - raiz -c 'sh /tmp/scx-opsuser/GetOSVersion.sh; EC=$?; rm -rf /tmp/scx-opsuser; $EC de saída'
Senha:
Saída
su: senha incorreta
saída opsuser@lx1:~>
Logout

Possível causa

A elevação de su foi selecionada na entrada de credencial do usuário, no entanto, uma senha raiz inválida foi fornecida para a elevação do su.

Resolução

Verifique a entrada de senha para raiz na caixa de diálogo Configuração de elevação.

Falha durante a descoberta do SSH. Código de saída: -2147221248

  • Descrição do erro

    Falha durante a descoberta do SSH. Código de saída: -2147221248
    Saída Padrão:
    Erro Padrão: não foi possível fazer chdir para o diretório inicial /home/nome de usuário: Nenhum arquivo ou diretório desse tipo

    Causa

    A conta de usuário especificada para descoberta não tem um diretório inicial.

    Resolução

    Verifique se o usuário tem um diretório inicial em: /home/ e se o usuário é capaz de gravar neste diretório.

  • Descrição do erro

    Falha durante a descoberta do SSH. Código de saída: -2147221248
    Saída Padrão:
    Erro Padrão: senha da raiz:
    Mensagem de exceção:tempo limite de operação

    Causa

    A elevação do Sudo foi selecionada na entrada de credencial do usuário. No entanto, a conta de usuário especificada para descoberta não está configurada corretamente para usar a elevação de sudo sem senha ou os privilégios de elevação de sudo necessários não foram concedidos para a conta de usuário usada na descoberta.

    Resolução

    Examine a documentação de configuração de elevação do sudo e verifique a configuração do usuário para sudo. Observe que o sudo sem senha deve ser configurado.

Erros de conectividade do WSMan

O agente respondeu à solicitação, mas a conexão WSMan falhou devido a: O acesso foi negado

Possíveis causas

  • O agente está instalado e o certificado do agente foi assinado. No entanto, a credencial de usuário fornecida para verificação do agente é inválida.
  • A conta de usuário especificada para descoberta foi configurada para autenticar com uma chave SSH, mas a credencial de usuário fornecida para verificação do agente é inválida.
  • Há um problema de permissão ou uma configuração pam incorreta no lado UNIX.

Resolução

Para corrigir o problema, execute estas etapas:

  1. Verifique se o nome de usuário e a senha para verificação do agente foram inseridos corretamente e se o usuário é um usuário válido no host de destino.

  2. Se o problema persistir, verifique se a elevação do sudo foi configurada corretamente.

  3. Também marcar o log de mensagens no computador UNIX/Linux. Por exemplo, no AIX, você pode encontrar o log em /var/adm/messages. Em outros sistemas operacionais, o local pode variar.

    Procure linhas como a seguinte:

    3 de setembro 14:49:07 servidor auth|security:debug /opt/microsoft/scx/bin/omiserver PAM: pam_authenticate: erro Autenticação falhou.

    Se você vir linhas semelhantes no log de mensagens, isso significa que o arquivo de configuração PAM não tem informações sobre o OMIServer. O arquivo de configuração PAM pode ser encontrado no /etc/pam.d/ diretório ou no /etc/pam.conf arquivo.

    A maneira mais fácil de adicionar as informações sobre o OMIServer de volta ao arquivo de configuração PAM é reinstalar o agente SCX do zero nesse computador. Se isso não for facilmente possível, você poderá copiar as linhas relativas ao OMI de um computador funcionando para o computador que não funciona.

Falha apenas na descoberta do WSMan para 192.168.x.x

Possíveis causas

  • A opção Tipo de Descoberta foi definida como Somente computadores com um agente instalado e certificado assinado e o host de destino tem o agente instalado. No entanto, o certificado de host de destino não foi assinado. Para usar a opção de descoberta somente WSMan, o agente deve ser instalado e o certificado deve ser assinado manualmente.
  • A opção Tipo de Descoberta foi definida como Somente computadores com um agente instalado e certificado assinado, mas o host de destino não tem o agente UNIX/Linux instalado no momento.
  • A opção Tipo de Descoberta foi definida como Somente computadores com um agente instalado e certificado assinado, mas o agente UNIX/Linux não está em execução no momento.
  • A opção Tipo de Descoberta foi definida como Somente computadores com um agente instalado e certificado assinado, mas o host de destino é inacessível, um firewall baseado em rede ou host está impedindo a conectividade ou o agente UNIX/Linux está em baixa no momento.

Resoluções

  • Assine manualmente o certificado.
  • Verifique se o agente UNIX/Linux foi instalado.
  • Altere a opção para Descobrir todos os computadores para permitir que o Assistente de Descoberta execute a assinatura do certificado.
  • Verifique se o agente UNIX/Linux está em execução e se o host de destino é acessível.
  • Verifique se nenhum firewall de rede ou firewall de host está impedindo o acesso na porta TCP 1270.

Outros erros

A tarefa não pode ser executada em relação aos objetos porque o destino da tarefa não corresponde a nenhuma das classes do objeto

Causa

Em um grupo de gerenciamento do System Center 2012 Operations Manager, isso pode ocorrer se os pacotes de gerenciamento UNIX/Linux importados forem versões do Operations Manager 2007 R2.

Resolução

Importe as versões do System Center 2012 dos pacotes de gerenciamento do sistema operacional UNIX/Linux.

O agente está instalado e o computador já está sendo monitorado pelo Operations Manager

Causa

O host de destino já foi descoberto neste grupo de gerenciamento.

Resolução

Nenhuma ação é necessária. A atualização ou migração do agente para um pool de recursos alternativo pode ser executada na exibição UNIX/Linux Servers no painel Administração do console de Operações.

Falha ao encontrar uma instância de agente compatível correspondente nos pacotes de gerenciamento importados

Descrição do erro

Falha ao encontrar uma instância de agente com suporte correspondente nos pacotes de gerenciamento importados. Importe os Pacotes de Gerenciamento para essa plataforma para descobrir esse computador.

Possíveis causas

  • O host de destino está executando um sistema operacional sem suporte.
  • O pacote de gerenciamento correto para o sistema operacional do host de destino não foi importado.
  • O pacote de gerenciamento correto para o sistema operacional foi importado recentemente, mas ainda não foi totalmente carregado.

Resoluções

  • Confirme se o host de destino está executando um sistema operacional com suporte.
  • Importe o pacote de gerenciamento para o sistema operacional e a versão do host de destino.
  • Se o pacote de gerenciamento foi importado, ele ainda poderá estar carregando. Aguarde alguns minutos e execute novamente a descoberta.

Não é possível enumerar tipos de agente instaláveis. O pool de recursos associado ainda pode estar inicializando

Descrição do erro

Não é possível enumerar tipos de agente instaláveis. O pool de recursos associado ainda pode estar inicializando. Se você tiver selecionado um pool de recursos recém-criado, aguarde alguns minutos antes de usá-lo.

Possíveis causas

  • O pool de recursos usado na descoberta não é saudável, por exemplo, a maioria dos servidores membros está offline.
  • O pool de recursos usado na descoberta foi criado recentemente, mas não foi totalmente inicializado.

Resolução

Se o pool de recursos usado na descoberta foi criado recentemente, tente novamente a descoberta após vários minutos para permitir que o pool seja inicializado. Caso contrário, marcar o Log de Eventos do Operations Manager nos servidores que são membros do Pool de Recursos usados para descoberta para obter indicações da origem do problema.

Não é possível copiar um novo agente para este computador

Descrição do erro

Mensagem: não é possível copiar um novo agente para este computador
Detalhes:
Falha ao copiar o kit. Código de saída: -1073479144
Saída Padrão:
Erro Padrão:
Mensagem de exceção: uma exceção (-1073479144) fez com que o comando SSH falhasse

Causa

As versões do agente de arquivos são incompatíveis entre o banco de dados e o repositório do agente.

Resoluções

  • Verifique se os agentes com falha estão todos falhando devido à incompatibilidade de versão. Caso contrário, aplique outras etapas de solução de problemas.
  • Tente atualizar os agentes com falha novamente. Normalmente, a lista de agentes com falha fica cada vez mais curta durante cada iteração de atualização.
  • Reinicie o Serviço de Integridade em todos os membros do pool de recursos do Linux ou em outro pool para gerenciar computadores Unix ou Linux. Verifique a pasta se os %ProgramFiles%\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits nomes de arquivo estão corretos. Lembre-se de fechar e reabrir o Assistente de Descoberta.

Mais informações

Para obter mais ajuda, consulte nosso fórum de suporte do TechNet ou entre em contato com Suporte da Microsoft.