В EPEL наконец завезли 4-ую ветку Nagios. Однако при обновлении есть вероятность столкнуться с рядом небольших особенностей.
Основные из них:
- При старте Nagios, демон падает из-за ошибки доступа к сокету. Данная проблема даже встречается в багзиле РедХата — https://bugzilla.redhat.com/show_bug.cgi?id=1291718
По логам видно, что демон пытается открыть сокет в директории /var/log/nagios/rw, но отваливается с ошибкой:
nagios: qh: Failed to init socket '/var/log/nagios/rw/nagios.qh'. bind() failed: No such file or directory
Тут все просто, по умолчанию, это директории нет, вернее нет последнего пункта пути — rw. Достаточно его создать, выставить права и все будет замечательно:
drwxr-xr-x. 2 nagios nagios 4096 Dec 24 14:41 rw
Однако, как выяснилось, это еще не все. Дальше в дело вступает всеми любимый SELinux и демон начинает падать с ошибкой доступа к сокету:
qh: Failed to init socket '/var/log/nagios/rw/nagios.qh'. bind() failed: Permission denied
Тут есть два варианта — отключить SELinux и не мучиться, что не правильно, либо взять в руки audit2allow и добавить необходимые разрешения в политику. audit2allow — замечательная утилита, которая позволяет разобрать данные, записанные в лог аудита, в которых содержатся ошибки доступа, и на их основе сгенерировать набор правил. Эта утилита входит в пакет policycoreutils-python, который по умолчанию не установлен, так что его нужно поставить. Более подробное описание можно найти в документации RH — https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow.html
Краткое описание — сначала необходимо посмотреть, что же пошло не так, при попытке доступа, с помощью команд audit2allow -w -a и audit2allow -a, а затем оформить необходимые разрешения в модуль с помощью команды audit2allow -a -M mycertwatch, ну и установить его semodule -i mycertwatch.pp
После чего, снова запустить демон. Тут он опять упадет с ошибкой доступа, но уже другой:
nagios: qh: Failed to init socket '/var/log/nagios/rw/nagios.qh'. unlink() failed: Permission denied
Можно снова прогнать audit2allow и добавить недостающие права, после чего ошибка опять изменится:
nagios: Failed to connect to query socket '/var/log/nagios/rw/nagios.qh': connect() failed: Permission denied
В общем здесь потребуется несколько итераций этого цикла, чтобы добиться того, что все необходимые разрешения наконец будут проставлены и демон перестанет ругаться на сокет. - Следующий этап борьбы — это проблема с модулем ndoutils. Здесь nagios начинает красиво падать с ошибкой вида:
nagios: Error: Could not load module '/usr/lib64/nagios/brokers/ndomod.so' -> /usr/lib64/nagios/brokers/ndomod.so: undefined symbol: hostdependency_list
Тут все просто. В репозиториях лежит еще старая версия ndoutils, которая подходит для третьей ветки, но не работает с четвертой. Тут особо делать нечего, так что пока в репозитории не появится новая версия все плохо. Можно правда пойти другим путем и тих мирно собрать новую версию. Делается это достаточно просто. Здесь — http://sourceforge.net/p/nagios/ndoutils/ci/ndoutils-2-0/tree/ присутствует достаточно подробная инструкция по сборке. Я использую отдельную станцию для сборки софта, как в обычном виде, так и пакетируя его. Для ndoutils проще не создавать пакет, поскольку данный пакет уже стоит в системе. Здесь проще собрать сами библиотеки и закинуть их в систему. Для сборки потребуется поставить роль «Development Tools» (yum groupinstall ‘Development Tools’).
Сама сборка проходит быстро — ./configure и make, единственный момент — потребуется поставить dev-пакет для MySQL (ныне MariaDB), поскольку для сборки нужны соответствующие заголовки (yum install mariadb-devel).
После того, как сборка закончится, можно раскидать необходимые файлы и поправить юнит для запуска ndo2mod. Это финт делается для того, чтобы установленный пакет не конфликтовал с собранным и не пришлось его удалять (до того момента, как в репозитории положат необходимую версию).
ndomod-4x.o закидывается в /usr/lib64/nagios/brokers/ с именем ndomod.o (здесь не будет конфликта, поскольку в дистрибутиве идет файл ndomod.so). Файл ndo2db-4x.o — в директорию /usr/sbin/, но, уже с именем ndo2db4, чтобы не конфликтовать с существующим. Конфигурационные файл можно оставить как есть, поскольку формат не изменился и все подхватится корректно. Нужно поправить только /etc/nagios/nagios.cfg, а именно изменить строчку
broker_module=/usr/lib64/nagios/brokers/ndomod.o config_file=/etc/nagios/ndomod.cfg
скорректировав путь (ndomod.o вместо ndomod.so), ну и сам юнит запуска демона ndo2mod.
Здесь лучше скопировать юнит в /etc/systemd/system/ndo2db.service, чтобы не править системный, который лежит в /usr/lib/systemd/system/ndo2db.service, и поправить строку запуска:
ExecStart=/usr/sbin/ndo2db4 -c /etc/nagios/ndo2db.cfg
Здесь задается путь к новому файлу, вместо старого ndo2db
Теперь все должно запускаться корректно. - Старая и злая засада с IO::Socket::SSL и SSL_VERIFY_NONE. Если используются некоторые старые модули, которые работают через SSL, то они могут сломаться. Все просто, сам скрипт отрабатывает корректно, но при выводе результатов вываливается красивое предупреждение вида:
*******************************************************************
Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
is deprecated! Please set SSL_verify_mode to SSL_VERIFY_PEER
together with SSL_ca_file|SSL_ca_path for verification.
If you really don't want to verify the certificate and keep the
connection open to Man-In-The-Middle attacks please set
SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application.
*******************************************************************
Естественно, Nagios от такого выхлопа немного расстраивается и монитор считается неисправным, возвращая результат UNKNOWN. Здесь, по хорошему, надо переписать проблемное место с учетом рекомендаций (http://search.cpan.org/~sullr/IO-Socket-SSL-1.962/lib/IO/Socket/SSL.pm#BUGS), но если очень лень, то можно повесить грязный хак. У меня проблемным монитором оказался check_imap_receive и я тупо переправил строку вызова безопасного соединения с
my $socket = IO::Socket::SSL->new(PeerAddr=>"$imap_server:$imap_port", %ssl_args);
на
my $socket = IO::Socket::SSL->new(PeerAddr=>"$imap_server:$imap_port",SSL_verify_mode => 0x00);
это очень грубо и некрасиво, но если надо быстро заставить работать, то сойдет.
В остальном, обновление прошло в целом спокойно. Вылезло еще несколько небольших косяков, связанных с более строгим подходом к конфигурационным файлам, но это уже мелочи и особенности самописной конфигурации.
Отдельно стоит отметить, что некоторые мониторы также падали с проверками из-за SELinux, так что для них тоже пришлось погонять audit2allow.
Уютный бложег 