• Patchman и ошибка веб-сервера Apache "AH03490: scoreboard is full, not at MaxRequestWorkers. Increase ServerLimit"

    Patchman and Apache Web Server Error AH03490: scoreboard is full, not at MaxRequestWorkers.Increase ServerLimitСпустя некоторое время после начала эксплуатации развёрнутого ранее сервера Patchman, мы столкнулись с ошибкой в работе веб-сервера Apache. Было замечено, что через несколько дней после запуска службы веб-сервера, веб-интерфейс сервера Patchman перестал штатным образом отвечать на запросы клиентов. При этом попытки обращения к любым URL веб-сервера в логе /var/log/apache2/error.log стали сопровождаться ошибками "AH03490: scoreboard is full, not at MaxRequestWorkers.Increase ServerLimit". Простой перезапуск юнита службы веб-сервера apache2.service купировал проблему, но примерно через неделю проблема воспроизвелась повторно.

    Читать далее...

  • Patchman : Kerberos аутентификация и LDAP авторизация в Django в домене Active Directory

    Patchman : Single Sign-On Authentication and Authorization in Django with Kerberos and LDAPРассмотренный ранее сервер Patchman на базе веб-фреймворка Django, в нашем случае функционирует в инфраструктуре, имеющей службу каталогов Microsoft Active Directory, поэтому для большего удобства работы с веб-интерфейсом Patchman возникает желание настроить на веб-сервере аутентификацию пользователей с помощью протокола Kerberos, а также авторизацию с помощью протокола LDAP через доменные группы безопасности. То есть, предполагается реализация механизма SSO (Single Sign-On) для того, чтобы пользователи не вводили какие-то локальные учётные записи каждый раз при входе в веб-интерфейс Patchman, а прозрачно получали доступ к сайту на основе своей доменной учётной записи, в контексте которой запущен клиентский браузер. Читать далее...

  • Развёртывание Patchman (Linux Patch Status Monitoring System) на базе Debian 12

    Deploying Patchman (Linux Patch Status Monitoring System) on Debian 12Patchman (Linux Patch Status Monitoring System) представляет собой систему отчётности о состоянии актуальности пакетной базы компьютеров на базе ОС Linux. Patchman имеет клиент-серверную архитектуру. Серверная часть представляет собой фронтэнд в виде веб-сервера на базе фреймворка Django с бакендом в виде базы данных SQLite/MySQL/PostgreSQL. Клиентская часть является по сути легковесным скриптом, работающим с такими пакетными менеджерами как YUM, APT и Zypper.

    Клиенты Patchman при каждом запуске отправляют список установленных пакетов и включенных репозиториев на сервер Patchman. Сервер Patchman по полученным от клиентам репозиториям формирует собственную базу метаданных о доступных в этих репозиториях пакетах. После этого сервер сопоставляет версии пакетов в метаданных репозиториев и на клиентах и в наглядном виде показывает то, какие хосты требуют обновлений, и являются ли эти обновления обычными или обновлениями безопасности. Кроме этого веб-интерфейс Patchman предоставляет дополнительную информацию о потенциальных проблемах, таких как пакеты, не имеющие привязки к репозиториям или включенные на клиентах репозитории, имеющие проблемы с онлайн-доступностью.

    При работе с веб-интерфейсом информация о хостах, пакетах, репозиториях и операционных системах может быть отфильтрована. Это позволяет, например, быстро получить информацию о том, на каких хостах установлена ​​определенная версия пакета и с каким репозиторием она сопоставима.

    С точки зрения взаимодействия клиента Patchman с пакетным менеджером работа выполняется в режиме "только чтение", то есть клиент не занимается обновлением кеша пакетного менеджера и не устанавливает пакеты обновлений на хосты. Плагины yum, apt и zypper отправляют отчеты на сервер Patchman каждый раз, когда выполняются стандартные процедуры установки/обновления/удаления пакетов на хосте.

    Читать далее...

  • Развёртывание Icinga 2 на базе Debian 12. Часть 6. Конфигурация веб-сервера Apache для интеграции Icinga Web 2 c Active Directory

    Deploying Icinga 2 on Debian 12. Part 6. Configuring the Apache web server to integrate Icinga Web 2 with Active DirectoryВ этой заключительной части нашего плана развёртывания Icinga на Debian GNU/Linux 12 "Bookworm" мы коротко обозначим основные моменты конфигурации веб-сервера Apache для интеграции Icinga Web 2 со службой каталогов Microsoft Active Directory, опираясь на более подробный материал, изложенный ранее в статье "Аутентификация и авторизация пользователей Active Directory в Icinga Web 2 (Kerberos и SSO)".

    Читать далее...

  • Локальный сервер обновлений для устройств MikroTik на Debian Linux

    Local update server for MikroTik devices on Debian LinuxДля поддержания актуального состояния прошивок MikroTik необходимо периодически обновлять их на всём парке устройств. И не всегда есть возможность открыть доступ в Интернет, чтобы устройство могло загрузить прошивку с серверов обновлений MikroTik. На этот случай вендор предлагает два штатных варианта действий: ручное или автоматизированное копирование прошивок на устройство с последующей перезагрузкой, либо настройка выделенного устройства в качестве источника обновлений для остальных устройств. Оба этих варианта имеют свои недостатки.

    В этой заметке мы рассмотрим ещё один, альтернативный, вариант - это создание локального веб-сервера, который бы имитировал структуру каталогов оригинального сервера обновлений upgrade.mikrotik.com. Подобный сервер позволит решить две основные проблемы: распространение обновлений в локальной сети без доступа в Интернет и контроль за версией прошивок, которые будут устанавливаться на устройствах.

    В случае выхода обновления прошивки администратор с помощью скрипта загружает новое обновление для всех интересующих его платформ. Проводиться обновление тестовой группы устройств, проверяется их работа. После тестирования можно выполнить развёртывание и на другие устройства. Или вернуть предыдущую версию, если новая версия не устраивает.

    Далее пошаговая инструкция по развёртыванию и использованию локального сервера обновлений.

    Читать далее...

  • Добавление SPN записей в keytab-файл (на стороне сервера Linux с помощью утилиты ktutil), связанный с учётной записью Computer в домене Active Directory

    Представим себе ситуацию, что есть некий сервер на базе Debian GNU/Linux, который уже введён в домен Active Directory с помощью SSSD и realmd и на нём уже имеется keytab-файл, который используется для механизмов аутентификации Kerberos и Single sign-on (SSO) при подключении к серверу по протоколу SSH. И вот возникает необходимость на данном Linux-сервере дополнительно настроить роль веб-сервера для служебных администраторских задач и организовать Kerberos SSO при подключении к веб-узлам этого веб-сервера. По ранее описанным примерам (здесь, здесь и здесь), предполагается, что для целей Kerberos-аутентификации веб-сервера Apache в домене Active Directory (AD) создаётся отдельная сервисная учётная запись типа User, для которой генерируется keytab-файл и в последствии привязывается к настройкам Apache на стороне Linux-сервера. С точки зрения аспектов безопасности такой поход (отдельный Linux-сервис = отдельная учётная запись в AD со своим keytab-файлом) можно считать вполне правильным. Но что, если Linux-сервис, использующий Kerberos-аутентификацию, используется не широким кругом пользователей, а исключительно для административных целей парой-тройкой системных администраторов? В таком случае создание отдельной учётной записи типа User в домене со своим keytab-файлом может показаться избыточным. В этой заметке мы рассмотрим пример того, как добавить дополнительную нужную нам запись servicePrincipalName (SPN) (на примере SPN-записи типа HTTP/) в уже имеющийся на Linux-сервере keytab-файл, ориентированный на сам хост (содержащий SPN-записи типа HOST/). В результате мы получим Kerberos аутентификацию на веб-узлах нашего Linux-сервера и при этом не будем плодить в домене лишние сервисные учётные записи типа User.

    Читать далее...

  • Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 11. Настройка интеграции Graphite в Icinga Web 2

    В развёрнутой ранее конфигурации Icinga Web 2 по умолчанию отсутствует возможность просматривать исторические графики изменения показателей производительности объектов мониторинга. Однако фронтенд Icinga Web 2 имеет модуль расширения, который позволяет получать данные из Graphite. В этой заметке мы рассмотрим пример интеграции Graphite в Icinga Web 2.

    Читать далее...

  • Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 10. Аутентификация и авторизация пользователей Active Directory в Icinga Web 2 (Kerberos и SSO)

    В этой части нашего цикла заметок об 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-каталогу.

    Читать далее...

  • Создание keytab-файла, содержащего несколько разных Kerberos Principal

    Разные службы и приложения, работающие в Linux и использующие аутентификацию Kerberos, например в связке с контроллерами домена Active Directory (AD), используют для механизмов этой самой аутентификации специальный keytab-файл, который содержит хеши пароля доменной учётной записи пользователя, с которым ассоциирована та или иная служба в Linux-системе (как с Kerberos Principal). И вполне типичной и распространённой практикой является создание отдельного keytab-файла для каждого принципала Kerberos. То есть, как правило, прослеживается такая логика: отдельная учётная запись служебного пользователя в AD, для которого зарегистрировано конкретное имя службы ServicePrincipalName (SPN) => отдельный keytab-файл, сопоставимый с записью SPN в AD.

    Читать далее...