The audit trail

"Nobody reads the trail until the day everybody reads the trail." — Archivist Yenna Tal
Verified

Every staff change to an account appends one line to logs/admintrail.log.

This is the main way to notice a compromised staff account. Nothing else on the server records who changed what.

What it does

Account changes are quiet by design. A promotion prints one line to the admin who ran it and nobody else. Without a record, a stolen leadership login could hand itself extra staff accounts and leave no trace anyone would see.

The trail closes that gap. It is append-only, plain text, and written the moment the change lands.

Where the file is

The trail sits alongside the database and the ban list, in your server's writable folder:

<fs_homepath>/StoryForce/logs/admintrail.log

Under Docker that resolves to /opt/openjk/homepath/StoryForce/logs/admintrail.log, inside the volume you mapped, so it survives an image update. The logs folder is created for you on the first entry.

Every entry is also mirrored into the ordinary server log, games.log, prefixed with comadmin:. That copy is useful for cross-referencing a change against what was happening in the world at the time.

Reading a line

Fields are separated by a vertical bar and always appear in this order:

epoch | date | actor account id | actor | action | target | detail

A promotion by Dara Sunn looks like this:

1785345851 | 2026-07-28 19:04:11 | 3 | dara | admin promote | rhen | clerical

The first 2 fields are the same moment written twice, once as a Unix timestamp for sorting and once in a readable form. The actor is the account username of whoever ran the command, with its database row id. The target is the account or character the change landed on. The detail is the resulting value.

A change made from the server console or over rcon has no account behind it, so it is recorded as actor console with id 0:

1785346002 | 2026-07-28 19:06:42 | 0 | console | rootreset | storyforce | console

What gets recorded

Action Written when
create An account is created, with its starting membership
member Membership changes by any route, with the new state
admin promote, admin demote Admin rank changes, with the new rank
set password A password is overwritten. The detail is always -
set adminrank Admin rank is written directly, with the new rank
designate status, designate faction, designate rank A character designation changes
listedname, loadout A character's listed name or spawn loadout changes
login-root The leadership seed account logs in, with the address it came from
rootreset The console recovery command runs

Passwords are never written to the file, in any action. The only trace a password change leaves is that it happened, to whom, and by whom.

Spotting a compromised account

3 patterns are worth checking for, and all 3 are one search away in a text editor:

  • a login-root entry from an address you do not recognise
  • a run of create and admin promote entries close together, especially outside your usual hours
  • a set password against an account whose owner did not ask for one

Search the file for login-root first. The seed account holds leadership permanently and cannot be demoted or disabled. That makes it the most valuable login on the server, and the one worth watching.

If you find something, change the affected passwords with /comadmin set <username> password <newvalue>, then demote the accounts that should not be staff. The trail records those changes too, which is what you want.

Things to note

  • Kicks and bans are not in this file. They go to games.log, and the permanent ban record is bannedips.cfg. See kick and ban.
  • Nothing rotates or prunes the file. It grows for the life of the server, which is the point, but it is yours to archive.
  • The file is writable by whatever runs the server. Anyone with shell access to that account can edit it, so a copy off the machine is worth having.
  • The actor is the account, not the person. A shared staff login makes every entry ambiguous, so give each member of staff their own account.
  • Only the address of the seed account is logged. Ordinary logins are not recorded here at all.
  • The list and show subcommands write no entry, because they read data rather than change it.
  • Timestamps come from the server's clock. Check the machine's time zone before drawing conclusions from the readable column.

Next