- docs/07: полный порядок staged apply, инвариант снятия guard, объяснение
почему окно 45 секунд не обязано покрывать smoke и почему guard не трогает
nftables.service, семантическая проверка эффективного firewall;
- docs/11: разделы A5e/A5f для новых unit-тестов и серверные сценарии D1e
(guard доходит до дедлайна), D1f (конкурентные операции), D1g (успешная
операция не оставляет следов транзакции); матрица и acceptance criteria
дополнены;
- docs/12: разбор отказов "уже выполняется другая операция" и
firewall_guard_fired;
- docs/13: строки журнала guard в таблице recovery, новый раздел 8a про замок
операций;
- docs/14 и purge-v0.sh: очистка /run/hy2xs, замка операций и candidate-файлов
firewall — /run это tmpfs, но очистка не имеет права требовать перезагрузки;
- README: защита от потери доступа при смене firewall и раздел "Одна операция
за раз";
- CHANGELOG: шестой проход.
fatal_pre_apply мог означать «хост уже изменён». install-state.json пишется
сразу после успешного preflight, до установки пакетов, но классификация
отказа его не учитывала. Падение apt-get объявлялось как «на сервере ничего
не изменено»: откат и обработка состояния пропускались, а маркер оставался на
диске и ломал следующую установку по clean-host контракту.
Ownership-флаги переформулированы с «шаг успешно завершился» на «операция
могла начать менять систему» и взводятся перед мутирующим вызовом: apt-get
умеет изменить систему и упасть. fatal_pre_apply теперь недостижим ни при
одном взведённом флаге, включая stateWritten.
Read-only guard PHASE 0 можно было обойти. Guard стоял на writeText,
writeTextAtomic, runVisible, runHidden и runRawVisible, но не на универсальном
run, через который в коде проходили и наблюдение (ss, systemctl is-active), и
настоящие мутации (useradd, install -d, mkdir, cp -a, tar). Универсального
раннера больше нет: runReadOnly/runReadOnlySecret без guard'а и runMutating*
под guard'ом, выбор — явное решение на месте вызова.
clean-host не замечал часть того, что удаляет purge. /var/lib/hysteria с
ACME-состоянием Hysteria, /var/log/hy2xs, /usr/local/lib/hy2xs и
/usr/local/bin/hy2xs-orchestrator не были маркерами: сервер, где остался
только старый runtime-state Hysteria, проходил проверку и получал свежую
установку поверх чужого состояния. Пути, которые install.sh создаёт между
фазами, помечены как созданные установщиком, иначе PHASE 1 отказала бы на
собственном оркестраторе.
purge-v0.sh --keep-hysteria-binary противоречил установщику: скрипт сохранял
/usr/local/bin/hysteria и сообщал «хост чист для установки HY2XS v1», хотя
clean-host считает этот бинарник legacy-маркером. Флаг удалён.
DNS проверялся на существование A-записи, но не на то, куда она ведёт. После
принудительной смены IPv4 провайдером doctor отвечал успехом, хотя клиентская
ссылка отправляла людей на чужую машину. Проверялся при этом HY2XS_DOMAIN,
тогда как в hysteria2:// уезжает HY2XS_PUBLIC_HOST.
Добавлен инвариант публичного endpoint: A-записи обязаны принадлежать
множеству публичных IPv4, назначенных интерфейсам этого сервера. Проверка
живёт в общем preflight, поэтому действует в install, reconfigure и doctor.
Адрес определяется локально, без внешних сервисов определения IP. Строгость
управляется HY2XS_PUBLIC_ENDPOINT_POLICY (strict по умолчанию); отсутствие
A-записи фатально при любом значении.
TS-санитайзер приведён к той же формулировке, что и Go: URL-значение
определяется по самому значению, а не по имени ключа.
Раз v1 принципиально не мигрирует состояние 0.x, политика должна быть
операционно завершённой: у оператора обязан быть явный способ привести
сервер в состояние, которое установщик примет.
tools/legacy/purge-v0.sh делает это отдельной осознанной операцией:
- по умолчанию печатает план и НЕ меняет ничего;
- выполнение требует --apply вместе с --yes-i-know;
- снимает таймеры отката firewall hy2xs-fw-rollback-*, которые
переживают неудачную установку и иначе продолжили бы менять ruleset
уже после очистки;
- из /etc/nftables.conf убирает только include HY2XS: остальной
ruleset принадлежит оператору;
- в конце проверяет чистоту хоста по тому же контракту, что и
установщик.
Из install.sh он не вызывается никогда: встроенная очистка вернула бы
destructive migration logic обратно в путь свежей установки - ровно то,
от чего мы ушли.
Acceptance-набор дополнен проверками, которые не дают инвариантам
тихо развалиться: порядок фаз в install.sh, наличие read-only guard,
preflight раньше первой записи install-state, ownership-aware rollback,
отказ по отсутствующей схеме, проверка поколения в reconfigure/repair,
структурная редакция, отсутствие удалённых маршрутов, e2e на
production-генераторе, сверка с upstream hashes.txt, контрольные суммы
в versions.env, версия админки из контракта.
founder