Позиционирование как самостоятельного продукта и переход на AGPL-3.0-only

HY2XS больше не описывается как форк H UI. Из README, docs, сообщений
builder'а и post-install metadata убрана вся fork/H UI терминология.

Лицензия:
- LICENSE: MIT заменён на полный текст AGPL-3.0-only
- README: бейдж и раздел лицензии, подпись Flamy Studio
- orchestrator/package.json, apps/frontend/package.json: license
- package.sh: LICENSE кладётся в install package, license=AGPL-3.0-only
  в metadata
- verify.sh, acceptance.sh: проверки корневой AGPL и metadata

Документация:
- 04-admin-panel-h-ui-fork.md -> 04-admin-panel.md, переписан вокруг
  модели Hysteria2 = external runtime dependency,
  HY2XS admin = native HY2XS component
- docs 01, 02, 03, 08, 09, 11, 12, README: единая терминология HY2XS admin

post-install.env:
- блок HUI_* заменён на HY2XS_ADMIN_*, HUI_FORK_REF -> HY2XS_ADMIN_SOURCE

Внутренний legacy namespace (H_UI_* ключи SQLite, HUI_DATA/HUI_LOG,
API /hui, h_ui_db.sql) намеренно не тронут: он требует отдельной
миграции БД и выносится в отдельный этап.
This commit is contained in:
2026-08-15 03:34:18 +05:00
parent 656cc7ca5b
commit b903a09fb1
20 changed files with 835 additions and 170 deletions
+3 -3
View File
@@ -11,7 +11,7 @@
Функции:
- хранение исходников проекта
- хранение и сопровождение **нашего форка HY2XS admin**
- хранение и сопровождение исходного кода **HY2XS admin**
- хранение исходников оркестратора на **Bun + TypeScript**
- компиляция install-артефакта оркестратора
- подготовка install package
@@ -46,7 +46,7 @@ Target layer **не содержит сборщика** и **не выполня
- лимит по умолчанию: 50/50 Mbps на клиента
### UI слой
- **наш форк H UI / HY2XS admin**
- **HY2XS admin** — штатный компонент проекта
- поставляется внутри проекта
- устанавливается локально из итогового пакета
- не скачивается с upstream на сервере
@@ -66,7 +66,7 @@ Target layer **не содержит сборщика** и **не выполня
### 1. Ядро, UI и оркестратор ведут себя по-разному
- Hysteria2: берём свежую upstream-версию при установке
- HY2XS admin: держим **свой fork** и поставляем его сами
- HY2XS admin: разрабатываем **внутри проекта** и поставляем его сами
- Оркестратор: пишем на **Bun + TypeScript**, но собираем **локально**, а не на target
### 2. Builder и target не смешиваются
+2 -2
View File
@@ -36,7 +36,7 @@ Builder не является частью target install flow: на target serv
- шаблоны конфигов
- systemd unit templates
- docs
- **наш fork HY2XS admin**
- исходный код **HY2XS admin**
- шаблоны для `post-install.env`
- package metadata
@@ -79,7 +79,7 @@ project/
│ ├── templates/
│ └── systemd/
├── ui/
│ └── hy2xs-admin-fork/
│ └── hy2xs-admin/
├── docs/
└── dist/
```
+1 -1
View File
@@ -7,7 +7,7 @@
## Роль Hysteria2
Hysteria2 — основной транспортный компонент сервера.
Он не форкается и не поставляется как часть UI-форка.
Он не вендорится и не собирается как часть HY2XS.
## Source policy
-114
View File
@@ -1,114 +0,0 @@
# Admin panel: bundled H UI fork
## Цель документа
Зафиксировать новую модель работы с UI: панель больше не рассматривается как внешний upstream-зависимый слой для target install, а становится **нашим вендорным компонентом**, поставляемым вместе с проектом.
## Почему меняем подход
Причина архитектурная:
- Hysteria2 ядро считаем достаточно стабильным upstream-компонентом
- UI считаем более слабым по поддержке и менее надёжным как внешний operational dependency
- поэтому UI забираем к себе: **fork + vendor + ship with package**
## Что это означает практически
### Было
- Hysteria — upstream
- H UI — отдельный upstream
- оркестратор ставит оба компонента как внешние зависимости
### Стало
- Hysteria — upstream
- H UI — **наш fork внутри проекта**
- итоговый package уже содержит UI
- на target server не надо скачивать H UI из чужого репозитория
## Правильная модель
- локальный builder хранит и собирает наш fork H UI
- install package везёт UI на сервер
- target-side orchestrator только раскладывает UI и создаёт unit
- H UI продолжает работать как надстройка над Hysteria YAML/API-слоем
## Что считать нормальным
Факт, что H UI — это надстройка над YAML-конфигом Hysteria, считается нормальным.
Это не аргумент против использования UI.
Важно только, чтобы источник истины по runtime-состоянию был понятен и не было двух конкурирующих конфигурационных миров без правил синхронизации.
## Scope панели
Панель нужна для:
- operator-facing управления
- просмотра статуса
- работы с пользователями / трафиком / сущностями доступа
- удобной админской рутины
Панель не должна:
- определять install lifecycle сервера
- превращать систему в сложный control plane
- диктовать scope оркестратора
## Правила поставки
Bundled H UI должна:
- поставляться внутри итогового пакета
- иметь свой install dir
- иметь свой data dir
- иметь rootless systemd unit (`hy2xs-admin`)
- запускаться отдельным systemd unit
- не требовать target-side build
## Правила ответственности
### Source of truth
- runtime transport layer: Hysteria
- операторский UI layer: forked H UI
- install lifecycle: наш orchestrator
- deploy facts: `post-install.env`
## Production lifecycle Hysteria2
В production package HY2XS admin не скачивает и не обновляет бинарь Hysteria2 самостоятельно.
Правильная модель:
- Hysteria2 устанавливается install-оркестратором с official upstream
- Hysteria2 запускается отдельным `hysteria-server.service`
- HY2XS admin работает как operator UI и HTTP auth/traffic layer
- HY2XS admin не запускается от root
- смена версии Hysteria2 через UI отключена в baseline
- список upstream releases не является частью operator UI baseline
- port hopping не является частью production path
### Что нельзя делать
- скачивать H UI с upstream прямо на target как baseline
- собирать UI на сервере
- склеивать unit Hysteria и unit H UI в один сервис
- раздувать оркестратор из-за особенностей UI
- использовать HY2XS admin как updater бинаря Hysteria2
- использовать `JWT_SECRET` как `trafficStats.secret` для Hysteria API
## Что фиксировать в `post-install.env`
Минимум:
- `HUI_ENABLED`
- `HUI_FORK_REF`
- `HUI_BUILD_ID`
- `HUI_BIND_HOST`
- `HUI_PORT`
- `HUI_INSTALL_DIR`
- `HUI_DATA_DIR`
## Инварианты
Схема считается корректной, если:
1. UI приезжает на target уже в составе пакета
2. target не скачивает UI с внешнего upstream
3. UI работает отдельным сервисом
4. UI не меняет install-only scope оркестратора
5. Hysteria остаётся внешним vanilla upstream-компонентом
6. UI не выступает updater-менеджером Hysteria2
7. `trafficStats.secret` не связан с `JWT_SECRET`
+109
View File
@@ -0,0 +1,109 @@
# Admin panel: HY2XS admin
## Цель документа
Зафиксировать модель работы с admin-панелью: HY2XS admin является **штатным компонентом HY2XS**, а не внешней зависимостью, которую target server где-то добывает во время установки.
## Место компонента в системе
Проект состоит из компонентов двух разных типов:
- **Hysteria2** — external runtime dependency. Ванильный upstream-бинарник, который оркестратор забирает из официального источника во время установки.
- **HY2XS admin** — native HY2XS component. Исходный код лежит в репозитории, компонент собирается production builder'ом вместе с остальными артефактами HY2XS.
Это противопоставление и есть основная архитектурная граница.
## Состав компонента
- исходный код admin-компонента хранится в [`apps/`](../apps);
- backend реализован на Go;
- frontend реализован на Vue/Vite;
- frontend-ассеты встраиваются в Go-бинарник;
- компонент собирается production builder'ом вместе с остальными артефактами HY2XS;
- готовый бинарник едет в install package как `ui/hy2xs-admin/hy2xs-admin`.
## Правила поставки
HY2XS admin:
- поставляется внутри итогового пакета;
- имеет свой install dir;
- имеет свой data dir;
- запускается отдельным rootless systemd unit (`hy2xs-admin`);
- не требует target-side build.
Target server **не собирает** admin-компонент из исходного кода и **не скачивает** его из внешнего репозитория.
## Scope панели
Панель нужна для:
- operator-facing управления;
- просмотра статуса;
- работы с пользователями / трафиком / сущностями доступа;
- удобной админской рутины.
Панель не должна:
- определять install lifecycle сервера;
- превращать систему в сложный control plane;
- диктовать scope оркестратора.
HY2XS admin работает как надстройка над Hysteria YAML/API-слоем. Это нормально: важно только, чтобы источник истины по runtime-состоянию был понятен и не было двух конкурирующих конфигурационных миров без правил синхронизации.
## Правила ответственности
### Source of truth
- runtime transport layer: Hysteria2
- операторский UI layer: HY2XS admin
- install lifecycle: оркестратор HY2XS
- deploy facts: `post-install.env`
## Production lifecycle Hysteria2
В production package HY2XS admin не скачивает и не обновляет бинарь Hysteria2 самостоятельно.
Правильная модель:
- Hysteria2 устанавливается install-оркестратором с official upstream;
- Hysteria2 запускается отдельным `hysteria-server.service`;
- HY2XS admin работает как operator UI и HTTP auth/traffic layer;
- HY2XS admin не запускается от root;
- смена версии Hysteria2 через UI отключена в baseline;
- список upstream releases не является частью operator UI baseline;
- port hopping не является частью production path.
### Что нельзя делать
- собирать admin-компонент на target server;
- скачивать admin-компонент на target из внешнего репозитория;
- склеивать unit Hysteria2 и unit HY2XS admin в один сервис;
- раздувать оркестратор из-за особенностей панели;
- использовать HY2XS admin как updater бинаря Hysteria2;
- использовать `JWT_SECRET` как `trafficStats.secret` для Hysteria API.
## Что фиксировать в `post-install.env`
Минимум:
- `HY2XS_ADMIN_ENABLED`
- `HY2XS_ADMIN_SOURCE`
- `HY2XS_ADMIN_BUILD_ID`
- `HY2XS_ADMIN_BIND_HOST`
- `HY2XS_ADMIN_PORT`
- `HY2XS_ADMIN_INSTALL_DIR`
- `HY2XS_ADMIN_DATA_DIR`
- `HY2XS_ADMIN_LOG_DIR`
## Инварианты
Схема считается корректной, если:
1. HY2XS admin приезжает на target уже в составе пакета
2. target не скачивает и не собирает admin-компонент
3. HY2XS admin работает отдельным сервисом
4. HY2XS admin не меняет install-only scope оркестратора
5. Hysteria2 остаётся внешним vanilla upstream-компонентом
6. HY2XS admin не выступает updater-менеджером Hysteria2
7. `trafficStats.secret` не связан с `JWT_SECRET`
+1 -1
View File
@@ -35,7 +35,7 @@
- uninstall
- repair старых неизвестных состояний
- target-side build
- target-side git clone нашего UI-форка
- target-side git clone исходного кода HY2XS admin
- Telegram-бот / access delivery
## Предусловия
+9 -9
View File
@@ -19,7 +19,7 @@
- какой build артефакт использован
- какой стек оркестратора применён
- какая версия Hysteria реально установилась
- какой fork/build UI разложен на target
- какой build HY2XS admin разложен на target
- какие базовые параметры сети и портов заданы
Именно для этого создаётся `post-install.env`.
@@ -89,14 +89,14 @@
- `HY2_CONFIG_PATH`
### HY2XS admin
- `HUI_ENABLED`
- `HUI_FORK_REF`
- `HUI_BUILD_ID`
- `HUI_BIND_HOST`
- `HUI_PORT`
- `HUI_INSTALL_DIR`
- `HUI_DATA_DIR`
- `HUI_LOG_DIR`
- `HY2XS_ADMIN_ENABLED`
- `HY2XS_ADMIN_SOURCE`
- `HY2XS_ADMIN_BUILD_ID`
- `HY2XS_ADMIN_BIND_HOST`
- `HY2XS_ADMIN_PORT`
- `HY2XS_ADMIN_INSTALL_DIR`
- `HY2XS_ADMIN_DATA_DIR`
- `HY2XS_ADMIN_LOG_DIR`
## Как работать с файлами
+1 -1
View File
@@ -107,7 +107,7 @@
1. production builder на Debian 13 amd64 выдаёт переносимый install package
2. target server не выполняет build step
3. Hysteria2 получена из official upstream
4. UI поставлен из bundled fork
4. HY2XS admin поставлен из install package
5. `post-install.env` отражает фактическое deploy-состояние
6. оркестратор зафиксирован как Bun/TypeScript stack и поставляется как готовый install-артефакт
7. оркестратор не требует standalone update / rollback / uninstall subcommands
+3 -3
View File
@@ -24,8 +24,8 @@ apt-get install -y sudo ca-certificates curl iproute2 tar openssl nftables syste
### 2. UI приезжает из нашего пакета
Если проблема в UI, сначала смотреть:
- какой `HUI_FORK_REF`
- какой `HUI_BUILD_ID`
- какой `HY2XS_ADMIN_SOURCE`
- какой `HY2XS_ADMIN_BUILD_ID`
- тот ли пакет вообще стоит на сервере
### 3. Hysteria приходит из upstream
@@ -108,7 +108,7 @@ curl -sS \
Проверить:
- разложился ли bundled UI
- корректен ли unit `hy2xs-admin`
- совпадает ли `HUI_INSTALL_DIR` с реальностью
- совпадает ли `HY2XS_ADMIN_INSTALL_DIR` с реальностью
- не сломан ли bind host / port
### Admin UI access via SSH tunnel
+7 -7
View File
@@ -3,7 +3,7 @@
Этот набор документов фиксирует актуальную baseline-модель HY2XS под следующие ограничения:
- серверный транспорт: **ванильная Hysteria2**
- UI: **наш форк H UI / HY2XS admin**, поставляется **вместе с проектом**
- UI: **HY2XS admin**, штатный компонент проекта, поставляется **вместе с пакетом**
- target OS: **только чистый Debian 13**
- оркестратор: **install-only**, только первичная установка и базовая настройка
- стек оркестратора: **Bun + TypeScript**
@@ -18,20 +18,20 @@
В этой редакции зафиксированы два слоя:
1. **Builder layer** — работает на отдельном **Debian 13 amd64 build host**.
Он собирает итоговый пакет, подготавливает **наш форк HY2XS admin**, компилирует **Bun/TypeScript оркестратор** в install-артефакт, упаковывает шаблоны, unit-файлы и примеры конфигов.
Он собирает итоговый пакет, собирает **HY2XS admin**, компилирует **Bun/TypeScript оркестратор** в install-артефакт, упаковывает шаблоны, unit-файлы и примеры конфигов.
2. **Runtime / target layer** — работает **на чистом Debian 13**.
Здесь нет сборщика. Здесь запускается только итоговый install package / orchestrator, который:
- ставит системные зависимости
- разворачивает **наш встроенный UI**
- разворачивает **встроенный HY2XS admin**
- забирает **свежую Hysteria2 из официального upstream**
- создаёт конфиги, systemd unit-файлы и `post-install.env`
- выполняет базовую настройку сервера
## Базовые правила
1. Hysteria2 не форкается и не вендорится в проект.
2. HY2XS admin форкается к себе и поставляется вместе с пакетом.
1. Hysteria2 не вендорится и не собирается как часть HY2XS.
2. HY2XS admin — штатный компонент проекта и поставляется вместе с пакетом.
3. Оркестратор пишется на **Bun + TypeScript**.
4. На target нет `npm` / `pnpm` / `yarn` / `bun install` / transpile step.
5. На target нет standalone логики update / rollback / uninstall.
@@ -43,7 +43,7 @@
1. [01-architecture-baseline.md](01-architecture-baseline.md)
2. [02-build-layer-and-package.md](02-build-layer-and-package.md)
3. [03-server-hysteria2.md](03-server-hysteria2.md)
4. [04-admin-panel-h-ui-fork.md](04-admin-panel-h-ui-fork.md)
4. [04-admin-panel.md](04-admin-panel.md)
5. [05-client-and-access-scope.md](05-client-and-access-scope.md)
6. [06-speed-limits-and-congestion.md](06-speed-limits-and-congestion.md)
7. [07-systemd-and-firewall.md](07-systemd-and-firewall.md)
@@ -72,4 +72,4 @@
Правильная baseline-модель теперь такая:
**Локальный builder собирает install package с нашим форком HY2XS admin и Bun/TypeScript оркестратором; серверный install-only orchestrator ставит этот пакет на чистый Debian 13, тянет свежую Hysteria2 из upstream, разворачивает UI, создаёт systemd + nftables + post-install env и подготавливает рабочее серверное окружение.**
**Локальный builder собирает install package с HY2XS admin и Bun/TypeScript оркестратором; серверный install-only orchestrator ставит этот пакет на чистый Debian 13, тянет свежую Hysteria2 из upstream, разворачивает HY2XS admin, создаёт systemd + nftables + post-install env и подготавливает рабочее серверное окружение.**