NRPE incapable de lire la sortie, mais pourquoi?

27

J'ai ce problème avec NRPE, tout ce que j'ai trouvé jusqu'à présent sur le net me semble indiquer des choses que j'ai déjà essayées.

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

donne

NRPE v2.12

comme prévu.

L'exécution manuelle de la commande (telle que définie dans nrpe.cfg sur "nrpeclient", donne la réponse attendue

nrpe.cfg:

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

"Expected response"

Mais si j'essaie d'exécuter la commande à partir du serveur Nagios, j'obtiens ce qui suit:

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

Quelqu'un peut-il penser à un autre endroit où j'aurais pu me tromper? J'ai fait la même chose sur plusieurs autres serveurs sans problème. La seule différence à laquelle je peux penser est que cette boîte est basée sur RHEL 5, tandis que les autres sont basées sur RHEL 4.

Ces deux bits ci-dessus que j'ai testés sont ce que la plupart des gens semblent suggérer lorsque les gens ont eu ce problème.

Je dois mentionner que j'obtiens une erreur étrange dans les journaux lorsque je redémarre 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

Même s'il lit simplement ce /usr/local/nagios/etc/nrpe.cfgfichier pour obtenir les informations dont il parle plus bas.

nagios nrpe ticktockhouse
la source
possible doublon de NRPE incapable de lire la sortie, mais pourquoi?
mailq
Gardons celui-ci, puisque l'autre était fermé.
Bart De Vos
Assurez-vous également que STDOUT est réellement vidé.

Réponses:

35

Vous avez un problème de droits.

Modifiez la commande en:

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

(ajouter sudo)

Ensuite, ajoutez l'utilisateur nagios aux sudoers:

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

Ou vous pouvez simplement modifier le fichier ... Cela fonctionne également.

Si vous utilisez CentOS, Red Hat, Scientific ou Fedora, assurez-vous de désactiver Defaults requirettydans le fichier sudoers.

