server-monitor-manager/agents/hermes/inbox/from-smm-deliverables/Старые задачи/smm-hermes-task-release-alpha8-and-monitor-2026-08-10.md

Hermes: совместимость БД, выпуск alpha.8, роль Monitor

Состояние

• main @ df4dfd1;
• PR #24 fix(enrollment): repair node enrollment path слит — блокирующий дефект регистрации Node закрыт;
• слиты шесть обновлений dependabot, включая SQLitePCLRaw 2.1.12 → 3.0.5;
• последний релиз — v0.1.0-alpha.7, в нём фикса регистрации нет;
• на живом Hub пользователя развёрнут alpha.7 с работающей control.db, созданной версией 2.1.12.

Ветка: hermes/release-alpha8-and-monitor (части 1–2) и hermes/monitor-role (часть 3) — либо одна ветка на часть, по вашему усмотрению, но части 1–2 и часть 3 разными PR.

---

Часть 1 — совместимость существующей базы с SQLitePCLRaw 3.0.5 · сделать первым

SQLitePCLRaw — нативная библиотека под SQLite, на которой держится вся база Control: enrollment, identities, links, provisioning, audit. Мажорное обновление слито без проверки на существующей базе; CI создаёт базу с нуля и потому совместимость не проверяет в принципе.

Если совместимости нет, это проявится в момент update-control на живом Hub — то есть в самый неудобный момент и без пути назад.

Проверить:

1. Взять control.db, созданную сборкой на 2.1.12 (подойдёт база с реального Hub либо созданная из тега v0.1.0-alpha.7).
2. Открыть её сборкой из текущего main: PRAGMA user_version читается, значение прежнее, миграции не пытаются примениться повторно.
3. Данные читаются: агенты, identities, links, provisioning-задания, аудит.
4. backup-create на этой базе и backup-restore из полученного бэкапа проходят и дают рабочий Control.
5. Повторить на linux-arm64 self-contained trimmed single-file: нативные библиотеки в такой сборке линкуются иначе, чем под x64.

Если хоть один пункт не проходит — не выпускать релиз, откатить #23 отдельным PR и написать об этом прямо.

Обязательно добавить тест, которого сейчас нет: открытие базы предыдущей схемы. Зафиксировать в репозитории эталонную control.db (или скрипт её воспроизведения) и проверять открытие при каждом прогоне. Без него следующее обновление SQLite повторит ту же историю.

---

Часть 2 — выпустить v0.1.0-alpha.8

Пользовательские серверы стоят: Hub развёрнут и работает, Node зарегистрировать нельзя, потому что фикс лежит только в main.

После части 1:

1. Тег v0.1.0-alpha.8 на текущий main, push тегом через git push — release-workflow триггерится на push: tags: v*.
2. Убедиться, что оба release-workflow отработали и в релиз попали: bootstrap + .sha256, оба tar.gz + .sha256, manifest, MSIX, SBOM.
3. Проверить, что permissions на job-уровне из PR #14 действительно сработали — release-workflow не запускаются на pull request, и это первый настоящий их прогон после той правки. Если публикация упадёт по 403, чинить здесь же.
4. К релизу приложить smm-setup.sh из server-monitor-manager-deliverables — файл берётся как ассет релиза и должен обновиться на новый тег. В нём есть временный обход бага validate_control_url; убрать его, раз дефект исправлен в #24. Обход помечен комментарием в коде.

После выпуска сообщить: пользователь повторит регистрацию Node на своих серверах через update-control и новый node-code.

---

Часть 3 — роль Monitor в bootstrap

Пункт Горизонта 0, который никто не начинал. Сегодня SSH-мониторинг — функция, ради которой существует Desktop, — не имеет серверной части: в bootstrap нет действия установки, forced-command скрипт не поставляется, а парсер SshMonitorService.QueryAsync ожидает ключи PROTOCOL, CPU_COUNT, MEM_AVAILABLE_KB, DISK_INODES_TOTAL и другие, которых в репозитории не производит никто.

Объём:

• действия install-monitor PUBLIC_KEY и uninstall-monitor;
• системный пользователь ochenstarik-monitor: nologin, без пароля, без sudo;
• /usr/local/libexec/ochenstarik-smm-metrics, root-owned 0755, выдающий ровно снимок из docs/installer-contract.md §7 и read-only mesh status;
• authorized_keys с command="…",restrict,no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding;
• идемпотентность повторного запуска и корректное удаление;
• контрактный тест формата снимка, общий для скрипта и парсера Desktop — иначе они разъедутся снова.

Формат снимка не выдумывать: он уже зафиксирован в docs/installer-contract.md §7.

SshMonitorService.cs не менять — если парсер потребует правки, описать нужное в REPORT.md.

---

Критерий приёмки

• существующая база открывается новой сборкой, backup/restore работают, есть тест на предыдущую схему;
• v0.1.0-alpha.8 выпущен со всеми ассетами, публикация не упала по правам;
• обход validate_control_url из smm-setup.sh убран;
• чистый сервер попадает под мониторинг одной командой, README соответствует коду;
• контрактный тест формата снимка в CI;
• Control suite прогнан на Linux;
• PR созданы, CI зелёный.

Отчёт

Раздельно: локально, в CI со ссылками, не запускалось и почему. Физическая приёмка на трёх серверах выполняется пользователем и в это задание не входит.