Skip to content

fix(bootstrap): onboarding and re-runs with tnctl (keys, k3s token, pull secret) - #17

Merged
tekn0ir merged 2 commits into
mainfrom
bootstrap-require-keys
Oct 16, 2026
Merged

tekn0ir merged 2 commits into
mainfrom
bootstrap-require-keys

Conversation

@tekn0ir

@tekn0ir tekn0ir commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor

Found onboarding a fresh VM device (vm-tnctl-01, Debian 13) to staging with tnctl bootstrap and re-running the script:

  1. Missing keys: right after a device is created, the catalog doesn't have its key pair yet (device-controller generates it; the Backstage device provider refreshes every 5 min). tnctl bootstrap wrote empty keys, and the script failed later with "Cannot generate the k3s CA". It now stops with a clear message.
  2. Re-run took k3s down: every tnctl bootstrap makes a new k3s token, and k3s refuses to start on an existing datastore with another one. The server script now keeps the passphrase of the existing server/token (agents joining later need that token as K3S_TOKEN).
  3. Invalid pull secret: without --docker-secret, teknoir-registry-secret got an empty .dockerconfigjson and k3s rejected the Teknoir manifest in a loop. The script now keeps the device's existing secret, or writes {"auths":{}}.
  4. setup_user no longer aborts on an empty platform password (key-only login, the tunnel key is still installed).

Tests: new k3stoken_test.go and registrysecret_test.go; goldens regenerated; go test ./cmd/... ./pkg/templates/... pass. On the VM: first run and two re-runs end with rc=0, k3s active, AppliedManifest, TOE connected to MQTT, tnctl ssh vm-tnctl-01 works through the reverse tunnel.

🤖 Generated with Claude Code

tekn0ir and others added 2 commits October 16, 2026 17:56
…user

Onboarding a new device right after creating it: the device-controller
generates the key pair after creation and the Backstage catalog only picks
it up on its next device refresh (5 min), so tnctl bootstrap wrote empty
rsa_private.pem/rsa_public.pem and the server script failed later at
"Cannot generate the k3s CA". tnctl now says so and stops.

setup_user no longer aborts the script when the platform has no password
for the device user (chpasswd under set -e): it warns and keeps key-only
login, so the SSH key for the tunnel is still installed.

Found onboarding a fresh VM device (vm-tnctl-01) to staging with tnctl.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Re-running a tnctl server script on a device whose k3s has started took k3s
down: tnctl generates a new token for every set of scripts, and k3s refuses
to start with another one ("bootstrap data already found and encrypted with
different token"). The script now takes the passphrase of the existing
server/token.

Without --docker-secret, teknoir-registry-secret got an empty
.dockerconfigjson, which is invalid JSON: k3s rejected the Teknoir manifest
in a loop (ApplyManifestFailed). The script now keeps the secret the device
already has, or writes a valid empty config ({"auths":{}}).

Verified on a fresh Debian 13 VM onboarded to staging with tnctl: first run,
two re-runs (rc=0, k3s active, manifest applied, tnctl ssh through the
reverse tunnel).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@tekn0ir tekn0ir changed the title fix(bootstrap): refuse scripts without the device key pair; key-only user fix(bootstrap): onboarding and re-runs with tnctl (keys, k3s token, pull secret) Oct 16, 2026
@tekn0ir
tekn0ir merged commit f657949 into main Oct 16, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant