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

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

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

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

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

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

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

Как это работает — общая схема#

Ключевые свойства#

• Pull-модель — агент сам опрашивает сервер (GET /api/v1/clients/ansible/runs/pending), никаких входящих SSH/портов на клиенте открывать не нужно. Тот же Bearer-токен, что у lsus-client.
• Локальный Ansible — ansible-playbook -c local запускается на самом клиенте, без SSH-push с сервера. Пакет lsus-config-agent поставляется со встроенным venv (15 wheels, ~12 МБ), не требует интернета и установки ansible из ОС.
• Ed25519-подпись версий — каждый playbook подписывается приватным ключом сервера; агент обязательно проверяет подпись перед выполнением. Защищает от подмены контента (RCE от root — главный риск).
• Версионирование — контент playbook'а хранится в immutable config_playbook_versions; редактирование создаёт новую версию. Идущие прогоны ссылаются на конкретную версию — редактирование их не ломает.
• Антишторм — раскатка батчами с throttle/jitter, lease на выполнение, экспоненциальный backoff на агенте.

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

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

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

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

Как применить:
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. Отметьте сценарий «Контроль службы антивируса» чекбоксом (можно отметить несколько).
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/ADML (Windows GPO),
адаптированный под LSUS: вместо записи в реестр он генерирует YAML (Ansible)
или PowerShell скрипт. Единица сохранения — обычный ConfigPlaybook (попадает в
«Сценарии и скрипты» с бейджем ⚙ конструктор), поэтому к нему применимы все
существующие механизмы (версионирование, Ed25519-подпись, назначения, запуски).

Конструктор — это хелпер создания сценария/скрипта, поэтому открывается
модальным окном (не отдельной подвкладкой):
- кнопка «⚙ Создать через конструктор» на подвкладке «Сценарии и скрипты»;
- пункт «Открыть в конструкторе» в контекстном меню сценария, созданного
конструктором (round-trip пересборка).

Принцип работы#

1. Выберите целевую ОС (Windows → PowerShell, Linux → YAML) и найдите политику в
   дереве «категория → политика» слева.
2. Задайте состояние триады: Not Configured (политика выключена), Enabled
   (привести к целевому состоянию) или Disabled (обратное действие, если автор
   шаблона его задал).
3. Заполните параметры (элементы): строки, списки, ключ=значение, пути, выбор
   дистрибутива и т.п.
4. Живое превью внизу показывает сгенерированный код и строку доставки
   (какие дистрибутивы будут доставлены на хост).
5. «Сохранить как сценарий» создаёт ConfigPlaybook со спецификацией сборки
   (builder_spec).

Виды политик#

• action — эмитит фрагмент кода напрямую (служба, реестр, sysctl, UAC);
• contribution — вкладывает значения в общий артефакт (напр. policies.json
  Firefox), который доставляется один раз; кросс-ОС: один и тот же артефакт под
  Windows/Linux разными путями;
• resource — объявляет привязку-ресурс: дистрибутив доставляется на хост
  (deliver-only), а скрипт ставит/удаляет ПО. Используется для установки ПО.

Встроенные типовые политики#

Все встроенные шаблоны помечены в списке «Каталог и политики → Административные шаблоны» колонкой «Зрелость» как эксперимент — до проверки в контуре и перевода в «проверена» используйте их с осторожностью, начиная с пилота (подробнее — в руководстве автора шаблонов).

Поставляются builtin-шаблоны (видны сразу в дереве конструктора):

Windows:
- Служба (lsus.win.service) — состояние и тип запуска службы.
- Значение реестра (lsus.win.registry) — задать/удалить значение (hive, ключ, тип).
- Брандмауэр (lsus.win.firewall) — вкл/выкл профили Domain/Private/Public.
- Microsoft Defender (lsus.win.defender) — защита в реальном времени (RTP) вкл/выкл.
- Часовой пояс и NTP (lsus.win.timezone) — TZ + служба w32time + ресинхронизация.
- UAC (lsus.win.uac) — EnableLUA.

Linux:
- Службы (lsus.linux.service) — служба running+enabled / stopped+disabled; маскирование опасных служб (telnet/rsh/rlogin/tftp/rpcbind и др.).
- sysctl (lsus.linux.sysctl) — параметры ядра (ключ=значение).
- Хардненинг sshd (lsus.linux.sshd) — параметры sshd_config с валидацией sshd -t.
- Пакеты (lsus.linux.package) — установка (present) / удаление (absent).
- Ввод в домен (lsus.linux.domain-join) — после агента: AD/Samba/RedADM (realm/net ads) и FreeIPA/ALD Pro; пароль — ConfigCredential, не kickstart. См. PXE.

