NRPE non è in grado di leggere l'output, ma perché?


27

Ho questo problema con NRPE, tutte le cose che ho trovato finora in rete sembrano indicarmi cose che ho già provato.

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

NRPE v2.12

come previsto.

Eseguendo il comando a mano (come definito in nrpe.cfg su "nrpeclient", si ottiene la risposta prevista

nrpe.cfg:

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

"Expected response"

Ma se provo ad eseguire il comando dal server Nagios ottengo quanto segue:

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

Qualcuno può pensare a qualcos'altro che avrei potuto fare un errore in questo? Ho fatto la stessa cosa su più altri server senza problemi. L'unica differenza che mi viene in mente è che questa scatola è basata su RHEL 5, mentre le altre sono basate su RHEL 4.

Quei due bit sopra che ho testato sono ciò che la maggior parte della gente sembra suggerire quando le persone hanno avuto questo problema.

Dovrei dire che quando riavvio ricevo uno strano errore nei registri 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

Anche se, sta chiaramente leggendo quel /usr/local/nagios/etc/nrpe.cfgfile per ottenere le cose di cui sta parlando più in basso ..



Conserviamo questo, poiché l'altro era chiuso.
Bart De Vos,

Inoltre, assicurarsi che STDOUT sia effettivamente scaricato.

Risposte:


35

Hai un problema con i diritti.

Cambia il comando in:

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

(aggiungi sudo)

Quindi, aggiungi l'utente nagios ai sudoer:

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

Oppure potresti semplicemente modificare il file ... Funziona anche.

Se stai usando CentOS, Red Hat, Scientific o Fedora, assicurati di disabilitare Defaults requirettynel file sudoers.


1
@Bart De Vos ma la risposta che hai aggiunto creerà un buco nella sicurezza> l'aggiunta di qualcosa al file sudoers ti apre per un potenziale rischio per la sicurezza. cioè se attraverso un buffer overflow qualcuno è in grado di rilasciare un file con lo stesso nome nella stessa posizione, potrebbe eseguirlo senza conoscere la password di root e ottenere il controllo della casella: S Non c'è modo di mettere in qualche modo una firma (SHA1 o MD5) dell'applicazione nel file sudoers per impedire quel tipo di attacco. cioè il file iniettato non avrà la stessa firma e quindi non verrà eseguito. [Leggi il primo commento qui] ( crashatau.blogspot.co
Ahmad Hajjar

1
@ X-Ware: anche se questo è vero, la possibilità che un buffer overflow possa essere abusato qui è molto ridotta. Per evitare che ciò accada, tuttavia, è necessario utilizzare apparmor / SELinux. Ecco perché esistono queste cose.
Bart De Vos,

Immagino che diverse distribuzioni abbiano anche utenti diversi, nel mio caso l'utente da aggiungere a visudo non era né nagios. Ho ancora seguito la soluzione di Bart De Vos, tuttavia puoi vedere quale utente sta provando ad accedere al comando nrpe visualizzando il registro / var / log / secure access. 24 lug 15:39:09 nome host sudo: nrpe: utente NON in sudoers; TTY = sconosciuto; PWD = /; USER = root; COMANDO = / usr / lib64 / nagios / plugins / check_disk -w 20% -c 10% -p / dev / mapper / vg_uxp-lv_root

@AhmadHajjar Sei serio? Pensi che qualcuno hackererà i nagios (un sistema di 20 anni) e userà quell'utente per eseguire un file con permessi di root. E pensi che non abbia fatto eseguire l'eseguibile come root come di sola lettura per impedire a qualcuno di copiare un file su di esso? Se sei preoccupato, invece di usare sudo puoi impostare lo stesso eseguibile check_openmanage e lasciare che chiunque lo esegua!
Evan Langlois,

11

Risposta breve: se stai usando un plugin Bash, assicurati di avere un shebang che indichi quale interprete dovrebbe essere usato:#!/bin/bash


Stavo affrontando lo stesso problema con un plugin Nagios che ho scritto da solo. Lo script era in esecuzione come previsto quando è stato avviato localmente, anche quando è in esecuzione come utente nagiosutilizzando la seguente istruzione:

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

Ma l'avvio remoto tramite NRPE dal server Nagios3 non ha avuto esito positivo:

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

Alla fine ho risolto questo caso aggiungendo uno shebang nella mia sceneggiatura, poiché sembrava che l'esecuzione della sceneggiatura tramite NRPE non usasse lo stesso interprete di quando la correvo sudo sudo -s -u nagios.


Aveva questo problema quando si utilizzava un plugin nagios di script ruby ​​con rbenv. La correzione consisteva nel creare uno script wrapper con#!/bin/bash -el eval "$(rbenv init -)" /usr/lib/nagios/plugins/check_something $@
TrinitronX,

1
risposta incredibile! sudo -s -u nagios mi ha permesso di capire perché nagios non è riuscito a restituire l'output di un plug-in specifico. grazie mille!
UFK

6

Nel mio caso il problema era semplicemente: i nagios dell'utente non erano in grado di eseguire lo script. Dopo chmod ha iniziato a funzionare. Il Sudo non è necessario. È perfino malvagio :)


1
La vera risposta è questa. Nagios non è stato in grado di eseguire lo script, a causa di cattive autorizzazioni, lo script non è stato scritto correttamente o lo script non è presente.
droope

5

check_nrpe stava ottenendo 'NRPE: impossibile leggere l'output' nonostante il controllo funzionasse localmente perché il plugin che stavo usando non funzionava bene con SELinux. Disabilitalo e assicurati di rimuovere i contesti del file:

$ 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

mentre disabilitare in generale selinux potrebbe non essere una buona idea per testarlo, è ancora valido.
Dennis Nolte,

4

Controlla percorso, permessi, selinux, iptables.

Il mio era un problema di percorso nel client: nrpe.cfg, ricontrolla il percorso del comando fino al nome del plugin check_ *. Questi possono essere confusi, (lib / local) (libexec / plugins) come percorso. Ho erroneamente strappato e messo i percorsi dal file cfg nrpe preconfezionato commentato per eseguire comandi. L'installazione make install o yum plug-in li inserisce in una directory difft.

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

contro

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

Dal server sono stato in grado di confermare che non si trattava di un problema del firewall, di telnet alla porta 5666, di eseguire un controllo check_nrpe e di ottenere lo stato come valore di ritorno. Potrebbe eseguire i comandi localmente ma nrpe aveva il percorso errato sul client in nrpe.cfg.


4

Nel mio caso, solo un plug-in è fallito mentre molti altri hanno funzionato bene. Si è rivelato essere un problema LOCALE.

Il plugin è stato check_mem.shed ha eseguito un grep per Meml'output di free. Ma LOCALE a livello di sistema ha restituito Speicher(tedesco) invece di Mem, quindi tutti i valori ricevuti erano stringhe vuote.


2
Rush, benvenuto in SF! Questa è un'ottima prima risposta, secondo me: breve, al punto, e aggiunge qualcosa di nuovo alla raccolta di risposte già qui. +1 da parte mia, e spero di leggere altre tue risposte in futuro (spero che perdonerai la mia piccola modifica di formattazione).
MadHatter supporta Monica il

2

Questo è un problema di autorizzazione, basta dare l'esecuzione corretta dello script e andrà bene:

qui un esempio: Prima / 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

Server NRPE :

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

Dopo: 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 risolto.


1
Buona risposta, ma è anche bene notare che consentire a tutti gli utenti di eseguire check_nrpe, come fa chmod o + x, potrebbe essere un potenziale rischio per la sicurezza, a seconda della configurazione / accesso / utilizzo del sistema.
austinian l'

1

Nel mio caso il file di registro monitorato era di proprietà di root: adm, quindi l'aggiunta dell'utente nagios al gruppo adm ha dato esito positivo al comando check_log, ma solo se eseguito direttamente sugli host monitorati. Ha continuato a fallire utilizzando check_nrpe sul server Nagios fino a quando non ho riavviato il servizio nagios-nrpe-server sugli host monitorati, ad es.

service nagios-nrpe-server restart

Quindi apparentemente il riavvio del servizio era necessario per rendere effettive le modifiche alle autorizzazioni per NRPE, ma mi ci è voluto un po 'di tempo per capirlo.


1

Nel caso di plug-in NRPE personalizzati, assicurarsi di stampare un po 'di output insieme al valore di uscita. Se non è presente alcun output dallo script NRPE si lamenterà dicendo "NRPE impossibile leggere l'output" . È possibile abilitare il debug in nrpe.cfg e osservare questo errore.


1

Nel mio caso i problemi riguardavano selinux (eseguendo RHEL 6.5, selinux è impostato per l'applicazione).

L'installazione di nagios-plugins- * tramite yum creerà i file del plug-in in / usr / lib64 / nagios / plugins. Se controlli fcontext su quei file plugin (ls -lZ), vedrai che i file hanno il tipo di contesto impostato su "nagios_system_plugin_exec_t", che è il tipo di contesto che check_nrpe si aspetta.

Nel mio caso, avevo creato uno script personalizzato "check_mem.sh" usando "vi". Il file risultante aveva il tipo di contesto impostato su "lib_t". Ciò causava l'output di nrpe "NRPE: impossibile leggere l'output".

La modifica del contesto del file in "nagios_system_plugin_exec_t" ha risolto il problema:

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

La solita risoluzione dei problemi di selinux mi avrebbe indicato anche questo problema (controllando /var/log/audit/audit.log), ma era ovviamente l'ultima cosa a cui pensavo

Modifica: chcon modifica solo temporaneamente il contesto. Per cambiarlo persistentemente usare 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


0

È possibile che tu non abbia installato i tuoi plugin Nagios, che NRPE non riesca a trovarli o ad accedervi.

Non ho mai dovuto aggiungere i miei comandi ai sudatori. Assicurarsi che i comandi siano di proprietà dell'utente Nagios e siano leggibili.


0

Penso che tu debba aggiungere i plugin nella tua directory locale /usr/lib64/nagios/plugins/*. Ho avuto lo stesso problema con te e posso risolverlo con questa soluzione.


0

Ho avuto il problema che scrivi. Il test che ho eseguito è stato dal Perl. Inserisci questa riga nel file /etc/nagios/nrpe.cfgper farlo funzionare.

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

0

C'è un articolo davvero carino che copre l'installazione e la configurazione dell'intero agente NRPE con molti esempi di comandi_di_controllo, uso questo articolo ogni volta che devo installare NRPE su un nuovo server. Inoltre, alla fine della pagina puoi trovare uno script interessante che installa e configura automaticamente NRPE per te (in base alle variabili che hai impostato), puoi trovare l'articolo: Qui


Il link è stato aggiornato
Itai Ganot il

0

Questo di solito accade quando il server NRPE viene avviato con l'utente nrpe, anziché con nagios.

La modifica del nrpe_uservalore in nagios nel /etc/nagios/nrpe.cfgfile dovrebbe risolvere il problema.

Il nrpe_grouppuò anche essere cambiato se necessario.


0

Un'altra cosa da verificare è che se il comando viene utilizzato sudo -u <another user>per eseguire il comando, la libexecdirectory (e le directory sopra di essa) deve essere leggibile dall'utente su cui si esegue il sudo.

Ad esempio se il tuo comando è:

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

L'utente tomcat deve essere in grado di accedere a quel file.

Un modo per risolvere questo sarebbe:

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

Sostituendo l'ultima parte con il luogo in cui vivono i tuoi eseguibili


0

Ho avuto lo stesso problema e riesco a risolverlo uccidendo il processo nagios (sulla macchina monitorata):

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

Dopo tutto è andato bene.


0

Ho appena avuto questo problema su FreeBSD. Dopo aver sbattuto la testa contro un muro per un'ora mi sono reso conto che il problema era che /usr/local/nagios/etc/nrpe.cfgindicava la posizione sbagliata per sudo.

Per trovare la posizione corretta a cui puntare per l'esecuzione del comando sudo:

# whereis sudo

Ho quindi modificato command_prefix in nrpe.cfg da:

command_prefix=/usr/local/sudo

a:

command_prefix=/usr/local/bin/sudo

Quindi corse service nrpe restart e il problema è stato risolto.

Potrebbe essere un problema simile su altri sistemi operativi, solo un'altra cosa per verificare se hai verificato tutti gli altri possibili problemi di autorizzazione e continui a riscontrare questo problema.



-2

Ho avuto questo problema e ho risolto disabilitando il selinux

setenforce 0


2
Benvenuti in Server Fault. Potete fornire maggiori dettagli spiegando come / perché funziona?
Dico Reinstate Monica
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.