Upgrade clan to 26.05
Bump clan-core and nixos-mailserver to 26.05 (NixOS 26.05) and adapt to
the breaking changes surfaced by nix flake check:
- mesh-hosts/clan.nix: read the new shared, instance-scoped zerotier vars
(zerotier-ip-<machine>-zerotier, zerotier-network-zerotier); admit
external members via the controller's native allowedIds.
- monitoring/server.nix: Grafana lost its built-in secret_key default;
mint one via a clan generator and pass it with $__file{}.
- dns/authoritative.nix: services.resolved.extraConfig removed -> settings.
- mail.nix: SNM cert API change (x509.useACMEHost + acme extraDomainNames)
and accounts/dkim option renames.
- docs: mesh runbook updated for the new var paths and allowedIds.
This commit is contained in:
+9
-11
@@ -10,10 +10,12 @@ transfers and metrics scraping ride this mesh, never the public net.
|
||||
## The mesh map
|
||||
|
||||
`modules/mesh-hosts.nix` does **not** hardcode addresses. It reads each machine's
|
||||
IP from the public clan vars that clan-core's zerotier generator already writes
|
||||
(`vars/per-machine/<m>/zerotier/zerotier-ip/value`) and derives the `/88` subnet
|
||||
from `control`'s `zerotier-network-id`. Regenerate or re-key a node and the map
|
||||
follows automatically.
|
||||
IP from the public clan vars that clan-core's zerotier service writes. As of
|
||||
clan-core 26.05 these are shared, instance-scoped generators
|
||||
(`vars/shared/zerotier-ip-<machine>-zerotier/ip/value`), and the `/88` subnet is
|
||||
derived from the instance network id
|
||||
(`vars/shared/zerotier-network-zerotier/network-id/value`). Regenerate or re-key a
|
||||
node and the map follows automatically.
|
||||
|
||||
Consumers: `modules/dns/authoritative.nix` (transfer ACLs), `modules/monitoring/*`
|
||||
(scrape targets and firewall scoping).
|
||||
@@ -21,12 +23,11 @@ Consumers: `modules/dns/authoritative.nix` (transfer ACLs), `modules/monitoring/
|
||||
## Admitting external members
|
||||
|
||||
Inventory machines are auto-accepted. External devices (admin laptops) are listed
|
||||
in `clan.nix` under the controller's `allowedIps`. Because this clan-core pins the
|
||||
`allowedIps` interface (admit by network IPv6), we keep a **node-id** list and a
|
||||
`ztMemberIp` helper derives each device's IP on this network:
|
||||
in `clan.nix` under the controller's `allowedIds` — clan-core 26.05 admits members
|
||||
by their 10-char ZeroTier node id directly, so no IP derivation is needed:
|
||||
|
||||
```nix
|
||||
roles.controller.settings.allowedIps = map ztMemberIp [
|
||||
roles.controller.settings.allowedIds = [
|
||||
"8802c8d7e0" # alex-nixos
|
||||
"2bd36db8cc" # kurogeek-thinkpad
|
||||
];
|
||||
@@ -34,6 +35,3 @@ roles.controller.settings.allowedIps = map ztMemberIp [
|
||||
|
||||
A device's 10-char node id comes from `zerotier-cli info` on that device. After
|
||||
editing, deploy `control`; the controller admits the new member on its next run.
|
||||
|
||||
> A newer clan-core exposes `allowedIds` (admit by node id directly), but adopting
|
||||
> it means a zerotier vars-schema migration, so we stay on the IP-derivation path.
|
||||
|
||||
Reference in New Issue
Block a user