HY2XS_flamy

prod/HY2XS_flamy

Fork 0

Commit Graph

Author	SHA1	Message	Date
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	b22b4b0d99	fix(v1): сделать read-only свойством doctor, а sentinel-ошибки — решением Два свойства были описаны в документации, но не обеспечены кодом. 1. doctor «не изменяет диагностируемую систему». Принудительный skipServiceStart закрывал ровно одну ИЗВЕСТНУЮ мутацию — рестарт сервисов. Всё остальное в smoke держалось на том, что автор правки выбрал правильный раннер: `test -s`, `grep -q`, `stat`, `sudo -u ... test` и `nft -c` шли через мутирующий namespace, хотя ничего не меняют. Ожидание между попытками выполнялось подпроцессом `sleep` через runMutatingHidden, то есть пауза между двумя чтениями объявлялась изменением системы. Следствие: настоящая мутация, случайно добавленная в smoke, ничем бы от них не отличалась и была бы разрешена в doctor молча — а включить guard было нельзя, он отказал бы на первой же читающей команде. Команды классифицированы честно, `sleep` заменён таймером, и doctor целиком выполняется под тем же read-only guard, что и PHASE 0 установки. Guard снимается в finally. Диагностика при этом не сузилась: слушатели, healthz, права, machine auth, trafficStats, версия бинаря, семантика конфига и синтаксис nft проверяются полностью. 2. reset-admin различает «администратора нет» и «база не ответила». Слой данных специально возвращает разные sentinel'ы, но команда склеивала их обычным `if err != nil { создать } else { обновить }`. Опасен здесь не только нарушенный смысл: при транзиентном отказе чтения («database is locked») ветка создания отрабатывала успешно, и в таблице оказывались ДВЕ учётные записи администратора. GetAdminUser берёт First() и о второй строке не сообщает — на сервере оставалась вторая рабочая учётка с паролем, уже напечатанным на экран, и ни один запрос об этом не говорил. Заодно исправлено проглатывание ошибки хеширования: в ветке обновления стояло `hash, _ := util.HashPassword(password)` внутри литерала map. При отказе bcrypt в password_hash уезжала пустая строка, а на экран печатался пароль, которым войти уже невозможно — VerifyPassword отклоняет всё, что не bcrypt. Команда восстановления доступа умела молча его отобрать. Тесты: doctor-readonly.test.ts дополнен поведенческой проверкой guard и контролем набора раннеров в smoke; apps/cmd/reset_test.go проверяет обе ветки на настоящей SQLite и отказ чтения при полностью работоспособной базе — ровно тот случай, который прежний код превращал во второго администратора. Добавлена dao.CountAdminUsers: до неё появление дубликата было ненаблюдаемым.	2026-08-30 18:28:39 +05:00
founder	cf094f6e6f	fix(v1): сделать отзыв доступа, бэкап и диагностику соответствующими своим именам Проход по операциям, которые делают не то, что обещает их имя. P0. Удаление bootstrap-admin-peer не было отзывом доступа. Признаком «создавать пир или нет» служило наличие строки в таблице, а HY2XS_ADMIN_CON_PASS продолжает жить в /etc/hy2xs/hy2xs.env — его читает systemd-юнит. Оператор удалял пира, доступ исчезал, и ближайший restart возвращал того же пира с тем же секретом. Молча. Признаком стала отметка BOOTSTRAP_PEER_SEEDED в таблице config: «создавался когда-либо», а не «существует сейчас». Отметка и пир пишутся одной транзакцией. P1. Резервная копия с includeSecrets=true проглатывала и ошибку расшифровки, и отсутствие шифртекста, отдавая пира с пустым secret и успешный ответ. Теперь недоступный секрет любого пира отклоняет весь запрос с указанием имени. P1. DecryptPeerSecret возвращала содержимое колонки как расшифрованный секрет, если оно не начиналось с v1: — остаток поколения с открытыми секретами. P1. doctor перезапускал hysteria-server и hy2xs-admin: диагностика подозрения на проблему обрывала все живые соединения. P1. Админка сама генерировала HYSTERIA2_TRAFFIC_STATS_SECRET, записать который в /etc/hysteria/config.yaml она не может. Сервис объявлял себя здоровым, а machine auth переставал совпадать. P1. Обходы проверки зависимостей (accepted-risk/skipped) не могли произвести артефакт: приёмка требует dependency_security_gate=true. Удалены из сборки и документации, отсутствие проверяется приёмкой. P2. UPDATE по отсутствующей строке config считался успехом, и cron перепланировался при несохранённом значении. Решение по RowsAffected. P2. Слой данных не отличал «записи нет» от «база не ответила»: sentinel-значения ErrPeerNotFound / ErrAdminUserNotFound / ErrConfigNotFound / ErrStorage. P2. Удалены алиасы /:id/client-url и /:id/qr. Контракт разработки: apps/go.mod объявляет toolchain go1.26.7 (директива go — языковой baseline, а не выбор компилятора), tools/dev/doctor.sh\|.ps1 сверяют среду с versions.env.	2026-08-30 06:48:50 +05:00

Author

SHA1

Message

Date

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

b22b4b0d99

