NRPE не может прочитать вывод, но почему?

27

У меня эта проблема с 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файл, чтобы понять, о чем идет речь, в дальнейшем.

nagios nrpe ticktockhouse
источник
возможный дубликат NRPE не может прочитать вывод, но почему?
mailq 20.10.11
Давайте сохраним этот, так как другой был закрыт.
Барт Де Вос
Также убедитесь, что STDOUT действительно сброшен.

Ответы:

35

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

Измените команду на:

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

(добавить sudo)

Затем добавьте пользователя nagios в sudoers:

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

Или вы можете просто chmod файл ... Это тоже работает.

Если вы используете CentOS, Red Hat, Scientific или Fedora, обязательно отключите их Defaults requirettyв файле sudoers.

Барт Де Вос
источник
1
@Bart De Vos, но ответ, который вы добавили, сделает дыру в безопасности> добавление чего-либо в файл sudoers откроет вам потенциальную угрозу безопасности. то есть, если через переполнение буфера кто-то может удалить файл с тем же именем в том же месте, он может выполнить его, не зная пароля root, и получить контроль над полем: S Нет ли способа каким-либо образом поставить подпись (SHA1 или MD5) приложения в файле sudoers для предотвращения атак такого типа. т.е. внедренный файл не будет иметь одинаковую подпись и, следовательно, не выполняется. [Прочитайте первый комментарий здесь] ( crashatau.blogspot.co
Ахмад Хаджар
1
@ X-Ware: Хотя это действительно так, вероятность переполнения буфера здесь очень мала. Однако, чтобы этого не случилось, вы должны использовать apparmor / SELinux. Вот почему эти вещи существуют.
Барт Де Вос
Я предполагаю, что в разных дистрибутивах даже есть разные пользователи, в моем случае пользователь, добавляющий в visudo, был npre, а не nagios. Я все еще следовал решению Барта Де Воса, однако вы можете увидеть, какой пользователь пытается получить доступ к команде nrpe, просмотрев журнал / var / log / secure access. 24 июля 15:39:09 имя хоста sudo: nrpe: пользователь NOT в sudoers; TTY = неизвестно; PWD = /; ПОЛЬЗОВАТЕЛЬ = root; COMMAND = / usr / lib64 / nagios / plugins / check_disk -w 20% -c 10% -p / dev / mapper / vg_uxp-lv_root
@AhmadHajjar Ты серьезно? Вы думаете, что кто-то взломает nagios (система, которой 20 лет) и использует этого пользователя для запуска файла с правами root. И вы думаете, что я не сделал исполняемый файл для запуска с правами суперпользователя как доступный только для чтения, чтобы предотвратить копирование файла поверх него? Если вы беспокоитесь об этом, вместо использования sudo вы можете установить сам исполняемый файл check_openmanage и позволить любому запускать его!
Эван Ланглуа
11

Краткий ответ: если вы используете плагин 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 скрипта ruby ​​с rbenv. Исправлено было создание скрипта-обертки с#!/bin/bash -el eval "$(rbenv init -)" /usr/lib/nagios/plugins/check_something $@
TrinitronX
1
удивительный ответ! sudo -s -u nagios позволил мне понять, почему nagios не может вернуть вывод из определенного плагина. большое спасибо!
Уфк
6

В моем случае проблема была просто - пользователь nagios не смог выполнить скрипт. После chmod это начало работать. Судо не обязательно. Это даже зло :)

bluszcz
источник
1
Настоящий ответ таков. Nagios не смог выполнить скрипт из-за неправильных разрешений, неправильного написания скрипта или отсутствия скрипта.
droope
5

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
AX Labs
источник
хотя отключение selinux, как правило, не является хорошей идеей для тестирования, оно все еще действует.
Деннис Нольте
4

Проверьте пути, разрешения, selinux, iptables.

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

Командный: / usr / local / nagios / libexec / check_disk

против

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

