server-monitor-manager/docs/roadmap.md

План разработки

Подробные требования к собственному bootstrap, управляемой настройке Linux и Xray находятся в ТЗ Provisioning и Xray VPN. Все компоненты Server Monitor Manager разрабатываются, версионируются и выпускаются только в этом репозитории.

Текущее автоматическое покрытие поддерживаемых Linux-платформ описано в Linux platform matrix.

Очерёдность работ определяется горизонтами продукта. Этот документ отвечает на вопрос «что сделано», горизонты — на вопрос «что разрешено начинать». Этапы 14–18 ниже относятся к Горизонтам 1–3 и не начинаются до закрытия Горизонта 0.

Этап 0 — граница и базовая архитектура

• переименовать проект в Server Monitor Manager;
• зафиксировать самостоятельность репозитория и отсутствие межрепозиторных runtime-зависимостей;
• выбрать звёздную архитектуру Hub/Node для первого Mesh;
• разделить monitoring, terminal, Agent, Operator и AI-automation identities;
• описать направленные Links и kill switch;
• выбрать Apache License 2.0;
• добавить CI, форматирование, тесты и release checksums.

Этап 1 — Windows SSH MVP

• создать packaged WinUI 3 приложение;
• добавить адаптивный Overview и профили нескольких серверов;
• генерировать отдельный Ed25519 monitoring SSH key;
• защищать monitoring key и Operator certificate через DPAPI;
• сохранять профили локально без паролей;
• получать CPU/load, RAM, disk, uptime и latency;
• редактировать и удалять серверы;
• поддерживать единственный изменяемый Mesh Hub;
• добавить страницы Servers, Links, Sessions и Settings;
• собирать и запускать x64-приложение;
• добавить группы, теги и избранные серверы;
• добавить настраиваемые alert rules и журнал уведомлений;
• добавить управляемую отдельную terminal key identity вместо зависимости только от обычных пользовательских SSH-ключей.

Этап 2 — постоянный Control и Agent

• ASP.NET Core Control Hub и SQLite;
• self-contained Agent/Control binaries для linux-x64 и linux-arm64;
• исходящие mTLS Agent sessions;
• одноразовые enrollment tokens не более чем на 10 минут;
• локальная генерация Agent private key и CSR;
• отдельные Agent, Operator и source-scoped Automation certificates;
• отзыв и повторная регистрация Node/Operator;
• подтверждение SHA-256 fingerprint Control CA;
• защищённый event stream для Desktop;
• ограниченный offline buffer Agent и downsampling;
• idempotency и replay protection;
• SQLite schema version, retention и backup/restore Control DB + CA;
• добавить Desktop UI управления Automation identities и токенами.

Этап 3 — управляемые Links

• направленные пары source -> destination;
• управление Links из Windows-клиента;
• политики по destination /32, TCP/UDP и порту;
• TTL и фоновое автоматическое истечение;
• состояния Connecting, Active, Disconnecting, Partial, Disabled и Failed;
• версия политики и подтверждение применения helper;
• обязательное восстановление disabled policy после reconnect;
• append-only audit операций Link;
• интеграционные тесты kill switch, process restart и helper failure;
• B-2: независимая фоновая и emergency-triggered реконсиляция, агрегированное состояние недоступного Mesh firewall и Desktop banner;
• B-3: факт-первичная реконсиляция использует один link-list, удаляет orphan/дубликаты (включая Disabled/Disabled), разводит Examined / Converged / Failed (M2), ограничивает marker-prompt тремя попытками, добавляет фильтр истории и retention завершённых Links (M4), а также типизированное ожидание активации Mesh Node (M5). Physical acceptance остаётся внешним блокером;
• выполнить физический acceptance Hub + source Node + два destination Node с WireGuard/nftables/reboot.

Этап 4 — мониторинг и терминал

• CPU/load, RAM, swap, disk, inode, network и uptime;
• состояния SSH/WireGuard и latency;
• локальные предупреждения по ресурсам и доступности;
• автоматическое обновление каждые 30 секунд;
• локальная история до 240 точек на сервер;
• графики CPU, RAM и диска;
• экспорт redacted diagnostics;
• прямой SSH-терминал с явным выбором пользователя;
• source-scoped Automation API для AI-агента.

