LSUS — обзор системы

LSUS (Linux System Update Service) — корпоративная платформа для централизованного управления обновлениями рабочих станций и серверов под управлением Linux и Windows. LSUS решает ключевую проблему современных организаций: как своевременно и безопасно обновлять сотни и тысячи машин, не теряя контроль над процессом и не создавая рисков для стабильности инфраструктуры.

Вместо того чтобы каждый администратор вручную обновлял серверы и рабочие станции, LSUS даёт единую точку управления с гибкими политиками, тестированием перед внедрением, умной доставкой пакетов и поддержкой полностью изолированных (air-gapped) сред.

Эта страница даёт концептуальный обзор архитектуры и ролей. Пошаговая установка — в Развёртывании серверов; требования к хосту — в Требованиях. Быстро поднять пилот — Быстрый старт.

Ключевые принципы¶

• Единая точка управления — один веб-интерфейс для всех задач: хосты, политики, репозитории, тестирование, отчёты, безопасность.
• Контролируемое внедрение — тестирование обновлений перед массовым развёртыванием, каналы testing → stable, чек-листы и итерации проверки.
• Гибкие политики — разные правила для разных групп машин: серверы обновляются по выходным, рабочие станции — ночью, критические системы — только после ручного подтверждения.
• Работа в любых сетевых условиях — от открытых сетей до полностью изолированных сред с офлайн-импортом из ISO-образов.
• Многоуровневая доставка — Edge → Master → Site → клиенты: обновления доходят до каждой машины без перегрузки каналов связи.
• Безопасность по умолчанию — HTTPS на всех уровнях, ролевая модель доступа (RBAC), интеграция с LDAP и Kerberos, журнал аудита действий.
• Единая платформа для Linux и Windows — обновления для обеих ОС в одном интерфейсе: APT/DNF/YUM/APT-RPM + KB/MSU.
• Поддержка отечественных ОС — Astra Linux, РЕД ОС, ALT Linux с учётом их специфики (APT-RPM, подпись пакетов).

Архитектура ролей¶

LSUS состоит из пяти ролей. Серверные роли конфликтуют между собой — на одном хосте разворачивается только одна (исключение инсталлятора — master+edge; pxe всегда exclusive). Все серверные роли работают в Docker-контейнерах и используют общую сеть хоста (network_mode: host).

Роль	Назначение	Порт	Контейнеры
Master	Центральный сервер: веб-админка, регистрация хостов, приём heartbeats, раздача репозиториев и KB-кеша, единая БД политик	443	lsus-master, lsus-master-worker, lsus-master-replication, lsus-postgres, lsus-pgbouncer, lsus-nginx
Site	Сервер площадки: прокси для своего пула клиентов, синхронизация с Master, локальная копия репозиториев	443	lsus-site, lsus-site-replication, lsus-postgres, lsus-site-pgbouncer, lsus-site-nginx
Edge	Пограничный сервер в DMZ: приём/раздача файлов, зеркала репозиториев, доставка внешних обновлений в закрытый контур	443	lsus-edge, lsus-postgres, lsus-edge-nginx
PXE	Точка сетевой установки ОС: ISO, extract, proxyDHCP/TFTP, HTTP boot. Свой хост, без PostgreSQL	443 + 80, UDP 67/69/4011	lsus-pxe, lsus-pxe-nginx
Клиент	Агент на управляемом хосте: heartbeat, выполнение команд, установка обновлений	—	lsus-client.service (systemd)

Master¶

Главная точка администрирования. Здесь администратор работает с хостами, политиками, репозиториями, ролями пользователей, площадками Site и связью с Edge. Если Master недоступен, система теряет единый центр управления.

Функции Master:

• приём регистрации клиентов, heartbeat и отчётов;
• хранение каталога хостов и их текущего состояния;
• выдача настроек и команд обновления;
• хранение и раздача репозиториев пакетов и кеша KB;
• управление площадками Site и связью с Edge;
• хранение ролей, прав и параметров серверной интеграции;
• центр управления кампаниями установки Linux и Windows — массовая установка пакетов по группам хостов и расписанию;
• анализ уязвимостей OVAL — сопоставление установленных пакетов с базами CVE/BDU.

API Master (важно для сети и балансировщиков):

Путь	Назначение
/api/v1/clients	клиентское API (регистрация, heartbeat, отчёты)
/api/v1/admin	административное API
/api/v1/commands	команды обновления
/api/v1/health	проверка работоспособности

Site¶

Сервер площадки для разгрузки центрального узла. Обслуживает клиентов своего сегмента сети и связывает их с Master. Site внедряют, когда:

• у организации несколько площадок и нужно локально контролировать состояние клиентов филиала;
• часть клиентов не имеет прямого маршрута к Master (изолированные сегменты сети);
• нужно снизить нагрузку на центральный канал — Site держит локальные реплики репозиториев, и пакеты тянутся с ближайшего узла, а не из центрального офиса.

