Stage 4b of the clan migration. Declares a clan.inventory.instances.zerotier
instance with sunken-ship as controller and phantom-ship as peer (controller
is also listed as a peer so it joins its own network). Generates the network
ID, controller identity, and per-peer identities via `clan vars generate`;
all secrets are SOPS-encrypted to the user's age key and the per-machine
age keys.
- nixos/sops/ — clan-managed SOPS state (user + per-machine age keys).
- nixos/vars/ — shared + per-machine zerotier vars; *-identity-secret
files are SOPS-encrypted, *.value files are plain public data.
- clan.core.networking.{targetHost,buildHost} = "danny@<host>" on both
servers so `clan machines update` knows where to push and build.
- mac gets `zerotier-one` installed as a homebrew cask; authorization
on the controller happens manually by node-ID in a follow-up step.
Known rough edges (to chase in later stages):
- zerotier-inventory-autoaccept.service races zerotierone.service on
first activation (connection refused against the local API). Retrying
the unit succeeds; clan upstream bug.
- Deployment must go through `clan machines update`, not plain
nixos-rebuild, or the per-host SOPS age key isn't uploaded and
zerotier-one can't decrypt its identity.
6 lines
No EOL
112 B
JSON
Executable file
6 lines
No EOL
112 B
JSON
Executable file
[
|
|
{
|
|
"publickey": "age1zy3q73pujauyajgfqwu0pnyy8732lzwvw87tu7p2xg3xuzaujc2qh6ql77",
|
|
"type": "age"
|
|
}
|
|
] |