NRPE incapaz de ler a saída, mas por quê?

Question

Eu tenho esse problema com o NRPE, todas as coisas que eu encontrei até agora na net parecem apontar para as coisas que eu já tentei.

# /usr/local/nagios/plugins/check_nrpe -H nrpeclient

dá

NRPE v2.12

como esperado.

Executar o comando manualmente (conforme definido em nrpe.cfg em "nrpeclient", fornece a resposta esperada

nrpe.cfg:

command[check_openmanage]=/usr/lib/nagios/plugins/additional/check_openmanage -s -e   -b ctrl_driver=0 bat_charge

"Expected response"

Mas se eu tentar executar o comando do servidor Nagios, recebo o seguinte:

# /usr/local/nagios/plugins/check_nrpe -H comxps -c check_openmanage
NRPE: Unable to read output

Alguém pode pensar em qualquer outro lugar que eu poderia ter cometido um erro com isso? Eu fiz a mesma coisa em vários outros servidores sem nenhum problema. A única diferença com a qual posso pensar é que essa caixa é baseada no RHEL 5, enquanto as outras são baseadas no RHEL 4.

Esses dois bits acima que testei são o que a maioria das pessoas parece sugerir quando as pessoas tiveram esse problema.

Devo mencionar que recebo um erro estranho nos logs quando reinicio o nrpe :

nrpe[14534]: Unable to open config file '/usr/local/nagios/etc/nrpe.cfg' for reading 
nrpe[14534]: Continuing with errors...
nrpe[14535]: Starting up daemon
nrpe[14535]: Warning: Daemon is configured to accept command arguments from clients!
nrpe[14535]: Listening for connections on port 5666 
nrpe[14535]: Allowing connections from: bodbck,combck,nam-bck

Mesmo assim, está claramente lendo o arquivo /usr/local/nagios/etc/nrpe.cfg para fazer com que as coisas sobre as quais ele está falando continuem ...

    

Answer 1

Você tem um problema de direitos.

Altere o comando para:

command[check_openmanage]=sudo /usr/lib/nagios/plugins/additional/check_openmanage -s -e -b ctrl_driver=0 bat_charge

(adicione sudo)

Em seguida, adicione o nagios-user aos sudoers:

nagios ALL=(ALL) NOPASSWD:/usr/lib/nagios/plugins/additional/check_openmanage

Ou você pode apenas chmod o arquivo ... Isso também funciona.

Se você estiver usando o CentOS, Red Hat, Scientific ou Fedora, certifique-se de desabilitar Defaults requiretty no arquivo sudoers.

    

Answer 2

Resposta curta: se você estiver usando um plug-in do Bash, certifique-se de ter um shebang informando qual interpretador deve ser usado: #!/bin/bash

Eu estava enfrentando o mesmo problema com um plugin do Nagios que eu mesmo escrevi. O script estava sendo executado como esperado quando lançado localmente, mesmo quando executado como usuário nagios usando a seguinte instrução:

$ sudo sudo -s -u nagios
$ /path/to/my/plugin.sh
STATUS: OK

Mas o lançamento remoto usando o NRPE do servidor Nagios3 não teve sucesso:

$ /usr/lib/nagios/plugins/check_nrpe -H my-nagios-client -c my_plugin
NRPE: Unable to read output

Eu finalmente resolvi esse caso adicionando um shebang no meu script, como parecia que executar o script por meio do NRPE não usava o mesmo interpretador que ao executar sudo sudo -s -u nagios .

    

Answer 3

No meu caso, o problema era simplesmente - o usuário nagios não conseguia executar o script. Depois do chmod, começou a funcionar. Sudo não é necessário. É mesmo mal:)

    

Answer 4

check_nrpe estava recebendo 'NRPE: não é possível ler a saída' apesar de a verificação funcionar localmente porque o plug-in que eu estava usando não funcionava bem com o SELinux. Desative e certifique-se de remover os contextos do arquivo:

$ ls -l check_om_storage
-r-xr-xr--. 1 root nrpe 3808 Feb 27 17:54 check_om_chassis
$ setfattr -x security.selinux check_om_storage
$ ls -l check_om_chassis 
-r-xr-xr-- 1 root nrpe 3808 Feb 27 17:54 check_om_chassis

    

