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

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 original do KB: 4490426

Para monitorar computadores UNIX ou Linux no System Center Operations Manager (OpsMgr), os computadores devem primeiro ser descobertos e o agente OpsMgr deve ser instalado. O Assistente de Gerenciamento de Computadores e 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, problemas de 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 assinado não foi bem-sucedida

Quando a verificação do certificado falha, você normalmente recebe um erro semelhante 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 quanto à revogação. O servidor usado para verificar a revogação pode estar inacessível.
O certificado SSL contém um nome comum (CN) 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 do 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 de host e o nome de domínio do host do agente 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:

  assunto= /DC=nome/DC=novodomínio/CN=novonome/CN=novonomedohost.novodomínio.nome
  emissor = / DC = nome / DC = novo domínio / CN = novo nome do host / CN = novo nome do host.novo domínio.nome
  notBefore = 25 de março 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 de host não corresponderem, use uma das seguintes ações para resolver o problema:

  • Se o nome do host UNIX ou Linux estiver correto, mas o servidor de gerenciamento do Operations Manager estiver resolvendo 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, siga um destes 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 de host desejado.

  Para alterar o nome no certificado:

  Se o certificado tiver sido criado com um nome incorreto, você poderá alterar o nome de host e criar novamente 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 de domínio no certificado usando as -h opções e -d , 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 de hosts localizado no servidor de gerenciamento para fornecer a resolução de nome. O arquivo hosts está localizado na \Windows\System32\Drivers\etc pasta. Uma entrada no arquivo hosts é uma combinação do endereço IP e o 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 uma 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 usado para descoberta confiam no certificado uns dos outros servidores.

  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 a senha estão incorretos

Você pode ver o erro ao tentar descobrir agentes UNIX/Linux. A falha pode ocorrer durante a etapa de verificação do certificado durante a descoberta de uma máquina UNIX/Linux.

Possíveis causas:

• A autenticação básica é definida como false em um ou mais servidores de gerenciamento no pool de recursos do 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 a senha está incorreta.

Resolução

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

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

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 StdErr nos detalhes do erro para identificar a causa da falha. Verifique também a configuração de privilégios sudo para a conta usada para assinatura de certificado.

Erros de resolução de nomes de rede

O endereço de destino não pode ser resolvido

Esses problemas geralmente se enquadram em uma das seguintes categorias:

• Descrição do erro

  Falha ao resolver o endereço <IP 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 pode ser resolvido para um nome no DNS (pesquisa inversa).

  Resolução

  Para corrigir esse problema, corrija a configuração de resolução de nomes (DNS) para a zona de pesquisa inversa, certifique-se de que exista um endereço IP para mapeamento de nomes para o host afetado.

• Descrição do erro

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

  Causa

  Esse erro ocorrerá se um FQDN para o host tiver sido inserido para descoberta, mas o nome não puder ser resolvido para o endereço IP no DNS (pesquisa direta).

  Resolução

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

Configuração de DNS: a resolução DNS de encaminhamento não corresponde à resolução DNS reversa

Descrição do erro

Nessa situação, você normalmente recebe um erro semelhante 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 pela pesquisa inversa do endereço IP 192.168.x.x não correspondia ao nome do host fornecido. Verifique a configuração de DNS e repita a solicitação.

Causa

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

Resolução

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

O endereço de destino está inacessível

Descrição do erro

Nessa situação, você normalmente recebe um erro semelhante ao seguinte:

O cliente WinRM não pode concluir a operação no tempo especificado. Verifique se o nome do computador é válido, se ele pode ser acessado pela rede e se a exceção de firewall para o serviço Gerenciamento Remoto do Windows está habilitada.

Possíveis causas:

• O host está inacessível devido à resolução incorreta de nomes, interrupção da 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 executar ping no 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. Por favor, registre o relatório de bug - Nome do parâmetro: s

Descrição do erro

