docs(reference): import Dune: Awakening server-manager references
All checks were successful
CI / backend-types (push) Successful in 10s
CI / frontend-build (push) Successful in 15s
CI / agent-tests (push) Successful in 39s
CI / integration (push) Successful in 22s

Phase 2 references for the host-agent Dune adapter, moved out of volatile /tmp
into docs/reference-repos/ (per Commander). Three upstream projects, .git +
node_modules + compiled binaries stripped (16MB source). Nested AI-instruction
files (.claude/, CLAUDE.md) removed so they don't pollute Corrosion sessions.

- icehunter/    dune-admin (Go+React) — 4 control planes; SETUP_DOCKER.md is the
                closest analog to our agent's Dune docker control plane (compose
                lifecycle, docker logs, RabbitMQ-via-exec, dune Postgres schema)
- adainrivers/  Rust/Tauri desktop — SSH+k8s BattleGroup control, maintenance
                daemon, in-game admin console (Rust idiom reference)
- the4rchangel/ Node web UI replacing battlegroup.bat — matches the Commander's
                Hyper-V self-host path + game-config schema

See docs/reference-repos/README.md for the full index + how we use each.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Vantz Stockwell
2026-06-11 21:08:05 -04:00
parent 0715492ddf
commit 651a35d4be
1334 changed files with 238971 additions and 0 deletions

View File

@@ -0,0 +1,24 @@
Experimental welcome-package release.
## Reinstall step
After updating the desktop app, click **Install / Update** on the Management Service card so the refreshed on-host service binary is pushed.
## Added
- **Welcome package worker** in the guest management service. It detects players from the game Postgres database, records per-player/package grant state in the service SQLite database, and grants configured items through the existing MQ server-command path when the player is online.
- **Welcome package configuration** in Schedule settings: enable/disable, package version, poll interval, and a JSON item list shaped like:
```json
[
{ "itemName": "PlantFiber", "quantity": 10, "durability": 1.0 }
]
```
- **Manual welcome-package scan** button in Automated Tasks so the first test pass does not have to wait for the interval.
- **Recent welcome grants** summary in the Schedule settings card, backed by the daemon ledger.
## Notes
- Changing the package version grants the package again to already-seen players.
- This experiment only grants inventory items. Progression unlocks should stay out of direct DB writes until the game-owned tables and side effects are fully mapped.

View File

@@ -0,0 +1,8 @@
# 0.3.11
Experimental welcome-package iteration.
- Added configurable welcome whisper source and message fields on the Welcome Package tab.
- Added a manual welcome-whisper send path that works even when automated welcome packages are disabled.
- Added a welcome-message chain action that uses the configured whisper source/message after earlier actions confirm.
- Added `chat.whispers` RabbitMQ publish support using the live-tested player-sourced whisper shape.

View File

