HY2XS_flamy

prod/HY2XS_flamy

Fork 0

Commit Graph

Author	SHA1	Message	Date
founder	4e7f54b9ff	fix(orchestrator): сделать staged firewall guard транзакционным Снятие автоматического отката firewall было утверждением, а не фактом: systemctl stop <unit>.timer <unit>.service \|\| true -> "firewall rollback timer disarmed" -> phase=installed Отказ остановки стирался через `\|\| true`, и взведённый таймер мог вернуть прежний firewall уже ПОСЛЕ долговечной записи успеха. Просто убрать `\|\| true` нельзя: для транзиентного юнита, уже убранного systemd, `systemctl stop` возвращает 5 — законный исход, неотличимый от успеха. Соседний дефект того же корня: guard мог сработать ВО ВРЕМЯ успешного smoke. Окно 45 секунд короче худшего случая smoke, а единственной проверкой firewall был `nft -c` — разбор текущего файла, каким бы он ни был. Откатившийся прежний ruleset проходил её зелёным, и сервер объявлялся настроенным с firewall, который операция же и заменила. Оба закрываются маркером /run/hy2xs/rollback/<op>/auto-rollback-fired, который rollback-скрипт создаёт первым действием. Инвариант стал детерминированным: маркер отсутствует И timer/service inactive => можно фиксировать успех Остальное в том же проходе: - auto-rollback переехал из однострочного `sh -c` в сгенерированный скрипт. Прежний держался на склейке соседних кавычек и на том, что op-id не содержит пробелов; теперь ключ проверяется, а скрипт покрыт тестом и shell-парсером; - скрипт накапливает rc и уходит в failed вместо молчаливого 0 при частичном восстановлении. Состояние nftables.service он сознательно не трогает: ExecStop у него делает `nft flush ruleset`; - smoke сверяет ЭФФЕКТИВНЫЙ firewall: фрагмент на диске против отрендеренного, принадлежность entrypoint и загруженность таблицы inet hy2xs; - откат восстанавливает enabled/active nftables.service — стадиями, идущими до применения ruleset; - остановка guard'а в rollbackFirewallNow стала стадией с отчётом, а не вызовом с `\|\| true` внутри; - `*.candidate` больше не остаются на диске навсегда; - стадии восстановления reconfigure независимы по ОТДЕЛЬНОМУ ФАЙЛУ, а не по группе; - ключ операции считается одной функцией: install писал в маркер сырой ISO-timestamp, и путь /run/hy2xs/rollback/<op_id> из runbook не существовал.	2026-08-30 22:54:57 +05:00
founder	330a63b050	fix(v1): сделать надёжным нижний слой отката, а не только его запуск Верхнеуровневый откат стал неотменяемым в прошлом проходе, и на этом фоне проявилось, что его substrate этой надёжности не соответствует: откат гарантированно запускался, но отдельные его шаги могли молча не выполнить восстановление, отчитаться успехом и уничтожить резервную копию. 1. Данные для отката уничтожались ДО фиксации успеха (commit ordering). cancelFirewallRollback снимала таймер автоотката И удаляла резервные копии firewall, а вызывалась до долговечной записи phase=installed. Отказ этой записи (ENOSPC/EIO/read-only ФС) приводил в обработчик ошибки, обязательный откат честно запускался и сообщал "no HY2XS rollback markers found": откатывать было нечем. Причём отказ записи маркера — ровно тот сценарий, который прошлый проход специально сделал безопасным. Разделено на disarmFirewallRollback (снять таймер, копии оставить) и cleanupFirewallRollback (удалить копии). Порядок в install и reconfigure: smoke_ok -> disarm -> durable installed -> cleanup best-effort. 2. Резервные копии снимались без доказательства. И firewall, и reconfigure копировали как `cp ... \|\| true`: отказ игнорировался, операция шла менять систему без копии, на которую рассчитывает откат. У firewall маркер prepared («данные для отката существуют») выставлялся вообще ДО копирования. Копирование строгое, факт создания проверяется, маркер ставится после. 3. Копии reconfigure смешивались между операциями. Общий набор *.bak в /etc/hy2xs/backups не был привязан к проходу. Если у операции B копирование падало, B всё равно менял систему, а его откат восстанавливал файлы операции A — сервер возвращался в более старое состояние и это выглядело успешным откатом. Копия стала операционной: /etc/hy2xs/backups/<op-id>/ с манифестом, где отсутствие файла записано явно ("present": false), а не выведено из неудачи cp. Разбор строгий, включая проверку opId. 4. Ошибка восстановления скрывалась, и после неё копии удалялись. rollbackFirewallNow выполняла cp и nft -f с `\|\| true`, затем безусловно удаляла /run/hy2xs/rollback/<op>. Худшая комбинация: неудача не видна, стадия успешна, данные для ручной починки уничтожены. Теперь копии удаляются только после подтверждённого успеха, иначе сохраняются с сообщением manual recovery data preserved at ... 5. Команды отката глушили собственный код возврата. До стадийного раннера `\|\| true` был единственной защитой от обрыва цепочки; после его появления стал маскировкой — стадия не могла сообщить, что ничего не сделала. Убран; rollbackCurrentState разбита на семь независимых стадий. 6. Долговечность записи каталога маркера. writeTextAtomic синхронизирует файл и его каталог, но при первой установке /var/lib/hy2xs создаётся тут же, и запись "hy2xs" в /var/lib оставалась несинхронизированной. ensureDir сообщает о фактическом создании и синхронизирует родителя только тогда. Отдельно про doctor. Утверждение аудита, что doctor вызывает UpdatePeerLastConnectionAt через успешную machine-auth, кодом не подтверждается: проба с действующим паролем ограничена `context.mode === "install"`, а doctor работает в режиме reconfigure. Инвариант, однако, ничем не охранялся — добавлены тест и приёмка. Документация уточнена: guard действует внутри процесса, а границу «что doctor шлёт по сети» держит состав проб; единственный остающийся след — записи в журнале админки, и это сказано прямо. Тесты: backup-integrity.test.ts (манифест, строгий разбор, копия до мутации, сохранение копий при неудачном восстановлении), commit-ordering.test.ts (disarm/cleanup разделены, порядок фиксации в обеих командах). Три теста, закреплявших прежний инвариант «каждая команда отката несёт \|\| true», переписаны на обратный: команды обязаны сообщать о своих отказах.	2026-08-30 19:32:43 +05:00
founder	672d455467	fix: закрыть каналы утечки секретов и сделать PHASE 1 владением оркестратора Hardening-проход перед первой сборкой на Debian. Три из найденного не воспроизводились ни на одном dry-run и проявились бы только на живом сервере. Установка * preflight внутри install вызывался дважды и оба раза проверял clean-host. Ко второму вызову на диске лежал собственный /var/lib/hy2xs/install-state.json, записанный после первого preflight, и опознавался как маркер посторонней установки: КАЖДАЯ чистая установка падала сразу после apt-get с fatal_post_apply и оставляла сервер наполовину настроенным. Чистота хоста — условие входа в операцию, возможности платформы проверяются уже внутри PHASE 1, поэтому checkCleanHost стал отдельным параметром без умолчания. * PHASE 1 начиналась в install.sh: shell сам создавал /usr/local/lib/hy2xs, ставил бинарник, вешал symlink и копировал runtime-пакет, и только потом запускал оркестратор с его собственным preflight. Отказ того preflight объявлялся fatal_pre_apply — «на сервере ничего не изменено» — при уже созданном каталоге оркестратора. Отследить владение мутацией невозможно, пока мутируют двое: install.sh больше не изменяет ничего, раскладку выполняет steps/bootstrap.ts под ownership.bootstrapTouched, пути попали в owned_paths. Как следствие удалено деление clean-host на фазы. * diagnosticsCollect стояла перед rollback обычным await в install и в reconfigure. На заполненном диске она падает сама и отменяла откат целиком. Диагностика — best effort, откат — обязателен. * reconfigure/repair выбирали записываемую фазу отказа регулярным выражением по тексту ошибки. Переведено на ownership-флаги. Секреты * Журнал админки писал RequestURI, то есть путь вместе с query. Hysteria обращается к /internal/hysteria/auth?access_token=<секрет> при каждом подключении пира, поэтому действующий machine token оседал открытым текстом в hy2xs-admin.log, который отдаётся через ExportLog и попадает в diagnostics-бандл. Логируется путь; значения query не пишутся, имена — пишутся. Канала было два: gin.Default() печатает path?query в stdout, оттуда в journald и в тот же бандл, — панель переведена на gin.New() + Recovery(). Журналы внутри бандла и журнал Hysteria из ExportLog теперь проходят санитайз. Сравнение токена — constant time. * Config API позволял прочитать и подменить ключи приложения: getConfig и listConfig принимали произвольный ключ, а проверка записи была denylist'ом из трёх ключей оркестратора. Запрос ?key=PEER_SECRET_ENCRYPTION_KEY отдавал master-key шифрования секретов пиров. Доступ переведён на allowlist, маршрут getConfig удалён целиком — потребителей у него не было ни одного. Пиры * Импорт применялся по одной записи вне транзакции, вопреки собственному контракту. Валидация не знает, что уже лежит в базе: cross-conflict по UNIQUE(name) оставлял часть файла применённой. Применение выполняется одной транзакцией, криптоматериал считается до её открытия. * Файл импорта мог содержать хвостовой JSON-документ, который молча не применялся. После разбора проверяется io.EOF. * Экспорт разделён на «Экспорт настроек» и «Резервная копия» с секретами и подтверждением: обычный экспорт выдаёт пирам новые секреты при импорте, и прежние клиентские ссылки после переноса переставали работать. Сборка * Два stale-грепа в приёмке роняли build.sh в самом конце, внутри verify_archive. Первый искал в smoke.ts исчезнувший литерал URL, второй совпадал с router_test.go, который перечисляет удалённые маршруты, потому что проверяет их отсутствие: добавление регрессионного теста ломало сборку. * verify_archive требовал наличия мутирующей строки в install.sh. Инвариант перевёрнут: их не должно быть ни одной. Очистка * Удалены entity.LegacyAccount, миграции 002/003 и мёртвые хелперы listSQLMigrationFiles и envInt: v1 не мигрирует базу 0.x ни при каком сценарии. Номера оставшихся миграций сохранены. H UI-словарь убран из обычных доков, в docs/14 он остаётся — там это имена объектов для удаления. * Список непубличных IPv4 приведён к IANA Special-Purpose Address Registry: 203.0.113.5 из RFC-примеров считался публичным адресом сервера. Отказ резолвера отделён от отсутствия A-записи. Проверено: bun test 233, go test 71, tsc/vue-tsc, bash -n 11 скриптов, приёмка прогнана против дерева.	2026-08-28 05:27:10 +05:00

