63 lines
3.7 KiB
Markdown
63 lines
3.7 KiB
Markdown
# Administration and manager interfaces
|
|
|
|
## Shared design principles
|
|
|
|
- Responsive, keyboard-accessible and understandable without Docker vocabulary.
|
|
- Capability- and permission-aware: absent functions are hidden or explain why unavailable.
|
|
- Always distinguish container state from game readiness.
|
|
- Show previews and consequences before deployment, update, restore and deletion.
|
|
- Never display stored secret values.
|
|
|
|
## Main dashboard
|
|
|
|
The default table/cards show name, game, state/readiness, players, CPU, RAM, last backup and permitted quick actions. No dense historical charts are required. Users see only assigned instances; administrators see all.
|
|
|
|
## Instance page
|
|
|
|
Tabs or clear sections:
|
|
|
|
- Overview: artwork, welcome text, readiness, connection address and recent actionable error.
|
|
- Players: list/count and allowed announce/kick/ban controls.
|
|
- Configuration: safe visible values, pending restart changes and configuration history.
|
|
- Resources and storage: limits, current usage, ports, mount categories and disk status.
|
|
- Mods: only when supported.
|
|
- Backups: list, create/export and authorized restore/import flows.
|
|
- Updates: current/candidate image, module/template compatibility and operation history.
|
|
- Access: admin-only memberships and overrides.
|
|
|
|
## Catalog and requests
|
|
|
|
Users browse game cards and submit an installation request with optional name, player estimate, schedule and mods. Administrators approve or refuse with a reason. Approval opens the instance creation wizard; it does not deploy immediately.
|
|
|
|
Catalog administration supports validated import, local copy/customization, source/trust display, version comparison and activation. Schema errors point to fields and line/path locations.
|
|
|
|
## Creation wizard
|
|
|
|
1. Template and version.
|
|
2. New world or import existing save.
|
|
3. Game settings and write-only secrets.
|
|
4. Public ports and connection preview.
|
|
5. CPU, memory and storage locations.
|
|
6. Mods and optional integration module.
|
|
7. Backup schedule/retention and safety policies.
|
|
8. Final canonical preview and validation.
|
|
|
|
Import validation precedes container creation. Warnings distinguish guaranteed facts from compatibility guesses.
|
|
|
|
## Backup and restore UI
|
|
|
|
Backup list shows origin, created/imported dates, size, validation, game/template version and checksum status. Cron has common presets, custom expression, timezone and next-run preview.
|
|
|
|
Restore shows overwritten data, safety-backup behavior and server downtime. It requires recent authentication and typed confirmation where data is replaced. Results distinguish rolled back, safely stopped and intervention required.
|
|
|
|
## Administration
|
|
|
|
Global screens cover users, public address, approved storage roots (displayed, bootstrap-controlled where appropriate), catalog/modules, notification channels, audit retention/default 30 days, upload limits, disk thresholds and safety defaults.
|
|
|
|
The game-container label editor is a multiline `key=value` field with one label per line, the complete allowed-variable list, and explicit `apply immediately` versus `apply on next start` choices. Immediate application confirms that affected containers stop and are recreated, connected players disconnect, persistent data remains, and displays affected/running counts when known.
|
|
|
|
Instance creation includes Docker-user mode, conditional custom UID/GID, tracked/pinned image tag and optional labels. Existing-instance advanced configuration displays the Docker user read-only with the backup/new-instance/restore migration explanation, permits label and tag changes with the same application choices, and visibly reports `container_config_pending`.
|
|
|
|
The audit viewer is compact and filterable by time, actor, instance, action and outcome. It is not a raw log console.
|
|
|