С сервера я смог подтвердить, что это не проблема брандмауэра, он мог подключиться к порту 5666, мог запустить общий check_nrpe и получить статус в качестве возвращаемого значения. Может выполнять команды локально, но nrpe указал неверный путь на клиенте в nrpe.cfg.

Привет, мир
источник
4

В моем случае только один плагин вышел из строя, а несколько других работали нормально. Это оказалось локальной проблемой.

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

порыв
источник
2
Раш, добро пожаловать в SF! На мой взгляд, это отличный первый ответ: кратко, и он добавляет что-то новое в коллекцию ответов уже здесь. +1 от меня, и я надеюсь прочитать больше таких ответов от вас в будущем (я надеюсь, вы простите мое небольшое редактирование форматирования).
MadHatter поддерживает Монику
2

Это проблема с правами, просто дайте право выполнения скрипта, и все будет в порядке:

Вот пример: До / Удаленный хост :

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

Проблема решена.

Юсеф АСЕБРИЙ
источник
1
Хороший ответ, но также приятно отметить, что разрешение всем пользователям запускать check_nrpe, как это делает chmod o + x, может представлять потенциальную угрозу безопасности, в зависимости от того, как система настроена / доступна / используется.
австралиец
1

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

service nagios-nrpe-server restart

Очевидно, что перезапуск службы был необходим для того, чтобы изменение разрешений вступило в силу для NRPE, но мне потребовалось некоторое время, чтобы понять это.

Тони
источник
1

В случае пользовательских плагинов NRPE обязательно распечатайте некоторые выходные данные вместе со значением выхода. Если в сценарии нет выходных данных, NRPE выдаст сообщение «NRPE не может прочитать выходные данные» . Вы можете включить отладку в nrpe.cfg и наблюдать за этой ошибкой.

Картик
источник
1

В моем случае проблемы были связаны с 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

Александру Тодическу
источник
0

Возможно, вы не установили свои плагины Nagios, NRPE не может их найти или получить к ним доступ.

Мне никогда не приходилось добавлять свои команды в Sudoers. Убедитесь, что команды принадлежат пользователю Nagios и доступны для чтения.

Дэниел Бейкер
источник
0

Я думаю, что вы должны добавить плагины в ваш локальный каталог /usr/lib64/nagios/plugins/*. У меня была та же проблема, что и у вас, и я могу решить ее с помощью этого решения.

Тарик Насер
источник
0

У меня была проблема, которую ты пишешь. Тест, который я провел, был от Perl. Поместите эту строку в файл, /etc/nagios/nrpe.cfgчтобы он работал.

command [check_memory] = /usr/bin/perl /usr/lib64/nagios/plugins/check_memory -w 75-c 90
user224319
источник
0

Есть действительно хорошая статья, которая охватывает всю установку и настройку агента NRPE со многими примерами check_commands, я использую эту статью, когда мне когда-либо нужно установить NRPE на новый сервер. Более того, в конце страницы вы можете найти классный скрипт, который автоматически устанавливает и настраивает NRPE для вас (в зависимости от установленных вами переменных), статью можно найти здесь :

Итай Ганот
источник
Ссылка обновлена
Итай Ганот
0

Обычно это происходит, когда сервер NRPE запускается с пользователем nrpe вместо nagios.

Изменение nrpe_userзначения в /etc/nagios/nrpe.cfgфайл nagios должно решить вашу проблему.

Также nrpe_groupможно изменить при необходимости.

Умут Узун
источник
0

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

Замена последней части на то, где живут ваши исполняемые файлы

Митч
источник
0

У меня была та же проблема, и мне удалось решить ее, убив процесс nagios (на контролируемой машине):

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

После этого все прошло хорошо.

user428879
источник
0

Просто была эта проблема во 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и проблема была решена.

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

Graeme
источник
-2

У меня была эта проблема и я решил отключить selinux

Сетенфорс 0

Пауло Азедо
источник
2
Добро пожаловать в сбой сервера. Можете ли вы более подробно объяснить, как / почему это работает?
Я говорю: восстанови Монику