FFXI — LandSandBoat

Field	Value
Internal ID	ffxi-landsandboat
Upstream	LandSandBoat/server
Preserved mirror	MMO-Preservation/preservation-landsandboat, 34a92a55ff383c37ccd00c2abba7c21c0b3c1b84
Manager module	gsm-mod-landsandboat
Support status	Supported
Client requirement	FFXI client data compatible with the pinned server revision
Database	MariaDB, default database xidb
Runtime	Linux; systemd or tmux-managed world/search/connect/map processes
Default installation	/opt/gsm/servers/landsandboat
Preservation level	P1 source captured; client/server pair unverified
Owner	Ryuu
Last documentation review	2026-07-16
Runtime verification	Not completed — #7

Preserve together

• Full upstream Git mirror, tags/branches, submodules, and a dated bundle.
• Exact server commit used for each baseline.
• Matching client snapshot metadata and the client-derived data required by the server.
• Database schema/migration state, configuration templates, and any post-update SQL.
• Toolchain and package versions used to build the C++ server.
• Service definitions, multi-map port configuration, and operational runbooks.
• Optional pydarkstar auction-house tooling as a separate mirror/artifact.

Manager coverage

The manager currently models dependency installation, source/build/update operations, MariaDB setup, configuration, systemd/tmux service control, multi-map processes, database actions, automatic updates, and optional auction-house tooling.

Defaults visible in the module include:

• Service user: landsandboat
• Database/user: xidb / xi
• Tmux session: landsandboat
• Default map ports: 54230,54231

These are operational defaults, not credentials and not a preserved baseline.

Known constraints and risks

• Client-derived data must match the selected server revision; record the tested relationship explicitly.
• Upstream database migrations and content updates can make rollback difficult. Snapshot before update.
• Automatic update paths need a pinned/recoverable baseline; following an unpinned branch is not preservation.
• Multi-map service definitions and firewall rules must remain synchronized.
• Custom SQL and destructive database actions require separate backups and confirmation.

Baseline verification

1. Restore the pinned source and dependencies from preserved locations.
2. Build on the declared Linux/toolchain baseline.
3. Initialize MariaDB from the recorded schema and migrations.
4. Apply configuration without embedding secrets in artifacts.
5. Start world, search, connect, and map components.
6. Use a disposable account and matching client snapshot to log in and enter a test zone.
7. Stop, restart, and repeat the milestone.
8. Record logs, checksums, server commit, client snapshot ID, and result.

Open preservation work

• Add exact tested server/client pairs to the compatibility matrix.
• Mirror and bundle the upstream repository and optional pydarkstar dependency.
• Pin a first P3 baseline with toolchain/package versions.
• Document client-data extraction and validation without distributing unauthorized client files.
• Test a full restore from offline backups.

Live tracking

• Compatibility investigation: #9
• First P3 baseline: #7
• Cross-project mirror verification: #2