Each machine derives its SSH client config from its own identity record #56
Labels
No labels
blocked
bug
decision
duplicate
enhancement
help wanted
invalid
landed?
question
ready-to-merge
stale
wontfix
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
allod/strategy#56
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Stop copying the hypervisor's SSH address book into every dev VM, and have the framework render a dev VM's forge host entry from that VM's own identity record, so that no SSH host block has two authors and no machine carries aliases it cannot use. This is the multi-repo home for that change; the framework work is allod/archetypes#54.
Primary goals:
forgeHost,forgePort,sshKeyName). The profile copies and thelib.mkDefaulttie-breaker that let two layers define one block go away.identity.sshHostsis the hypervisor's SSH client configuration, keyed to a key only the hypervisor holds. Dev VMs stop receiving it, which closes the dead-alias and fleet-exposure defects by absence rather than by a per-entry filter.programs.ssh.settings, translating the currentsshHostsfield names to upstream directive names in one place. Home Manager 26.05'smatchBlockswarnings stop without renaming any data.sshHostsentry changes, and the nexus rotation scripts keep reading the same fields.Children
sshHostsentries gainlocalForwardsandextraOptionsso the framework check exercises every field shape the translation claims (part of the allod/archetypes#54 change)hosts/dev/allod-dev/home.nix; the neovim half is independentHeld pull requests
allod/archetypes#80 and allod/profiles#9 implemented the warning fix by keeping both authors and porting the tie-breaker to the new option, which forces a strict landing order between the two repos. They stay open but unmerged. The translation and the
ssh -Gcheck from allod/archetypes#80 are harvested into the allod/archetypes#54 change, after which both are closed.Landing order
The framework keeps
lib.mkDefaulton the rendered forgeIdentityFileuntil every profile copy is gone, so the deploy lock may take the archetypes change and the profiles changes in either order. The trigger for the follow-up that drops it is a deploy lock in which no profile input still defines the forge block; after that, a stray copy is a type clash at evaluation, not a silent winner.Out of scope
Renaming
sshHostsfield names to OpenSSH's directive names, which would make the hypervisor path a verbatim copy with no translation; a separate step across the secrets template, deployments' data, and the nexus scripts. A per-VM list of extra hosts a VM reaches with its own key, which would live in that VM's identity record besidesshKeyNamewhen a deployment needs it. Deriving the address book's VM addresses from inventory, which is its own arc.The three public changes for this issue are open: allod/archetypes#81 (framework split, translation,
ssh -Gcheck; closes allod/archetypes#54), allod/secrets#33 (templatelocalForwardsandextraOptionsentries) and allod/profiles#10 (forge block deleted, neovim provider flags). Each body carries its validation against the public deploy template. What remains for this issue is the per-deployment half: the private profile copies of the forge block, and the render of each deployment machine's~/.ssh/configagainst allod/archetypes#81, which only the deployer can run.One correction to the "Landing order" section. Evaluation is clean in either order, as written. Deployment order is not free: a deploy lock that takes the profile deletion while its archetypes pin still predates allod/archetypes#81 leaves that dev VM with the address book's forge block, keyed to the hypervisor's key it does not hold, until the archetypes pin catches up. Take the archetypes change first or together with the profile deletions. Nothing fails to evaluate in the wrong order, so this is a human check at the lock bump, not a canary.
One precision on "byte-identical". Measured on the public template with allod/secrets#33 in place: the hypervisor's rendered config is byte-identical for every entry without
extraOptions; for an entry withextraOptionsthe same directives render in a different order inside the block (the legacy option appended them after the typed directives, the flat merge sorts them in).ssh -Gresolves every host identically under both. A deployment measurement should comparessh -Goutput per host, not bytes, for those entries.Two facts a deployment's address book may hit at the lock bump, both loud evaluation errors naming the host: an
extraOptions.SetEnvwritten as a string must become an attribute set (SetEnv = { ROLE = "backup"; }), because Home Manager's settings renderer takes only that form; and anextraOptionskey that names a directive already set by a translated field, compared case-insensitively, is rejected rather than silently winning.Status. Every child has landed: allod/archetypes#54 (framework, c213a34), the allod/secrets template shapes (e21b088), allod/profiles#8 (fa37849), and the deployment's private profile copies, taken into its deploy lock together with the framework. allod/archetypes#80 and allod/profiles#9 are closed. Measured on a rebuilt dev VM:
~/.ssh/configholds oneHostblock, the forge, and git over SSH to the forge works with the VM's own key.The landing-order trigger is met, so the follow-up that drops the transitional
lib.mkDefaultis filed as allod/archetypes#82; this issue closes with it. One residual outside this arc: a dev VM that reached an external host with its own key through an address-book alias no longer has that alias, which is the per-VM host list named under Out of scope, tracked by the deployment.