From 38f2435767719427170467a4b5a1d7a5c286e6c7 Mon Sep 17 00:00:00 2001 From: atlas Date: Sat, 6 Jun 2026 10:50:55 +0200 Subject: [PATCH 1/2] fix(matrix): give hive-matrix container a DNS resolver so tuwunel can boot tuwunel hard-fails to start when /etc/resolv.conf has no nameserver line (Failed to configure DNS resolver: no nameservers found in config -> exit 1 -> systemd start-limit). The declarative containers.hive-matrix generates its own resolv.conf via resolvconf and, unlike agent containers whose resolv.conf is written by hive-c0re's lifecycle, has no nameserver source -> it comes up empty (just 'options edns0'). Defaulting network.enable on surfaced this: the host DNS moved to the bridge dnsmasq but the container was never pointed at it, so the homeserver could not boot, taking down matrix for all agents. Point the container at the hive resolver (the dnsmasq the network module runs at bridgeIp) when the network module is enabled; the container always shares the host netns (privateNetwork = false) so it reaches bridgeIp whether or not isolateContainers is set. With the network module off, inherit the host resolv.conf. --- nix/modules/hive-matrix.nix | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/nix/modules/hive-matrix.nix b/nix/modules/hive-matrix.nix index 9a6ddf9c..b63cd224 100644 --- a/nix/modules/hive-matrix.nix +++ b/nix/modules/hive-matrix.nix @@ -6,6 +6,7 @@ }: let cfg = config.services.hyperhive.matrix; + networkCfg = config.services.hyperhive.network; hyperhiveDomain = config.services.hyperhive.domain; effectiveServerName = if cfg.serverName != null then cfg.serverName else hyperhiveDomain; @@ -337,6 +338,29 @@ in { ... }: { system.stateVersion = "26.05"; + + # tuwunel hard-fails to boot if `/etc/resolv.conf` has no + # `nameserver` line (`Failed to configure DNS resolver ... no + # nameservers found in config` → exit 1). This declarative + # nixos-container generates its own resolv.conf via resolvconf + # and — unlike agent containers, whose resolv.conf is written by + # hive-c0re's lifecycle — it has no nameserver source, so it + # comes up empty (just `options edns0`). When the hive network + # module is on, point it at the dnsmasq resolver the module runs + # at `bridgeIp`; this container always shares the host netns + # (`privateNetwork = false`), so it reaches `bridgeIp` whether or + # not `isolateContainers` is set. With the network module off, + # inherit the host's resolv.conf (which carries the host + # resolver). See `docs/network.md`. + networking = lib.mkMerge [ + (lib.mkIf networkCfg.enable { + nameservers = [ networkCfg.bridgeIp ]; + }) + (lib.mkIf (!networkCfg.enable) { + useHostResolvConf = true; + }) + ]; + services.matrix-tuwunel = { enable = true; package = cfg.package; From 43776afbfd2f2803e3abcd0d144cffddfdcc6a69 Mon Sep 17 00:00:00 2001 From: atlas Date: Sat, 6 Jun 2026 11:02:25 +0200 Subject: [PATCH 2/2] fix(matrix): order hive-matrix container start after the gateway (resolver) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Per operator review on the PR: when the network module is on, the matrix container's resolver is the dnsmasq in the gateway container, so order the matrix container start after the gateway container. This is robustness for tuwunel's lazy federation lookups, not a boot requirement — the boot fix is the resolv.conf nameserver line (the failure was a parse error on an empty resolv.conf, not connectivity). Soft 'after' (not 'requires') keeps lifecycles decoupled; network.enable asserts gateway.enable so the gateway container unit always exists. --- nix/modules/hive-matrix.nix | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/nix/modules/hive-matrix.nix b/nix/modules/hive-matrix.nix index b63cd224..875b165a 100644 --- a/nix/modules/hive-matrix.nix +++ b/nix/modules/hive-matrix.nix @@ -403,5 +403,22 @@ in cfg.httpPort ]; }; + + # 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. `network.enable` + # asserts `gateway.enable`, so the gateway container unit always exists + # here. (Declarative `containers.` → `nixos-container@.service`, + # per the hive-ci precedent.) + systemd.services."nixos-container@hive-matrix".after = lib.mkIf networkCfg.enable [ + "nixos-container@hive-gateway.service" + ]; }; }