Этап 5 — качество и нагрузка

• HTTP authorization/integration tests;
• Linux Agent parser tests;
• Windows Desktop contract tests;
• тест 100 Node: concurrent heartbeat, inventory и replay;
• проверка TTL, retention, schema и backup/restore;
• CI Windows/Linux и проверка форматирования;
• выполнить полную физическую приёмку по docs/three-server-acceptance.md;
• добавить долговременный soak test и измеримые performance budgets.

Этап 6 — releases

• GitHub prerelease с test-signed Windows MSIX;
• SHA-256 для Windows package и Linux binaries;
• self-contained Control/Agent release artifacts;
• настроить постоянную доверенную Windows code-signing identity;
• синхронизировать все переводы README с текущим release status.

Этап 7 — собственный bootstrap Server Monitor Manager

• добавить bootstrap source в этот репозиторий;
• упаковывать bootstrap, checksum и compatibility manifest в release workflow;
• добавить криптографическую подпись compatibility manifest для production release;
• проверять Ubuntu 22.04/24.04 и Debian 12/13, amd64/arm64;
• добавить non-interactive install/update/rollback/uninstall;
• устанавливать Control/Agent, restricted helper и systemd units;
• локально создавать Agent key/CSR, выполнять mTLS enrollment и не сохранять token;
• добавить собственную установку WireGuard Hub/Node и выдачу внутренних адресов;
• реализовать nftables policy helper вместо временного deny-by-default helper;
• добавить native Ubuntu 22.04/24.04 x64/arm64 VM CI и повторную установку;
• добавить Debian 12/13 x64/arm64 systemd-container restart matrix;
• добавить полный reboot настоящих Debian VM;
• добавить локальную emergency recovery command для текущих Mesh/firewall-компонентов.

Этап 8 — Provisioning control plane

• модели и SQLite migration v2 для ProvisioningJob;
• state machine, confirmations, cancellation, retry и rollback;
• создание, чтение, подтверждение и отмена через Operator API;
• выполнение, retry, verification и rollback в полной state machine;
• безопасный частичный execution increment для system.base-install: timezone-only, factual verification и автоматический rollback;
• обязательные idempotency key, audit reason и job TTL;
• атомарный Agent job channel только для собственного node_id;
• начальные строгие JSON schemas v1 для preflight и system.base-install;
• versioned JSON schemas для остальных action type;
• restricted root helper через Unix socket (preflight, plan и подтверждённый timezone-only execution для system.base-install);
• двухфазный system.base-install: сохранённый проверенный plan до Operator confirmation;
• короткоживущий ECDSA execution grant, привязанный к Node, job и SHA-256 подтверждённого plan;
• structured redacted events, bounded Operator history и progress;
• NeedsReconciliation после истечения execution TTL и неопределённого результата;
• desired/factual configuration и drift (preflight завершён; остальные action type ещё не подключены);
• запрет параллельных активных заданий на одном Node (безопасный первый вариант).

Этап 9 — базовая настройка и пользователи

• preflight ОС, архитектуры, SSH, firewall, APT и capabilities;
• Desktop wizard timezone/locale/packages/swap/unattended upgrades;
• versioned package allowlist (catalog v1 с фиксированными package groups);
• root-only backups и symlink protection;
• user lifecycle без sudo по умолчанию;
• SSH public keys, fingerprints и permissions;
• sudo/passwordless sudo с отдельным подтверждением;
• block/unblock, sessions, services и безопасное удаление;
• verification и rollback для каждого action.

Этап 10 — firewall и безопасная миграция SSH

• редактор managed firewall rules IPv4/IPv6/CIDR;
• preflight port conflict и effective sshd config;
• managed sshd_config.d drop-in;
• sshd -t, sshd -T и firewall dry-run;
• второе SSH-подключение Desktop на новом порту;
• сохранение host key fingerprint;
• запрет закрытия порта 22 до успешной проверки;
• отдельное подтверждение закрытия старого порта;
• автоматический rollback без разрыва активной сессии.

Этап 11 — системный Xray VPN