Site передаёт на Master heartbeat, журналы и служебные данные клиентов своей площадки. Связь с Master — постоянный HTTPS-доступ к LSUS_MASTER_URL. Может работать в режиме proxy (проксирование без хранения) или mirror (локальная копия репозитория).

Edge¶

Пограничный узел для вынесенного сегмента сети (DMZ). Безопасно принимает, хранит и выдаёт файлы обновлений на границе контура, не превращая Master в прямую внешнюю точку доступа. Edge может выступать точкой выхода в интернет за репозиториями для закрытого контура.

Функции Edge:

• хранение загруженных файлов в локальном хранилище;
• веб-интерфейс и API на едином порту (по умолчанию 443);
• настройка загрузок, зеркал, хранилищ и расписаний;
• зеркалирование внешних репозиториев с собственными TLS-сертификатами upstream;
• опциональная антивирусная проверка (EDGE_AV_ENABLED);
• standalone-режим — Edge может работать автономно, без постоянной связи с Master (для распределённых контуров).

PXE¶

Отдельный хост сетевой установки ОС. ISO не хранятся на Master: браузер загружает их на точку по одноразовому билету. Точка отвечает как proxyDHCP рядом с корпоративным DHCP (не вместо него). Вкладка консоли — только на Master: PXE. Установка роли — Установка PXE.

В MVP: РЕД ОС, Astra, Альт; загрузчик iPXE; Secure Boot выключен.

Клиент¶

Агент на рабочей станции или сервере. Поставляется пакетами под все поддерживаемые ОС:

Пакет	Назначение	Когда нужен
lsus-client	Фоновый сервис (systemd + D-Bus), CLI lsus-client-ctl, связь с сервером	на всех машинах
lsus-client-gui	Графический клиент для системного трея (PyQt6)	только на рабочих станциях с графикой
lsus-client-windows-dotnet	Агент для Windows: heartbeat, обновления KB, автообновление	на Windows-машинах
lsus-usb-control	Служба мониторинга USB-событий	при использовании модуля USB Control

Поддерживаемые клиентские ОС: Astra Linux 1.7/1.8, РЕД ОС 7.3/8, ALT Linux p10+, Debian 12/13, Ubuntu 22.04/24.04, CentOS/RHEL/Rocky и совместимые, Windows 10/11 и Server 2012 R2/2019/2022.

Подробно об установке, конфигах и диагностике клиента — в Клиент LSUS.

Схема взаимодействия¶

Что происходит на схеме:

• Edge стоит на границе контура (DMZ) и тянет репозитории, OVAL-базы и KB из интернета — у Master нет прямого выхода наружу. Edge синхронизируется только с Master (по API-ключу) и никогда не общается с Site или клиентами напрямую.
• Master — центральный узел: все Site регистрируются на нём и синхронизируют репозитории/настройки; от Master клиенты центра получают политики и пакеты.
• Site на каждой площадке держит локальную реплику репозиториев и обслуживает клиентов своего сегмента — это снимает нагрузку с центрального канала.
• Клиенты обращаются к ближайшему серверу — Site или Master, — получают политики и heartbeat, скачивают пакеты с /repos.

Направления соединений¶

Направление	Порт	Назначение
Клиент → Master/Site	443	heartbeat, получение команд, скачивание пакетов с /repos
Site → Master	443	регистрация, синхронизация политик и репозиториев
Edge → Master	443	регистрация, синхронизация (через API-ключ)
Edge → интернет	443	загрузка зеркал, репозиториев, OVAL, KB

Backpressure¶

При превышении лимита одновременных запросов на горячих эндпоинтах (heartbeat, settings, commands) сервер возвращает 503 + Retry-After, а не падает. Клиент уважает Retry-After и откладывает повтор. Это защита от «шторма» переподключений тысяч клиентов после восстановления связи с сервером.

Инфраструктура¶

Компонент	Назначение
PostgreSQL 15	Хранение данных серверных ролей. При совмещении ролей на одном хосте используются отдельные БД/пользователи (lsus, lsus_site, lsus_edge). Образ — postgres:15-bookworm.
PgBouncer	Пул соединений (только Master и Site), мультиплексирует короткоживущие сессии веб-API на ограниченный набор backend'ов PostgreSQL. Защита от шторма переподключений.
nginx	TLS-фронтенд (только TLS 1.2/1.3, HTTP/2). Разводит трафик по портам/путям на приложение, терминирует HTTPS.
Python 3.11	Серверное приложение (Flask 3.0 + SQLAlchemy 2.0 + Gunicorn). Базовый образ — debian:bookworm-slim.
Docker	Единственный поддерживаемый способ поставки серверных ролей. Все контейнеры работают в network_mode: host.

В стеке нет Redis, gRPC и других бинарных протоколов — только HTTPS между всеми компонентами. Это упрощает прохождение корпоративных firewall и аудит трафика.

