ccnet-wi-fw: provision an OPNsense API key so opnsense-mcp can manage the WI site firewall too #41

New issue

Open

opened 2026-07-24 12:40:38 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-07-24 12:40:38 +00:00

Collaborator

opnsense-mcp currently only covers blaze (the main site's OPNsense) — see docs/homelab-architecture.md's MCP reference. ccnet-wi-fw (the WI site's OPNsense firewall, see docs/ccnet-wi-site.md) has no API key and no MCP/API tooling coverage at all, so any change there today means either the web UI or hand-rolled SSH + raw PHP scripting directly against the OPNsense Model layer.

Hit the real cost of that during issue #24 (Phase 3, 2026-07-24): adding a single firewall pass rule to ccnet-wi-fw required writing a standalone PHP script against \OPNsense\Firewall\Filter (no REST API key existed to use the documented FilterController HTTP endpoint instead). First attempt used the legacy write_config() call, which silently no-ops on Model-layer changes — no error, a plausible-looking "OK" from filter reload, but the actual rule never reached disk. Only caught via an explicit before/after diff of /conf/config.xml against a manual backup, not because anything failed loudly. See the fix in ~/.claude/plans/quiet-mirroring-compass.md's Phase 3 (real finding #5) — the correct call is Config::getInstance()->save().

Scope: create a scoped API user on ccnet-wi-fw (not admin — same pattern as service_onboard.py's OPNsense API user for the main site) and register it as a second opnsense-mcp target/instance, so future changes to this firewall go through the same tested, reviewed API path the main site already has instead of ad-hoc console scripting against a box that's already proven capable of silent, hard-to-detect failures in this exact scripting style.

Related: ccnet-borg-backup's WI offsite-copy work (issue #24), docs/ccnet-wi-site.md, docs/homelab-architecture.md's MCP section.

`opnsense-mcp` currently only covers `blaze` (the main site's OPNsense) — see `docs/homelab-architecture.md`'s MCP reference. `ccnet-wi-fw` (the WI site's OPNsense firewall, see `docs/ccnet-wi-site.md`) has no API key and no MCP/API tooling coverage at all, so any change there today means either the web UI or hand-rolled SSH + raw PHP scripting directly against the OPNsense Model layer. Hit the real cost of that during issue #24 (Phase 3, 2026-07-24): adding a single firewall pass rule to `ccnet-wi-fw` required writing a standalone PHP script against `\OPNsense\Firewall\Filter` (no REST API key existed to use the documented `FilterController` HTTP endpoint instead). First attempt used the legacy `write_config()` call, which **silently no-ops on Model-layer changes** — no error, a plausible-looking "OK" from `filter reload`, but the actual rule never reached disk. Only caught via an explicit before/after `diff` of `/conf/config.xml` against a manual backup, not because anything failed loudly. See the fix in `~/.claude/plans/quiet-mirroring-compass.md`'s Phase 3 (real finding #5) — the correct call is `Config::getInstance()->save()`. Scope: create a scoped API user on `ccnet-wi-fw` (not `admin` — same pattern as `service_onboard.py`'s OPNsense API user for the main site) and register it as a second `opnsense-mcp` target/instance, so future changes to this firewall go through the same tested, reviewed API path the main site already has instead of ad-hoc console scripting against a box that's already proven capable of silent, hard-to-detect failures in this exact scripting style. Related: `ccnet-borg-backup`'s WI offsite-copy work (issue #24), `docs/ccnet-wi-site.md`, `docs/homelab-architecture.md`'s MCP section.

claude-bot added the

infra

p:medium

labels

2026-07-24 12:40:56 +00:00

claude-bot referenced this issue

2026-07-25 14:15:29 +00:00

ccnet-WI: add a borg backup target on the QNAP alongside the PBS replica #24