HydraIssues

Issues / #611
Omada decommission leftovers: factory reset the gear and reclaim the controller storage
open improvement Project: hydraneck Parent: #535 Reporter: cederik 31 Aug 2026 14:24

Description

Goal

Finish the physical and storage leftovers from the Omada decommission (#535, closed 2026-08-31). The software side is done: the omada router backend, the omada guard type, the live config entry, the mesh peer and the docs are all gone. What remains needs either physical access or an explicit delete-the-data decision.

Leftovers

  • Factory-reset the TP-Link Omada gear before disposal. It still holds the AD6 WireGuard private key and the admin password. The key is already useless, because the AD6 peer was removed from the hydraguard hub on 2026-08-31, but the gear must not leave the building with credentials on it. Physical task.
  • Reclaim the Omada controller storage on the hydraneck server (node-7662c033, 46.225.8.28). The container was stopped and removed on 2026-08-07 and the docker daemon is now disabled and inactive, but about 1.3 GB stays under /var/lib/docker in the omada-data and omada-logs named volumes. These hold the controller database. Deleting them cannot be undone, so #535 left them alone. Decide whether anything in that database is worth exporting, then docker volume rm omada-data omada-logs, prune the images, and remove /root/omada/docker-compose.yaml.
  • Decide whether docker stays installed on the hydraneck server. The Omada controller was its only workload. Nothing else on the box uses docker. If nothing is planned, remove the packages and drop the daemon.
  • AD6 venue posture. The gear is gone and no replacement is configured, so AD6 is pure-consumer today by default. Decide whether it gets a GL.iNet Slate 7 Pro like sint-niklaas-tourism-office, or stays with no router API. This is a purchase decision, not cleanup. The ad6 venue still exists in HydraVenues and shows in hydraneck scan with no routers, which is correct for a pure-consumer site.

Not in scope

The cluster API returned 401 warning on every hydraneck venue scan is a separate problem. The stored cluster.token in /root/.hydraneck/config.yaml predates the admin token rotation, so hydraneck reports "0 nodes tracked" fleet-wide.