Author

SHA1

Message

Date

founder

4e7f54b9ff

fix(orchestrator): сделать staged firewall guard транзакционным

Снятие автоматического отката firewall было утверждением, а не фактом:

    systemctl stop <unit>.timer <unit>.service || true
    -> "firewall rollback timer disarmed"
    -> phase=installed

Отказ остановки стирался через `|| true`, и взведённый таймер мог вернуть
прежний firewall уже ПОСЛЕ долговечной записи успеха. Просто убрать `|| true`
нельзя: для транзиентного юнита, уже убранного systemd, `systemctl stop`
возвращает 5 — законный исход, неотличимый от успеха.

Соседний дефект того же корня: guard мог сработать ВО ВРЕМЯ успешного smoke.
Окно 45 секунд короче худшего случая smoke, а единственной проверкой firewall
был `nft -c` — разбор текущего файла, каким бы он ни был. Откатившийся прежний
ruleset проходил её зелёным, и сервер объявлялся настроенным с firewall,
который операция же и заменила.

Оба закрываются маркером /run/hy2xs/rollback/<op>/auto-rollback-fired, который
rollback-скрипт создаёт первым действием. Инвариант стал детерминированным:

    маркер отсутствует И timer/service inactive => можно фиксировать успех

Остальное в том же проходе:

