Module admin 

recall-server admin: listing, renaming, removing and restoring the memory stored under a project key, from a shell on the server’s host.

docker exec -it -u node recall-server recall-server admin list

It is a subcommand rather than a route on purpose. The HTTP API has no way to delete or move a project, so a leaked token cannot destroy history through it, and this keeps that true: these commands open no listener of any kind, not even one bound to 127.0.0.1. Running them takes a shell inside the server’s container, which is the same access that could already open the database file directly, so they give no attacker anything new. “Admin commands” in ARCHITECTURE.md has the reasoning.

What they add over the file is the procedure a human used to have to remember. Every change:

1. names its keys exactly (never a prefix or a pattern) and is confirmed by typing each key back, a rename’s target included, or by --yes, which prints them instead;
2. takes a fresh backup first, with Store::backup, into an admin/ directory the server’s rotation never prunes, checks that the backup holds the rows it was shown, and prints its path;
3. runs in one transaction, re-checks inside it that nothing changed since it was shown, closes the merge jobs still open for the rows it touches, so no worker’s late result lands on them, appends one audit leaf saying what it did, as the host, and commits only if changes() matches;
4. waits out the server’s merge window after committing, and checks that no push that was already in flight has partly undone it, or queued a job for its rows again;
5. can be previewed with --dry-run, which changes nothing and takes no backup.

It runs beside a running server. Both wait up to 5 seconds on a lock the other holds, and a change’s transaction takes the write lock before it re-reads anything, so neither can fail the other half way. A lock cannot order a change against a whole push, though, which reads, merges with no lock held, and then writes: step 4 is there for the push that read before the change and writes after it. The store’s admin module has the detail.

reset_passkeys is here for the same reasons: it is the way back into /admin for an owner who lost every passkey, so it must take a shell on the host, and it is held to the same owner check and lock wait.

Functions

main

Runs recall-server admin, given the arguments after admin.

reset_passkeys

Runs recall-server reset-passkeys: removes every passkey and admin session from the database at RECALL_DB_PATH, and prints a new bootstrap code, which with RECALL_TOKEN registers a first passkey again.