NRPE nie może odczytać danych wyjściowych, ale dlaczego?

27

Mam ten problem z NRPE, wszystkie rzeczy, które znalazłem do tej pory w sieci, wydają się wskazywać na rzeczy, które już próbowałem.

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

daje

NRPE v2.12

zgodnie z oczekiwaniami.

Ręczne uruchomienie polecenia (zgodnie z definicją w nrpe.cfg na „nrpeclient” daje oczekiwaną odpowiedź

nrpe.cfg:

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

"Expected response"

Ale jeśli spróbuję uruchomić polecenie z serwera Nagios, otrzymuję:

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

Czy ktoś może pomyśleć o innym miejscu, w którym mógłbym się z tym pomylić? Zrobiłem to samo na wielu innych serwerach bez problemu. Jedyną różnicą, o której mogę tutaj myśleć, jest to, że to pudełko jest oparte na RHEL 5, podczas gdy inne są oparte na RHEL 4.

Te dwa bity powyżej, które przetestowałem, wydają się sugerować większość ludzi, gdy mają ten problem.

Powinienem wspomnieć, że po ponownym uruchomieniu pojawia się dziwny błąd w dziennikach 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

Mimo to po prostu odczytuje ten /usr/local/nagios/etc/nrpe.cfgplik, aby uzyskać więcej informacji na ten temat ...

ticktockhouse
źródło
Zatrzymajmy ten, ponieważ drugi był zamknięty.
Bart De Vos,
Upewnij się również, że STDOUT jest rzeczywiście opróżniony.

Odpowiedzi:

35

Masz problem z prawami.

Zmień polecenie na:

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

(dodaj sudo)

Następnie dodaj użytkownika sudios do sudoers:

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

Lub możesz po prostu chmod plik ... To też działa.

Jeśli używasz CentOS, Red Hat, Scientific lub Fedora, upewnij się, że wyłączono Defaults requirettyw pliku sudoers.

Bart De Vos
źródło
1
@Bart De Vos, ale dodana odpowiedź spowoduje powstanie dziury w zabezpieczeniach> dodanie czegoś do pliku sudoers otworzy cię na potencjalne zagrożenie bezpieczeństwa. tzn. jeśli przez przepełnienie bufora ktoś może upuścić plik o tej samej nazwie w tej samej lokalizacji, może go wykonać bez znajomości hasła roota i przejąć kontrolę nad skrzynką: S Czy nie ma sposobu, aby w jakiś sposób złożyć podpis (SHA1 lub MD5) aplikacji w pliku sudoers, aby zapobiec tego typu atakowi. tzn. wstrzyknięty plik nie będzie miał tej samej sygnatury i dlatego się nie uruchomi. [Przeczytaj pierwszy komentarz tutaj] ( crashatau.blogspot.co
Ahmad Hajjar
1
@ X-Ware: Chociaż jest to prawda, szansa, że ​​przepełnienie bufora może być tutaj wykorzystane, jest bardzo niewielka. Jednak aby temu zapobiec, powinieneś użyć apparmor / SELinux. Właśnie dlatego te rzeczy istnieją.
Bart De Vos,
Wydaje mi się, że różne dystrybucje mają nawet różnych użytkowników, w moim przypadku użytkownik, który dodał do Visudo, nie był nie nagios. Nadal śledziłem rozwiązanie Bart De Vos, jednak możesz zobaczyć, który użytkownik próbuje uzyskać dostęp do polecenia nrpe, przeglądając dziennik / var / log / secure access log. 24 lipca 15:39:09 nazwa hosta sudo: nrpe: użytkownik NIE w sudoers; TTY = nieznany; PWD = /; USER = root; COMMAND = / usr / lib64 / nagios / plugins / check_disk -w 20% -c 10% -p / dev / mapper / vg_uxp-lv_root
@AhmadHajjar Mówisz poważnie? Myślisz, że ktoś zhakuje nagios (system mający 20 lat) i użyje tego użytkownika do wykonania pliku z uprawnieniami roota. I myślisz, że nie sprawiłem, aby plik wykonywalny był uruchamiany jako root tylko do odczytu, aby zapobiec kopiowaniu przez niego pliku? Jeśli martwisz się o to, zamiast używać sudo, możesz ustawić plik wykonywalny check_openmanage i pozwolić każdemu go uruchomić!
Evan Langlois,
11

Krótka odpowiedź: jeśli używasz wtyczki Bash, upewnij się, że masz shebang określający, którego tłumacza należy użyć:#!/bin/bash


Ten sam problem dotyczy wtyczki Nagios, którą sam napisałem. Skrypt działał zgodnie z oczekiwaniami, gdy został uruchomiony lokalnie, nawet podczas uruchamiania jako użytkownik nagiosprzy użyciu następującej instrukcji:

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

Jednak zdalne uruchomienie przy użyciu NRPE z serwera Nagios3 zakończyło się niepowodzeniem:

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

W końcu rozwiązałem ten przypadek, dodając shebang do mojego skryptu, ponieważ wydawało się, że uruchomienie skryptu przez NRPE nie używało tego samego interpretera, jak podczas uruchamiania sudo sudo -s -u nagios.

Mickaël Le Baillif
źródło
Wystąpił ten problem podczas korzystania z wtyczki nagios Ruby script z rbenv. Naprawiono utworzenie skryptu opakowania z#!/bin/bash -el eval "$(rbenv init -)" /usr/lib/nagios/plugins/check_something $@
TrinitronX
1
niesamowita odpowiedź! sudo -s -u nagios pozwoliło mi zobaczyć, dlaczego nagios nie może zwrócić danych wyjściowych z określonej wtyczki. Dziękuję bardzo!
ufk
6

W moim przypadku problem był po prostu - nagios użytkownika nie był w stanie wykonać skryptu. Po chmod zaczął działać. Sudo nie jest konieczne. To nawet złe :)

bluszcz
źródło
1
Prawdziwa odpowiedź brzmi: Nagios nie był w stanie wykonać skryptu z powodu złych uprawnień, błędnego skryptu lub braku skryptu.
droope,
5

check_nrpe otrzymywał komunikat „NRPE: Nie można odczytać danych wyjściowych” pomimo sprawdzania działającego lokalnie, ponieważ wtyczka, której używałem, nie działała dobrze z SELinux. Wyłącz i upewnij się, aby usunąć konteksty pliku:

$ 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
źródło
podczas gdy wyłączenie selinux generalnie może nie być dobrym pomysłem do testowania, jest to nadal ważne.
Dennis Nolte
4

Sprawdź ścieżki, uprawnienia, selinux, iptables.

Mój problem dotyczył patpowania w kliencie: nrpe.cfg, sprawdź dokładnie ścieżkę polecenia do nazwy wtyczki check_ *. Mogą być mylące (lib / local) (libexec / plugins) jako nazwa ścieżki. Przez pomyłkę szarpnąłem i umieściłem ścieżki z komentowanego wstępnie spakowanego pliku nrpe cfg, aby wykonać polecenia. Make install lub yum plugin install umieszcza je w katalogu difft.

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

przeciw

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

Z serwera mogłem potwierdzić, że nie jest to problem z zaporą, mogłem telnet do portu 5666, mogłem uruchomić koc check_nrpe i uzyskać status jako wartość zwracaną. Można uruchomić polecenia lokalnie, ale nrpe miał niewłaściwą ścieżkę na kliencie w nrpe.cfg.

Witaj świecie
źródło
4

W moim przypadku tylko jedna wtyczka uległa awarii, a kilka innych działało dobrze. Okazało się, że jest to problem LOCALE.

Wtyczka była check_mem.shi wykonała grep dla Memwyjścia free. SpeicherZamiast tego zwrócono LOCALE w Memcałym systemie (niemiecki) , więc wszystkie otrzymane wartości były pustymi ciągami.

Pośpiech
źródło
2
Pośpiesz się, witaj w SF! To jest, moim zdaniem, doskonała pierwsza odpowiedź: krótka, do rzeczy, i dodaje coś nowego do zbioru odpowiedzi już tutaj. +1 ode mnie i mam nadzieję, że w przyszłości przeczytam więcej takich odpowiedzi (mam nadzieję, że wybaczycie moją małą edycję formatowania).
MadHatter obsługuje Monikę
2

To jest problem z uprawnieniami, po prostu daj prawemu wykonanie skryptu i będzie dobrze:

tutaj przykład: Przed / Zdalny 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

Serwer NRPE :

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

Po: zdalny 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 rozwiązany.

Youssef ASEBRIY
źródło
1
Dobra odpowiedź, ale warto również zauważyć, że zezwolenie wszystkim użytkownikom na uruchamianie check_nrpe, podobnie jak chmod o + x, może stanowić potencjalne zagrożenie bezpieczeństwa, w zależności od konfiguracji / dostępu / użytkowania systemu.
austriacki
1

W moim przypadku monitorowany plik dziennika był własnością root: adm, więc dodanie użytkownika nagios do grupy adm sprawiło, że polecenie check_log zakończyło się powodzeniem, ale tylko wtedy, gdy zostało wykonane bezpośrednio na monitorowanych hostach. Nadal nie powiodło się, używając check_nrpe na serwerze Nagios, dopóki nie zrestartowałem usługi nagios-nrpe-server na monitorowanych hostach, np.

service nagios-nrpe-server restart

Więc najwyraźniej ponowne uruchomienie usługi było konieczne, aby zmiana uprawnień zaczęła obowiązywać dla NRPE, ale zajęło mi to trochę czasu, aby to zrozumieć.

Tony
źródło
1

W przypadku niestandardowych wtyczek NRPE pamiętaj, aby wydrukować część danych wyjściowych wraz z wartością wyjścia. Jeśli nie ma danych wyjściowych ze skryptu, NRPE będzie narzekać, mówiąc „NRPE nie może odczytać danych wyjściowych” . Możesz włączyć debugowanie w nrpe.cfg i zaobserwować ten błąd.

Karthik
źródło
1

W moim przypadku problemy były związane z selinux (uruchamianie RHEL 6.5, selinux jest ustawiony na wymuszanie).

Zainstalowanie nagios-plugins- * przez yum spowoduje utworzenie plików wtyczek w / usr / lib64 / nagios / plugins. Jeśli sprawdzisz fcontext w tych plikach wtyczek (ls -lZ), zobaczysz, że dla plików ustawiono typ kontekstu na „nagios_system_plugin_exec_t”, który jest typem kontekstu, którego oczekuje check_nrpe.

W moim przypadku utworzyłem niestandardowy skrypt „check_mem.sh” za pomocą „vi”. Plik wynikowy miał typ kontekstu ustawiony na „lib_t”. Powodowało to, że nrpe wypisał „NRPE: Nie można odczytać danych wyjściowych”.

Zmiana kontekstu pliku na „nagios_system_plugin_exec_t” rozwiązała problem:

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

Zwykłe rozwiązywanie problemów selinux również wskazałoby mi ten problem (sprawdzanie /var/log/audit/audit.log), ale oczywiście była to ostatnia rzecz, o której myślałem

Edycja: chcon tylko chwilowo zmienia kontekst. Aby go zmienić, należy go używać 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
źródło
0

Możliwe, że nie zainstalowałeś wtyczek Nagios, NRPE nie może ich znaleźć ani uzyskać do nich dostępu.

Nigdy nie musiałem dodawać moich poleceń do Sudoers. Upewnij się, że polecenia są własnością użytkownika Nagios i są czytelne.

Daniel Baker
źródło
0

Myślę, że musisz dodać wtyczki do lokalnego katalogu /usr/lib64/nagios/plugins/*. Miałem ten sam problem co ty i mogę go rozwiązać za pomocą tego rozwiązania.

Tarik Nasser
źródło
0

Miałem problem, który piszesz. Test, który przeprowadziłem, był z Perla. Umieść tę linię w pliku, /etc/nagios/nrpe.cfgaby działała.

command [check_memory] = /usr/bin/perl /usr/lib64/nagios/plugins/check_memory -w 75-c 90 
użytkownik224319
źródło
0

Jest naprawdę fajny artykuł, który opisuje całą instalację i konfigurację agenta NRPE z wieloma przykładami check_commands. Korzystam z tego artykułu, gdy muszę zainstalować NRPE na nowym serwerze. Co więcej, na końcu strony znajdziesz fajny skrypt, który automatycznie instaluje i konfiguruje NRPE dla Ciebie (na podstawie ustawionych zmiennych), artykuł można znaleźć: Tutaj

Itai Ganot
źródło
Link został zaktualizowany
Itai Ganot
0

Zwykle dzieje się tak, gdy serwer NRPE jest uruchamiany z użytkownikiem nrpe zamiast nagios.

Zmiana nrpe_userwartości na nagios w /etc/nagios/nrpe.cfgpliku powinna rozwiązać twój problem.

W nrpe_grouprazie potrzeby można je również zmienić.

Umut Uzun
źródło
0

Jeszcze jedną rzeczą do sprawdzenia jest to, że jeśli twoje polecenie korzysta sudo -u <another user>z polecenia, libexeckatalog (i katalogi nad nim) muszą być czytelne dla sudo użytkownika.

Na przykład jeśli twoje polecenie to:

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

Użytkownik tomcat musi mieć dostęp do tego pliku.

Jednym ze sposobów rozwiązania tego byłoby:

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

Zastąpienie ostatniej części dowolnym miejscem, w którym znajdują się pliki wykonywalne

Mitch
źródło
0

Miałem ten sam problem i udało mi się go rozwiązać, zabijając proces nagios (na monitorowanym komputerze):

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

Potem wszystko poszło dobrze.

użytkownik428879
źródło
0

Właśnie miałem ten problem na FreeBSD. Po godzinnym uderzaniu głową o ścianę zdałem sobie sprawę, że problem /usr/local/nagios/etc/nrpe.cfgpolega na tym, że wskazywało to niewłaściwe miejsce dla sudo.

Aby znaleźć poprawną lokalizację do uruchomienia polecenia sudo:

# whereis sudo

Następnie zmieniłem przedrostek komendy w nrpe.cfg z:

command_prefix=/usr/local/sudo

do:

command_prefix=/usr/local/bin/sudo

Następnie pobiegł service nrpe restarti problem został rozwiązany.

Może to być podobny problem w innych systemach operacyjnych, po prostu kolejna rzecz, aby sprawdzić, czy sprawdziłeś wszystkie inne możliwe problemy dotyczące uprawnień i nadal napotykasz ten problem.

Graeme
źródło
-2

Miałem ten problem i rozwiązałem wyłączanie selinux

setenforce 0

Paulo Azedo
źródło
2
Witamy w usłudze Server Fault. Czy możesz podać więcej szczegółów wyjaśniających, jak / dlaczego to działa?
Mówię: Przywróć Monikę