- auto-rollback переехал из однострочного `sh -c` в сгенерированный скрипт.
  Прежний держался на склейке соседних кавычек и на том, что op-id не содержит
  пробелов; теперь ключ проверяется, а скрипт покрыт тестом и shell-парсером;
- скрипт накапливает rc и уходит в failed вместо молчаливого 0 при частичном
  восстановлении. Состояние nftables.service он сознательно не трогает:
  ExecStop у него делает `nft flush ruleset`;
- smoke сверяет ЭФФЕКТИВНЫЙ firewall: фрагмент на диске против отрендеренного,
  принадлежность entrypoint и загруженность таблицы inet hy2xs;
- откат восстанавливает enabled/active nftables.service — стадиями, идущими до
  применения ruleset;
- остановка guard'а в rollbackFirewallNow стала стадией с отчётом, а не вызовом
  с `|| true` внутри;
- `*.candidate` больше не остаются на диске навсегда;
- стадии восстановления reconfigure независимы по ОТДЕЛЬНОМУ ФАЙЛУ, а не по
  группе;
- ключ операции считается одной функцией: install писал в маркер сырой
  ISO-timestamp, и путь /run/hy2xs/rollback/<op_id> из runbook не существовал.

2026-08-30 22:54:57 +05:00

founder

330a63b050

