mirror of https://github.com/Vateron-Media/XC_VM.git synced 2026-10-12 12:02:51 +02:00

Files

T

Divarion-D 76844fef11 docs: restructure, fix PSR-4 drift, and unify en/ru

Overhaul the Docsify documentation (English + Russian) so it matches the current
codebase and follows one consistent pattern.

Content accuracy (post-migration):
- Rewrite development/autoloader.md to PSR-4 / Composer (the old XC_Autoloader
  scanner, igbinary tmp/cache/autoload_map and registerDirectories are gone).
- PascalCase every source path (src/core -> src/Core, domain/Stream, cli/Commands,
  public/Controllers, Infrastructure/Redis, ...) across all docs.
- Replace the removed autoload.php references with vendor/autoload.php
  (build_system, bootstrap-contexts, error-handling, modules).
- ssl-generation: note that the installer now auto-generates a unique self-signed
  certificate before Nginx starts.

Common pattern (Clean & uniform):
- Strip emoji from headings; remove the in-page Navigation blocks (the Docsify
  sidebar already provides navigation).
- One H1 + intro per doc; uniform "Related files" / "Связанные файлы" section,
  added to the code-centric docs that lacked it.

Structure:
- Remove the empty stray docs/api/; move updates_checklist.md into builds/;
  link the previously-orphaned ucs-integration.md.
- Regroup the sidebars (split the oversized guides group into Developer Guides /
  Security & Access / Integrations; fold builds into Build & Release).

Augment:
- dev-workflow: Local Setup (make dev-tools) + Quality Checks (phpstan, cs, gates).
- build_system: Composer Dependencies section (committed prod-only vendor,
  committed lock, dev tools via composer install, no build-time vendor step).

en/ru parity:
- Apply the same structure, fixes and pattern to docs/ru/ (translated), including
  a new Russian ucs-integration.md. The en and ru file sets are now identical.

2026-06-26 15:56:15 +03:00

6.7 KiB

Raw Blame History

Механизм обновлений в XC_VM

Система обновлений XC_VM реализована как многоуровневый процесс: от веб-интерфейса до системных скриптов. Такой подход обеспечивает надёжность, автоматизацию и целостность данных при обновлении панели.

1. Инициация обновления

Процесс начинается с нажатия кнопки "Обновить" в веб-интерфейсе панели.

Создаётся сигнал update, который записывается в таблицу signals базы данных.
Этот сигнал выступает триггером, запускающим дальнейший процесс обновления.

2. Запуск через CRON

Каждую минуту выполняется системное задание CRON:

/home/xc_vm/console.php cron:root_signals

Крон-задача root_signals проверяет наличие новых сигналов и при обнаружении update запускает:

/home/xc_vm/console.php update update

⚙️ Этот механизм позволяет выполнять обновления автоматически, без ручного вмешательства администратора.

3. Управление обновлением (PHP-уровень)

Основная логика находится в классе UpdateCommand:

src/Cli/Commands/UpdateCommand.php

На этом этапе выполняются следующие действия:

Определение текущей версии панели (MAIN или LB).
Получение данных о новой версии с GitHub:
- Ссылка на архив обновления.
- Контрольная сумма (хеш) для проверки целостности.
Скачивание архива во временную директорию.
Проверка соответствия хеш-суммы.
Запуск системного обновления с помощью Python:

sudo /usr/bin/python3 /home/xc_vm/update "/home/xc_vm/tmp/.update.tar.gz" "HASH" > /dev/null 2>&1 &

💡 После завершения Python-обновления вызывается console.php update post-update, который запускает миграции базы данных и post-update очистку.

4. Системное обновление (Python-уровень)

После вызова передача управления переходит к скрипту:

/home/xc_vm/update

Он выполняет операции на уровне системы:

Повторная проверка контрольной суммы архива.
Остановка панели, чтобы избежать конфликтов при обновлении.
Распаковка архива во временную директорию:
```
/tmp/xc_vm_update_*/
```
Удаление исключаемых каталогов из временной копии — бинарники, конфиги и пользовательские данные, которые не должны перезаписываться:

bin/ffmpeg_bin, bin/nginx, bin/nginx_rtmp, bin/php, bin/redis, bin/install, bin/maxmind, bin/certbot, content, backups, tmp, config, signals
Копирование оставшихся файлов поверх рабочей установки:
```
cp -a /tmp/xc_vm_update_*/. /home/xc_vm/
```
Настройка прав доступа:
```
chown -R xc_vm:xc_vm /home/xc_vm/
```

Запуск пост-обновления:

/home/xc_vm/console.php update post-update

Перезапуск панели в рабочем режиме.
Очистка временной директории и удаление архива.

ℹ️ Один и тот же архив используется для установки и обновления. Фильтрация происходит на сервере во время обновления — список исключаемых каталогов задан непосредственно в src/update.

5. Завершение обновления

Финальные действия выполняются в фазе post-update команды UpdateCommand:

Проверка, включено ли автообновление LB:
- Если обновлялся MAIN, создаются сигналы обновления для всех Load Balancer’ов.
Обновление версии панели в базе данных.
Удаление устаревших файлов.
Повторное выравнивание прав:
```
chown -R xc_vm:xc_vm /home/xc_vm/
```
Перезагрузка системных демонов:
```
sudo systemctl daemon-reload
```
Проверка статуса панели:
```
sudo /home/xc_vm/console.php status
```
Завершение процесса обновления.

6. Итоговая схема работы

[ Веб-интерфейс ]
        │
        ▼
[ БД: сигнал update ]
        │
        ▼
[ CRON → console.php cron:root_signals ]
        │
        ▼
[ UpdateCommand (PHP): скачивание + проверка хеша ]
        │
        ▼
[ update (Python): распаковка в /tmp → удаление исключённых → копирование ]
        │
        ▼
[ post-update → UpdateCommand ]
        │
        ▼
[ Завершение, рестарт демонов, обновление версии ]

Ключевые особенности

🔒 Двойная проверка целостности (на уровне PHP и Python).
🧠 Автоматическое распространение обновлений между MAIN и LB.
🧹 Очистка устаревших файлов и выравнивание прав доступа.
🔄 Безопасный перезапуск панели после установки.
⚙️ Гибкость и автономность за счёт CRON и сигналов.

6.7 KiB Raw Blame History Unescape Escape