• Node-specific encryption VPN subscription secrets;
• установка, update, disable и verification Xray;
• routing exclusions для Mesh, Control, SSH и VPN endpoint;
• automatic rollback timer;
• TCP/UDP/DNS/IPv6 probes и внешний IP до/после;
• system-wide kill switch с management exceptions;
• emergency disable без Control Hub;
• reboot/reconciliation tests.

Этап 12 — Xray VPN для пользователя

• UID/cgroup marking, fwmark, policy route и TPROXY;
• один активный VPN profile на UID;
• TCP, UDP, DNS и IPv6 policy;
• per-user kill switch;
• probes от назначенного UID;
• исключение Xray, Mesh и management traffic;
• отключение assignment при смене UID/удалении пользователя;
• UI assignment и audit;
• VM test: один пользователь через VPN, второй напрямую.

Этап 13 — hardening и дополнительные платформы

• threat-model review Provisioning и VPN;
• полная VM matrix и physical alpha acceptance;
• macOS и Linux Desktop после стабилизации Core/API;
• Android/iOS companion clients;
• push-уведомления без административных secrets у push provider.

Этап 14 — роль Monitor и доверенная поставка (Горизонт 0)

• install-monitor в bootstrap: системный пользователь, root-owned forced command, установка публичного ключа из Desktop, идемпотентная переустановка и удаление;
• контрактный тест формата снимка метрик, общий для forced command и Desktop-парсера;
• подписанный release manifest с хэшами всех артефактов и версиями Control/Agent/helper/Desktop;
• публичный ключ проверки вшит в bootstrap и Desktop, проверка подписи до разбора manifest;
• отказ update-control/update-agent при несовместимых версиях;
• негативные тесты в CI: подменённый архив, подменённый хэш, manifest без подписи;
• пиннинг GitHub Actions по commit SHA, dependabot, SBOM;
• автопродление сертификата Agent и документированная ротация Control CA;
• доверенная подпись Windows MSIX.

Этап 15 — политики подтверждения (Горизонт 1)

Спецификация: политики подтверждения.

• режимы none, operator, operator_reauth, owner, two_person, time_window, maintenance_window, emergency_only, read_only_automation;
• версионируемая политика на Control, недоступная для ослабления клиентом;
• повторное доказательство владения identity, привязанное к конкретному job_id;
• сравнение инициатора и подтверждающего по identity при two_person;
• изменение политики как аудируемое событие, действующее только на новые задания.

Этап 16 — alerts, уведомления и наблюдение за сервисами (Горизонт 1)

• alert rules: порог, duration, severity, cooldown, дедупликация;
• режим обслуживания, подтверждение, эскалация, история инцидентов, автозакрытие, тихие часы;
• Telegram только на чтение: /status, /servers, /alerts, /links, /jobs;
• наблюдение Docker: контейнеры, образы, healthcheck, счётчики рестартов, лимиты;
• наблюдение systemd: units, failed units, счётчики рестартов, journald;
• действия над Docker и systemd только по allowlist, с подтверждением и аудитом.

Этап 17 — Backup Manager (Горизонт 1)

• источники: каталоги, конфигурации, Docker volumes, Control DB и CA;
• хранилища local и S3;
• расписания, шифрование, retention, контрольные суммы;
• проверка архива и тестовое восстановление;
• оповещения об ошибках резервного копирования и об устаревшей копии.

Этап 18 — интеграция с KAgent (Горизонт 3)

Спецификация: интеграция с KAgent. Начинается только после закрытия Горизонта 1.

• локальное обнаружение через Unix-сокет с проверкой SO_PEERCRED, таймаутами и лимитами;
• идентичность KAgentIntegration с одноразовым token, сроком, областью Nodes и отзывом;
• модель возможностей: чтение, запрос, невыдаваемые;
• согласование версии протокола и фактически выданных возможностей;
• чтение Nodes, метрик, здоровья и событий;
• планы и запросы через обычный конвейер typed provisioning;
• жизненный цикл Worker с инвариантом недоверенного исполнителя;
• временные задачные Links с обязательным TTL и запретом destination = Hub или другой Worker;
• аварийные средства: отзыв, остановка, карантин, режим только чтения.