fix(v1): сделать надёжным нижний слой отката, а не только его запуск

Верхнеуровневый откат стал неотменяемым в прошлом проходе, и на этом фоне
проявилось, что его substrate этой надёжности не соответствует: откат
гарантированно запускался, но отдельные его шаги могли молча не выполнить
восстановление, отчитаться успехом и уничтожить резервную копию.

1. Данные для отката уничтожались ДО фиксации успеха (commit ordering).

cancelFirewallRollback снимала таймер автоотката И удаляла резервные копии
firewall, а вызывалась до долговечной записи phase=installed. Отказ этой
записи (ENOSPC/EIO/read-only ФС) приводил в обработчик ошибки, обязательный
откат честно запускался и сообщал "no HY2XS rollback markers found":
откатывать было нечем. Причём отказ записи маркера — ровно тот сценарий,
который прошлый проход специально сделал безопасным.

Разделено на disarmFirewallRollback (снять таймер, копии оставить) и
cleanupFirewallRollback (удалить копии). Порядок в install и reconfigure:
smoke_ok -> disarm -> durable installed -> cleanup best-effort.

2. Резервные копии снимались без доказательства.

И firewall, и reconfigure копировали как `cp ... || true`: отказ
игнорировался, операция шла менять систему без копии, на которую
рассчитывает откат. У firewall маркер prepared («данные для отката
существуют») выставлялся вообще ДО копирования. Копирование строгое, факт
создания проверяется, маркер ставится после.

3. Копии reconfigure смешивались между операциями.

Общий набор *.bak в /etc/hy2xs/backups не был привязан к проходу. Если у
операции B копирование падало, B всё равно менял систему, а его откат
восстанавливал файлы операции A — сервер возвращался в более старое
состояние и это выглядело успешным откатом. Копия стала операционной:
/etc/hy2xs/backups/<op-id>/ с манифестом, где отсутствие файла записано
явно ("present": false), а не выведено из неудачи cp. Разбор строгий,
включая проверку opId.

4. Ошибка восстановления скрывалась, и после неё копии удалялись.

rollbackFirewallNow выполняла cp и nft -f с `|| true`, затем безусловно
удаляла /run/hy2xs/rollback/<op>. Худшая комбинация: неудача не видна,
стадия успешна, данные для ручной починки уничтожены. Теперь копии
удаляются только после подтверждённого успеха, иначе сохраняются с
сообщением manual recovery data preserved at ...

5. Команды отката глушили собственный код возврата.

До стадийного раннера `|| true` был единственной защитой от обрыва цепочки;
после его появления стал маскировкой — стадия не могла сообщить, что
ничего не сделала. Убран; rollbackCurrentState разбита на семь независимых
стадий.

6. Долговечность записи каталога маркера.

writeTextAtomic синхронизирует файл и его каталог, но при первой установке
/var/lib/hy2xs создаётся тут же, и запись "hy2xs" в /var/lib оставалась
несинхронизированной. ensureDir сообщает о фактическом создании и
синхронизирует родителя только тогда.

Отдельно про doctor. Утверждение аудита, что doctor вызывает
UpdatePeerLastConnectionAt через успешную machine-auth, кодом не
подтверждается: проба с действующим паролем ограничена `context.mode ===
"install"`, а doctor работает в режиме reconfigure. Инвариант, однако, ничем не
охранялся — добавлены тест и приёмка. Документация уточнена: guard действует
внутри процесса, а границу «что doctor шлёт по сети» держит состав проб;
единственный остающийся след — записи в журнале админки, и это сказано прямо.

Тесты: backup-integrity.test.ts (манифест, строгий разбор, копия до мутации,
сохранение копий при неудачном восстановлении), commit-ordering.test.ts
(disarm/cleanup разделены, порядок фиксации в обеих командах). Три теста,
закреплявших прежний инвариант «каждая команда отката несёт || true»,
переписаны на обратный: команды обязаны сообщать о своих отказах.

2026-08-30 19:32:43 +05:00

founder

672d455467

fix: закрыть каналы утечки секретов и сделать PHASE 1 владением оркестратора

Hardening-проход перед первой сборкой на Debian. Три из найденного не
воспроизводились ни на одном dry-run и проявились бы только на живом сервере.