Типовые топологии¶

1. Один контур¶

Минимальная схема — Edge в DMZ тянет обновления из интернета, Master во внутренней сети раздаёт их клиентам напрямую. Подходит для небольшой инфраструктуры или пилота.

2. Несколько площадок¶

Edge в DMZ тянет обновления из интернета и отдаёт их Master. Master в центре + несколько Site на площадках. Клиенты привязаны к «своему» Site, который разгружает центр и обеспечивает работу в изолированных сетях.

Где используется LSUS¶

LSUS подходит для:

• корпоративных IT-отделов с парком от 50 до тысяч машин;
• государственных организаций с требованиями к отечественному ПО, аттестации и работе в изолированных средах;
• промышленных предприятий с изолированными технологическими сетями (АСУ ТП) и air-gapped средами;
• образовательных учреждений — компьютерные классы и централизованное обновление учебных машин;
• организаций с филиальной сетью — распределённая доставка обновлений через Site-серверы;
• компаний, использующих отечественные ОС (Astra Linux, РЕД ОС, ALT Linux) вместе с Windows.

Как устроена доставка обновлений¶

Собственные репозитории и линейки¶

LSUS поддерживает создание локальных репозиториев: загрузка пакетов вручную, импорт из ISO-образов, синхронизация зеркал внешних репозиториев через Edge — с автоматической сборкой метаданных APT/DNF/aptrpm.

Линейка дистрибутива — ключевая сущность, которая группирует репозитории одной ОС и является точкой контроля каналов обновлений:

Канал	Что содержит	Назначение
current	Рабочие репозитории с актуальными пакетами	Тестирование, пилотные группы
stable	Проверенная копия для продакшена (явный promote)	Продуктивный парк
frozen	Неизменяемый снимок для аудита/воспроизводимости	Регламентированные среды

Хосты получают стабильные URL линейки (например …/current, …/stable), а содержимое за ними администратор переводит осознанно. Не бывает «плавающих» путей или смешения тестового и боевого контуров.

Тестирование перед парком¶

Пока продуктивный парк смотрит на канал stable, новые пакеты из current ему недоступны. Процесс безопасного внедрения:

1. Новые пакеты появляются в канале current.
2. На тестовые хосты (фокус-группа) назначается доступ к current через политику или pin.
3. Администратор наблюдает за результатами через сессии тестирования и отзывы с клиентов.
4. После положительного решения — promote репозитория из current в stable.
5. Продуктивный парк получает обновление при следующем цикле.

Для отдельных хостов можно закрепить конкретный репозиторий через host-pins — это позволяет держать критичные серверы на конкретной версии до отдельного решения.

Консистентность при синхронизации¶

Сборка и публикация репозиториев идут с атомарной записью:

• На уровне репозитория поддерживается публикация ревизиями — переключение симлинка происходит только после успешного завершения сборки метаданных.
• Хосты никогда не видят «полусобранный» индекс — они либо работают со старой ревизией, либо с полностью готовой новой.
• Агент получает сигнал о публикации и кратко откладывает цикл apt update / dnf check, чтобы не налететь на переключение.
• Если скачивание пакета уже началось, при атомарной публикации открытые файлы прежней ревизии остаются валидными до конца отдачи — загрузка не прерывается.

Предзагрузка перед установкой¶

В кампаниях и заданиях на обновление Linux работает предзагрузка:

1. Клиент сначала забирает все нужные пакеты в локальный кэш (apt-get download / dnf download), без установки.
2. Только после успешной предзагрузки запускается применение обновлений.
3. При ошибке предзагрузки (нет пакета, мало места, сеть) — установка не стартует.

Каталог и политики¶

Управление конфигурационным состоянием хостов — отдельный модуль LSUS, доступный через вкладку Каталог и политики. Это AD-подобное дерево с групповыми политиками (GPO-модель), коллекциями хостов, ролями доступа, дистрибутивами ПО и центр управления раскатками.

Уведомления¶

LSUS сам отслеживает состояние инфраструктуры и уведомляет администратора:

• недоступные хосты (>90 дней без heartbeat);
• недоступные Site/Edge;
• истекающие сертификаты;
• новые пакеты в репозиториях;
• ошибки LDAP-синхронизации и исчезнувшие LDAP-объекты.

Каналы: in-app (колокольчик в шапке), email, webhook. См. Уведомления.

---

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

• Редакции и поддержка — уровни сопровождения и положение о технической поддержке.
• Требования и подготовка — ОС, ресурсы, firewall, DNS SRV.
• Развёртывание серверов — пошаговая установка ролей.
• Справочник портов и переменных — полный референс.
• Каталог и политики — управление конфигурациями, коллекции, GPO.
• Клиент LSUS — установка агентов.
• Обновление системы — процедура обновления.
• API инвентаризации — REST API для внешних систем.