pastilhasandClaude Opus 5
27aa72d923
Asked for a thorough check that nothing of offscale is left in the platform. The extraction was sound — no router, no permission entry, no app-store entry, no screen, no panel app, no env var anything reads. Two things were genuinely wrong, and both were in setup rather than in the server. ── The secret store minted a key for a plugin ── `officer-setup` bootstrapped two purposes: `jwt` and `headscale`. The second was a key for a PLUGIN, under a name the rename had already replaced, on a machine where the plugin is not installed and nothing would ever ask for it. offscale encrypts under `offscale`, and `getKey` creates on demand — which is precisely what lets core know nothing about plugins. Now core bootstraps `jwt` alone. ── `.env.example` documented variables for a deleted router ── HEADSCALE_URL, HEADSCALE_API_KEY and HEADSCALE_USER were described as driving `/api/vpn`. That router was deleted on 2026-08-14 and nothing has read any of them since. Left as a note saying where the tailnet's credentials live now, because somebody with an older `.env` will otherwise wonder why setting them does nothing. ── Names that outlived the thing ── Eleven comments referred to the plugin's route, panels, console or server registry as "headscale": three sidecar config files describing their own shape by pointing at it, two screens citing `/headscale` as the example of a Workspace/Panel route, the terminal's note about the Console, and the photos types. Also `catalogue.ts`, which still claimed headscale "is CORE now", and `working-on-officer.md`, which told the reader a core install runs six processes including `officer-headscale`. Upstream references are deliberately untouched: "Headscale's API", "the Headscale admin credential", "is this a Headscale server?" all name the thing the plugin drives, and renaming those would make the sentences false. `docs/secret-store.md` argued headscale must be core because the tailnet is the perimeter. Marked superseded rather than deleted, with the distinction that settles it: the perimeter is the tailnet EXISTING, which machine-setup still arranges on a core install — not the platform shipping the screen that administers it. Verified by counting: live code, setup provisioning, env references, permission entries, app-store entries, hono mounts, dock defaults, screens and panel apps all zero. What is left is generated files (Plugins.gen, plugin-schemas.gen), the bundled catalogue entry, test fixtures using "offscale" as an example app name, and history. tsgo clean, frontend builds, 873 pass / 7 fail unchanged, setup scripts parse. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
45 lines
2.1 KiB
Bash
45 lines
2.1 KiB
Bash
#!/bin/bash
|
|
# =============================================================================
|
|
# officer-setup — the secret store
|
|
# =============================================================================
|
|
#
|
|
# Definitions only.
|
|
#
|
|
# The store is $OFFICER_ROOT/secrets/officer-keys.db, deliberately a sibling of
|
|
# the repo and NOT under data/ — that directory holds the managed homes and
|
|
# attachments people back up, and a key store travelling in the same tarball as a
|
|
# database dump rebuilds the exact problem it exists to avoid.
|
|
#
|
|
# Bootstrapping runs the platform's own module rather than reimplementing the
|
|
# schema in bash. There is exactly one writer of this file's format, and a second
|
|
# one in shell would drift the first time a column is added.
|
|
|
|
[[ -n "${OFFICER_SETUP_SECRETS_LOADED:-}" ]] && return 0
|
|
OFFICER_SETUP_SECRETS_LOADED=1
|
|
|
|
secret_store_dir() { echo "${OFFICER_ROOT}/secrets"; }
|
|
secret_store_path() { echo "$(secret_store_dir)/officer-keys.db"; }
|
|
|
|
# Create the store and the one purpose a core install needs.
|
|
#
|
|
# `jwt` only. It used to also mint `headscale`, which was a key for a PLUGIN — and a plugin is not on a
|
|
# fresh machine, so the key was created, named after a rename that had already happened, and never used
|
|
# by anything. `getKey` creates on demand, so offscale mints its own `offscale` key the first time it
|
|
# encrypts a server's API key. Nothing here has to know a plugin exists.
|
|
#
|
|
# Run AS the owner, not as root: the platform runs as them, and a store root
|
|
# created would be a store they cannot write. `install -d -o` sets the owner in
|
|
# one step rather than mkdir-then-chown, so it is never briefly root's.
|
|
bootstrap_secret_store() {
|
|
install -d -m 0700 -o "$USERNAME" -g "$(user_group)" "$(secret_store_dir)" || return 1
|
|
|
|
# From the repo, because the module derives the install root as the parent of
|
|
# the working directory — the same rule as src/servers/data-path.ts.
|
|
sudo -u "$USERNAME" bash -c "cd '$(platform_dir)' && bun --eval \"
|
|
const { getKey } = await import('officerdb/secret-store');
|
|
getKey('jwt');
|
|
\"" >/dev/null 2>&1 || return 1
|
|
|
|
[[ -f "$(secret_store_path)" ]]
|
|
}
|