NRPE kann die Ausgabe nicht lesen, aber warum?

27

Ich habe dieses Problem mit NRPE. Alles, was ich bisher im Internet gefunden habe, scheint mich auf Dinge hinzuweisen, die ich bereits ausprobiert habe.

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

gibt

NRPE v2.12

wie erwartet.

Wenn Sie den Befehl manuell ausführen (wie in nrpe.cfg unter "nrpeclient" definiert), erhalten Sie die erwartete Antwort

nrpe.cfg:

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

"Expected response"

Wenn ich jedoch versuche, den Befehl vom Nagios-Server auszuführen, erhalte ich Folgendes:

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

Kann sich irgendjemand etwas anderes vorstellen, bei dem ich vielleicht einen Fehler gemacht habe? Ich habe das gleiche auf mehreren anderen Servern ohne Probleme gemacht. Der einzige Unterschied, den ich mir dabei vorstellen kann, ist, dass diese Box auf RHEL 5 basiert, während die anderen auf RHEL 4 basieren.

Die beiden oben genannten Punkte, die ich getestet habe, scheinen den meisten Leuten nahezulegen, wenn sie dieses Problem hatten.

Ich sollte erwähnen, dass ich einen seltsamen Fehler in den Protokollen bekomme, wenn ich neu starte 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

Obwohl es einfach ist, diese /usr/local/nagios/etc/nrpe.cfgDatei zu lesen, um die Dinge zu bekommen, über die es weiter unten spricht.

Ticktockhouse
quelle
Mögliches Duplikat von NRPE kann Ausgabe nicht lesen, aber warum?
mailq
Lassen Sie uns dieses behalten, da das andere geschlossen war.
Bart De Vos
Stellen Sie außerdem sicher, dass STDOUT tatsächlich gespült wird.

Antworten:

35

Sie haben ein Rechteproblem.

Ändern Sie den Befehl in:

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

(füge sudo hinzu)

Fügen Sie dann den Nagios-Benutzer zu den Sudoern hinzu:

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

Oder Sie könnten einfach die Datei chmod ... Das funktioniert auch.

Wenn Sie CentOS, Red Hat, Scientific oder Fedora verwenden, müssen Sie Defaults requirettydie sudoers-Datei deaktivieren .

