Use Determinate Nix as `nix.package` for systems, homes and the
devshell, for its parallel evaluation and lazy trees. We only take the
package, not `determinate-nixd`: the daemon and `nix.conf` model are
unchanged and the Determinate NixOS module is not imported.
- Add the `determinate-nix` (`nix-src`) input, following our
`nixpkgs-unstable`. FlakeHub's cache needs auth, so we build it
ourselves and let it flow through Harmonia like everything else.
- `determinateOverlay` exposes it as `pkgs'.mine.determinate-nix`;
`lib.my.c.nix.determinateSettings` (`lazy-trees`, `eval-cores = 0`)
is merged into `nix.settings` and the devshell `nix.conf`.
- Switch CI to `DeterminateSystems/determinate-nix-action` so the
runner itself evaluates with Determinate.
- Advertise the Harmonia cache via the flake's `nixConfig`, trusted
without a prompt via `accept-flake-config` in the devshell, `.envrc`
and CI only (boxes already trust it through `nix.settings`).
- Re-attach `pkgs`/`lib` to container and installer
`nixosConfigurations` so Determinate's flake schemas can evaluate
them (`nix flake check` otherwise fails with `attribute 'pkgs'
missing`).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Statically-addressed home servers on hi run no DHCP, so they learned a
resolver only from the v6 RA RDNSS and lost DNS whenever v6 (and thus
the RA) was absent. Factor the fix castle/palace applied inline into a
shared lib.my.c.home.vlanDns helper that points resolved at the VLAN's
VRRP VIPs (always-present static v4, plus v6 when up) and sets the
advertised search domains, then apply it to every statically-addressed
hi client: castle, palace, cellar, sfh and the sfh hass/unifi
containers. Document it under the router client DNS section.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
radvd's DNSSL and kea's domain-search hardcoded the same list of
search domains in two places. Hoist it to lib.my.c.home.searchDomains
so there is a single source of truth (and so other consumers, such as
statically-configured boxes, can reuse it). No change to what is
advertised.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
With a single ONT the ISP's VLAN 10 is unique on the fabric, so there's no
need to swap it to a private fabric VLAN. Carry pon-isp (10) trunked straight
through the switches to river and run PPPoE directly on it, dropping the old
wan-pon-isp (141) translation. The ONT's untagged management is PVID'd onto
wan-pon-ont (140) at its edge switch (brian).
wan-pon-isp (141) is kept as a constant, reserved for the future multi-ONT
case where per-port VLAN translation disambiguates two VLAN-10 ONTs.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Digiweb's ONT delivers its untagged management traffic (192.168.100.0/24)
alongside the tagged ISP VLAN 10. The switch feeding river now tags the ONT's
untagged port as wan-pon-ont (140) and swaps the ISP VLAN 10 to wan-pon-isp
(141) on ingress, so both reach river single-tagged: river takes an address in
the ONT's /24 on 140 to reach its web UI, and PPPoE runs directly on 141.
Replaces the old QinQ-into-131 (wanStacked) transport; the wan-pon (131) VLAN
constant is dropped and prefixes.ont added.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Digiweb assigned river a static IPv4 (84.203.124.128). Point river's
public address at it and have pppd actively request it as the IPCP local
address (local:remote form) rather than passively accepting whatever the
peer offers via noipdefault. The address stays sourced from the
routersPubV4 constant, so the ipsec l2 mesh peer, the nft DNS redirect,
and the cross-router route all follow.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
river's WAN moves to a PPPoE session (Digiweb, over VLAN 10 with baby-jumbo
1508 MTU) driven by pppd, with its ip-up/ip-down hooks toggling a new
wan-online.target. stream keeps its DHCP WAN, so the existing 50-wan /
50-wan-ifb networkd config moves out of routing-common into stream, and the
shared consumers (ipsec, ipv6-clear-default-route) now attach to
wan-online.target instead of depending on systemd-networkd-wait-online@wan
directly.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
jackos1998