@@ -0,0 +1,41 @@
# 0.3.12
First release of the Welcome Package automation: a per-player onboarding flow that runs on the on-host management service, detects new players from the game Postgres database, inserts configured backpack items directly into the game database, and can send a separate welcome whisper through the existing MQ chat path. Includes a Visual + JSON editor in the desktop app, a SQLite-backed package ledger, and several follow-up fixes from internal review.
This is the first tagged release since v0.3.9. All 0.3.10 / 0.3.11 / 0.3.12 work ships together.
## Reinstall step
After updating the desktop app, open each server's Management Service card and click **Install / Update** so the refreshed on-host `dune-server-service` binary is pushed. The Welcome Package tab will not function until the host service is at v0.3.12.
## Added
- **Welcome Package tab** in the management view, with separate toggles for the welcome message (whisper) and the item package.
- **Package contents editor** for item rows. Each row inserts the configured `itemName` (Unreal FName / row name) and `quantity` into the player's backpack; durability defaults to `1.0`.
- **Optional raw JSON mode** on the package contents editor. Toggle the checkbox to swap the visual editor for a textarea you can paste / hand-edit, so a long package can be saved and restored without re-clicking every row. Switching back to the visual editor parses and validates first; an invalid textarea keeps you in JSON mode with an inline error so a typo cannot silently drop items.
- **Welcome whisper** support: configurable source player, message body, and a separate "Send test whisper" button that works even when the automated welcome message is disabled. Whispers publish on `chat.whispers` using the live-tested player-sourced shape.
- **Single transaction item grants**: all configured item rows are inserted into the player's backpack in one Postgres transaction. The package ledger is marked granted only after that transaction commits.
- **Full water-container grants**: known fillable containers such as `Literjon` and `Decajon` include embedded fillable stats for a full water container.
- **Recent welcome grants** table in the Welcome Package tab, backed by the daemon ledger. Failed rows show the error and a **Retry** button that clears the failed record so the next scan re-attempts the grant; granted rows are never cleared, so a retry can't duplicate a package.
- **Manual welcome scan** button in the Automated Tasks tab so a test pass does not have to wait for the next poll interval.
- **`scripts/rebuild-release.cmd`** helper for local release rebuilds: workspace tests, frontend build, musl service cross-compile, bundled binary copy, and Tauri NSIS in one shot.
## Fixed
- `welcome_package_items_json` (legacy alias) no longer clobbers `welcome_package_actions_json` when both are sent in the same `PATCH /api/config` request. The legacy field is only applied when the canonical field is absent.
- `welcome_package_version` mismatches now return `400 "currently fixed to v1 and cannot be changed"` instead of accepting the value and silently dropping it. Echoing the same `v1` value remains a no-op so the existing UI save flow still works.
- Removed the old MQ item-grant path, planned item ids, water-refill actions, and empty-backpack wait. Item packages now wait only for the player's backpack inventory row to exist.
- Dropped the inline 30-second `wait_for_item_quantity` poll inside `process_grant_item`. The direct DB transaction is the confirmation point, and missing backpacks do not create ledger rows until a later scan finds the backpack.
- Welcome automation no longer waits for the game DB `online_status` flag before running. Item grants are DB-backed, and welcome whispers are attempted from the configured chat identity without an online-grace gate.
## Changed
- Renamed the welcome automation toggles to "new players" in the UI so the wording matches the worker's actual scope.
- Split welcome message automation from welcome package grants so each can be enabled independently. Sending a manual test welcome whisper no longer overwrites unsaved tab state.
- The welcome whisper now runs on its own worker at a 60-second cadence instead of riding the 2-second package scan. A cheap local check skips accounts whose whisper is already confirmed before any Postgres chat lookup, so the fast item-grant loop no longer pays for a per-account chat query every tick.
## Notes
- Welcome Package timing on a fresh player: the service scans every 2 seconds while welcome automation is enabled. Once the service sees the account and its backpack inventory row exists, item insertion can happen on that scan.
- The package ledger is keyed by `(player_id, package_version, account_id)`. Recreating a character under the same FLS id creates a new `account_id`, so the welcome package can be granted again to the new character. Editing the item list while keeping the same `welcome_package_version` will not re-grant rows already marked granted for that account. The `welcome_package_version` field is currently pinned to `v1` server-side; "re-grant everyone" via a version bump is not yet wired up.
- This experiment only grants backpack items. Progression unlocks should stay out of direct DB writes until the game-owned tables and side effects are fully mapped.

View File

@@ -0,0 +1,25 @@
# 0.3.13
This release reworks the Welcome Package so new-player gifts arrive reliably. Items are now placed straight into the new player's backpack the moment their character is ready, water containers show up full, and a failed delivery can be retried with one click. The welcome whisper now runs on its own schedule.
## Reinstall step
After updating the desktop app, open each server's Management Service card and click **Install / Update** so the refreshed host service is pushed. Welcome packages keep using the old behavior until the host service is updated.
## Changed
- **More reliable delivery.** Welcome package items are now placed directly into the new player's backpack instead of being sent through an in-game command. Delivery no longer depends on timing during the player's login and loading, so gifts arrive consistently.
- **Delivers as soon as the character is ready.** The package no longer waits for an "online" status or for the backpack to be empty first. As soon as the new character's backpack is in place, the gift is handed out.
- **Simpler package editor.** The Welcome Package tab is now a straightforward list of items and quantities: add an item, set how many, done. The older step-by-step editor with separate water-refill steps and manual up/down ordering has been removed. Raw JSON editing is still available if you prefer to paste a list in.
- **Full water containers.** Known water containers such as Literjon and Decajon are handed out full instead of empty.
- **Welcome whisper on its own schedule.** The welcome message now runs as a separate, lighter background job (about once a minute) instead of riding along with the package check. The two can still be enabled independently.
## Added
- **Retry a failed delivery.** The Recent grants list now shows the reason a package failed and a **Retry** button that clears the failed record so the next check tries again. A package that was delivered successfully is never retried, so a retry can't hand a player duplicate items.
## Notes
- **After updating:** players who were seen by the previous version but never actually received their package are picked up and granted on the next check. Players who already received their package keep it and are not granted again.
- A small number of players who already received a welcome whisper under the previous version may get it one more time after the update. Item gifts are not affected.
- The Welcome Package still hands out backpack items only. Progression unlocks remain out of scope for now.