Bart De Vos
la source
1
@Bart De Vos, mais la réponse que vous avez ajoutée créera une faille de sécurité> l'ajout de quelque chose au fichier sudoers vous ouvrira à un risque de sécurité potentiel. c'est-à-dire que si, via un dépassement de tampon, quelqu'un est capable de déposer un fichier du même nom au même emplacement, il pourrait l'exécuter sans connaître le mot de passe root et prendre le contrôle de la boîte: S N'y a-t-il aucun moyen de mettre une signature (SHA1 ou MD5) de l'application dans le fichier sudoers pour empêcher ce type d'attaque. c'est-à-dire que le fichier injecté n'aura pas la même signature et ne s'exécute donc pas. [Lire le premier commentaire ici] ( crashatau.blogspot.co
Ahmad Hajjar
1
@ X-Ware: Bien que cela soit vrai, les chances qu'un débordement de tampon puisse être abusé ici sont très minces. Pour éviter que cela ne se produise cependant, vous devez utiliser apparmor / SELinux. Voilà pourquoi ces choses existent.
Bart De Vos
Je suppose que différentes distributions ont même des utilisateurs différents, dans mon cas, l'utilisateur à ajouter à visudo n'était pas nagios. J'ai toujours suivi la solution de Bart De Vos, mais vous pouvez voir quel utilisateur essaie d'accéder à la commande nrpe en affichant le journal d'accès / var / log / secure. 24 juillet 15:39:09 nom d'hôte sudo: nrpe: utilisateur NON dans sudoers; ATS = inconnu; PWD = /; USER = root; COMMANDE = / usr / lib64 / nagios / plugins / check_disk -w 20% -c 10% -p / dev / mapper / vg_uxp-lv_root
@AhmadHajjar Êtes-vous sérieux? Vous pensez que quelqu'un piratera nagios (un système qui a 20 ans) et utilisera cet utilisateur pour exécuter un fichier avec les autorisations root. ET vous pensez que je n'ai pas fait exécuter l'exécutable en tant que root en lecture seule pour empêcher quelqu'un de copier un fichier dessus? Si cela vous inquiète, au lieu d'utiliser sudo, vous pouvez définir l'exécutable check_openmanage lui-même et laisser quiconque l'exécuter!
Evan Langlois
11

Réponse courte: si vous utilisez un plugin Bash, assurez-vous d'avoir un shebang indiquant quel interprète doit être utilisé:#!/bin/bash

J'étais confronté au même problème avec un plugin Nagios que j'ai écrit moi-même. Le script s'exécutait comme prévu lors de son lancement local, même lors de son exécution en tant qu'utilisateur à l' nagiosaide de l'instruction suivante:

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

Mais le lancement à distance à l'aide de NRPE à partir du serveur Nagios3 a échoué:

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

J'ai finalement résolu ce cas en ajoutant un shebang dans mon script, car il semblait que l'exécution du script via NRPE n'utilisait pas le même interpréteur que lors de l'exécution sudo sudo -s -u nagios.

Mickaël Le Baillif
la source
J'ai eu ce problème lors de l'utilisation d'un plugin nagios de script ruby ​​avec rbenv. Le correctif consistait à créer un script wrapper avec#!/bin/bash -el eval "$(rbenv init -)" /usr/lib/nagios/plugins/check_something $@
TrinitronX
1
réponse incroyable! sudo -s -u nagios m'a permis de voir pourquoi nagios ne pouvait pas retourner la sortie d'un plugin spécifique. Merci beaucoup!
2015
6

Dans mon cas, le problème était simplement - l'utilisateur nagios n'était pas en mesure d'exécuter le script. Après chmod, cela a commencé à fonctionner. Sudo n'est pas nécessaire. C'est même mal :)

bluszcz
la source
1
La vraie réponse est la suivante. Nagios n'a pas pu exécuter le script, en raison de mauvaises autorisations, d'une mauvaise orthographe du script ou de l'absence du script.
droope
5

check_nrpe obtenait 'NRPE: Impossible de lire la sortie' malgré le fait que la vérification fonctionnait localement parce que le plugin que j'utilisais ne fonctionnait pas bien avec SELinux. Désactivez-le et assurez-vous de supprimer les contextes du fichier:

$ 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
AX Labs
la source
Bien que la désactivation de selinux ne soit généralement pas une bonne idée pour tester, cela reste valable à mon humble avis.
Dennis Nolte
4

Vérifiez le chemin, les autorisations, selinux, iptables.

Le mien était un problème de cheminement dans le client: nrpe.cfg, revérifiez le chemin de la commande jusqu'au nom du plugin check_ *. Ceux-ci peuvent être source de confusion, (lib / local) (libexec / plugins) en tant que chemin d'accès. J'ai par erreur tiré et mis les chemins du fichier cfg nrpe préemballé commenté pour faire des commandes. L'installation du plugin make install ou yum les place dans un répertoire difft.

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

contre

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

À partir du serveur, j'ai pu confirmer qu'il ne s'agissait pas d'un problème de pare-feu, pouvait telnet au port 5666, pouvait exécuter une vérification check_nrpe et obtenir le statut comme valeur de retour. Pourrait exécuter les commandes localement mais nrpe avait le mauvais chemin sur le client dans le nrpe.cfg.

Bonjour le monde
la source
4

Dans mon cas, un seul plugin a échoué tandis que plusieurs autres fonctionnaient bien. Cela s'est avéré être un problème LOCAL.

Le plugin était check_mem.shet il a effectué une grep for Memdans la sortie de free. Mais LOCALE à l'échelle du système a renvoyé Speicher(allemand) au lieu de Mem, donc toutes les valeurs reçues étaient des chaînes vides.

se ruer
la source
2
Rush, bienvenue à SF! C'est une excellente première réponse, à mon avis: bref, au point, et cela ajoute quelque chose de nouveau à la collection de réponses déjà ici. +1 de ma part, et j'espère lire plus de ces réponses de votre part à l'avenir (j'espère que vous pardonnerez ma petite modification de mise en forme).
MadHatter prend en charge Monica le
2

C'est un problème de permission, donnez juste le droit d'exécution du script et ça ira:

voici un exemple: Avant / Hôte distant :

