• Развёртывание Icinga 2 на базе Debian 12. Часть 4. Настройка SNMP и интеграция с Icinga API

    Deploying Icinga 2 on Debian 12. Part 4. Configuring SNMP in IcingaВ этой части нашего плана развёртывания Icinga на Debian GNU/Linux 12 "Bookworm" мы рассмотрим особенности настройки поддержки протокола SNMP и интеграции механизма получения SNMP Trap с интерфейсом Icinga 2 API. Предполагается, что на предыдущих этапах мы уже успешно развернули фронтэнд Icinga Web 2 и провели базовую настройку и наполнение данными модуля Icinga Director.

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

  • Развёртывание Icinga 2 на базе Debian 12. Часть 3. Установка Icinga Director и миграция данных со старого сервера с помощью Configuration Baskets и файлов JSON

    Deploying Icinga 2 on Debian 12. Part 3. Installing Icinga Director and migrating data between servers using Configuration Baskets and JSON filesПродвигаясь по пунктам нашего плана развёртывания Icinga 2 на Debian 12, в прошлый раз мы провели развёртывание бакэнда Icinga DB и фронтэнда Icinga Web 2, а также выполнили инициализацию Master-сервера Icinga. Поэтому теперь мы готовы развернуть модуль Icinga Director и провести миграцию конфигурационных данных из старого экземпляра Icinga Director в новый.

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

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

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

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

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

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

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

  • Опрос сети на предмет используемых версий контроллеров HP iLO

    Несколько дней назад компания Hewlett Packard Enterprise опубликовала бюллетень безопасности HPESBHF03797 с информацией о наличии множественных удалённо эксплуатируемых уязвимостей в контроллерах управления HP Integrated Lights-Out 2 (iLO2) с прошивкой версии 2.29. Контроллеры iLO2 используются на серверных платформах HP пятого (G5) и шестого (G6) поколений в линейке 300-тых моделей, например ProLiant DL360/380, а также в некоторых других моделях, например ProLiant DL320s Gen1. Для закрытия уязвимостей необходимо выполнить установку прошивки версии 2.31 (7 Dec 2017). И если в локальной сети развёрнут репозиторий VCRM, то исполняемый файл прошивки можно добавить в этот репозиторий ранее описанным способом (для возможности установки прошивки на Windows Server 2012/2012 R2). Также прошивку можно обновить подключившись напрямую к веб-интерфейсу, встроенному в iLO2. Но в этой заметке речь пойдёт не о самой процедуре обновления, а о том, как провести аудит используемых версий iLO на всех серверах локальной сети. Такой аудит может быть полезен, с одной стороны - для того, чтобы предварительно оценить необходимый объем контроллеров, требующих обновления, и с другой стороны – в контрольных целях, в случае, если в организации между администраторами есть разделение на зоны обслуживания серверного оборудования.

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

  • Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 13.2. Настройка мониторинга сетевых устройств в Icinga Director (на примере контроллеров управления ИБП). Получение SNMP Trap

    В данной части цикла заметок об Icinga мы продолжим тему мониторинга сетевых устройств по протоколу SNMP и рассмотрим пошаговый пример настройки ловушки SNMP Trap в конфигурации Icinga Director. Сразу хочу отметить тот факт, что в Icinga нет встроенных механизмов получения и обработки SNMP Trap. Поэтому, для того, чтобы реализовать нужный нам функционал, нам потребуется настроить стек состоящий из ряда элементов:

    • snmptrapd – Служба SNMP Trap Daemon из состава Net-SNMP. Данная служба отвечает за прослушивание на сервере мониторинга UDP-порта и получение от внешних сетевых устройств сообщений SNMP Trap
    • snmptt – Служба SNMP Trap Translator (SNMPTT). Данный элемент отвечает за разбор и интерпретацию сообщений SNMP Trap, полученных от службы snmptrapd. В частности он преобразует числовые идентификаторы OID в читаемый формат, используя подключаемые MIB-файлы.
    • submit_snmp_trap – Скрипт, который принимает от службы snmptt нормализованное Trap-сообщение и, преобразовав данные этого сообщения в понятный для Icinga формат, отправляет их в командный pipe-файл Icinga.
    • "SNMP Trap" - специальная пассивная Служба Icinga, в которую будут "прилетать" данные из pipe-файла Icinga. Данная Служба будет служить нам для визуализации конечного результата в веб-интерфейсе Icinga Web 2, а также организации оповещений администратора о проблеме.

     

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

  • Развёртывание и настройка oVirt 4.0. Часть 11. Резервное копирование oVirt Hosted Engine

    Рассматривая тему резервного копирования в oVirt 4.0, выделю два основных направления – это резервное копирование данных самой системы управления oVirt Engine и резервное копирование виртуальных машин. В этой части мы рассмотрим конкретный практический пример автоматизации регулярного резервного копирования данных oVirt Hosted Engine 4.0.4 и с теоретической точки зрения поговорим о восстановлении. Читать далее...

  • Распределение трафика между двумя прокси-серверами Squid (на Ubuntu Server 14.04.2 LTS) подключёнными к двум интернет-провайдерам (Multi-WAN). Обновлённый вариант.

    image

    В общем случае для организации балансировки трафика между двумя WAN-интерфейсами на Ubuntu можно использовать способы описанные в документе Ubuntu-ru - IP-Балансировка: объединяем несколько интернет-каналов в один. В нашем случае требуется организовать немного более простую конфигурацию и поэтому способ её реализации будет несколько более прост. На уже работающих прокси-серверах Squid, собранных в конфигурацию повышенной доступности, имеется по одному WAN-интерфейсу направленному в сторону одного интернет-провайдера. Для повышения доступности Интернет для конечных пользователей мы добавим на прокси-серверы ещё по одному WAN-интерфейсу направленному в сторону другого интернет-провайдера и настроим скрипт перестроения правил маршрутизации в случае возникновения проблем с одним из провайдеров. Здесь мы рассмотрим обновлённый вариант такой настройки (без использования multipath-маршрутизации).

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

  • Аутентификация и авторизация в домене Active Directory при подключении к серверу Ubuntu Server 14.04 LTS

    imageВ одной из прошлых заметок мы рассмотрели процедуру присоединения сервера на базе Ubuntu Server 14.04 LTS к домену Active Directory (AD) для обеспечения работы процедур аутентификации и авторизации на прокси-сервере Squid 3.3. Тем самым мы упростили доступ рядовых доменных пользователей к ресурсам Интернет. Однако не стоит забывать и об администраторах. Использование локальных учетных записей для аутентификации и авторизации администраторов на Linux-серверах может доставлять свои неудобства, когда количество таких серверов в организации увеличивается. В этой заметке мы рассмотрим процедуры настройки сервера Ubuntu направленные на упрощение процедур аутентификации и авторизации при входе в Linux-систему путём использования учетных записей пользователей и групп безопасности домена AD.

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

  • Настройка прокси сервера Squid 3.3 на Ubuntu Server 14.04 LTS. Часть 9. Конфигурация LightSquid

    imageВ этой части мы рассмотрим инструмент разбора логов Squid3 и построения отчетов о пользовательской активности в Интернет – LightSquid 1.8. LightSquid по сути своей является набором Perl-скриптов, выполняющих анализ лог-файлов access.log* и способных на основе данных этого анализа строить HTML-отчёты. Выбор именно этого инструмента был сделан после ряда сравнительных экспериментов в контексте сопоставления функциональности с другими программами выполняющими аналогичные задачи.

    Немного предыстории. Поначалу я было уцепился за SARG, так как по истории выхода версий было предположено, что этот продукт развивается активней своих аналогов. Однако после его настройки и нескольких дней использования стали очевидны его недостатки, главным из которых оказался размер генерируемых отчетов даже при самых скромных настройках конфигурации. Размер ежедневного отчета сливаемого SARG на диск при количестве ~800 пользователей (не одновременно работающих, а в целом за день) составлял 1,2 – 1,5GB. Стало понятно, что если выпустить всех пользователей через Squid и рассчитывать при этом на хранение отчётов минимум за 3 месяца потребуется приличная дисковая ёмкость. LightSquid оказался в этом плане многократно скромнее при почти той-же функциональности отчетов, да ещё и выгодно отличился скоростью обработки access-лога.

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