Bart De Vos
quelle
1
@Bart De Vos, aber die Antwort, die Sie hinzugefügt haben, führt zu einer Sicherheitslücke> Wenn Sie der sudoers-Datei etwas hinzufügen, können Sie ein potenzielles Sicherheitsrisiko erkennen. Wenn also jemand über einen Pufferüberlauf eine Datei mit dem gleichen Namen am gleichen Ort ablegen kann, kann er sie ausführen, ohne das root - Passwort zu kennen und die Kontrolle über die Box zu erlangen: S Gibt es keine Möglichkeit, irgendwie eine Signatur (SHA1) zu setzen? oder MD5) der Anwendung in der sudoers-Datei, um diese Art von Angriff zu verhindern. dh die injizierte Datei hat nicht die gleiche Signatur und wird daher nicht ausgeführt. [Lesen Sie den ersten Kommentar hier] ( crashatau.blogspot.co
Ahmad Hajjar
1
@ X-Ware: Während dies zutrifft, ist die Chance, dass ein Pufferüberlauf hier missbraucht wird, sehr gering. Um dies zu verhindern, sollten Sie apparmor / SELinux verwenden. Deshalb gibt es diese Dinge.
Bart De Vos
Ich denke, verschiedene Distributionen haben sogar unterschiedliche Benutzer, in meinem Fall war der Benutzer, der zu visudo hinzugefügt wurde, npre not nagios. Ich habe immer noch die Lösung von Bart De Vos verfolgt. Sie können jedoch feststellen, welcher Benutzer versucht, auf den Befehl nrpe zuzugreifen, indem Sie das Protokoll / var / log / secure access anzeigen. 24. Juli 15:39:09 Hostname sudo: nrpe: Benutzer NICHT in sudoers; TTY = unbekannt; PWD = /; USER = root; BEFEHL = / usr / lib64 / nagios / plugins / check_disk -w 20% -c 10% -p / dev / mapper / vg_uxp-lv_root
@ Ahmad Hadschar Sind Sie ernst? Sie glauben, jemand hackt Nagios (ein System, das 20 Jahre alt ist) und verwendet diesen Benutzer, um eine Datei mit Root-Berechtigungen auszuführen. UND Sie denken, ich habe die ausführbare Datei nicht so eingerichtet, dass sie als Root-Datei ausgeführt wird, um zu verhindern, dass jemand eine Datei darüber kopiert? Wenn Sie sich Sorgen machen, können Sie anstelle von sudo die ausführbare Datei check_openmanage selbst festlegen und von jedem ausführen lassen!
Evan Langlois
11

Kurze Antwort: Wenn Sie ein Bash-Plugin verwenden, stellen Sie sicher, dass Sie einen Shebang haben , der angibt, welcher Interpreter verwendet werden soll:#!/bin/bash


Ich hatte das gleiche Problem mit einem Nagios-Plugin, das ich selbst geschrieben habe. Das Skript wurde beim lokalen Start erwartungsgemäß ausgeführt, auch wenn es als Benutzer nagiosmit der folgenden Anweisung ausgeführt wurde:

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

Das Remote-Starten mit NRPE vom Nagios3-Server aus war jedoch nicht erfolgreich:

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

Schließlich löste ich diesen Fall, indem ich meinem Skript einen Shebang hinzufügte , da anscheinend beim Ausführen des Skripts über NRPE nicht derselbe Interpreter wie beim Ausführen verwendet wurde sudo sudo -s -u nagios.

Mickaël Le Baillif
quelle
Hatte dieses Problem bei der Verwendung eines Ruby-Skript-Nagios-Plugins mit rbenv. Fix war, ein Wrapper-Skript mit#!/bin/bash -el eval "$(rbenv init -)" /usr/lib/nagios/plugins/check_something $@
TrinitronX
1
erstaunliche Antwort! Mit sudo -s -u Nagios konnte ich sehen, warum Nagios keine Ausgabe von einem bestimmten Plugin zurückgeben konnte. ich danke dir sehr!
ufk
6

In meinem Fall bestand das Problem einfach darin, dass der Benutzer nagios das Skript nicht ausführen konnte. Nach chmod fing es an zu arbeiten. Sudo ist nicht notwendig. Es ist sogar böse :)

bluszcz
quelle
1
Die wahre Antwort lautet: Nagios war nicht in der Lage, das Skript auszuführen, entweder weil die Berechtigungen nicht korrekt waren, das Skript falsch geschrieben wurde oder weil das Skript nicht vorhanden war.
Droope
5

check_nrpe erhielt 'NRPE: Ausgabe konnte nicht gelesen werden', obwohl die Überprüfung lokal funktionierte, da das von mir verwendete Plugin mit SELinux nicht gut funktionierte. Deaktivieren Sie es und stellen Sie sicher, dass Sie die Kontexte der Datei entfernen:

$ 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
quelle
Obwohl das Deaktivieren von Selinux im Allgemeinen keine gute Idee zum Testen ist, ist es dennoch gültig.
Dennis Nolte
4

Überprüfen Sie die Pfade, Berechtigungen, Selinux und Iptables.

Meins war ein Pfadproblem im Client: nrpe.cfg, überprüfen Sie den Befehlspfad zum Namen des check_ * -Plugins. Dies kann verwirrend sein (lib / local) (libexec / plugins) als Pfadname. Ich habe fälschlicherweise gezerrt und die Pfade aus der kommentierten vorverpackten nrpe cfg-Datei eingefügt, um Befehle zu erstellen. Die make install- oder yum plugin-Installation legt diese in einem anderen Verzeichnis ab.

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

gegen

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

Vom Server aus konnte ich bestätigen, dass es sich nicht um ein Firewall-Problem handelt, konnte eine Telnet-Verbindung zum 5666-Port herstellen, konnte eine Blanket-check_nrpe ausführen und den Status als Rückgabewert abrufen. Konnte die Befehle lokal ausführen, aber nrpe hatte den falschen Pfad auf dem Client in der Datei nrpe.cfg.

