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

hive-forge: resolve through the hive's dnsmasq

Browse source 
The forge container used the host's resolvers, where the swarm domain has
no records — so every outbound call to a swarm name failed with "no such
host". Forgejo's webhook deliveries died there: knowledge, config-pr and
vcs-activity alike, which is why the swarm-controller's receiver has never
logged a verified delivery and knowledge propagation has been running on
its hourly fallback.

An earlier fix taught the container authelia's name with a `networking.hosts`
entry. That covered one name and left the rest, so use the resolver every
other service container already uses and drop the override — hive-matrix
records why a second answer that can disagree with the first is worse than
none.

Closes #3824
This commit is contained in:
atlas 2026-08-31 11:17:05 +02:00 • committed by mara
commit d6f3af60ae
3 changed files with 36 additions and 33 deletions
Download patch file Download diff file Expand all files Collapse all files

46
nix/host-modules/hive-forge/default.nix
View file

@ -10,6 +10,7 @@ let
hyperhiveDomain = config.services.hyperhive.domain;
swarmDomain = config.services.hyperhive.swarm.domain;
tlsCfg = config.services.hyperhive.deploy.hive-controller.tls;
networkCfg = config.services.hyperhive.network;
# Forgejo's name for the login source. A constant, not an option: it
# is the key this module's own idempotency check looks up, so making
@ -669,6 +670,24 @@ in
in
{
imports = [
# Ask the hive's dnsmasq, not the host's resolvers. The swarm
# names — the controller's webhook endpoint, the SSO issuer —
# resolve to the bridge and have no public records, so a
# container using the host's resolvers gets "no such host" for
# every one of them while the same name resolves fine one
# container over.
#
# Both units that make an outbound call are consumers, for the
# same reason the trust bundle below names both: an unordered
# resolver write is a race that only shows up on a cold boot.
(import ./../swarm-container-resolver.nix {
inherit (networkCfg) bridgeIp;
dnsConsumers = [
"forgejo.service"
]
++ lib.optional ssoLocal "forgejo-sso-source.service";
})
# Forgejo is Go, and `SSL_CERT_FILE` *replaces* the default store
# rather than adding to it — so it needs the system CAs and the
# hive CA concatenated, not the CA alone, or public mirror fetches
@ -699,28 +718,11 @@ in
# bridge DHCP/DNS holes and agent NAT. The host firewall owns
# all filtering; never run one in here.
networking.firewall.enable = false;
# Teach this container the SSO name, because nothing else will.
#
# The hive's dnsmasq is authoritative for the swarm service
# names, but only containers whose resolv.conf points at the
# bridge ask it — agent containers do, by an explicit unit
# (`nix/agent-modules/network.nix`) written for exactly this
# reason. This container resolves through the host's resolvers
# instead, and the swarm domain has no public records, so
# `admin auth add-oauth` fails at discovery with "no such
# host" while the same name resolves fine one container over.
#
# `127.0.0.1` rather than the bridge IP: sharing the host netns
# means loopback IS the host, where nginx serves this vhost.
# TLS still validates — the CA trust bundle is bind-mounted
# above, and the leaf covers this name.
#
# Only when THIS host runs authelia. With a remote provider the
# name belongs to another machine and must resolve normally.
networking.hosts = lib.mkIf ssoLocal {
"127.0.0.1" = [ autheliaCfg.domain ];
};
# resolvconf stays off because the resolver unit imported above
# owns /etc/resolv.conf. Leaving it on would let host-tracking
# regenerate the file empty, since the host's copy doesn't cross
# the boundary after start.
networking.resolvconf.enable = lib.mkForce false;
services.forgejo = {
enable = true;