NRPE no puede leer la salida, pero ¿por qué?

27

Tengo este problema con NRPE, todo lo que he encontrado hasta ahora en la red parece señalarme cosas que ya he probado.

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

da

NRPE v2.12

como se esperaba.

Ejecutar el comando a mano (como se define en nrpe.cfg en "nrpeclient", da la respuesta esperada

nrpe.cfg:

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

"Expected response"

Pero si trato de ejecutar el comando desde el servidor Nagios me sale lo siguiente:

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

¿Alguien puede pensar en otro lugar donde podría haber cometido un error con esto? He hecho lo mismo en muchos otros servidores sin ningún problema. La única diferencia que puedo pensar con esto es que esta caja está basada en RHEL 5, mientras que las otras están basadas en RHEL 4.

Esos dos bits anteriores que he probado son lo que la mayoría de las personas parecen sugerir cuando las personas han tenido este problema.

Debo mencionar que me sale un error extraño en los registros cuando reinicio 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

Aunque, simplemente está leyendo ese /usr/local/nagios/etc/nrpe.cfgarchivo para obtener las cosas de las que habla más abajo ...

nagios nrpe ticktockhouse
fuente
posible duplicado de NRPE no puede leer la salida, pero ¿por qué?
mailq
Mantengamos este, ya que el otro estaba cerrado.
Bart De Vos
Además, asegúrese de que STDOUT esté realmente enjuagado.

Respuestas:

35

Tienes un problema de derechos.

Cambie el comando a:

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

(agregar sudo)

Luego, agregue el usuario nagios a los sudoers:

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

O podrías simplemente modificar el archivo ... Eso también funciona.

Si está utilizando CentOS, Red Hat, Scientific o Fedora, asegúrese de desactivarlo Defaults requirettyen el archivo sudoers.

Bart De Vos
fuente
1
@Bart De Vos, pero la respuesta que agregó hará un agujero de seguridad> agregar algo al archivo sudoers lo abrirá para un posible riesgo de seguridad. es decir, si a través de un desbordamiento de búfer, alguien puede soltar un archivo con el mismo nombre en la misma ubicación, podría ejecutarlo sin conocer la contraseña de root y obtener el control del cuadro: S ¿No hay forma de poner una firma de alguna manera (SHA1 o MD5) de la aplicación en el archivo sudoers para evitar ese tipo de ataque. es decir, el archivo inyectado no tendrá la misma firma y, por lo tanto, no se ejecutará. [Lea el primer comentario aquí] ( crashatau.blogspot.co
Ahmad Hajjar
1
@ X-Ware: Si bien esto es cierto, la posibilidad de que se pueda abusar de un desbordamiento del búfer aquí es muy pequeña. Sin embargo, para evitar que ocurra, debe usar apparmor / SELinux. Por eso existen estas cosas.
Bart De Vos
Supongo que diferentes distribuciones incluso tienen diferentes usuarios, en mi caso, el usuario para agregar a visudo era npre no nagios. Todavía seguí la solución de Bart De Vos, sin embargo, puede ver qué usuario está intentando acceder al comando nrpe al ver el registro de acceso / var / log / secure. 24 de julio 15:39:09 nombre de host sudo: nrpe: usuario NO en sudoers; TTY = desconocido; PWD = /; USUARIO = raíz; COMANDO = / usr / lib64 / nagios / plugins / check_disk -w 20% -c 10% -p / dev / mapper / vg_uxp-lv_root
@AhmadHajjar ¿Hablas en serio? Cree que alguien hackeará nagios (un sistema que tiene 20 años) y usará a ese usuario para ejecutar un archivo con permisos de root. ¿Y cree que no hice que el ejecutable se ejecute como root como de solo lectura para evitar que alguien copie un archivo sobre él? Si le preocupa, en lugar de usar sudo, puede configurar el ejecutable check_openmanage y dejar que cualquiera lo ejecute.
Evan Langlois
11

Respuesta corta: si está usando un complemento Bash, asegúrese de tener un shebang que indique qué intérprete debe usarse:#!/bin/bash

Estaba enfrentando el mismo problema con un complemento de Nagios que escribí yo mismo. El script se ejecutó como se esperaba cuando se lanzó localmente, incluso cuando se ejecutaba como usuario nagioscon la siguiente instrucción:

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

Pero el lanzamiento remoto utilizando NRPE desde el servidor Nagios3 no tuvo éxito:

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

Finalmente resolví este caso agregando un shebang en mi script, ya que parecía que ejecutar el script a través de NRPE no usaba el mismo intérprete que cuando se ejecutaba sudo sudo -s -u nagios.

Mickaël Le Baillif
fuente
Tuve este problema al usar un complemento nagios de script ruby ​​con rbenv. La solución fue crear un script de envoltura con#!/bin/bash -el eval "$(rbenv init -)" /usr/lib/nagios/plugins/check_something $@
TrinitronX
1
respuesta asombrosa! sudo -s -u nagios me permitió ver por qué nagios no podía devolver la salida de un complemento específico. ¡Muchas gracias!
Ufk
6

En mi caso, el problema era simplemente: el usuario nagios no pudo ejecutar el script. Después de chmod comenzó a funcionar. Sudo no es necesario. Es incluso malvado :)

bluszcz
fuente
1
La verdadera respuesta es esta. Nagios no pudo ejecutar el script, ya sea debido a los malos permisos, el script está mal escrito o el script no está allí.
Droope
5

check_nrpe estaba obteniendo 'NRPE: no se puede leer la salida' a pesar de que el cheque funcionaba localmente porque el complemento que estaba usando no funcionaba bien con SELinux. Deshabilítelo y asegúrese de eliminar los contextos del archivo:

$ 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
Laboratorios AX
fuente
aunque deshabilitar selinux en general puede no ser una buena idea para probar esto, aún es válido.
Dennis Nolte
4

Verifique rutas, permisos, selinux, iptables.

El mío fue un problema de ruta en el cliente: nrpe.cfg, verifique la ruta del comando al nombre del complemento check_ *. Estos pueden ser confusos, (lib / local) (libexec / plugins) como un nombre de ruta. Tiró por error y puse los caminos del archivo ngpe cfg preempaquetado comentado para hacer comandos. La instalación del complemento make install o yum los coloca en un directorio difft.

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

versus

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

Desde el servidor pude confirmar que no se trataba de un problema de firewall, podía hacer telnet al puerto 5666, podía ejecutar un check_nrpe general y obtener el estado como valor de retorno. Podría ejecutar los comandos localmente pero nrpe tenía la ruta incorrecta en el cliente en el nrpe.cfg.

Hola Mundo
fuente
4

En mi caso, solo un complemento falló mientras que otros funcionaron bien. Resultó ser un problema LOCALE.

El complemento fue check_mem.shy realizó un grep para Memla salida de free. Pero el sistema LOCALE regresó Speicher(alemán) en lugar de Mem, por lo que todos los valores recibidos eran cadenas vacías.

Prisa
fuente
2
Rush, bienvenido a SF! Esta es una excelente primera respuesta, en mi opinión: breve, al punto, y agrega algo nuevo a la colección de respuestas que ya están aquí. +1 de mi parte, y espero leer más de esas respuestas en el futuro (espero que perdones mi pequeña edición de formato).
MadHatter apoya a Monica
2

Este es un problema de permiso, solo dale a la ejecución del script correctamente y estará bien:

Aquí un ejemplo: 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

Después: 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 resuelto.

Youssef ASEBRIY
fuente
1
Buena respuesta, pero también es bueno tener en cuenta que permitir que todos los usuarios ejecuten check_nrpe, como lo hace chmod o + x, podría ser un riesgo de seguridad potencial, dependiendo de cómo se configure / acceda / use el sistema.
austinian
1

En mi caso, el archivo de registro que se está monitoreando era propiedad de root: adm, por lo que agregar el usuario nagios al grupo adm hizo que el comando check_log tuviera éxito, pero solo cuando se ejecuta directamente en los hosts monitoreados. Continuó fallando usando check_nrpe en el servidor Nagios hasta que reinicié el servicio nagios-nrpe-server en los hosts monitoreados, por ej.

service nagios-nrpe-server restart

Aparentemente, era necesario reiniciar el servicio para que el cambio de permisos entrara en vigencia para NRPE, pero me tomó un tiempo resolver esto.

Tony
fuente
1

En el caso de complementos personalizados de NRPE, asegúrese de imprimir algunos resultados junto con el valor de salida. Si no hay salida del script, NRPE se quejará diciendo "NRPE no puede leer la salida" . Puede habilitar la depuración en nrpe.cfg y observar este error.

Karthik
fuente
1

En mi caso, los problemas estaban relacionados con selinux (ejecutando RHEL 6.5, selinux está configurado para hacer cumplir).

La instalación de nagios-plugins- * a través de yum creará sus archivos de complemento en / usr / lib64 / nagios / plugins. Si marca el fcontext en esos archivos de complemento (ls -lZ), verá que los archivos tienen el tipo de contexto establecido en "nagios_system_plugin_exec_t", que es el tipo de contexto que check_nrpe espera.

En mi caso, había creado un script personalizado "check_mem.sh" usando "vi". El archivo resultante tenía el tipo de contexto establecido en "lib_t". Esto causaba que nrpe produjera el "NRPE: no se puede leer la salida".

Cambiar el contexto del archivo a "nagios_system_plugin_exec_t" resolvió el problema:

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

La solución de problemas habitual de selinux también me habría señalado este problema (marcando /var/log/audit/audit.log), pero por supuesto fue lo último en lo que pensé

Editar: chcon solo cambia temporalmente el contexto. Para cambiarlo 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

Alexandru Todicescu
fuente
0

Es posible que no haya instalado sus complementos de Nagios, NRPE no puede encontrarlos ni acceder a ellos.

Nunca he tenido que agregar mis comandos a Sudoers. Asegúrese de que los comandos sean propiedad del usuario de Nagios y que sean legibles.

Daniel Baker
fuente
0

Creo que debe agregar los complementos en su directorio local /usr/lib64/nagios/plugins/*. Tuve el mismo problema que tú y puedo resolverlo con esta solución.

Tarik Nasser
fuente
0

Tuve el problema que escribes. La prueba que hice fue de perl. Pon esta línea en el archivo /etc/nagios/nrpe.cfgpara que funcione.

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

Hay un artículo realmente bueno que cubre toda la instalación y configuración del agente NRPE con muchos ejemplos de check_commands. Utilizo este artículo cuando necesito instalar NRPE en un nuevo servidor. Más que eso, al final de la página puede encontrar una secuencia de comandos genial que instala y configura automáticamente NRPE para usted (según las variables que establezca), puede encontrar el artículo: aquí

Itai Ganot
fuente
El enlace ha sido actualizado
Itai Ganot
0

Esto suele suceder cuando el servidor NRPE se inicia con el usuario nrpe, en lugar de nagios.

Cambiar el nrpe_uservalor a nagios en el /etc/nagios/nrpe.cfgarchivo debería resolver su problema.

También nrpe_groupse puede cambiar si es necesario.

Umut Uzun
fuente
0

Otra cosa a verificar es que si su comando está usando sudo -u <another user>para ejecutar el comando, libexecel usuario (a los directorios que están encima) deben poder leerlo.

Por ejemplo, si su comando es:

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

El usuario de tomcat debe poder acceder a ese archivo.

Una forma de arreglar esto sería:

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

Reemplazar la última parte por donde vivan tus ejecutables

Mitch
fuente
0

Tuve el mismo problema y logré resolverlo matando el proceso de nagios (en la máquina monitoreada):

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

Todo salió bien después de eso.

usuario428879
fuente
0

Acabo de tener este problema en FreeBSD. Después de golpear mi cabeza contra la pared durante una hora, me di cuenta de que el problema era que /usr/local/nagios/etc/nrpe.cfgestaba apuntando a la ubicación incorrecta para sudo.

Para encontrar la ubicación correcta a la que apuntar el comando sudo, ejecute:

# whereis sudo

Luego cambié el comando_prefijo en nrpe.cfg de:

command_prefix=/usr/local/sudo

a:

command_prefix=/usr/local/bin/sudo

Luego corrió service nrpe restarty el problema se resolvió.

Podría ser un problema similar en otros sistemas operativos, solo otra cosa que debe verificar si ha verificado todos los otros posibles problemas de permisos y aún tiene este problema.

Graeme
fuente
-2

Tuve este problema y resolví deshabilitar el selinux

setenforce 0

Paulo Azedo
fuente
2
Bienvenido a la falla del servidor. ¿Puede proporcionar más detalles explicando cómo / por qué funciona esto?
Digo reinstalar a Mónica