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

fix(3191): order gateway TLS against the units that read it, not a dead container

Browse source 
Removing the gateway container retired two things that were still
depended on: an ordering edge and a delivery path.

- hive-tls-ca ordered itself before/requiredBy
  container@hive-gateway.service. That unit no longer exists, so the CA
  was sequenced against nothing while its real consumer,
  hive-gateway-self-signed-cert (which nginx Requires=), could win the
  race and fail its copy under set -eu, blocking nginx.

- hive-tls-resign propagated a rotated leaf with
  `systemctl -M hive-gateway … || true`. The machine is gone, so both
  calls failed and both failures were swallowed: the unit logged
  "propagating" and exited 0 while nginx served the stale copy until it
  expired. Host units now, so no -M and no || true — a failed
  propagation fails the timer.

- container@hive-matrix ordered after the gateway container to get the
  resolver up first. dnsmasq is a host service now, so it orders after
  dnsmasq.service, which is what the edge always meant.
This commit is contained in:
atlas 2026-08-12 12:18:13 +02:00
commit d70b1e0a97
2 changed files with 55 additions and 37 deletions
Download patch file Download diff file Expand all files Collapse all files

33
nix/host-modules/hive-matrix.nix
View file

@ -581,25 +581,30 @@ in
];
};
# 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.)
# The matrix container's resolver is the hive's dnsmasq (bound at
# `bridgeIp`). Order the matrix container start after it 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 resolver's.
#
# ⚠️ This named `container@hive-gateway.service` until the gateway
# moved onto the host: dnsmasq lived in that container, so ordering
# after the container was how you ordered after the resolver. The
# container is gone and dnsmasq is a plain host `services.dnsmasq`,
# so the ordering now names the resolver directly — which is what it
# always meant. Naming the *container* was already indirection; it
# just happened to be correct while the container existed.
#
# `mkMerge`, not a bare assignment: `caTrust.containerOrdering` also
# sets `after`/`requires` (so the bound trust bundle exists before
# nspawn wires the mount up), and two plain assignments to the same
# unit would conflict rather than combine.
systemd.services."container@hive-matrix" = lib.mkMerge [
{ after = [ "container@hive-gateway.service" ]; }
{ after = [ "dnsmasq.service" ]; }
caTrust.containerOrdering
];
};