Tipo DiscoveryResult.ErrorData inesperado. Envie um relatório de bug.
ErrorData: System.ArgumentNullException
O valor não pode ser nulo.
Nome de parâmetro: s
em System.Activities.WorkflowApplication.Invoke (atividade de atividade, entradas IDictionary'2, extensões WorkflowInstanceExtensionManager, tempo limite de TimeSpan)
em System.Activities.WorkflowInvoker.Invoke (fluxo de trabalho da atividade, entradas IDictionary'2, tempo limite do TimeSpan, extensões WorkflowInstanceExtensionManager)
em Microsoft.SystemCenter.CrossPlatform.ClientActions.DefaultDiscovery.InvokeWorkflow(IManagedObject managementActionPoint, critérios DiscoveryTargetEndpoint, IInstallableAgents, installableAgents)

Causa

Esse erro ocorre porque as configurações de proxy WinHTTP foram definidas 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 FQDN do UNIX ou do Linux à lista de bypass de proxy WinHTTP.

Nos servidores de gerenciamento no pool de recursos UNIX ou Linux, execute o seguinte comando em um prompt de comando com privilégios elevados para verificar a configuração atual do proxy:

netsh winhttp show proxy

Se um servidor proxy WinHTTP estiver configurado, adicione o FQDN do servidor que você está tentando descobrir à 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, verifique se a descoberta do agente foi bem-sucedida.

Tipo discoveryResult.ErrorData inesperado. Por favor, registre o relatório de bug - Nome do parâmetro: lhs

Descrição do erro

Descoberta não bem-sucedida
Mensagem: Falha não especificada
Detalhes: tipo DiscoveryResult.ErrorData inesperado. Envie um relatório de bug.
ErrorData: System.ArgumentNullException
O valor não pode ser nulo.
Nome do parâmetro: lhs
em System.Activities.WorkflowApplication.Invoke (atividade de atividade, entradas IDictionary'2, extensões WorkflowInstanceExtensionManager, tempo limite de TimeSpan)
em System.Activities.WorkflowInvoker.Invoke (fluxo de trabalho da atividade, entradas IDictionary'2, tempo limite do TimeSpan, extensões WorkflowInstanceExtensionManager)
em Microsoft.SystemCenter.CrossPlatform.ClientActions.DefaultDiscovery.InvokeWorkflow(IManagedObject managementActionPoint, critérios DiscoveryTargetEndpoint, IInstallableAgents, installableAgents)

Causa

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

Resolução

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

C:\Arquivos de Programas\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 do System Center Operations Manager (SCOM).

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

Depois que eles forem movidos da pasta DownloadedKits , repita a descoberta. A descoberta deve ter sucesso agora.

Erros de conectividade SSH

Falha durante a descoberta de 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 pôde ser feita porque a máquina 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 de SSH. Código de saída: -1073479118

Descrição do erro

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

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 de SSH. Código de saída: 1

Descrição do erro

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

Causa

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

Resolução

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

Padrões: <username>!requiretty

Para obter mais informações, consulte Como configurar a elevação sudo e as chaves SSH.

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; Saia $EC'
Senha:
exit
su: senha incorreta
opsuser@lx1: ~> saída
logout

Causa possível

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

Resolução

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

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

• Descrição do erro

  Falha durante a descoberta de SSH. Código de saída: -2147221248
  Saída padrão:
  Erro padrão: Não foi possível chdir para o diretório inicial /home/username: Não existe esse arquivo ou diretório

  Causa

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

  Resolução

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

• Descrição do erro

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

  Causa

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

  Resolução

  Revise 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: Acesso 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 configuração incorreta do PAM no lado do 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 sudo foi configurada corretamente.

3. Verifique também o log de mensagens no computador UNIX/Linux. Por exemplo, no AIX, é possível localizar o log em /var/adm/messages. Em outros sistemas operacionais, a localização pode variar.

   Procure linhas como as seguintes:

   3 de setembro 14:49:07 autenticação do servidor | segurança: debug / opt / microsoft / scx / bin / omiserver PAM: pam_authenticate: erro Falha na autenticação.

   Se você vir linhas semelhantes no log de mensagens, isso significa que o arquivo de configuração do PAM não tem informações sobre o OMIServer. O arquivo de configuração do 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 do PAM é reinstalar o agente SCX do zero nesse computador. Se isso não for facilmente possível, você poderá copiar as linhas pertencentes ao OMI de um computador em funcionamento para o computador que não está funcionando.

WSMan apenas a descoberta falhou 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 está inacessível, um firewall baseado em rede ou host está impedindo a conectividade ou o agente UNIX/Linux está inativo 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 está 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 no(s) objeto(s) 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 do 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 Servidores UNIX/Linux no painel Administração do console de Operações.

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

Descrição do erro

Não foi possível localizar uma instância de agente com suporte correspondente nos pacotes de gerenciamento importados. Importe os Pacotes de Gerenciamento desta plataforma para descobrir este computador.

Possíveis causas:

• O host de destino está executando um sistema operacional incompatível.
• 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 compatível.
• 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 pode estar carregando. Aguarde alguns minutos e execute novamente a descoberta.

Não é possível enumerar os tipos de agentes instaláveis. O pool de recursos associado ainda pode estar sendo inicializado

Descrição do erro

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

Possíveis causas:

• O pool de recursos usado na descoberta não está íntegro, 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, repita a descoberta após alguns minutos para permitir que o pool seja inicializado. Caso contrário, verifique o Log de Eventos do Operations Manager nos servidores que são membros do Pool de Recursos usado para descoberta para obter indicações da origem do problema.

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

Descrição do erro

Mensagem: Não é possível copiar o 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) causou a falha do comando SSH

Causa

Incompatibilidade de versões do agente de arquivos entre o banco de dados e o repositório do agente.

Resoluções

• Verifique se todos os agentes com falha estão 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 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 dos arquivos 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 o Suporte da Microsoft.