Re-authors the fix stranded on origin/fix/node-dns-resilient-upstream (7a34590). That
commit was NOT landed: it wrote a netplan drop-in and ran `netplan apply`, but netplan
does not exist on these nodes any more (Debian 13 trixie generic cloud image; not in
node_baseline_packages). Landing it would have failed the handler with command-not-found
and BROKEN node-baseline.yml on every node — worse than not landing it. Its dev-LAN
literals also sat in role defaults, which prod inherits, pointing prod nodes at a PiHole
on a network they cannot reach.
The underlying problem is real and verified: a SINGLE upstream resolver is a hard SPOF.
PiHole answers jackson.lan instantly but its external recursion flaps — 0/25 for public
names (registry-1.docker.io, quay.io, ghcr.io) while gitea.jackson.lan resolved 5/5 —
breaking containerd image pulls and CoreDNS `forward . /etc/resolv.conf`.
MECHANISM DETECTION (new `dns` tag in node_baseline). Five read-only probes feed one
set_fact yielding three outcomes, because the two environments no longer share a resolver
stack (dev-1 is behind resolved's 127.0.0.53 stub; prod-1 has a direct resolv.conf and no
cloud-init at all):
* systemd-resolved — resolved running AND owning /etc/resolv.conf (proven by the
symlink pointing into /run/systemd/resolve/, or by every nameserver being a resolved
loopback). Writes resolved.conf.d/99-k3s-dns.conf with an ordered DNS=, Domains=, and
FallbackDNS= EXPLICITLY EMPTIED so systemd's compiled-in public resolvers can never
silently bypass the local zone and ad-blocking.
* resolv-conf-file — plain directly-managed file (prod's shape). Ordered nameserver
lines + options timeout:2 attempts:2, backup: true. Deliberately NO `rotate`, which
would destroy PiHole-first ordering.
* contended — resolvconf/openresolv present or NetworkManager active. Writes NOTHING
and fails loudly: a change that silently gets reverted is worse than no change.
Resolved-running-but-not-owning-resolv.conf correctly falls through to the file branch.
Ordering is the policy that keeps the local zone working — the second server is only
consulted after the first fails, so a gateway NXDOMAIN can never beat PiHole to a
jackson.lan answer.
SEAMS. Dev values in role defaults ([192.168.1.18, 192.168.1.1], search jackson.lan);
prod values in inventory/group_vars/k3s_prod/vars.yml. NOT cluster-vars — that ConfigMap
is consumed by Flux postBuild for platform/ and apps/, and no Ansible code reads it.
PROD'S SECOND UPSTREAM IS AN OPEN OPERATOR DECISION and is left as a loud
BLOCKED-pending-second-upstream placeholder, the same precedent as the node_baseline disk
devices, with a dns-tagged assert that stops the play before any file is written. A
public resolver was NOT invented as a default: it would bypass the local zone, which is a
decision, not a default. PROD-PROVISIONING.md §4 was rewritten (the old bullet pointed at
the now-dropped branch) to state the choice, including that prod routing to the dev
PiHole is unverified across the pfSense boundary.
tofu: servers = [var.dns_server, var.network_gateway] — the one hunk of the old branch
worth taking as-is. Dev-only by nature.
ALSO FIXES A FALSE WARN THIS WOULD OTHERWISE CREATE: node_health_collect.py parsed
/etc/resolv.conf only, so on dev it read the 127.0.0.53 stub and would report a permanent
single-upstream WARN even after a correct fix. It now asks resolvectl for the real
upstreams when it sees the stub — and if that fails, nameservers is NULL with the reason
recorded, never the stub and never a guess. assess.yml turns null into SKIP, not WARN and
not PASS. The honesty discipline is preserved exactly.
Verified with NO play run against any node: syntax-check + yamllint + tofu fmt clean;
--tags packages still selects ONLY the apt task (the prod package-floor escape hatch
bypasses DNS entirely); --list-hosts unchanged; -c local simulation driving the REAL
detection expression and REAL file bodies extracted from the role by script (so the test
cannot drift) passes all 5 scenarios — dev stub -> systemd-resolved, prod shape ->
resolv-conf-file, NetworkManager and resolvconf -> contended; dev defaults pass the
assert byte-identically while prod overrides fail it by name; collector unit-tested
against 8 resolver shapes.
Serves: R-DNS-01, R-DNS-03, R-ENV-02, R-ENV-03.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
infra/tofu — dev/test cluster nodes (OpenTofu + Proxmox VE)
Provisions the "Create" lifecycle stage (docs/02): 3 cloud-init'd VMs on the
Proxmox VE box, each with an imported OS disk and a blank Longhorn data disk.
(Migrated from the old memory-constrained libvirt host; provider is now bpg/proxmox.)
APPLIED AND LIVE. These three VMs are the running dev cluster — k3s-dev-1/2/3, k3s
v1.36.4, carrying the whole platform. Treat any tofu apply/destroy here as an operation on
production-for-dev, and note the state file caveat below.
Serves R-ENV-01/02, R-PLAT-01, ADR-0001 (k3s substrate).
What it builds (defaults = the LIVE cluster, verified 2026-08-26)
| Resource | Value |
|---|---|
| Proxmox node | proxmox |
| Disk datastore | Storage (ZFS, 4.3TB) |
| Image/snippet datastore | local (dir; content = iso + snippets) |
| Bridge | vmbr0 (no VLAN) |
| Nodes | k3s-dev-1/2/3 at 192.168.1.50/.51/.52, gw 192.168.1.1, DNS 192.168.1.18 |
| Per node | 6 vCPU, 24 GiB RAM, cpu type host (nested virt for KubeVirt — real KVM confirmed in-guest) |
| OS disk | 64 GiB, virtio0 (/dev/vda, boot), imported from the Debian 13 cloud image |
| Data disk | 128 GiB, virtio1 (/dev/vdb) → /var/lib/longhorn (mounted by cloud-init; Longhorn reports ~125 GiB usable per node) |
| etcd disk | 16 GiB SSD, virtio2 (/dev/vdc) on the local-zfs SSD datastore → etcd data dir (/var/lib/rancher/k3s/server/db); isolates etcd WAL fsync from the HDD Longhorn I/O (docs/plans/ssd-etcd-isolation.md) |
| Cloud-init | native initialization (static IP + DNS) + user-data snippet for the baseline |
| Reserved | 192.168.1.53–.60 for Cilium L2 ingress VIPs (surfaced in outputs). In use: .53 shared Gateway, .54 UniFi |
⚠️ State file
terraform.tfstate is gitignored and lives only on the workstation that ran the apply. On a
fresh workstation it is absent — and a tofu apply with empty state will try to create three
VMs that already exist. Recover the state file (or tofu import the existing VMs) before running
anything that plans changes. tofu plan against empty state is itself harmless, but read the plan:
"3 to add" means you are missing state, not that the cluster is gone.
All sizing/IPs/counts/placement are variables — see variables.tf.
Files
versions.tf— OpenTofu1.9.0pin +bpg/proxmox ~> 0.66; provider block with endpoint scheme-normalization (see below).variables.tf— every knob (Proxmox placement, counts, sizing, IPs, image, SSH key).main.tf— cloud image download, per-node user-data snippet, and the 3 VMs.outputs.tf— node IPs/names,primary_node_ip,k3s_api_endpoint, renderedansible_inventory.terraform.tfvars.example— copy toterraform.tfvars; onlyssh_authorized_keyrequired.
Operator prerequisites (before tofu apply)
- Enable
snippetscontent on thelocaldatastore. The rich first-boot baseline (users, packages, kernel modules, Longhorn mount, swap-off) is shipped as a cloud-init user-data snippet. In the Proxmox UI: Datacenter → Storage →local→ Edit → Content → add Snippets. Without this theproxmox_virtual_environment_file(user-data) resource fails. (Alternatively pointimage_datastoreat any datastore that has snippets enabled.) - Endpoint scheme. If the operator env file exports
PROXMOX_VE_ENDPOINTwithouthttps://, the provider talks HTTP and eats a 301. Either fix the env file to include the scheme, or exportTF_VAR_proxmox_endpoint="$PROXMOX_VE_ENDPOINT"so tofu normalizes it (prependshttps://). - pfSense NAT — DONE, live. The workstation reaches the nodes and the kube-API
across it: SSH
192.168.2.102:2250/2251/2252→192.168.1.50/.51/.52:22, and kube-API192.168.2.50:6443→ kube-vip VIP192.168.1.49:6443.infra/ansible/inventory/hosts.iniis hand-maintained for this mapping — do not regenerate it fromtofu output -raw ansible_inventory, which knows nothing about the NAT and would overwrite it.
Auth (env only — never in tofu vars/state)
The provider reads these from the environment; the API token is never a tofu
variable, so it never enters state, vars, or plan output. You do NOT export these by hand —
they live encrypted in secrets.sops.env and the tf.sh wrapper decrypts + exports them
(and sets TF_VAR_proxmox_endpoint for scheme normalization) at runtime:
PROXMOX_VE_ENDPOINT=https://192.168.2.102:8006/
PROXMOX_VE_API_TOKEN=user@realm!tokenid=SECRET
PROXMOX_VE_INSECURE=true
See REMOTE-STATE.md for the encrypted-secrets + wrapper flow.
Usage (operator — NOT run here)
All secrets come from the encrypted secrets.sops.env via the tf.sh wrapper, run inside the
dev container (which has sops + the age key):
cp infra/tofu/terraform.tfvars.example infra/tofu/terraform.tfvars # set ssh_authorized_key
./infra/devcontainer/dev.sh run ./infra/tofu/tf.sh init
./infra/devcontainer/dev.sh run ./infra/tofu/tf.sh plan
./infra/devcontainer/dev.sh run ./infra/tofu/tf.sh apply
# hand the node IPs to Ansible:
./infra/devcontainer/dev.sh run ./infra/tofu/tf.sh output -raw ansible_inventory > infra/ansible/inventory/hosts.ini
Hand-off contract
primary_node_ip/k3s_api_endpoint(192.168.1.50:6443) is the value the Ansible Cilium bootstrap and the Fluxplatform/ciliumHelmRelease must BOTH use fork8sServiceHost/k8sServicePort(docs/02 parity contract).- Destroy/rebuild proof: name-keyed
for_eachmeanstofu destroy -target='proxmox_virtual_environment_vm.node["k3s-dev-2"]'thentofu applyre-creates just that node (stop_on_destroyallows the clean stop); Ansible re-joins it; Longhorn replicas reconverge (nodes are cattle).
Static validation (PM, offline)
tofu fmt -check -recursive
tofu init # fetches the bpg provider (network, read-only)
tofu validate