4 Server Aura Kingdom
official-markus-maurer edited this page 2026-07-16 16:12:39 +02:00

Aura Kingdom — Legacy Server Preservation

Field Value
Internal ID aura-kingdom
Reference source nathawut1992/ak_oneclick_installer
Preserved mirror MMO-Preservation/preservation-aura-kingdom, 6d36aabf0c7fb9dca606241188b468c8c41de3f4
Manager module gsm-mod-aura-kingdom
Support status Experimental
Default release profile v7-content-110
Database PostgreSQL; default databases ffaccount, ffdb1, ffmember
Runtime Mixed i386/x86-64 legacy binaries through QEMU user-mode; tmux
Default installation /opt/gsm/servers/aura-kingdom
Default preservation store /opt/gsm/assets/aura-kingdom
Target noted by module Raspberry Pi 5 / Linux; compatibility remains experimental
Preservation level P1/P2 work in progress; V15 service smoke test complete, client-login milestone pending
Owner Ryuu
Last documentation review 2026-07-16
Runtime verification V15 multi-service smoke test completed on Raspberry Pi 5 on 2026-07-16; broader per-release/client testing remains tracked in #12

Preservation approach

The module mirrors installer history and available release files, keeps originals immutable, and prepares an isolated working copy. This separation is essential because the releases contain untrusted proprietary legacy binaries and historical installers may perform unsafe host modifications.

Known release profiles currently represented in the working module:

  • v15-yokohiro-015.001.01.16 — installable profile with a matched server bundle and embedded SQL pack; isolate its databases from V7.
  • v7-content-110
  • v7-v16-hybrid-14class — proposed preservation ID for the audited V7-binary/V16-content hybrid; incomplete and intentionally not installable until its matching client is recovered.
  • yokohiro_007_010_01_02
  • wangweijing1262_007_004_01_02
  • yokohiro_003_005_01_04
  • genz_003_005_01_04
  • eperty123_003_005_01_04
  • hycker_003_005_01_03

Some original Google Drive links are no longer available. Preserve the missing entries in preservation-status.tsv or equivalent metadata rather than deleting them from history.

Current module classification is more precise than a single supported list:

  • Installable: v15-yokohiro-015.001.01.16, v7-content-110, hycker_003_005_01_03.
  • Audit-only preservation candidate: v7-v16-hybrid-14class; verified server archive, missing matching client payload.
  • Partially preserved because the shared SQL archive is unavailable: yokohiro_003_005_01_04, genz_003_005_01_04.
  • Upstream payload links unavailable: eperty123_003_005_01_04, wangweijing1262_007_004_01_02, yokohiro_007_010_01_02.

Verified V15 deployment

Aura Kingdom V15 is supported by the working module and has been deployed successfully on the Raspberry Pi 5.

Field Verified value
Profile v15-yokohiro-015.001.01.16
Databases ffaccount_v15, ffdb1_v15, ffmember_v15
Detected game version 015.001.01.16
Detected database schema 2009251000
User-supplied SQL RAR /opt/gsm/assets/aura-kingdom/v15-yokohiro-015.001.01.16/original/user-supplied/SQL-[RaGEZONE].rar
SQL RAR SHA-256 2a5ec4736f5437dfec89a8ce84878866786b6d5f5125e31589b5e9ec28978814
Matched V15 server ZIP /opt/gsm/assets/aura-kingdom/v15-yokohiro-015.001.01.16/original/hxsy.zip
Server ZIP SHA-256 ff7e039fe3300050d85f1d2c6c3abcdda2f84c076217343a82246ad3953f2b0
Original payload root /opt/gsm/assets/aura-kingdom/v15-yokohiro-015.001.01.16/
Prepared release root /opt/gsm/servers/aura-kingdom/releases/v15-yokohiro-015.001.01.16/

The supplied SQL RAR matches the SQL content bundled with the AKF installer for the Yokohiro V15 release. The preparation workflow keeps the original inputs immutable and handles preservation locking, checksum validation, the required legacy database encodings, release-isolated V15 databases, guarded IPv4/subnet binary patching, ARM/QEMU execution, and ordered World/Zone readiness checks. The implementation lives in gui/crates/gsm-mod-aura-kingdom/src/scripts.rs; the selectable profile and V15 information action are declared in gui/crates/gsm-mod-aura-kingdom/src/manifest.rs.

The Pi smoke test kept Ticket, Gateway, Login, Mission, World, and Zone running on their expected ports, with approximately 5.1 GiB of RAM still available. Aura was stopped after validation and the existing Sapphire session was not modified. Aura has no startup unit, and PostgreSQL remains disabled/manual at boot. In the application, select v15-yokohiro-015.001.01.16 and use the three _v15 database names listed above.

V7/V16 hybrid 14-class preservation candidate

The original release thread describes a V7 server with V16-derived content and 14 classes. Its server archive is worth preserving, but this release is not yet suitable for an Install/Start profile because the matching MEGA client and later client mirrors are unavailable.

Field Audit result
Proposed profile ID v7-v16-hybrid-14class
Current state Incomplete, audit-only; not exposed as runnable
Server archive size 306,707,061 bytes
Server archive SHA-256 1227215126e5abab2f3a3dd9485ecbe97895fbb67b6e3ebf4aebb17c7656579c
Current audit cache /home/ryuu/.cache/gsm-aura-v7v16-audit/hxsy.zip
Reported game version 007.004.01.02
Reported database schema 1401271755
Data inventory 2,733 data files, including 629 scene22 files
Obsolete logs in archive Approximately 2.55 GiB; exclude from any prepared installation

