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

    09.06.2024 Автор:Алексей Максимов
    826 Просмотров Комментариев нет

    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

    08.06.2024 Автор:Алексей Максимов
    920 Просмотров Комментариев нет

    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

    07.04.2024 Автор:Владимир Леттиев
    1 102 Просмотров 1 Комментарий

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

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

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

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

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

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

    18.01.2018 Автор:Алексей Максимов
    8 741 Просмотров 2 комментария

    Несколько дней назад компания 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

    23.08.2017 Автор:Алексей Максимов
    10 380 Просмотров 7 комментариев

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

    06.10.2016 Автор:Алексей Максимов
    8 740 Просмотров 8 комментариев

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

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

    20.05.2015 Автор:Алексей Максимов
    10 160 Просмотров 3 комментария

    image

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

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

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

    06.07.2014 Автор:Алексей Максимов
    58 268 Просмотров 9 комментариев

    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

    30.06.2014 Автор:Алексей Максимов
    77 588 Просмотров 44 комментария

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

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

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