Установка

* preflight внутри install вызывался дважды и оба раза проверял clean-host.
Ко второму вызову на диске лежал собственный /var/lib/hy2xs/install-state.json,
записанный после первого preflight, и опознавался как маркер посторонней
установки: КАЖДАЯ чистая установка падала сразу после apt-get с
fatal_post_apply и оставляла сервер наполовину настроенным. Чистота хоста —
условие входа в операцию, возможности платформы проверяются уже внутри
PHASE 1, поэтому checkCleanHost стал отдельным параметром без умолчания.

* PHASE 1 начиналась в install.sh: shell сам создавал /usr/local/lib/hy2xs,
ставил бинарник, вешал symlink и копировал runtime-пакет, и только потом
запускал оркестратор с его собственным preflight. Отказ того preflight
объявлялся fatal_pre_apply — «на сервере ничего не изменено» — при уже
созданном каталоге оркестратора. Отследить владение мутацией невозможно,
пока мутируют двое: install.sh больше не изменяет ничего, раскладку
выполняет steps/bootstrap.ts под ownership.bootstrapTouched, пути попали
в owned_paths. Как следствие удалено деление clean-host на фазы.

* diagnosticsCollect стояла перед rollback обычным await в install и в
reconfigure. На заполненном диске она падает сама и отменяла откат целиком.
Диагностика — best effort, откат — обязателен.

* reconfigure/repair выбирали записываемую фазу отказа регулярным выражением
по тексту ошибки. Переведено на ownership-флаги.

Секреты

* Журнал админки писал RequestURI, то есть путь вместе с query. Hysteria
обращается к /internal/hysteria/auth?access_token=<секрет> при каждом
подключении пира, поэтому действующий machine token оседал открытым текстом
в hy2xs-admin.log, который отдаётся через ExportLog и попадает в
diagnostics-бандл. Логируется путь; значения query не пишутся, имена —
пишутся. Канала было два: gin.Default() печатает path?query в stdout,
оттуда в journald и в тот же бандл, — панель переведена на gin.New() +
Recovery(). Журналы внутри бандла и журнал Hysteria из ExportLog теперь
проходят санитайз. Сравнение токена — constant time.

* Config API позволял прочитать и подменить ключи приложения: getConfig и
listConfig принимали произвольный ключ, а проверка записи была denylist'ом
из трёх ключей оркестратора. Запрос ?key=PEER_SECRET_ENCRYPTION_KEY отдавал
master-key шифрования секретов пиров. Доступ переведён на allowlist, маршрут
getConfig удалён целиком — потребителей у него не было ни одного.

Пиры

* Импорт применялся по одной записи вне транзакции, вопреки собственному
контракту. Валидация не знает, что уже лежит в базе: cross-conflict по
UNIQUE(name) оставлял часть файла применённой. Применение выполняется одной
транзакцией, криптоматериал считается до её открытия.

* Файл импорта мог содержать хвостовой JSON-документ, который молча не
применялся. После разбора проверяется io.EOF.

* Экспорт разделён на «Экспорт настроек» и «Резервная копия» с секретами и
подтверждением: обычный экспорт выдаёт пирам новые секреты при импорте, и
прежние клиентские ссылки после переноса переставали работать.

Сборка

* Два stale-грепа в приёмке роняли build.sh в самом конце, внутри
verify_archive. Первый искал в smoke.ts исчезнувший литерал URL, второй
совпадал с router_test.go, который перечисляет удалённые маршруты, потому
что проверяет их отсутствие: добавление регрессионного теста ломало сборку.

* verify_archive требовал наличия мутирующей строки в install.sh. Инвариант
перевёрнут: их не должно быть ни одной.

Очистка

* Удалены entity.LegacyAccount, миграции 002/003 и мёртвые хелперы
listSQLMigrationFiles и envInt: v1 не мигрирует базу 0.x ни при каком
сценарии. Номера оставшихся миграций сохранены. H UI-словарь убран из
обычных доков, в docs/14 он остаётся — там это имена объектов для удаления.

* Список непубличных IPv4 приведён к IANA Special-Purpose Address Registry:
203.0.113.5 из RFC-примеров считался публичным адресом сервера. Отказ
резолвера отделён от отсутствия A-записи.

Проверено: bun test 233, go test 71, tsc/vue-tsc, bash -n 11 скриптов,
приёмка прогнана против дерева.

2026-08-28 05:27:10 +05:00

3 Commits