NRPE не може прочитати вихід, але чому?

У мене ця проблема з NRPE, всі речі, які я знайшов поки що в мережі, начебто вказують на речі, які я вже намагався

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

дає

NRPE v2.12

як і очікувалося.

Запуск команди вручну (як визначено в nrpe.cfg на "nrpeclient", дає очікуваний відгук

nrpe.cfg:

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

"Expected response"

Але якщо я спробую запустити команду з сервера Nagios, я отримаю наступне:

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

Хто-небудь може подумати де-небудь ще, я, можливо, помилився з цим? Я робив те ж саме на багатьох інших серверах без проблем. Єдина відмінність, яку я можу придумати, полягає в тому, що це поле засноване на RHEL 5, тоді як інші - на основі RHEL 4.

Ці два біти вище, які я перевірив, - це те, що, здається, пропонує більшість людей, коли люди мали цю проблему.

Я мушу зазначити, що я отримую дивну помилку в журналах при перезапуску 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

Незважаючи на те, що цей /usr/local/nagios/etc/nrpe.cfgфайл , безумовно, читає цей файл, щоб отримати речі, про які він говорить далі.

У вас проблема з правами.

Змініть команду на:

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

(додати судо)

Потім додайте nagios-користувача до sudoers:

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

Або ви могли просто chmod файл ... Це також працює.

Якщо ви використовуєте CentOS, Red Hat, Scientific або Fedora, переконайтесь, що вимкнено Defaults requirettyфайл судорів.

Коротка відповідь: якщо ви використовуєте плагін Bash, переконайтеся, що у вас є шебанг із зазначенням, який інтерпретатор слід використовувати:#!/bin/bash

Я зіткнувся з тим же питанням із плагіном Nagios, який я написав сам. Сценарій працював так, як очікувалося при локальному запуску, навіть при запуску як користувач із nagiosвикористанням наступного оператора:

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

Але віддалений запуск за допомогою NRPE з сервера Nagios3 виявився невдалим:

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

Нарешті я вирішив цю справу, додавши шебанг у свій сценарій, оскільки виявилося, що для запуску сценарію через NRPE не використовується той же інтерпретатор, як при запуску sudo sudo -s -u nagios.

У моєму випадку проблема була просто - користувацькі nagios не змогли виконати сценарій. Після chmod він почав працювати. Судо не потрібно. Це навіть зло :)

check_nrpe отримував "NRPE: Не вдається прочитати вихід", незважаючи на те, що перевірка працює локально, оскільки плагін, який я використовував, не працював добре з SELinux. Вимкніть його та переконайтесь, що вилучите контексти файлу:

$ 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

Перевірте шлях, дозволи, selinux, iptables.

У клієнта була проблема з маршрутизацією: nrpe.cfg, двічі перевірити шлях команди до імені плагіна check_ *. Вони можуть бути заплутаними, (lib / local) (libexec / plugins) як ім'я шляху. Я помилково потягнув і поклав шляхи від коментованого попередньо упакованого файлу nrpe cfg, щоб зробити команди. Make install або yum плагін встановлює їх у каталог difft.

командовано: / usr / local / nagios / libexec / check_disk

проти

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

З сервера я зміг підтвердити, що це не проблема з брандмауером, міг передати телнет на порт 5666, міг запустити ковдру check_nrpe і отримати статус поверненого значення. Не міг запускати команди локально, але nrpe мав неправильний шлях на клієнті в nrpe.cfg.

У моєму випадку лише один плагін вийшов з ладу, а кілька інших працювали нормально. Це виявилося проблемою LOCALE.

Плагін був, check_mem.shі він виконував греп для Memна виході free. Але система LOCALE повернула Speicher(німецька) замість Mem, тому всі отримані значення були порожніми рядками.

Це проблема з дозволом, просто дайте право виконання сценарію, і це буде добре:

ось приклад: До / Віддалений хост :

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

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

Після: Віддалений хост :

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

Проблема вирішена.

У моєму випадку моніторинговий файл журналу належав root: adm, тому додавання користувача nagios до групи adm зробило команду check_log успішною, але лише тоді, коли виконується безпосередньо на хостах, що контролюються. Він продовжував виходити з ладу за допомогою check_nrpe на сервері Nagios, поки я не перезапустив сервіс nagios-nrpe-сервер на хостах, що контролюються, наприклад

service nagios-nrpe-server restart

Тому, очевидно, перезапуск послуги був необхідний, щоб зміни дозволів набули чинності для NRPE, але мені знадобилося деякий час, щоб це зрозуміти.

