Собрание заметок об информационных технологиях
На днях получил по электронной почте интересный комментарий к статье про подключение Debian GNU/Linux 8.6 к домену Active Directory с помощью SSSD и realmd от одного из наших читателей - Степана Кохановского. В силу того, что данный комментарий объёмен и описывает некоторое обходное решение известной проблемы, я решил опубликовать его в виде отдельного поста.
В данной заключительной части нашего цикла заметок о развёртывании и базовой настройке Icinga будет рассмотрен пример того, как настроить SMS оповещения с помощью Icinga Director 1.3.1 и подключаемого плагина уведомлений (Notification Plugin).
В данной части цикла заметок об Icinga мы продолжим тему мониторинга сетевых устройств по протоколу SNMP и рассмотрим пошаговый пример настройки ловушки SNMP Trap в конфигурации Icinga Director. Сразу хочу отметить тот факт, что в Icinga нет встроенных механизмов получения и обработки SNMP Trap. Поэтому, для того, чтобы реализовать нужный нам функционал, нам потребуется настроить стек состоящий из ряда элементов:
В прошлый раз мы поговорили о развёртывании Graphite и настройки модуля интеграции с Icinga Web 2, что позволяет привнести возможности отображения графиков производительности непосредственно в веб-интерфейсе Icinga Web 2. Однако говоря о теме визуализации накопленных метрических данных, нельзя обойти вниманием такой интересный инструмент, как Grafana. В этой заметке мы рассмотрим простейший пример развёртывания фронтэнда Grafana на Debian Jessie (с подключением к данным Graphite) и посмотрим, какие у нас имеются на сегодняшний день возможности интеграции этой красоты с Icinga Web 2.
В развёрнутой ранее конфигурации Icinga Web 2 по умолчанию отсутствует возможность просматривать исторические графики изменения показателей производительности объектов мониторинга. Однако фронтенд Icinga Web 2 имеет модуль расширения, который позволяет получать данные из Graphite. В этой заметке мы рассмотрим пример интеграции Graphite в Icinga Web 2.
В этой части нашего цикла заметок об Icinga будет рассмотрен пример того, как можно организовать доменную аутентификацию пользователей Active Directory (AD) с поддержкой Kerberos и Single sign-on (SSO) при подключении к веб-консоли Icinga Web 2.
Если мы заглянем в опорный документ Icinga Web 2 Authentication, то узнаем, что веб-консоль Icinga Web 2 способна работать с аутентификаций, основанной на каталоге Active Directory, других реализациях LDAP-каталогов, базах данных MySQL или PostgreSQL, а также делегировать процесс аутентификации непосредственно веб-серверу. Так, как в рассматриваемом нами примере будут использоваться такие вещи, как аутентификация с помощью Kerberos и дополнительная авторизация с помощью PAM, выбран вариант с делегированием процесса аутентификации веб-серверу. При этом процедуры внутренней проверки прав доступа к объектам веб-консоли Icinga Web 2 будут выполняться через специально созданное подключение к AD, как к LDAP-каталогу.
Когда мы рассматривали настройку SSSD на Debian 8 (Jessie), немного упоминали о возможности ограничения доступа к Linux-системе через группы безопасности в домене Active Directory. Однако рассматриваемый в том случае пример предполагает безусловное глобальное ограничение доступа на уровне всей Linux-системы. То есть, указанная в секции описания домена конфигурационного файла sssd.conf опция simple_allow_groups ограничивает доступ не только для входа в систему, но и для всех других служб внутри этой системы, которые будут использовать возможности SSSD. Таким образом, рассмотренный ранее пример настройки авторизации с помощью SSSD в Apache точно также, как и другие сервисы, использующие SSSD, будет ограничен глобальной опцией simple_allow_groups. Но как же быть, если доступ к Linux-системе и её отдельным сервисам требует гранулированной настройки? Например, требуется, чтобы право локального и/или удалённого входа в систему имели члены одной доменной группы безопасности, а право доступа к какому-то сайту веб-сервера Apache (или даже отдельному веб-каталогу) имели члены другой группы безопасности домена Active Directory. Попробуем решить эту задачу с помощью настройки механизма подключаемых модулей аутентификации - Pluggable Authentication Modules (PAM), а конкретнее с помощью использования возможностей библиотеки pam_listfile.so.
В этой части нашего цикла заметок об Icinga будет рассмотрен пример того, как настроить оповещения по электронной почте с помощью Icinga Director 1.3.0 и подключаемого плагина уведомлений (Notification Plugin).
В этой части мы рассмотрим практический пример создания собственной Команды (Icinga Command) с набором аргументов в Icinga Director 1.3. В качестве подключаемого к Icinga плагина будем использовать плагин check_cpu.sh для мониторинга нагрузки на процессор с возможностью настройки допустимых границ нагрузки.
Прошлую заметку про основные приёмы использования Icinga Director мы закончили на том, что после создания Служб из базового набора Команд Icinga, автоматически импортированных в Icinga Director, можно столкнуться с ситуацией, когда стандартные настройки Команд приводят к не совсем ожидаемому результату. Например, используемые по умолчанию аргументы Команды http приводят к переводу созданной нами Службы http в состояние WARNINIG для некоторых клиентов Icinga, хотя на самом деле веб-сервер на этих системах работает штатно. Попробуем разобраться с тем, почему так происходит, и как в Icinga Director 1.3 можно решить этот вопрос.
Оба файла загрузил сюда, если кому всё ещё надо: https://disk.yandex.ru/d/gBRReDO6tBGloQ
Александр. спасибо за интересный содержательный комментарий.
RSS - Записи
Последние комментарии