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).
1.3 KiB
Updating a Server
Step-by-step guide to updating an XC_VM server. For the internals of the update process, see Update Mechanism.
💾 Before updating, it is recommended to create a backup.
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)
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.