Hallo Welt
quelle
4

In meinem Fall ist nur ein Plugin ausgefallen, während mehrere andere in Ordnung waren. Es stellte sich heraus, dass es sich um ein LOCALE-Problem handelte.

Das Plugin war check_mem.shund es hat ein Grep für Memdie Ausgabe von ausgeführt free. Aber systemweite LOCALE zurück Speicher(deutsch) statt Mem, so dass alle empfangenen Werte leere Strings waren.

Eilen
quelle
2
Rush, willkommen bei SF! Dies ist meiner Meinung nach eine exzellente erste Antwort: kurz, auf den Punkt, und sie fügt der bereits hier vorgestellten Sammlung von Antworten etwas Neues hinzu. +1 von mir, und ich hoffe, in Zukunft mehr solche Antworten von Ihnen zu lesen (ich hoffe, Sie werden meine kleine Formatierung bearbeiten vergeben).
MadHatter unterstützt Monica
2

Dies ist ein Berechtigungsproblem. Geben Sie dem Skript einfach das richtige Ausführungsrecht und es ist in Ordnung:

Hier ein Beispiel: Vorher / Remote Host :

[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

NRPE-Server :

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

Nachher: Remote-Host :

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

Problem gelöst.

Youssef ASEBRIY
quelle
1
Gute Antwort, aber es ist auch gut zu beachten, dass das Zulassen, dass alle Benutzer check_nrpe ausführen, wie dies bei chmod o + x der Fall ist, ein potenzielles Sicherheitsrisiko darstellen kann, je nachdem, wie das System konfiguriert / zugegriffen / verwendet wird.
Austin
1

In meinem Fall befand sich die überwachte Protokolldatei im Besitz von root: adm, sodass das Hinzufügen des Nagios-Benutzers zur Gruppe adm den Befehl check_log erfolgreich ausführte, jedoch nur, wenn er direkt auf den überwachten Hosts ausgeführt wurde. Die Verwendung von check_nrpe auf dem Nagios-Server schlug weiterhin fehl, bis ich den Dienst nagios-nrpe-server auf den überwachten Hosts neu startete, z

service nagios-nrpe-server restart

Offensichtlich war ein Neustart des Dienstes erforderlich, damit die Berechtigungsänderung für NRPE wirksam wird, aber es dauerte eine Weile, bis ich das herausgefunden hatte.

Tony
quelle
1

Stellen Sie bei benutzerdefinierten NRPE-Plug-ins sicher, dass einige Ausgaben zusammen mit dem Exit-Wert gedruckt werden. Wenn keine Ausgabe vom Skript vorhanden ist, meldet NRPE "NRPE kann die Ausgabe nicht lesen" . Sie können das Debuggen in nrpe.cfg aktivieren und diesen Fehler beobachten.

Karthik
quelle
1

In meinem Fall hatten die Probleme mit Selinux zu tun (unter RHEL 6.5 ist Selinux auf Enforcement eingestellt).

Wenn Sie nagios-plugins- * über yum installieren, werden Ihre Plugin-Dateien in / usr / lib64 / nagios / plugins erstellt. Wenn Sie den Kontext für diese Plug-in-Dateien überprüfen (ls -lZ), werden Sie feststellen, dass für die Dateien der Kontexttyp "nagios_system_plugin_exec_t" festgelegt ist. Dies ist der Kontexttyp, den check_nrpe erwartet.

In meinem Fall hatte ich ein benutzerdefiniertes Skript "check_mem.sh" mit "vi" erstellt. Die resultierende Datei hatte den Kontexttyp "lib_t". Dies führte dazu, dass nrpe die Meldung "NRPE: Ausgabe kann nicht gelesen werden" ausgab.

Durch Ändern des Dateikontexts in "nagios_system_plugin_exec_t" wurde das Problem behoben:

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

Die übliche Selinux-Fehlerbehebung hätte mich auch auf dieses Problem hingewiesen (siehe /var/log/audit/audit.log), aber natürlich war es das Letzte, woran ich dachte

Edit: chcon ändert nur vorübergehend den Kontext. Um es dauerhaft zu ändern, verwenden Sie 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
quelle
0

Es kann sein, dass Sie Ihre Nagios-Plugins nicht installiert haben, NRPE sie nicht findet oder nicht darauf zugreift.

Ich musste Sudoern noch nie meine Befehle hinzufügen. Stellen Sie sicher, dass die Befehle dem Nagios-Benutzer gehören und lesbar sind.

Daniel Baker
quelle
0

Ich denke, Sie müssen die Plugins in Ihrem lokalen Verzeichnis hinzufügen /usr/lib64/nagios/plugins/*. Ich hatte das gleiche Problem wie Sie und kann es mit dieser Lösung lösen.

Tarik Nasser
quelle
0

Ich hatte das Problem, dass Sie schreiben. Der Test, den ich lief, war von Perl. Fügen Sie diese Zeile in die Datei ein /etc/nagios/nrpe.cfg, damit sie funktioniert.

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

Es gibt einen sehr schönen Artikel, der die gesamte Installation und Konfiguration des NRPE-Agenten mit vielen check_commands-Beispielen behandelt. Ich verwende diesen Artikel immer dann, wenn ich NRPE auf einem neuen Server installieren muss. Darüber hinaus finden Sie am Ende der Seite ein cooles Skript, das NRPE automatisch installiert und konfiguriert (basierend auf den von Ihnen festgelegten Variablen). Den Artikel finden Sie hier

Itai Ganot
quelle
Der Link wurde aktualisiert
Itai Ganot
0

Dies geschieht normalerweise, wenn der NRPE-Server mit dem Benutzer nrpe anstelle von nagios gestartet wird.

Das Ändern des nrpe_userWerts in nagios in der /etc/nagios/nrpe.cfgDatei sollte Ihr Problem lösen.

Das nrpe_groupkann bei Bedarf auch geändert werden.

Umut Uzun
quelle
0

Eine andere zu überprüfende Sache ist, dass, wenn Ihr Befehl verwendet wird sudo -u <another user>, um den Befehl auszuführen, das libexecVerzeichnis (und die darüber liegenden Verzeichnisse) für den Benutzer lesbar sein müssen, für den Sudo ausgeführt werden soll.

Zum Beispiel, wenn Ihr Befehl lautet:

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

Der Tomcat-Benutzer muss auf diese Datei zugreifen können.

Eine Möglichkeit, dies zu beheben, wäre:

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

Ersetzen Sie den letzten Teil durch den, in dem sich Ihre ausführbaren Dateien befinden

Mitch
quelle
0

Ich hatte das gleiche Problem und schaffe es, es zu lösen, indem ich den Nagios-Prozess (auf dem überwachten Computer) abbrach:

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

Danach ging alles gut.

user428879
quelle
0

Hatte gerade dieses Problem auf FreeBSD. Nachdem ich meinen Kopf für eine Stunde gegen eine Wand geschlagen hatte, stellte ich fest, dass das /usr/local/nagios/etc/nrpe.cfgfür sudo auf die falsche Stelle zeigte.

So finden Sie den richtigen Speicherort für den Befehl sudo:

# whereis sudo

Ich habe dann das command_prefix in nrpe.cfg geändert von:

command_prefix=/usr/local/sudo

zu:

command_prefix=/usr/local/bin/sudo

Dann rannte service nrpe restart und das Problem wurde gelöst.

Ein ähnliches Problem könnte auch bei anderen Betriebssystemen auftreten. Überprüfen Sie nur, ob Sie alle anderen möglichen Berechtigungsprobleme überprüft haben und dieses Problem weiterhin besteht.

Graeme
quelle
-2

Ich hatte dieses Problem und löste das Deaktivieren von Selinux

setenforce 0

Paulo Azedo
quelle
2
Willkommen bei Serverfehler. Können Sie näher erläutern, wie / warum dies funktioniert?
Ich sage Reinstate Monica