Управление конфигурациями — руководство администратора

Практическое руководство по управлению конфигурационным состоянием хостов через вкладку «Каталог и политики».

Общая модель¶

Управление конфигурациями в LSUS построено по модели GPO: политика → назначение на коллекцию/хосты → автоматическое применение → контроль соответствия. Работа ведётся в двух местах UI:

• Дерево «Каталог и политики» — создание и редактирование политик, назначение на коллекции;
• Узел «Запуски сценариев» — мониторинг применения: кампании, расписания, журнал прогонов, соответствие.

Два способа доставки (виден в колонке «Доставка» таблицы политик):

• ⚡ heartbeat — клиент-конфигурации (источники репозиториев, опции ОС, hold-пакеты, GUI): применяются агентом lsus-client мгновенно при очередном опросе сервера, без ревизий и согласований;
• ⏱ расписание — сценарии: сервер по интервалу (по умолчанию каждые 15 мин) создаёт задание, которое исполняет lsus-config-agent (Ansible для Linux, PowerShell для Windows), с ревизиями и опциональным согласованием.

Типы политик¶

Конфигурации (сценарии)¶

Для чего: приведение хоста к требуемому состоянию скриптами/плейбуками — установка и настройка ПО, комплаенс-проверки, доставка файлов, приложений.

Пример: политика «Антивирус обязателен» — сценарий проверяет наличие пакета антивируса и при отсутствии устанавливает его из репозитория.

Как применить:
1. В узле «Групповые политики» создайте политику, добавьте элементы (сценарии из каталога или через конструктор политик).
2. Задайте режим: аудит (только проверка, активируется сразу) или применение (проверка → исправление → контроль, требует согласования).
3. Назначьте на коллекции и задайте расписание.

Как отслеживать: «Запуски сценариев» → «Соответствие» (per-host статус), карточка хоста → вкладка «Состояние» (применённые политики с раскрытием настроек), детали прогона (задачи, лог).

Источники репозиториев¶

Для чего: централизованно управляет списком репозиториев на хосте (sources.list / dnf-репо): какие группы репозиториев подключены, режим (замена/слияние).

Пример: политика «Только внутренние репо» — режим replace, в составе — группа репозиториев LSUS-сервера; хосты перестают ходить во внешние зеркала.

Доставка — heartbeat, применится при ближайшем опросе клиента (~120 с). Отслеживание: карточка хоста → «Состояние».

Опции ОС¶

Для чего: параметры механизма обновлений ОС: опции apt/dnf, фильтры Windows Update.

Пример: «Серверы БД — без автоперезагрузки» — опции apt, исключающие автоматический рестарт служб при обновлении.

Доставка — heartbeat.

Hold-пакеты¶

Для чего: заморозка версий пакетов — запрет их обновления (apt-mark hold / versionlock).

Пример: «Заморозить PostgreSQL 15.x на проде» — правило hold для пакета postgresql-15, чтобы кампания обновлений его не трогала.

Доставка — heartbeat.

GUI клиент¶

Для чего: ограничения интерфейса клиентского GUI на рабочих станциях: скрыть кнопки «Установить сейчас», «Проверить обновления», запрет менять расписание и т.п.

Пример: «Киоск-режим для АРМ» — включены disable_install_now и запрет изменения расписания.

Доставка — heartbeat.

Экспертные сценарии¶

Для чего: разовое или периодическое назначение отдельного плейбука/скрипта прямо на хост или коллекцию, минуя полноценную политику.

Как применить: модалка «Назначить политику» на хосте/коллекции → вкладка «Экспертные сценарии» → выбрать скрипт, режим (аудит/применение) и интервал.

Привязка файлов: в карточке сценария — кнопка «Файлы, доставляемые на хост». Перед прогоном агент скачает файлы (с проверкой Ed25519-подписи) и положит их по указанному dest_path с заданными правами/владельцем.

Практический пример: контроль службы антивируса¶

Разберём типовую задачу администратора: убедиться, что служба антивируса на Windows-хостах запущена и имеет тип запуска «Автоматически». Пример показывает весь цикл — от написания скрипта до контроля результата.

Контракт сценария¶

Сценарий (PowerShell для Windows, YAML для Linux) — это скрипт с двумя режимами:

• check (аудит) — только проверяет состояние и сообщает расхождения, ничего не меняя;
• apply (применение) — приводит хост к эталону (идемпотентно: если уже так — ничего не делает).

В конце скрипт обязан вывести в stdout один JSON-блок с результатом:

{"status":"changed","summary":{"ok":1,"changed":1,"failed":0},
 "tasks":[{"name":"Состояние службы","status":"ok","changed":true,"msg":"запущено"}]}

