diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index 81032c7..70560d2 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -71,9 +71,15 @@ `10.12.4.1/22` (ruled provider-public gateway). Verified on the kernel; **the edge itself egresses to 1.1.1.1 at 0% loss**, and the API answers at the new LAN address. Interim bootstrap address removed; virbr5 now - carries only the ruled `10.12.4.2/22`. REMAINING: D-129 edge plugin - profile on 26.7 (`opnsense-plugins.sh apply vr1-edge`, operator-gated - firmware mutation) + the qga channel question; then MAAS reach + + carries only the ruled `10.12.4.2/22`. **D-129 edge profile APPLIED + 2026-07-20 on 26.7** (operator-ruled): `expose_qga_channel` shipped in + `modules/opnsense-edge` (opt-in, default OFF; dc0 true) and applied as an + IN-PLACE domain update; os-qemu-guest-agent + os-iperf installed for real + and the agent ANSWERS -- `guest-ping` -> `{"return":{}}` and + `domifaddr --source agent` reports both legs. Note this run also exposed + and fixed a false-success bug: `opnsense-plugins.sh apply` had ALWAYS + dry-run (see session changelog item 12), so any prior "applied" claim + from that script is void. REMAINING: MAAS reach + `TF_VAR_maas_api_key` + region-side metal-admin DHCP naming this rack primary_rack (step D), and netem (step E). - The grounding audit is COMPLETE and EXITED (2026-07-19): Phases 1-6 all diff --git a/docs/audit/d129-plugins-20260720.txt b/docs/audit/d129-plugins-20260720.txt index 337042c..c33b29b 100644 --- a/docs/audit/d129-plugins-20260720.txt +++ b/docs/audit/d129-plugins-20260720.txt @@ -4,7 +4,7 @@ New DC edges should be BORN with the channel; office1-opnsense retrofits at its next scheduled restart. (D-129 Verification, 2026-07-18.) == install os-qemu-guest-agent == -DRY-RUN POST https://10.12.4.1/api/core/firmware/install/os-qemu-guest-agent +{"status":"ok","msg_uuid":"331a0296-95f4-416f-bc98-d664f1334863"} == install os-iperf == -DRY-RUN POST https://10.12.4.1/api/core/firmware/install/os-iperf +{"status":"ok","msg_uuid":"c22fe2d7-10a2-4e38-9d17-d3b95ded438d"} OK: profile 'vr1-edge' applied (os-qemu-guest-agent os-iperf) diff --git a/docs/changelog-20260719-dc0-deploy-stepB.md b/docs/changelog-20260719-dc0-deploy-stepB.md index 9003979..956933a 100644 --- a/docs/changelog-20260719-dc0-deploy-stepB.md +++ b/docs/changelog-20260719-dc0-deploy-stepB.md @@ -404,6 +404,61 @@ (`--commit lan 192.168.1.1 24`, `--commit wan ...`); the gateway item is named `WAN_GW` and is the only one this tool created. +## 12. D-129 edge profile APPLIED on 26.7 + qga channel shipped + a FALSE-SUCCESS bug fixed + +- **RULING RECORD (GA-R5), 2026-07-20.** Question: the qga virtio channel is + absent from the edge domain and unsupported by `modules/opnsense-edge` + (both MEASURED), so installing os-qemu-guest-agent alone yields a package + that can never answer. Options presented: add channel var now / iperf only + + defer / install both and leave qga inert. Operator answer, exact + utterance (option selected): "Add channel var now, then install both + (Recommended)". [OPS under D-129; no new D-number, GA-R3.] +- **SHIPPED `expose_qga_channel`** (opt-in, DEFAULT OFF) in + `modules/opnsense-edge`; `vr1-dc0-substrate` sets it true so NEW DC edges + are BORN with the channel (the runbook's no-retrofit intent). Default OFF + is load-bearing: a device change alters the domain, so defaulting ON would + bounce every existing edge on the next plan. Shape taken from + `tofu providers schema -json` (dmacvicar 0.9.8: + `devices.channels[].target.virt_io{name}` + `source.unix{mode}`), NOT from + a blog; `source.unix` carries no path, letting libvirt allocate the socket + (same reasoning the serial block documents for pty). +- APPLY was SAFE: plan showed **0 add / 1 change / 0 destroy -- an IN-PLACE + domain update**, so `libvirt_volume.disk` (holding the console + API + bootstrap) was never at risk. Verified after: channel present (grep count + 2), domain running, edge still reachable at 10.12.4.1. +- **BUG FOUND ON THE FIRST-EVER LIVE RUN -- `opnsense-plugins.sh apply` had + NEVER installed anything.** `api()` used `bash "$API" ${DRY_RUN:+--dry-run}`: + `${VAR:+word}` expands when VAR is set and NON-EMPTY, and `DRY_RUN=0` is + non-empty -- so every apply silently dry-ran while printing + "OK: profile 'vr1-edge' applied". A textbook false success, and the reason + it survived review is that the harness drove ONLY `--dry-run`, leaving the + live path with zero coverage. FIX tests the VALUE; harness gains two + live-path tests against a stub api client, **verified to FAIL 2/2 on the + buggy version before restoring** (a regression test that cannot fail is + worthless). 20/20. This is exactly the class D-129's own "package present + is not success" warning is about -- here the SCRIPT was the false reporter. +- REAL install then ran: `{"status":"ok","msg_uuid":...}` per plugin (not + dry-run echoes), capture `docs/audit/d129-plugins-20260720.txt` (the + earlier capture of the same name recorded the false dry-run and is + REPLACED). Measured on the edge: `os-qemu-guest-agent-1.3`, + `qemu-guest-agent-11.0.1`, `os-iperf-1.0_2`, `iperf3-3.21`. +- Service was NOT auto-started (the script's own NOTE); started via the + plugin's OWN API (`POST qemuguestagent/service/start` -> `{"response":"OK"}`, + status -> running) rather than by hand-editing rc.conf. +- **GATE MET, to the runbook's exact bar (not package-presence):** + `virsh qemu-agent-command vr1-dc0-opnsense '{"execute":"guest-ping"}'` -> + `{"return":{}}`, and `virsh domifaddr --source agent` reports vtnet0 + 10.12.4.1/22 + vtnet1 172.30.2.2/24. The agent ANSWERS over the channel. +- **SECURITY FINDING (queued for the item-8 hardening review):** the plugin + model exposes `DisabledRPCs`, including **`guest-exec`/`guest-exec-status` + -- arbitrary command execution on the edge from the libvirt host**. On a + commercial multi-tenant cloud the DC edge should almost certainly disable + the exec RPCs (we need guest-ping/fsfreeze/shutdown coordination, not + remote exec). Not changed mid-step; propose with options at the review. +- **Revert:** `POST qemuguestagent/service/stop`; uninstall via + `core/firmware/remove/`; set `expose_qga_channel = false` and re-apply + (in-place domain update again). + ## 8. STAGE-CLOSE QUEUE ITEM (operator directive, 2026-07-20): OPNsense 26.7 review - Operator directive (verbatim intent): at the proper time/place, review the