View File

@@ -0,0 +1,32 @@
# 0.3.14
This release puts you in control of the automated maintenance tasks, makes the Users list update by itself, and fixes the times shown around the app so they match your local clock. It also tidies up the Automated tasks screen and adds an About dialog.
## Reinstall step
After updating the desktop app, open each server's Management Service card and click **Install / Update** so the refreshed host service is pushed. The new enable switches, the cleaner Recent runs history, and the auto-restart fixes all live in the host service and only take effect once it is updated.
## Added
- **Turn automated tasks on or off.** Auto restart, auto update, and auto backup now each have their own enable switch on the Automated tasks card. Everything stays on by default, so existing servers keep behaving exactly as before, but you can now pause the nightly restart for a marathon weekend without losing your schedule. (#10)
- **Live Users list.** The Users tab now refreshes on its own every few seconds, so logins and logouts appear without reopening the app. There is an **Auto-refresh** toggle if you want to turn the polling off. (#13, #14)
- **About dialog.** A small info button next to "Check for updates" opens an About box showing the installed version and links to the project page and the issue tracker. (#11)
- **See what changed before updating.** The update prompt now shows the release notes for the new version, so you know what you are getting before you install.
## Fixed
- **Times now show in your local timezone.** Automated task run times, log timestamps, welcome-grant times, and the Users tab's last-seen column were displayed in UTC; they now follow your computer's local time. (#15)
- **Recent runs no longer fills up with empty checks.** The welcome-package and welcome-message background checks recorded a run on every pass even when there was nothing to do, burying the runs that mattered. They now only record a run when something actually happened. A failure is still recorded so problems stay visible.
- **Manual checks no longer "vanish."** Clicking a manual task (such as Check for update) when there was nothing to do made the run flash up and disappear, which looked broken. Manual runs now leave a visible "had nothing to do" entry. (#9)
- **Daily restart time displays properly.** The restart time editor showed values like "5 : 0"; it now reads "05 : 00".
- **Steadier Users toolbar.** The controls along the top of the Users tab no longer shift around when the list count changes during a refresh.
## Changed
- **Last seen is hidden for online players.** Players currently online no longer show a last-seen time, since the online badge already says they are connected.
- **Backups need a schedule when enabled.** Now that auto backup has its own switch, the backup schedule field requires a cron expression while the switch is on (the old "leave empty to disable" no longer applies). A link to crontab.guru was added next to the field to help build the expression.
## Notes
- All three maintenance switches default to enabled, and servers upgrading from an earlier version are treated as enabled, so nothing turns off on update.
- Auto backup still requires a backup schedule to be set; the switch only pauses or resumes that schedule.

View File

@@ -0,0 +1,19 @@
# 0.3.15
This release fixes automatic game updates, which could silently fail to apply when a new Dune build was released, and corrects the item data written by welcome packages so granted weapons and gear are well-formed.
## Reinstall step
Both fixes live in the host service. After updating the desktop app, open each server's Management Service card and click **Install / Update** so the refreshed host service is pushed. The fixes only take effect once the host service is updated.
## Fixed
- **Automatic game updates now actually apply.** When a new Dune build was released, auto-update could report success on every check while never updating the server. The version stayed on the old build until you ran the update by hand. The cause was an "already applied" safety check that compared the wrong versions and short-circuited before the download and restart could run, so the update silently did nothing and kept retrying every 15 minutes. It now only skips when the new build is genuinely already live, and otherwise runs the full backup, update, and restart as intended.
## Changed
- **Welcome-package items are written with corrected stats.** Items granted by a welcome package are now created with the item data the game expects. Weapons and equipment no longer carry a stray full-durability field and now include the customization data slot, so they come through clean. Water containers are unchanged and still arrive filled to capacity. Items granted at less than full durability still keep the durability you set.
## Notes
- No configuration changes are required. Existing welcome packages, schedules, and enable switches keep their current settings.

View File

@@ -0,0 +1,17 @@
# 0.3.16
This release fixes two BattleGroup control problems: scheduled restarts that wrongly reported a failure even though the server came back online fine, and the Stop / Start / Restart buttons misbehaving after a Funcom server update.
## Reinstall step
The scheduled-restart fix lives in the host service. After updating the desktop app, open each server's **Management Service** card and click **Install / Update** so the refreshed host service is pushed. The Stop / Start / Restart button fix takes effect as soon as the desktop app itself is updated.
## Fixed
- **Scheduled restarts no longer report a false failure (#20).** A nightly restart could log a "restart failed: timeout after 1200s" error roughly 20 minutes later even though the BattleGroup and all map servers were actually back online within a few minutes. The readiness check insisted on a fully settled state and refused to accept a BattleGroup that was up but still showing as `Reconciling` (a state in which the servers are already reachable), so it waited out the full timeout and reported a failure that never happened. It now recognises a reachable, started BattleGroup the same way the dashboard does, so a successful restart is reported as success.
- **Stop / Start / Restart BattleGroup work again (#19).** After a Funcom server update, the **Stop BattleGroup** button could fail with a "battlegroup status can not be pulled" error while the server kept running, even though stopping over SSH worked fine; Start and Restart could also stall until their timeout. The cause was that these actions read the vendor `battlegroup status` text output, whose column layout shifts between Funcom releases and was being misread. They now read BattleGroup state directly from the stable Kubernetes data the dashboard already uses, so they no longer break when the vendor output format changes.
## Notes
- No configuration changes are required. Existing schedules, welcome packages, and enable switches keep their current settings.

View File

@@ -0,0 +1,27 @@
A fix-focused release. Knocks down a cluster of install-time crashes, makes the backup schedule configurable, surfaces the full ServerShutdown broadcast in the admin UI, and adds a guarded cleanup for accumulated database-operation pods.
## Reinstall step
After updating the desktop app, click **Install / Update** on the Management Service card so the refreshed on-host service binary is pushed. If you previously workaround-started the service with `sudo ./dune-server-service &`, kill that process first so the new systemd / OpenRC unit owns the only running copy.
## Fixed
- **Management service silently failed to start on install** (issues #5, #6). The install flow now pre-creates every directory the systemd / OpenRC unit references (`~/.dune`, `~/.dune/state`, `~/.local`, `~/.steam`, `~/Steam`) with `dune:dune` ownership, plus the supervisor log file. Previously the unit started, immediately tripped on mount-namespace setup, and exited with `status=226/NAMESPACE` only visible in `journalctl`.
- **Service now always runs as the `dune` user**, regardless of which account you SSH in as (issue #3). The installer no longer rewrites the systemd unit with the SSH user's home; it pins `User=dune Group=dune` and paths under `/home/dune`. Operators logging in as `root` or `ubuntu` no longer get a unit pointing at `/root/.steam` that fails to mount.
- **Battlegroup start / stop / restart / update use the registered SSH user for vendor-wrapper impersonation** instead of hardcoding `dune`. Fixes a half-broken state from v0.3.6 where status reads worked but lifecycle actions silently misbehaved.
- **Manual ServerShutdown broadcast no longer no-ops.** Previously sent an empty payload that the game discarded; now sends the full countdown shape with `ShutdownType`, `ShutdownTimestamp`, `BroadcastFrequency`, and `BroadcastDuration`.
- **OpenRC unit self-heals on every start.** `start_pre` now also creates the parent `.dune` directory and the supervisor log file via `checkpath`.
- **Install verify step shows why the service is not active** by tailing `journalctl` (systemd) or the supervisor log (OpenRC). No more empty-parenthesis "not active ()" message.
## Added
- **Configurable backup schedule via 5-field cron expression**, with live validation and a preview of the next 5 fire times in your configured timezone. Default is disabled — vendor backups block server I/O for the full dump, so the manager no longer schedules them automatically. Set your own cadence under Management -> Automated Tasks -> Configure.
- **Full ServerShutdown broadcast surface in Admin -> Broadcast**: ShutdownType selector (Restart / Maintenance / Update), lead time, repeat frequency, display duration, and a "Cancel pending shutdown" toggle that short-circuits the payload (per the protocol parser). The scheduled `restart-notice` task ships the same shape so manual and automatic flows are now consistent.
- **"Clean up database operations" button** on Management -> Automated Tasks. Lists every terminal `DatabaseOperation` CR (Succeeded or Failed, dump or import) with phase badges, lets you tick which to delete, then deletes them via `kubectl delete databaseoperation`. The `.backup` files on disk are never touched, in-progress operations are never listed, and the server re-validates every item server-side before deleting.
- **Static musl service binary** ships in every release, so the daemon runs on Alpine images without a glibc loader.
## Changed
- The `publish_server_shutdown` helper that backs the scheduled restart-notice broadcast now emits `BroadcastDuration` so its payload matches the manual Admin form and the protocol spec.
- The on-install account discovery no longer follows the SSH login user — it resolves the canonical `dune` user via `getent passwd dune` and errors loudly if the vendor setup has not provisioned that account yet.
- Bundled systemd unit marks `/funcom/artifacts/database-dumps` as optional (`-` prefix on `ReadWritePaths`), so a fresh host without k3s + vendor setup no longer namespace-faults on first start.

View File

@@ -0,0 +1,14 @@
Two reported issues against v0.3.7 — both fixed.
## Reinstall step
After updating the desktop app, click **Install / Update** on the Management Service card so the refreshed on-host service binary is pushed.
## Fixed
- **`Install management service` failed with `install: No such file or directory` when SSH'ing in as `root`** on Ubuntu 24.04+. Root cause: the install-init and write-token steps piped base64-decoded content into `sudo install /dev/stdin <dest>`, and sudoers' `Defaults use_pty` (default on noble) allocates a pty for the child process which severs the upstream pipe. The same flow worked when SSH'ing as `dune` because that account's sudoers entry bypasses `use_pty`. Both steps now stage their payload to a real temp file via `mktemp` first, then `sudo install <tmp> <dest>`, sidestepping the pty entirely.
- **Director tunnel button grayed out even on a fully running BattleGroup**. We were parsing the vendor wrapper's `battlegroup status` text table for phase information, but newer Funcom operator builds changed the row vocabulary (the "Status" column now shows the partial world name, "Director" shows an `N/M` ready ratio, "Uptime" shows a `Healthy` / `Unhealthy` word instead of a duration). None of those values matched our phase allowlist, so the UI thought the BattleGroup was not started. We now read phase / serverGroupPhase / directorPhase / databasePhase / uptime / per-server stats directly from the BattleGroup CR's `status` object via `kubectl get battlegroup ... -o json`, which is the stable Kubernetes schema and immune to future wrapper text format changes.
## Changed
- Server status reads no longer go through the vendor wrapper. Start, stop, restart, and update lifecycle actions still use the wrapper (where it's the source of truth for orchestration).

View File

@@ -0,0 +1,20 @@
v0.3.8's switch to reading server status straight from the Kubernetes CR turned out to be matched against the wrong field names — the Status card came back populated with placeholders instead of real data. This release re-maps every cell to the live CR shape and pulls per-partition player counts from the same source the gaming.tools cron uses.
## Reinstall step
After updating the desktop app, click **Install / Update** on the Management Service card so the refreshed on-host service binary is pushed.
## Fixed
- **Status card showed every Game Server row as the literal text "Game Server"**. v0.3.8 was reading `status.servers[].map` / `.name`; the live Funcom operator publishes that as `partitionMap`. We now read `partitionMap` (with `map` / `name` kept as fallbacks for older operator builds) and append the `partitionIndex` so multi-partition maps like Hagga Basin are distinguishable as `Hagga Basin #1`, `Hagga Basin #31`, etc.
- **Player count column was blank for every row**. The BG CR's `status.servers[]` does not carry a player count; the Funcom operator emits a separate `ServerStats` CRD per partition with `status.runtime.players`. We now make a second `kubectl get serverstats -n <ns> -o json` call alongside the BG read and merge by partition index — the same data source `F:\Dune\Server\gt-server-status\gt_server_status.py` consumes. If your operator doesn't have the `ServerStats` CRD installed, the column degrades gracefully back to blank.
- **Age column was blank for every row**. v0.3.7's wrapper-text path had read this from a column that no longer exists in newer wrappers. We now derive age from `status.startTimestamp` and format it compactly as `5d 7h`, `3h 15m`, `45m`, or `30s`. Per-partition restart age would be more accurate but requires another kubectl call; the BG-level value matches the common case where all partitions started together.
- **Status header showed "—" for Database, Director, and Uptime**. Those values are nested in the live CR (`status.database.phase`, `status.utilities.director.phase`, `status.startTimestamp`) but v0.3.8 was looking for flat top-level keys (`databasePhase`, `directorPhase`, `uptime`). The header now reads the nested shapes with fallbacks to the older flat keys for older operator builds.
## Added
- **Admin tab: raw `CheatScript` and `ServerExec` commands** (under the "Server scripts" category). Both ship with explicit "live-tested no-op against seabass servers" warnings in their describe text — the seabass MQ handlers register both names and accept the publish, but the underlying functions never apply state. They're kept for protocol parity and so they're ready if Funcom wires up the missing dispatcher path on a later build.
## Changed
- No behavior change for the actual lifecycle actions (start / stop / restart / update / install): those still go through the vendor wrapper. Only the status read switched to direct kubectl JSON; this release just fixes the field mappings.