• status — successful (всё как надо), changed (что-то поправили), failed (ошибка);
• summary — счётчики ok / changed / failed;
• tasks — по одной записи на каждую проверку/действие.

Сам скрипт¶

Создаём PowerShell-сценарий. Параметры (имя службы, желаемое состояние) передаются через extra_vars — не нужно хардкодить их в коде.

param([string]$Mode = 'check')   # check = только проверка, apply = применить
$ErrorActionPreference = 'Continue'
$script:tasks = New-Object System.Collections.ArrayList

function Add-Task($name, $ok, $changed, $msg) {
    [void]$script:tasks.Add([pscustomobject]@{
        name = $name; status = $(if ($ok) { 'ok' } else { 'failed' });
        changed = [bool]$changed; msg = "$msg"
    })
}

# Параметры из extra_vars (агент передаёт их через LSUS_EXTRA_VARS как JSON)
$ev = @{}
try { if ($env:LSUS_EXTRA_VARS) { $ev = $env:LSUS_EXTRA_VARS | ConvertFrom-Json -AsHashtable } } catch {}

$srv = $ev.service_name              # напр. 'kes'
if (-not $srv) {
    Add-Task 'Параметр service_name' $false $false 'не задан в extra_vars'
} else {
    $wantState = $ev.want_state; if (-not $wantState) { $wantState = 'Running' }
    $wantStart = $ev.want_startmode; if (-not $wantStart) { $wantStart = 'Auto' }

    $s = Get-Service -Name $srv -ErrorAction SilentlyContinue
    if (-not $s) {
        Add-Task "Служба $srv установлена" $false $false 'служба не найдена'
    } else {
        $stateOk = ($s.Status -eq $wantState)
        $startMode = $s.StartType
        $startOk = ($startMode -eq $wantStart)

        if ($Mode -eq 'apply') {
            $changed = $false
            if (-not $stateOk) { try { Start-Service $s; $changed = $true } catch {} }
            if (-not $startOk) { try { Set-Service $s -StartupType $wantStart; $changed = $true } catch {} }
            Add-Task "Служба $srv приведена к эталону" $true $changed "$($s.Status) / $startMode"
        } else {
            Add-Task "Состояние $srv = $wantState" $stateOk $false "факт = $($s.Status)"
            Add-Task "Тип запуска $srv = $wantStart" $startOk $false "факт = $startMode"
        }
    }
}

$failed  = @($script:tasks | Where-Object { $_.status -eq 'failed' }).Count
$changed = @($script:tasks | Where-Object { $_.changed }).Count
$ok      = @($script:tasks | Where-Object { $_.status -eq 'ok' }).Count
$status  = if ($failed) { 'failed' } elseif ($changed) { 'changed' } else { 'successful' }

Write-Output ([ordered]@{ status=$status; summary=[ordered]@{ok=$ok;changed=$changed;failed=$failed}; tasks=$script:tasks } | ConvertTo-Json -Depth 6 -Compress)

Шаг 1. Создание сценария¶

1. Откройте Каталог и политики → в дереве разверните «Групповые политики» → выберите узел «Экспертные сценарии».
2. Нажмите «Создать сценарий» в тулбаре.

3. Заполните поля:
   - Имя — «Контроль службы антивируса»;
   - Тип контента — PowerShell (.ps1 / Windows);
   - Режимы — «Проверка + применение»;
   - Вставьте код скрипта в редактор.
4. Нажмите «Проверить» — сервер проверит синтаксис и контракт.
5. «Сохранить».

Шаг 2. Назначение на хосты¶

1. В дереве «Каталог и политики» кликните правой кнопкой мыши по коллекции (например, «Все хосты и пользователи» или конкретный OU) → «Назначить политику».

2. В открывшейся модалке перейдите на вкладку «Экспертные сценарии».
3. Выберите сценарий «Контроль службы антивируса» (radio-переключатель).
4. Задайте параметры (extra_vars):

5. Выберите режим: аудит (только проверить) или применение (проверить и исправить).
6. Задайте интервал (например, «Каждые 15 минут»).
7. Нажмите «Назначить».

Шаг 3. Запуск¶

Назначение создаёт расписание — сервер будет запускать прогон по интервалу автоматически. Но можно запустить и разовую кампанию:

1. В дереве выберите «Запуски сценариев» → подвкладка «Кампании».

2. Нажмите «+» (Создать кампанию).
3. Выберите одобренную ревизию сценария, укажите аудиторию (хосты/коллекции).
4. Нажмите «Создать и запланировать волны».
5. В списке кампаний — кнопки жизненного цикла: «На согласование» → «Согласовать» → «Старт».