Answer 5

Verifique o pathing, permissões, selinux, iptables.

O meu foi um problema de pathing no cliente: nrpe.cfg, verifique novamente o caminho do comando para o nome do plugin check_ *. Estes podem ser confusos, (lib / local) (libexec / plugins) como um nome de caminho. Eu erroneamente arrancou e colocou os caminhos do arquivo nrpe cfg pré-empacotado comentado para fazer comandos. A instalação do make install ou do yum coloca isso em um diretório difft.

commaneted: / usr / local / nagios / libexec / check_disk

versus

realpath: / usr / lib / nagios / plugins / check_disk

Do servidor eu pude confirmar que não era um problema de firewall, podia fazer telnet para a porta 5666, poderia executar um check_nrpe geral e obter o status como um valor de retorno. Poderia executar os comandos localmente, mas o nrpe tinha o caminho errado no cliente no nrpe.cfg.

    

Answer 6

No meu caso, apenas um plugin falhou enquanto vários outros funcionavam bem. Acabou sendo um problema de LOCALE.

O plug-in foi check_mem.sh e executou um grep para Mem na saída de free . Mas o LOCALE em todo o sistema retornou Speicher (alemão) em vez de Mem , portanto, todos os valores recebidos eram sequências vazias.

    

Answer 7

Este é um problema de permissão, apenas forneça a execução do script correta e tudo ficará bem:

aqui um exemplo: Antes / host remoto :

[root@puppet1 nrpe.d]# ls -l /usr/lib/nagios/plugins/check_mem.sh
-rwxr--r-- 1 root root 1598 Jul  7 10:55 /usr/lib/nagios/plugins/check_mem.sh

servidor NRPE :

[root plugins]# ./check_nrpe -H 172.19.9.200 -c check_mem_vb
NRPE: Unable to read output

Depois: Host remoto :

[root@puppet1 plugins]# chmod o+x /usr/lib/nagios/plugins/check_mem.sh

[root plugins]# ./check_nrpe -H 172.19.9.200 -c check_mem_vb
Memory: OK Total: 1980 MB - Used: 139 MB - 6% used|Total=2076479488;;;Used=145076224;;;Cache=1528111104;;Buffer=211890176;;;

Problema resolvido.

    

Answer 8

No meu caso, o arquivo de log sendo monitorado era de propriedade de root: adm, então adicionar o usuário nagios ao grupo adm tornava o comando check_log bem-sucedido, mas apenas quando executado diretamente nos hosts monitorados. Ele continuou a falhar usando check_nrpe no servidor Nagios até que reiniciei o serviço nagios-nrpe-server nos hosts monitorados, por exemplo

service nagios-nrpe-server restart

Então, aparentemente, o reinício do serviço era necessário para que a alteração das permissões fizesse efeito para o NRPE, mas demorei um pouco para descobrir isso.

    

Answer 9

No caso de plugins NRPE personalizados, certifique-se de imprimir alguma saída junto com o valor de saída. Se não houver saída do script, o NRPE reclamará dizendo "NRPE não é possível ler a saída" . Você pode ativar a depuração em nrpe.cfg e observar este erro.

    

Answer 10

No meu caso, os problemas estavam relacionados ao selinux (executando o RHEL 6.5, o selinux está configurado para impor).

Instalar o nagios-plugins- * via yum criará seus arquivos de plugin em / usr / lib64 / nagios / plugins. Se você verificar o fcontext nesses arquivos de plug-in (ls -lZ), verá os arquivos com o tipo de contexto configurado como "nagios_system_plugin_exec_t", que é o tipo de contexto que o check_nrpe espera.

No meu caso, eu criei um script personalizado "check_mem.sh" usando "vi". O arquivo resultante tinha o tipo de contexto definido como "lib_t". Isso estava causando nrpe para a saída "NRPE: não é possível ler saída".

A alteração do contexto do arquivo para "nagios_system_plugin_exec_t" resolveu o problema:

