Тайм-аут сокета NRPE через NRPE, работает как пользователь nrpe

nrpe на сервере Azure — nrpe-srvr, пользователь nrpe, выполнение скрипта /usr/local/naemon/libexec/check_curl_http.php я назову его script

Желаемый результат после ./script -U www.google.com:

Page OK: HTTP Status Code 200 - 11099 bytest in 0.** seconds | time=0.059 size=11099

Я получаю вышеуказанный результат, запуская скрипт из root или nrpe

Запуск sudo -u nrpe ./script -U www.google.com возвращает:

Ошибка открытия страницы! Err: Не удалось подключиться к [ipv6 addr] Сеть недоступна

Однако запуск su - nrpe -c './script -U www.google.com' работает с желаемым результатом.

Наймон сообщает:

CHECK_NRPE: тайм-аут сокета через 30 секунд

Другие проверки NRPE на том же хосте работают, поэтому я думаю, что это как-то связано с выполнением пользователем этого конкретного скрипта. У меня был отказ от SELinux, но я изменил контекст. Удаление контекста и установка разрешающего режима для SELinux привели к той же ошибке. Включены файлы журнала NRPE с отладкой, но, кроме Running command, это мало что показывает. Eсть:

WARNING: my_system() seteuid(0): Operation not permitted

в журналах, но глядя на документацию поддержки, это «нормальное» поведение.


person itChi    schedule 01.04.2019    source источник
comment
Попробуйте также запустить этот скрипт в подробном режиме.   -  person Rohlik    schedule 01.04.2019
comment
Я думаю, что скрипт работает нормально. На самом деле мне удалось заставить его работать как другой пользователь, используя su - nrpe - c './script -u www.google.com' в порядке. Так что я думаю, что сценарий это нормально. Выполнение NRPE вызывает проблему.   -  person itChi    schedule 01.04.2019


Ответы (1)


Я опубликую это на всякий случай, если у кого-то еще возникнет эта проблема, и я отмечу Azure/AWS.

По сути, облачные провайдеры (в основном) имеют внутренний прокси-сервер, который хранится в переменной среды http_proxy && https_proxy. NRPE по умолчанию не использует переменные среды загрузки. Теперь я не знаю, есть ли для этого вариант (в документах упоминается, что есть ошибка при использовании uid вместо имени пользователя (использовалось имя пользователя)), однако достаточно просто вызвать прокси для таких проверок.

person itChi    schedule 03.04.2019