mirror of
https://github.com/Vateron-Media/XC_VM.git
synced 2026-10-25 19:03:14 +01:00
Divarion_D
dcd1d8c860
Replace the hand-maintained Docsify site (parallel docs/en + docs/ru trees that had already drifted) with a MkDocs Material build where English is the single source of truth and Russian is generated at build time. Engine & structure - mkdocs.yml: Material theme, site_url for the /XC_VM/ Pages subpath, and a two-tab information architecture — User Guide (administration, API/Swagger, UI translations, diagnostics, info/FAQ) vs Developer Guide (architecture, workflow, security, integrations, build). Files are NOT moved — the split is nav-only, so URLs and cross-links stay stable. - mkdocs-static-i18n (folder mode): English at root, Russian under /ru/, with a language switcher. `mkdocs build --strict` validates every link/anchor. Translation pipeline (tools/docs/translate.py) - Engine-agnostic via DOCS_TRANSLATE_PROVIDER: translators (free, no API key — default), anthropic, deepl, or noop. Per-file sha256 cache so only changed English files are re-translated. Markdown-safe: code, URLs, HTML tags and glossary terms (XC_VM, FFmpeg, HLS, ...) are masked and never translated. A file whose translation fails falls back to English so the build never breaks. - docs/ru is generated and gitignored — never committed. It is produced locally (`make docs-serve` / `docs-build`) and in CI. CI & tooling - pages.yml: build-then-upload (setup-python -> install -> restore .docs-cache with restore-keys -> translate -> mkdocs build --strict -> deploy), replacing the verbatim docs/ upload. - Makefile: docs-venv / docs-translate / docs-build / docs-serve. - docs/requirements.txt; .gitignore for docs/ru, site/, .docs-cache. Migration details - Removed Docsify control files (index.html, _navbar.md, _sidebar.md, .nojekyll) and de-Docsify-ed body links in 6 English files (en-us/ aliases -> relative, swagger _media paths, stripped ':ignore' link syntax). - Preserved the two Russian-only planning docs (no English source) by moving them into docs/adr/ as *.ru.md (repo-internal, excluded from the site).
38 lines
1.3 KiB
Markdown
38 lines
1.3 KiB
Markdown
# Updating a Server
|
|
|
|
Step-by-step guide to updating an XC_VM server. For the internals of the update process, see [Update Mechanism](../administration/update-system.md).
|
|
|
|
> 💾 Before updating, it is recommended to create a [backup](../administration/backup-strategy.md).
|
|
|
|
## Updating via the Panel
|
|
|
|
**Step 1.** Open the **Servers** section in the top menu of the panel.
|
|
|
|
|
|
|
|
**Step 2.** Select **Manage Servers** from the dropdown menu.
|
|
|
|
|
|
|
|
**Step 3.** Locate the target server in the servers table and click the menu button in the **Actions** column.
|
|
|
|
|
|
|
|
**Step 4.** Select **Server Tools** from the menu.
|
|
|
|
|
|
|
|
**Step 5.** In the **Server Tools** dialog, click **Update Server**.
|
|
|
|
|
|
|
|
Clicking the button inserts an `update` signal into the database. Within a minute, CRON picks it up and the update runs automatically: the panel is stopped, updated, and restarted. You can track progress via the server version in the **Manage Servers** table.
|
|
|
|
## Manual Update (CLI)
|
|
|
|
```bash
|
|
sudo -u xc_vm /home/xc_vm/console.php update update
|
|
```
|
|
|
|
Downloads and applies the latest update from GitHub. Usually triggered automatically through the web panel.
|