Repository navigation
fix(bootstrap): onboarding and re-runs with tnctl (keys, k3s token, pull secret) - #17
Merged
Merged
Conversation
…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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found onboarding a fresh VM device (vm-tnctl-01, Debian 13) to staging with
tnctl bootstrapand re-running the script:tnctl bootstrapwrote empty keys, and the script failed later with "Cannot generate the k3s CA". It now stops with a clear message.tnctl bootstrapmakes 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 existingserver/token(agents joining later need that token as K3S_TOKEN).--docker-secret,teknoir-registry-secretgot an empty.dockerconfigjsonand k3s rejected the Teknoir manifest in a loop. The script now keeps the device's existing secret, or writes{"auths":{}}.setup_userno longer aborts on an empty platform password (key-only login, the tunnel key is still installed).Tests: new
k3stoken_test.goandregistrysecret_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-01works through the reverse tunnel.🤖 Generated with Claude Code