Audit findings:

  • Five service binaries and every SQL dump match the existing V7 base; Gateway matches the V15 payload. The preservation value is the hybrid data pack rather than a new complete binary or database baseline.
  • The included binaries are likely compatible with the existing V7/V15 QEMU runtime because those exact binaries already run there, but the hybrid profile has not received an end-to-end runtime/client test.
  • The archive contains only server-side S_*, translation T_*, and scene data. It does not contain the matching client-side c_* data required by the client. Forum follow-ups explicitly note that matching C/T/scene files are required and report that the available client mirrors are dead.
  • Upstream reports buggy animation for newer eidolons even though skills work, intermittent storyline problems, and invisible newer costume models. Later testing in the thread also reports unresolved gameplay/item behavior.
  • Its 007.004.01.02 databases must remain separate from both Content 110 and V15 databases. Do not merge the hybrid data into either managed profile.

Preservation decision:

  • Keep the proposed ID v7-v16-hybrid-14class as an incomplete preservation candidate.
  • Do not expose Install or Start until the exact matching client, including its c_*, T_*, and scene files, is recovered and verified.
  • Promote the verified server ZIP from the disposable audit cache into managed preservation before relying on it long term.
  • When adapting it, discard the obsolete logs and replace upstream killall -9, chmod 777, /root/hxsy, and hard-coded-IP behavior with the manager's constrained preparation and service lifecycle.

This audit also led to a Content 110 database-version correction in import_database_script: the preserved V7 base dump reports 007.004.01.02, while the Content 110 profile is normalized and verified as 007.010.01.02 with schema 1401271755. The current Aura module test suite covers this behavior.

Safety constraints

  • Never execute a preserved original in place.
  • Run legacy binaries with a dedicated unprivileged account, owner-only umask, constrained network, and isolated filesystem.
  • Do not reproduce installer behavior that rewrites the host clock or recursively changes /root permissions.
  • PostgreSQL MD5 compatibility must remain limited to the Aura role, the three named databases, and loopback.
  • Keep PostgreSQL and Aura services stopped/boot-disabled unless explicitly started.
  • Startup logs may expose legacy database credentials; store and redact logs accordingly.
  • Keep V15 databases release-specific, such as ffaccount_v15, ffdb1_v15, and ffmember_v15; do not reuse V7 databases.
  • Apply the V15 subnet compatibility patch only at verified binary offsets for the configured IPv4 address.

Operator tooling

AK-Tools v1.0 is preserved as an untouched Windows controller utility, not installed or executed on the Pi. The manager verifies the release and source archives separately and can launch the tool through a temporary, host-key-pinned SSH tunnel. PostgreSQL remains loopback-only.

The module also provides independent native actions for account creation, password resets, GM privilege, account/character browsing, live GMCmd.ini search, drop-rate preview/apply/rollback, and conditional Fortune Bag export. These actions use the selected instance's database names instead of AK-Tools' hard-coded V7 names.

Important limitations:

  • Upstream tested AK-Tools v1.0 only on V15.
  • Its DB Admin tab hard-codes FFMember, FFAccount, and FFDB1; the managed launcher refuses release-isolated names such as the recommended V15 databases.
  • The V7 fortune_bag table uses compatible fields in a different physical order; the manager exports a normalized copy for AK-Tools. The observed V15 table adds custom_id, so the exporter refuses it rather than letting v1.0 misclassify the schema.
  • Treat the selected release's live ZoneServer/GMCmd.ini as authoritative, not the tool's bundled catalog.
  • The v1.0 source tag has no license file; preserve it for evidence but do not incorporate its source into the manager.

Preserve together

  • Every release source URL, filename, size, checksum, availability state, and acquisition timestamp.
  • Original archives/installers plus extracted/normalized and prepared/derived trees.
  • QEMU version/architecture behavior and required loader/runtime libraries.
  • PostgreSQL version, original dumps, compatible import procedure, and configuration transformations.
  • Exact server/client relationship, endpoint configuration, and observed protocol behavior.
  • Negative results: missing files, dead URLs, architecture failures, date assumptions, and startup errors.

Baseline verification

  1. Verify checksums and release-profile inventory.
  2. Generate a prepared copy without mutating the original.
  3. Provision loopback-only PostgreSQL and import all three databases.
  4. Apply credentials/endpoints from secret-safe templates.
  5. Start processes under QEMU in the isolated environment.
  6. Capture process/port state and attempt the defined client handshake/login milestone.
  7. Stop cleanly, restore from preserved inputs, and repeat.

Open preservation work

  • Resolve or formally mark every dead release link and missing file.
  • Produce a per-release manifest and compatibility matrix.
  • Declare the first verified client/server smoke-test milestone.
  • Measure QEMU compatibility and performance on the target host.
  • Audit legacy binaries and network exposure in an isolated lab.
  • Complete an offline restore test.

Live tracking

  • Release recovery and inventory: #5
  • Per-release QEMU compatibility: #12
  • Mirror and bundle verification: #2