Кросс-ОС:
- Firefox (lsus.linux.gpo-firefox, lsus.win.gpo-firefox) — политики браузера через ff_json_set / ff_json_del.
- Установка/удаление ПО (lsus.software.install) — из «Дистрибутивов и файлов».
- Файл / строка / INI / cron / задание — lsus.linux.file, lsus.linux.lineinfile, lsus.linux.ini, lsus.linux.cron, lsus.win.file, lsus.win.scheduled-task.

Встроенные шаблоны (58): харденинг sshd/sysctl/firewall, Defender, UAC, реестр, службы, файл/INI/cron, Kerberos, SSSD, CA-сертификаты, Firefox, установка ПО и др. Свой шаблон — только если примитива не хватает: руководство автора Administrative Templates.

Builtin-набор (поставляется «из коробки»)#

Готовые builtin-сценарии (ConfigPlaybook) по умолчанию не сидируются — вместо этого поставляются ADMX-подобные шаблоны политик конструктора (см. выше). Администратор сам собирает нужный сценарий через UI конструктора, выбирая политики и задавая параметры — готовый плейбук сохраняется как custom с привязкой builder_spec (round-trip: пересборка не теряет ручные правки — см. Гибридный round-trip ниже).

Раньше (до переноса) существовал фиксированный набор из 25 builtin-сценариев (проверки EDR/AV/DLP, харднинг sshd/sysctl, службы, сбор фактов, обслуживание). Их функциональность перенесена в шаблоны:

Установка/удаление ПО из «Дистрибутивов и файлов»#

Политика «Установить / удалить приложение» (шаблон lsus.software.install):
берёт дистрибутив из «Дистрибутивов и файлов», доставляет его на хост
(только файлы, auto_install=false) и устанавливает (Enabled) или удаляет
(Disabled). На Windows использует install_command/uninstall_command
карточки или msiexec/exe; на Linux — apt/dnf/package. Установка делается
скриптом единообразно для обеих ОС — это делает процесс очевидным и доступным
через графический интерфейс.

Расширяемость и кастомные шаблоны#

• Builtin-шаблоны поставляются вместе с сервером и доступны сразу после установки.
• Кастомные создаются в UI: «Создать шаблон» (форма, рецепт, клон, AI-мастер)
  или «Сохранить как политику каталога» из конструктора. Также: импорт .zip-bundle
  (право config.builder.operate). Эквивалент API: POST /config/policy-templates/import
  и POST /config/policy-templates/from-builder.
• Опциональный ui.js — кастомные виджеты/валидация полей в UI
  (window.LsusBuilder.registerPlugin). Для builtin — доверенный; для custom по
  умолчанию выключен (риск XSS), включается флагом trusted отдельно.

Гибридный round-trip#

Сохранённый сценарий хранит builder_spec (выбранные политики + параметры) и
builder_generated_hash (sha256 сгенерированного контента). В списке сценариев:
- ⚙ — создано конструктором, пересборка безопасна;
- ⚙✎ — контент изменён вручную: при «Открыть в конструкторе» и пересборке
показывается подтверждение перезаписи.