[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

Serveur NRPE :

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

Après: hôte distant :

[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;;;

Problème résolu.

Youssef ASEBRIY
la source
1
Bonne réponse, mais il est également bon de noter que permettre à tous les utilisateurs d'exécuter check_nrpe, comme le fait chmod o + x, pourrait être un risque de sécurité potentiel, selon la façon dont le système est configuré / accédé / utilisé.
austinian
1

Dans mon cas, le fichier journal surveillé appartenait à root: adm, donc l'ajout de l'utilisateur nagios au groupe adm a fait réussir la commande check_log, mais uniquement lorsqu'elle était exécutée directement sur les hôtes surveillés. Il a continué d'échouer en utilisant check_nrpe sur le serveur Nagios jusqu'à ce que je redémarre le service nagios-nrpe-server sur les hôtes surveillés, par exemple

service nagios-nrpe-server restart

Donc, apparemment, le redémarrage du service était nécessaire pour que la modification des autorisations prenne effet pour NRPE, mais il m'a fallu un certain temps pour comprendre cela.

Tony
la source
1

Dans le cas de plugins NRPE personnalisés, assurez-vous d'imprimer une sortie avec la valeur de sortie. S'il n'y a pas de sortie du script, NRPE se plaindra en disant "NRPE incapable de lire la sortie" . Vous pouvez activer le débogage dans nrpe.cfg et observer cette erreur.

Karthik
la source
1

Dans mon cas, les problèmes étaient liés à selinux (en exécutant RHEL 6.5, selinux est configuré pour être appliqué).

L'installation de nagios-plugins- * via yum créera vos fichiers de plug-in dans / usr / lib64 / nagios / plugins. Si vous vérifiez le fcontext sur ces fichiers de plug-in (ls -lZ), vous verrez que les fichiers ont le type de contexte défini sur "nagios_system_plugin_exec_t", qui est le type de contexte que check_nrpe attend.

Dans mon cas, j'avais créé un script personnalisé "check_mem.sh" en utilisant "vi". Le fichier résultant avait le type de contexte défini sur "lib_t". Cela provoquait la sortie par nrpe du "NRPE: Impossible de lire la sortie".

Changer le contexte du fichier en "nagios_system_plugin_exec_t" a résolu le problème:

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

Le dépannage habituel de selinux m'aurait également signalé ce problème (vérification de /var/log/audit/audit.log), mais c'était bien sûr la dernière chose à laquelle j'ai pensé

Edit: chcon change juste temporairement le contexte. Pour le changer de façon persistante, utilisez 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
la source
0

Il se peut que vous n'ayez pas installé vos plugins Nagios, NRPE ne peut pas les trouver ou y accéder.

Je n'ai jamais eu à ajouter mes commandes aux Sudoers. Assurez-vous que les commandes appartiennent à l'utilisateur Nagios et qu'elles sont lisibles.

Daniel Baker
la source
0

Je pense que vous devez ajouter les plugins dans votre répertoire local /usr/lib64/nagios/plugins/*. J'ai eu le même problème que vous et je peux le résoudre avec cette solution.

Tarik Nasser
la source
0

J'ai eu le problème que vous écrivez. Le test que j'ai effectué était de perl. Mettez cette ligne dans le fichier /etc/nagios/nrpe.cfgpour le faire fonctionner.

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

Il y a un très bel article qui couvre toute l'installation et la configuration de l'agent NRPE avec de nombreux exemples check_commands, j'utilise cet article chaque fois que j'ai besoin d'installer NRPE sur un nouveau serveur. Plus que cela, à la fin de la page, vous pouvez trouver un script sympa qui installe et configure automatiquement NRPE pour vous (en fonction des variables que vous définissez), l'article peut être trouvé: ici

Itai Ganot
la source
Le lien a été mis à jour
Itai Ganot
0

Cela se produit généralement lorsque le serveur NRPE est démarré avec l'utilisateur nrpe, au lieu de nagios.

La modification de la nrpe_uservaleur en nagios dans le /etc/nagios/nrpe.cfgfichier devrait résoudre votre problème.

Le nrpe_grouppeut également être modifié si nécessaire.

Umut Uzun
la source
0

Une autre chose à vérifier est que si votre commande est utilisée sudo -u <another user>pour exécuter la commande, le libexecrépertoire (et les répertoires au-dessus) doivent être lisibles par l'utilisateur auquel il est destiné.

Par exemple, si votre commande est:

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

L'utilisateur tomcat doit pouvoir accéder à ce fichier.

Une façon de résoudre ce problème serait:

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

Remplacement de la dernière partie où que vos exécutables vivent

Mitch
la source
0

J'ai eu le même problème et j'ai réussi à le résoudre en tuant le processus nagios (sur la machine surveillée):

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

Tout s'est bien passé après ça.

user428879
la source
0

Je viens d'avoir ce problème sur FreeBSD. Après m'être cogné la tête contre un mur pendant une heure, j'ai réalisé que le problème était que le /usr/local/nagios/etc/nrpe.cfgpointait au mauvais endroit pour sudo.

Pour trouver l'emplacement correct vers lequel pointer pour l'exécution de la commande sudo:

# whereis sudo

J'ai ensuite changé le préfixe_commande dans nrpe.cfg de:

command_prefix=/usr/local/sudo

à:

command_prefix=/usr/local/bin/sudo

Puis a couru service nrpe restartet le problème a été résolu.

Cela pourrait être un problème similaire sur d'autres systèmes d'exploitation, juste une autre chose à vérifier si vous avez vérifié tous les autres problèmes d'autorisations possibles et que vous rencontrez toujours ce problème.

Graeme
la source
-2

J'ai eu ce problème et j'ai résolu de désactiver le selinux

setenforce 0

Paulo Azedo
la source
2
Bienvenue dans Server Fault. Pouvez-vous fournir plus de détails expliquant comment / pourquoi cela fonctionne?
Je dis Réintégrer Monica