fix(v1): сделать read-only свойством doctor, а sentinel-ошибки — решением

Два свойства были описаны в документации, но не обеспечены кодом.

1. doctor «не изменяет диагностируемую систему».

   Принудительный skipServiceStart закрывал ровно одну ИЗВЕСТНУЮ мутацию —
   рестарт сервисов. Всё остальное в smoke держалось на том, что автор правки
   выбрал правильный раннер: `test -s`, `grep -q`, `stat`, `sudo -u ... test`
   и `nft -c` шли через мутирующий namespace, хотя ничего не меняют. Ожидание
   между попытками выполнялось подпроцессом `sleep` через runMutatingHidden,
   то есть пауза между двумя чтениями объявлялась изменением системы.

   Следствие: настоящая мутация, случайно добавленная в smoke, ничем бы от них
   не отличалась и была бы разрешена в doctor молча — а включить guard было
   нельзя, он отказал бы на первой же читающей команде.

   Команды классифицированы честно, `sleep` заменён таймером, и doctor целиком
   выполняется под тем же read-only guard, что и PHASE 0 установки. Guard
   снимается в finally. Диагностика при этом не сузилась: слушатели, healthz,
   права, machine auth, trafficStats, версия бинаря, семантика конфига и
   синтаксис nft проверяются полностью.

2. reset-admin различает «администратора нет» и «база не ответила».

   Слой данных специально возвращает разные sentinel'ы, но команда склеивала их
   обычным `if err != nil { создать } else { обновить }`. Опасен здесь не
   только нарушенный смысл: при транзиентном отказе чтения («database is
   locked») ветка создания отрабатывала успешно, и в таблице оказывались ДВЕ
   учётные записи администратора. GetAdminUser берёт First() и о второй строке
   не сообщает — на сервере оставалась вторая рабочая учётка с паролем, уже
   напечатанным на экран, и ни один запрос об этом не говорил.

   Заодно исправлено проглатывание ошибки хеширования: в ветке обновления
   стояло `hash, _ := util.HashPassword(password)` внутри литерала map. При
   отказе bcrypt в password_hash уезжала пустая строка, а на экран печатался
   пароль, которым войти уже невозможно — VerifyPassword отклоняет всё, что не
   bcrypt. Команда восстановления доступа умела молча его отобрать.

Тесты: doctor-readonly.test.ts дополнен поведенческой проверкой guard и
контролем набора раннеров в smoke; apps/cmd/reset_test.go проверяет обе ветки
на настоящей SQLite и отказ чтения при полностью работоспособной базе — ровно
тот случай, который прежний код превращал во второго администратора. Добавлена
dao.CountAdminUsers: до неё появление дубликата было ненаблюдаемым.

2026-08-30 18:28:39 +05:00

founder

cf094f6e6f

fix(v1): сделать отзыв доступа, бэкап и диагностику соответствующими своим именам

Проход по операциям, которые делают не то, что обещает их имя.

P0. Удаление bootstrap-admin-peer не было отзывом доступа. Признаком «создавать
пир или нет» служило наличие строки в таблице, а HY2XS_ADMIN_CON_PASS
продолжает жить в /etc/hy2xs/hy2xs.env — его читает systemd-юнит. Оператор
удалял пира, доступ исчезал, и ближайший restart возвращал того же пира с тем же
секретом. Молча. Признаком стала отметка BOOTSTRAP_PEER_SEEDED в таблице config:
«создавался когда-либо», а не «существует сейчас». Отметка и пир пишутся одной
транзакцией.

P1. Резервная копия с includeSecrets=true проглатывала и ошибку расшифровки, и
отсутствие шифртекста, отдавая пира с пустым secret и успешный ответ. Теперь
недоступный секрет любого пира отклоняет весь запрос с указанием имени.

P1. DecryptPeerSecret возвращала содержимое колонки как расшифрованный секрет,
если оно не начиналось с v1: — остаток поколения с открытыми секретами.

P1. doctor перезапускал hysteria-server и hy2xs-admin: диагностика подозрения на
проблему обрывала все живые соединения.

P1. Админка сама генерировала HYSTERIA2_TRAFFIC_STATS_SECRET, записать который в
/etc/hysteria/config.yaml она не может. Сервис объявлял себя здоровым, а machine
auth переставал совпадать.

P1. Обходы проверки зависимостей (accepted-risk/skipped) не могли произвести
артефакт: приёмка требует dependency_security_gate=true. Удалены из сборки и
документации, отсутствие проверяется приёмкой.

P2. UPDATE по отсутствующей строке config считался успехом, и cron
перепланировался при несохранённом значении. Решение по RowsAffected.

P2. Слой данных не отличал «записи нет» от «база не ответила»: sentinel-значения
ErrPeerNotFound / ErrAdminUserNotFound / ErrConfigNotFound / ErrStorage.

P2. Удалены алиасы /:id/client-url и /:id/qr.

Контракт разработки: apps/go.mod объявляет toolchain go1.26.7 (директива go —
языковой baseline, а не выбор компилятора), tools/dev/doctor.sh|.ps1 сверяют
среду с versions.env.

2026-08-30 06:48:50 +05:00

3 Commits