Каталог сценариев (Playbook'и)#

Каталог Ansible-плейбуков: категории, редактор, версионирование и подпись. Обзор подвкладки (колонки, фильтры, импорт/экспорт) — на странице Конфигурации.

Управление категориями#

Кнопка «Категории…» в шапке подвкладки открывает модалку управления (configCategoriesModal):

• Добавить — ключ (строчные латинские, напр. compliance_db) + название.
• Переименовать — у любой категории можно изменить label (даже у builtin).
• Удалить — только пользовательские (builtin защищены); нельзя удалить, если она используется плейбуками (сначала смените им категорию).
• is_builtin — встроенные помечены бейджем «встр.», их нельзя удалить.

Категории используются в:
- фильтре подвкладки «Playbook'и»;
- селекте категории в модалке редактирования плейбука;
- группировке при выборе плейбуков в модалке профиля (чекбоксами).

Модалка «Создать/редактировать плейбук» (configPlaybookEditModal)#

Двухпанельный редактор:

Левая панель — метаданные:
- Имя — человекочитаемое.
- Slug — уникальный идентификатор (строчные латинские, цифры, дефис). По соглашению <category-short>-<target>-<action>, напр. sec-myapp-check.
- Категория (select).
- Теги (через запятую).
- ОС (os_family, или пусто = любая).
- Режимы — check + apply / только check / только apply.
- Описание.

Правая панель — редактор YAML:
- Текстовое поле с моноширинным шрифтом для контента playbook'а.
- Кнопка «Проверить» → серверная валидация (/config/playbooks/validate): YAML-парсинг + структурная схема + при наличии серверного ansible-core venv — ansible-playbook --syntax-check. Ошибки подсвечиваются с номерами строк.
- Кнопка AI — зарезервирована, в этой версии выключена (задел на будущее).

При сохранении:
1. Сервер валидирует YAML.
2. Создаётся новая immutable версия (config_playbook_versions) с SHA-256 checksum.
3. Версия подписывается Ed25519 приватным ключом сервера.
4. current_version_id плейбука переключается на новую версию.

Модалка «Запустить плейбук» (configPlaybookRunModal)#

• Режим — check / apply.
• Цель — host_id через запятую.
• Run as user (опц.).
• become (чекбокс).
• extra_vars (JSON).

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

Таргетинг#

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

Ревизии#

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

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

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

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

Шесть вкладок раздела — это одна цепочка, а не шесть разных журналов:

• Расписание ничего не ставит на компьютеры. В срок оно создаёт кампанию.
• Правило делает то же по событию, с паузой между повторами. Это настройка, а не журнал.
• Кампания — один запуск политики на группу хостов: вручную, по расписанию или по правилу. Это уровень задания, а не одного компьютера.
• Прогон — исполнение этой кампании на одном хосте. Колонки «Кампания» и «Расписание» в журнале прогонов — ссылки на те же объекты, не отдельные сущности.
• Соответствие — итог по хосту прямо сейчас (в норме, расхождение, ошибка), а не список прогонов. «Последний прогон» в строке — ссылка в журнал.
• Требуют внимания ничего своего не хранит: это очередь из кампаний, расписаний и строк соответствия, по которым нужен человек — согласовать, запустить, снять паузу, разобраться с ошибкой.

Порядок работы простой: сначала «Требуют внимания» — всё, что ждёт решения. Ход конкретного задания — в «Кампаниях». Регулярность — в «Расписаниях». Разбор одного компьютера — в «Прогонах». «Парк в норме или нет» — в «Соответствии». «Правила» открывают, только когда нужно, чтобы событие само создавало кампанию.

Вкладка запоминается: при следующем входе откроется та же, при первом открытии — «Кампании».

«Требуют внимания»#

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

Чего здесь нет: истории. Как только по строке принято решение, она уходит из очереди — сам объект живёт в своей вкладке.

Куда дальше: в кампанию, расписание или соответствие, откуда пришла строка.

«Кампании»#

Зачем заходить: посмотреть, как идёт конкретный запуск политики на группу хостов — статус, прогресс (сколько хостов прошло), следующий шаг. Кампания создаётся вручную (кнопка «+»), расписанием в срок или правилом по событию; источник виден у имени. Колонки: Имя, Политика, Статус, Прогресс, След. шаг, Действия.

Кампания расписания, в которой на всех компьютерах проверка лишь повторила прошлый успех без изменений, в этом списке не показывается.

Чего здесь нет: итога «парк в норме или нет» — это «Соответствие»; настройки регулярности — это «Расписания».

Куда дальше: в деталях кампании — прогон по каждому хосту. Тот же прогон открывается и из журнала «Прогоны».

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

Зачем заходить: настроить и проверить регулярность — политика, аудитория, режим, интервал, когда следующий запуск. Колонки: Имя, Политика, Аудитория, Режим, Интервал, Статус, Следующий запуск. Кнопка «Запустить сейчас» создаёт внеочередную кампанию; «+» — новое расписание.

Расписание само ничего не ставит: в срок оно создаёт кампанию, и дальнейшее видно там. Пока предыдущая кампания этого расписания не завершена, новая не создаётся — сдвигается только следующий срок. Кампания, которая висит дольше суток, закрывается как невыполненная, и расписание идёт дальше. Ошибка на предпроверке завершает эту кампанию, но расписание не останавливает: хост виден в «Соответствии» и в «Требуют внимания → Ошибки», следующий срок проверит его снова. Ошибка на применении или контроле по-прежнему ставит на паузу и кампанию, и расписание. Если у политики выключено согласование ревизий, «Продолжить» снимает паузу без повторного согласования. Если очередная проверка у всех прошла без изменений, кампания в список не попадает, а у расписания появляется подпись «последняя проверка без изменений» с временем.

Чего здесь нет: истории прошлых запусков — она в «Кампаниях» и «Прогонах».

Куда дальше: в кампании, созданные расписанием.

«Прогоны»#

Зачем заходить: разобрать один компьютер — что именно исполнялось, чем закончилось, что в логе. Колонки: ID, Хост, Сценарий, Статус, Режим, Длительность, Начато, Кем, Кампания, Расписание; последние две — ссылки на те же объекты.

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

Повторная проверка по расписанию, которая прошла так же и ничего не изменила, новой строки не добавляет. У оставшегося прогона подпись «без изменений, ещё N, последний …»: N — сколько раз результат совпал, время — последняя такая проверка. Подробный лог этой проверки остаётся на компьютере. Ручной запуск, диагностика, статус «Изменено», ошибка и недоступность по-прежнему пишутся отдельно.

В карточке прогона — сводка и две вкладки: «Задачи» (модуль, статус, было ли изменение) и «Лог» (полный вывод, активный прогон обновляется сам). Для неудачных видна первая упавшая задача; кнопки «Скопировать вывод» и «Повторить» (новый прогон с теми же параметрами).

Чего здесь нет: сводки по группе хостов — это кампания; текущего состояния «в норме ли хост» — это «Соответствие».

Куда дальше: из прогона — в его кампанию.

«Соответствие»#

Зачем заходить: ответ на «парк в норме или нет» — итог по каждому хосту сейчас, проблемные сверху. Колонки: Хост, Политики, Статус, Проверено, Последний прогон. «Проверено» — время последней проверки, в том числе когда она лишь подтвердила прежний результат и отдельной строкой в прогоны не попала. Раскрытие строки — статус по каждой политике; одна упавшая проверка не схлопывает весь результат.

Чего здесь нет: истории и очередей — «Прогоны» и «Требуют внимания».

Куда дальше: «Последний прогон» — ссылка в журнал прогонов.

«Правила»#

Зачем заходить: чтобы событие (например, попадание хоста в коллекцию) само создавало кампанию. Правило — настройка: событие, ревизия политики, пауза между повторами, включённость. Колонки: Название, Событие, Ревизия, Пауза, Последний запуск, Вкл., Действия; «+» — создать правило.

Чего здесь нет: самих запусков — созданные правилом кампании живут в «Кампаниях».

Куда дальше: в кампании, созданные правилом.

Жизненный цикл прогона (config_run)#

Статусы config_run (AWX-выровненные)#

Lease и reclaim#

Каждый claimed прогон имеет lease_expires_at = claimed_at + timeout + 30 мин. Если агент не отчитался в срок (упал, потерял связь, хост выключили) — worker task_config_lease_reaper возвращает прогон в pending (инкремент attempt). При attempt >= max_attempts (по умолчанию 3) — переводится в timed_out. Это исключает «зависшие» прогоны и дубли выполнения.

Антишторм и устойчивость#

Типичные сценарии#

1. Проверить, что на всех серверах работает EDR bi.zone#

1. Конструктор политик → «Создать через конструктор»: выбрать Linux → категория «Безопасность и СЗИ» → политика «EDR bi.zone» (шаблон lsus.linux.security-checks) → задать edr_package_name/edr_required_services (по умолчанию bzsenagent/bzsenagent, bzsenedcore) → «Включено» → сохранить как сценарий EDR-check.
2. В дереве «Каталог и политики» ПКМ по группе «Серверы Linux» → «Назначить политику»: сценарий EDR-check, режим — аудит, интервал — по регламенту.
3. В срок расписание создаст кампанию с проверочными прогонами для всех хостов группы.
4. Соответствие — смотрим сводку: какие хосты successful, какие failed.
5. Клик на failed → «Детали» → виден упавший assert («служба bzsenedcore не running»).
6. Передать в ИБ-отдел список хостов для разбора.

2. Привести sshd в соответствие стандарту (apply)#

1. Конструктор политик → «Создать через конструктор»: Linux → категория «Linux: SSH» → политика «Харднинг sshd» (шаблон lsus.linux.sshd) → в options задать PermitRootLogin=no, PasswordAuthentication=no, Protocol=2 (при необходимости добавить MaxAuthTries=3) → «Включено» → сохранить как сценарий.
2. В каталоге сценариев откройте плейбук → «Запустить»: сначала в режиме аудита — посмотреть, сколько хостов отличаются от стандарта.
3. Затем «Запустить» в режиме применения — конфиг будет приведён к стандарту с проверкой синтаксиса перед сохранением.
4. В «Прогонах» — детали: что именно поменялось в каждой задаче.
5. При необходимости донастроить сценарий вручную — «Открыть в конструкторе» пересоберёт поверх (round-trip), либо редактировать код напрямую (тогда пересборка предупредит diff'ом).

3. Перенос набора плейбуков между инсталляциями LSUS (air-gapped)#

1. На «исходном» Master: «Экспорт bundle» → скачивается lsus-config-bundle.zip.
2. На «целевом» Master: «Импорт» → выбрать ZIP → валидация → импорт.
3. Проверить, что все плейбуки появились в каталоге (как custom).
4. При необходимости — привязать к шаблонам/профилям/назначениям.

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

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

• Каталог и политики — структура дерева, коллекции, GPO.
• Сертификаты и списки отзыва — доставка CA и CRL на хосты шаблонами конструктора.
• lsus-config-agent — клиентский агент (Ansible).
• LDAP и Kerberos — синхронизация каталога.
• AI-стек — AI-генерация сценариев и анализ прогонов.
• Как создать Administrative Template — авторство шаблонов, пресеты и проверка контракта.