У разі користувацьких плагінів NRPE обов'язково надрукуйте деякий вихід разом із значенням виходу. Якщо немає виводу зі сценарію, NRPE скаржиться на те, що "NRPE не може прочитати вихід" . Ви можете увімкнути налагодження в nrpe.cfg і спостерігати за цією помилкою.

У моєму випадку проблеми були пов'язані з selinux (працює RHEL 6.5, selinux встановлений для виконання).

Встановлення nagios-plugins- * через yum створить ваші плагінні файли в / usr / lib64 / nagios / plugins. Якщо ви перевірте fcontext для цих файлів плагінів (ls -lZ), ви побачите, що для файлів тип контексту встановлено на "nagios_system_plugin_exec_t", що є типом контексту, якого очікує check_nrpe.

У моєму випадку я створив користувацький сценарій "check_mem.sh", використовуючи "vi". У отриманому файлі тип контексту був встановлений на "lib_t". Це викликало nrpe для виведення "NRPE: Не вдається прочитати вихід".

Зміна контексту файлу на "nagios_system_plugin_exec_t" вирішила проблему:

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

Звичайне усунення несправностей із selinux вказувало б і на цю проблему (перевірка /var/log/audit/audit.log), але, звичайно, це було останнє, про що я думав

Редагувати: chcon просто тимчасово змінює контекст. Щоб постійно його змінювати, використовуйте 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

Можливо, ви не встановили свої плагіни Nagios, NRPE не може їх знайти або отримати доступ до них.

Мені ніколи не доводилося додавати команди до Судорів. Переконайтеся, що командами належить користувач Nagios, і вони читаються.

Я думаю, ви повинні додати плагіни у своєму місцевому реєстрі /usr/lib64/nagios/plugins/*. У мене була така ж проблема, як у вас, і я можу вирішити це рішення.

У мене була проблема, що ти пишеш. Тест, який я проводив, був від perl. Поставте цей рядок у файл, /etc/nagios/nrpe.cfgщоб він працював.

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

Є дуже приємна стаття, яка охоплює всю установку та конфігурацію агента NRPE з багатьма прикладами check_commands, я використовую цю статтю, коли мені потрібно встановити NRPE на новому сервері. Більше того, в кінці сторінки ви можете знайти класний сценарій, який автоматично встановлює і налаштовує NRPE для вас (на основі встановлених вами змінних), тут можна знайти статтю: Тут

Зазвичай це відбувається, коли сервер NRPE запускається з користувачем nrpe замість nagios.

Зміна nrpe_userзначення на нагіоси у /etc/nagios/nrpe.cfgфайлі має вирішити вашу проблему.

При необхідності nrpe_groupможна також змінити балончик.

Ще одна річ, яку потрібно перевірити, - це те, що якщо ваша команда використовується sudo -u <another user>для запуску команди, libexecкаталог (та каталоги над нею) повинні бути читатими користувачем, на який судили.

Наприклад, якщо ваша команда:

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

Користувач tomcat повинен мати доступ до цього файлу.

Одним із способів виправити це було б:

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

Заміна останньої частини там, де живуть ваші виконавчі файли

У мене була така ж проблема, і мені вдається вирішити її, вбиваючи процес нагіосу (на моніторованій машині):

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

Після цього все пішло нормально.

Якраз виникла ця проблема на FreeBSD. Після удару головою об стіну протягом години я зрозумів, що проблема /usr/local/nagios/etc/nrpe.cfgвказує на неправильне місце для судо.

Щоб знайти правильне місце для вказівки для запуску команди sudo:

# whereis sudo

Потім я змінив command_prefix у nrpe.cfg з:

command_prefix=/usr/local/sudo

до:

command_prefix=/usr/local/bin/sudo

Потім побіг service nrpe restartі проблема була вирішена.

Можливо, подібні проблеми можуть бути і в інших операційних системах, лише інша справа, щоб перевірити, чи ви перевірили всі інші можливі проблеми з дозволами, і все-таки вирішили цю проблему.

Немає плагінів Nagios на клієнті nrpe.

Не використовуйте yum install nagios-plugins (nagios-plugins-2.0.3-1.el6.x86_64). Він не встановлює всі плагіни. Завантажте nagios-plugins-1.4.11.tar.gz та дотримуйтесь інструкцій у цьому документі.

http://www.thegeekstuff.com/2008/06/how-to-monitor-remote-linux-host-using-nagios-30/

У мене була ця проблема, і я вирішив відключення selinux

setenforce 0