vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

refactor: replace deprecated no-op options with mkRemovedOptionModule

Browse source
This commit is contained in:
müde 2026-07-13 21:58:30 +02:00
commit 7ad2bb9211
8 changed files with 85 additions and 189 deletions
Download patch file Download diff file Expand all files Collapse all files

73
nix/modules/hive-matrix.nix
View file

@ -366,39 +366,31 @@ in
# gets the host file across the shared-netns boundary), so it
# regenerates an empty file and tuwunel dies at boot.
#
# The earlier fix turned host-tracking off and trusted resolvconf
# to honour `networking.nameservers` — but that's a RUNTIME
# resolvconf behaviour, not verifiable at eval time, and it STILL
# came up empty in practice. So take resolvconf out of the
# loop entirely and write a STATIC `/etc/resolv.conf` from
# `bridgeIp` that nothing regenerates. Eval-proven: the generated
# Trusting resolvconf to honour `networking.nameservers` doesn't
# work either — that's a RUNTIME resolvconf behaviour, not
# verifiable at eval time, and it still comes up empty in
# practice. So take resolvconf out of the loop entirely and
# write a STATIC `/etc/resolv.conf` from `bridgeIp` that nothing
# regenerates. Eval-proven: the generated
# `environment.etc."resolv.conf".text` is `nameserver <bridgeIp>`.
# This container always shares the host netns
# (`privateNetwork = false`), so it reaches `bridgeIp` regardless
# of agent-container isolation. Network module off → inherit the host's
# resolv.conf. See `docs/network.md`.
networking = lib.mkMerge [
(lib.mkIf networkCfg.enable {
# resolvconf is taken out of the loop entirely; the static
# `environment.etc."resolv.conf"` below is the sole source of
# the resolver file (no `nameservers` — nothing would read it).
useHostResolvConf = lib.mkForce false;
resolvconf.enable = lib.mkForce false;
})
(lib.mkIf (!networkCfg.enable) {
useHostResolvConf = true;
})
];
# of agent-container isolation. See `docs/network.md`.
networking = {
# resolvconf is taken out of the loop entirely; the static
# `environment.etc."resolv.conf"` below is the sole source of
# the resolver file (no `nameservers` — nothing would read it).
useHostResolvConf = lib.mkForce false;
resolvconf.enable = lib.mkForce false;
};
# resolvconf is disabled above, so write the static resolver file
# explicitly — NixOS won't synthesise one from `nameservers` once
# resolvconf is off, and this is the file tuwunel parses at boot.
environment.etc = lib.mkIf networkCfg.enable {
"resolv.conf".text = ''
nameserver ${networkCfg.bridgeIp}
options edns0
'';
};
environment.etc."resolv.conf".text = ''
nameserver ${networkCfg.bridgeIp}
options edns0
'';
services.matrix-tuwunel = {
enable = true;
@ -444,21 +436,20 @@ in
];
};
# When the hive network module is on, the matrix container's resolver
# is the dnsmasq that runs in the gateway container (bound at
# `bridgeIp`). Order the matrix container start after the gateway
# container so the resolver is up before tuwunel's first federation
# lookups. tuwunel boots fine without this — it configures the resolver
# from `/etc/resolv.conf` at startup and only queries on-demand (the
# boot failure this module fixes was an *empty* resolv.conf, a parse
# error, not a connectivity one) — so this is robustness, not a boot
# requirement. Soft `after` ordering (not `requires`) keeps the matrix
# container's lifecycle decoupled from the gateway's. The gateway
# always runs alongside hyperhive, so the gateway container unit always
# exists here. (Declarative `containers.<n>` → `container@<n>.service` — the
# nspawn template NixOS generates, confirmed from the live
# `container@hive-matrix.service` host unit.)
systemd.services."container@hive-matrix".after = lib.mkIf networkCfg.enable [
# The matrix container's resolver is the dnsmasq that runs in the
# gateway container (bound at `bridgeIp`). Order the matrix
# container start after the gateway container so the resolver is up
# before tuwunel's first federation lookups. tuwunel boots fine
# without this — it configures the resolver from `/etc/resolv.conf`
# at startup and only queries on-demand (the boot failure this
# module guards against is an *empty* resolv.conf, a parse error,
# not a connectivity one) — so this is robustness, not a boot
# requirement. Soft `after` ordering (not `requires`) keeps the
# matrix container's lifecycle decoupled from the gateway's. The
# gateway always runs alongside hyperhive, so the gateway container
# unit always exists here. (Declarative `containers.<n>` →
# `container@<n>.service` — the nspawn template NixOS generates.)
systemd.services."container@hive-matrix".after = [
"container@hive-gateway.service"
];
};