Кампания исполняется по фазам: предпроверка → пробная группа (canary) → применение → контроль. Между группами работает проверка перехода — если доля успеха ниже порога, кампания встанет на паузу.

Шаг 4. Контроль результата¶

Прогон хоста¶

В подвкладке «Прогоны» кликните по строке прогона (или ссылке «подробнее») — откроется карточка с деталями:

Две вкладки:
- «Задачи» — по каждой задаче: модуль, статус (ok/changed/failed), было ли изменение (changed), сообщение;
- «Лог прогона» — полный stdout/stderr (live-поток во время выполнения).

Пример того, что увидит администратор при расхождении (служба остановлена):

{"status":"changed","summary":{"ok":1,"changed":1,"failed":0},
 "tasks":[{"name":"Служба kes приведена к эталону","status":"ok","changed":true,
           "msg":"Running / Auto"}]}

Если служба уже в норме — status: "successful", changed: 0.

Соответствие¶

Подвкладка «Соответствие» — итоговый комплаенс по всем хостам:

Проблемные хосты (расхождение / ошибка) — наверху. Раскройте строку хоста, чтобы увидеть статус по каждой политике. Одна упавшая проверка не «схлопывает» весь результат — комплаенс гранулярный по элементам.

Конструктор политик¶

Графический редактор по образцу ADMX/GPO — позволяет создавать сценарии без написания кода.

1. В узле «Групповые политики» нажмите «⚙ Создать через конструктор».
2. Выберите ОС (Linux/Windows) и политику из дерева шаблонов.
3. Задайте состояние (Enabled / Disabled / Not Configured) и параметры.
4. Preview показывает сгенерированный код (YAML/PowerShell).
5. Сохраните как сценарий.

Встроенные шаблоны (~40): харденинг sshd/sysctl/firewall, Defender, UAC, реестр, службы, Kerberos, SSSD, CA-сертификаты, Firefox, установка ПО и др. Можно создавать кастомные шаблоны.

Назначение и жизненный цикл¶

Таргетинг¶

Хосты выбираются через дерево коллекций: OU, группы, категории «По ОС», пользовательские коллекции. Аудитория кампании фиксируется на момент согласования и дальше не меняется.

Ревизии¶

Каждое сохранение политики-сценария создаёт неизменяемую ревизию (снапшот содержимого, подписи, параметров). Согласование ревизий — опционально (флаг «Требуется согласование»); по умолчанию ревизия авто-согласуется.

Согласование назначений¶

Изменение ревизии/аудитории/режима сбрасывает согласование (в UI — предупреждение «согласование устарело»).

Раздел «Запуски сценарие⻶

Центр мониторинга применения политик. Пять вкладок:

«Требуют внимания» (по умолчанию)¶

Отвечает на вопрос «что от меня ждут». Секции:
- Ждут согласования — кампании и расписания в статусе «Ожидает согласования», кнопка «Согласовать» прямо в строке;
- Ошибки и блокировки — упавшие кампании, остановленные gate-проверкой;
- На паузе; Согласование устарело; Выполняются сейчас; Расхождения соответствия (drift/ошибки).

«Кампани軶

Разовые запуски политики на аудитории. Создаются вручную или автоматически расписанием (бейдж «по расписанию»).

Жизненный цикл: Черновик → На согласовании → Согласована → Запущена → Завершена (или Ошибка/Отменена).

Волны (группы): кампания исполняется по фазам — Предпроверка → Канарейка → Применение → Контроль. Между волнами работает gate (доля успеха ≥ 95%, максимум ошибок/недоступных). Не пройден — кампания блокируется с указанием причины.

Детали прогона: сводка, переменные, вкладки «Задачи» (per-task: модуль, статус, changed, diff) и «Лог» (stdout/stderr, live-tail во время выполнения).

«Расписания»¶

Периодические назначения непрерывного применения (аналог обновления GPO). Строка: политика, частота, аудитория (с drift-бейджем), режим, последний запуск. Кнопка «Запустить сейчас» — внеочередной запуск.

«Прогоны»¶

Сквозной журнал всех прогонов на хостах, независимо от кампании: статус (pending/running/successful/failed/changed/timed_out/canceled), хост, сценарий, длительность. Точка входа для разбора инцидента.

«Соответстви延

Итоговый комплаенс по хостам: проблемные — сверху. Раскрытие строки — статус по каждой политике. Гранулярное per-элемент: одна упавшая проверка не схлопывает всю ревизию.

Сводная таблица: где что смотреть¶

Связанные страницы¶

• Каталог и политики — структура дерева, коллекции, GPO.
• lsus-config-agent — клиентский агент (Ansible).
• LDAP и Kerberos — синхронизация каталога.
• AI-стек — AI-генерация сценариев и анализ прогонов.