Remove the TP-Link Omada backend from hydraneck and decommission the physical Omada gear at AD6. The prosumer tier standardized on GL.iNet (#516, closed; first device live at sint-niklaas-tourism-office). AD6 is the only Omada neck. Carried out of #516 Phase C via #533.
omada, see hydraguard omada-venue.md).omada-ad6 entry from /root/.hydraneck/config.yaml. Check for other type: omada entries. Restart the service.ad6/omada-ad6 (DELETE /admin/api/secrets/ad6/omada-ad6). Verify with hydraneck secrets list. Unset any HYDRANECK_SECRET_AD6_OMADA_AD6 env override./root/.hydraneck/bandwidth/ad6.yaml is backend-agnostic and can stay.pkg/omada/ and the case "omada": block plus import in internal/cli/config.go. Remove the omada-only Site config field. Update the comments that name omada.go mod tidy to drop github.com/dougbw/go-omada.config.example.yaml: remove the omada examples.pkg/secrets/store_test.go; update "Omada-class" comments in pkg/store/store.go.make test && make vet, tag, release.runbook.md, neck-lifecycle.md, site-types.md, new-venue.md, mikrotik-rest-migration.md, mesh-participation.md, address-ranges.md, overview.md, partner-network-design.md, secrets-management.md, and CLAUDE.md.docs/runbooks/omada-venue.md and the --guard omada venue type; add a glinet/gateway procedure pointer to hydraneck's glinet.md.The owner confirmed the Omada hardware is physically removed. The software side is now done and verified. Follow-up for the physical and storage leftovers: #611.
hydraneck scan showed omada-ad6 omada prosumer awaiting-credentials (0 clients). cloud-seven live (87 clients), rupelmonde live (4), nbg1-dc live (8), mobile-kit unreachable (no route to 10.10.4.1), sint-niklaas glinet unreachable (10.10.5.1 timeout). The last two were ALREADY unreachable before any change here.
ad6: router block from /root/.hydraneck/config.yaml. Backup at config.yaml.bak-omada-decom-20260831-135818. No other type: omada entries existed.Environment=OMADA_DISABLE_HTTPS_VERIFICATION=true from /etc/systemd/system/hydraneck.service. This was not on the checklist, but it was the last Omada trace in the unit. Unit backed up to /root/hydraneck.service.bak-omada-decom-*. daemon-reload plus restart, service active.ad6/omada-ad6: ALREADY absent. hydraneck secrets list shows only the four live keys. No HYDRANECK_SECRET_AD6_OMADA_AD6 override anywhere./var/lib/docker/containers is empty. Nothing listens on 8043.omada.hydraneck.experiencenet.com: ALREADY gone, does not resolve./root/.hydraneck/scans.yaml self-cleaned on the next scan, as expected. bandwidth/ad6.yaml is backend-agnostic and stays.hydraguard venue remove AD6 then hydraguard apply. mesh.yaml backed up first. The AD6 peer (c142lq62Taj5..., 10.10.1.1/32 plus LAN 10.0.0.0/24) had not handshaked in 25 days, which matches the gear being gone. Live peer count went 32 to 31, exactly one peer.fluffy-dumpling-87 (node-11da9ea3, gallo-romeins body) has LAN IP 10.0.0.223, inside the AD6 LAN range. It is NOT routed through AD6. It is its own mesh peer at 10.10.100.15 and handshakes directly, so removing the AD6 peer was safe. The node stayed online throughout.pkg/omada/, the case "omada" in buildRouter, the omada-only Site field, and the github.com/dougbw/go-omada dependency via go mod tidy. Purged omada from config.example.yaml, CLAUDE.md and eleven runbooks. Renamed the omada fixture keys in pkg/secrets/store_test.go. go vet clean, full test suite passes.omada from the valid guard types in pkg/api/handlers.go and from the venue add --guard help. The guard type carried no behaviour, only a label, so the test fixtures moved to citymesh, which takes the same bare-config path. docs/runbooks/omada-venue.md is retired: the historical text stays behind a DECOMMISSIONED 2026-08-31 banner that points at hydraneck's glinet.md. Added the glinet.md pointer to the gateway guard row in the runbook and in CLAUDE.md.hydraneck scan on v0.16.0 returns exactly the baseline minus the omada row. cloud-seven live (87 clients), rupelmonde live (4), nbg1-dc live (8), mobile-kit and sint-niklaas unreachable exactly as before. The ad6 venue still appears, because it comes from HydraVenues, with no routers, which is correct. cloud-seven and rupelmonde mesh peers still handshake within a minute.
The omada-data and omada-logs docker volumes (about 1.3 GB), /root/omada/docker-compose.yaml, the physical factory reset, and the AD6 replacement decision. All moved to #611.
hydraneck still gets cluster API returned 401 from hydracluster on every venue scan and reports "0 nodes tracked" fleet-wide, because its stored cluster.token predates the admin token rotation. It did not block this work, and the production credential was not touched.