chcon -t nagios_system_plugin_exec_t /usr/lib64/nagios/plugins/check_mem.sh

A solução usual de selinux também teria me apontado para esse problema (verificando /var/log/audit/audit.log), mas foi, naturalmente, a última coisa que pensei sobre

Edit: chcon apenas muda temporariamente o contexto. Para mudá-lo persistentemente, use semanage fcontext -a -t nagios_system_plugin_exec_t /usr/lib64/nagios/plugins/check_mem.sh restorecon -vF /usr/lib64/nagios/plugins/check_mem.sh

    

Answer 11

Pode ser que você não tenha instalado seus plug-ins do Nagios, o NRPE não possa encontrá-los ou acessá-los.

Nunca precisei adicionar meus comandos para Sudoers. Certifique-se de que os comandos sejam de propriedade do usuário Nagios e que eles sejam legíveis.

    

Answer 12

Acho que você deve adicionar os plugins em sua pasta local /usr/lib64/nagios/plugins/* . Eu tive o mesmo problema que você e posso resolvê-lo com esta solução.

    

Answer 13

Eu tive o problema que você escreveu. O teste que eu fiz foi do perl. Coloque esta linha no arquivo /etc/nagios/nrpe.cfg para que funcione.

command [check_memory] = /usr/bin/perl /usr/lib64/nagios/plugins/check_memory -w 75-c 90 

    

Answer 14

Há um artigo muito legal que cobre toda a instalação e configuração do agente NRPE com muitos exemplos de check_commands. Eu uso este artigo sempre que preciso instalar o NRPE em um novo servidor. Mais do que isso, no final da página você pode encontrar um script legal que instala e configura automaticamente o NRPE para você (com base nas variáveis que você definir), o artigo pode ser encontrado: aqui

    

Answer 15

Isso geralmente acontece quando o servidor NRPE é iniciado com o nrpe do usuário, em vez de nagios.

A alteração do valor de nrpe_user em nagios no arquivo /etc/nagios/nrpe.cfg deve resolver seu problema.

O nrpe_group também pode ser alterado, se necessário.

    

Answer 16

Uma outra coisa a verificar é que, se o seu comando estiver usando sudo -u <another user> para executar o comando, o diretório libexec (e os diretórios acima dele) devem ser legíveis pelo usuário que está sendo sudoed.

Por exemplo, se o seu comando for:

command[check_tomcat]=sudo -u tomcat /usr/local/nagios/libexec/check_tomcat ...

O usuário do tomcat deve poder acessar esse arquivo.

Uma maneira de corrigir isso seria:

chmod 0775 /usr/local/nagios/
chmod 0755 /usr/local/nagios/libexec

Substituindo a última parte por onde quer que seus executáveis estejam

    

Answer 17

Eu tive o mesmo problema e consegui resolvê-lo matando o processo nagios (na máquina monitorada):

ps -ef | grep nagios
kill -9 [NagiosProcessNumber]
/etc/init.d/nagios-nrpe-server start

Tudo correu bem depois disso.

    

Answer 18

Acabou de ter esse problema no FreeBSD. Depois de bater minha cabeça contra uma parede por uma hora, percebi que o problema era que o /usr/local/nagios/etc/nrpe.cfg estava apontando para o local errado para o sudo.

Para encontrar o local correto para o comando sudo:

# whereis sudo

Eu então alterei o command_prefix em nrpe.cfg de:

command_prefix=/usr/local/sudo

para:

command_prefix=/usr/local/bin/sudo

Em seguida, executei service nrpe restart e o problema foi resolvido.

Pode ser um problema semelhante em outros sistemas operacionais, apenas outra coisa é verificar se você verificou todos os outros possíveis problemas de permissões e se ainda assim ocorreu esse problema.

    

Answer 19

A falta de plug-ins do Nagios no cliente nrpe.

Não use o yum install nagios-plugins (nagios-plugins-2.0.3-1.el6.x86_64). Não instala todos os plugins. Faça o download do nagios-plugins-1.4.11.tar.gz e siga as instruções deste documento.

link

    

Answer 20

Eu tive esse problema e resolvi desativar o selinux

setenforce 0