CHG-0003: Host Rename (ADR-0008) #

**Retrospective change record.** This was rebuilt from the runbook page that tracked the rename as it ran (marked done on 2026-09-08), and from the commits and pull requests across the seven repos it touched. Times are local (UTC−4), from commit timestamps.

Summary #

The migration that brought the estate onto the naming scheme in ADR-0008: fixed-width hostnames (dv02hyp001p01), site codes, and the home / mobile DNS zones. The site inventories were renamed with it, from dvnt/ and dvntm/ to home/ and mobile/. The ADR was proposed on 2026-09-04 and accepted as the first step of the change.

Goal #

The end state that counts as done:

• Every host carries its ADR-0008 name everywhere: in inventory, DNS, DHCP and its OS hostname, on appliances, and — for hypervisors — as the Proxmox node name.
• The site zones are home.deevnet.net and mobile.deevnet.net, and the inventories are home/ and mobile/.
• The home site has its identity declared.
• DNS and DHCP carry only declared names, with no stale records left behind by the rename.

Scope #

All hosts in the mobile inventory, both site inventories, the DNS zones, and every repo that names a host, a site or a zone. The home site had no hosts to rename.

Risk and impact #

Procedure #

Least risky first; each phase landed on its own and was verified before the next began.

Phase 13 came last deliberately: the Proxmox node name is the one identifier with no supported rename, so it waited until the estate around it was already consistent. It followed Rename a Proxmox Node:

What Phase 4 fixed #

The rename could not be done safely until three shared-role defects were dealt with. All three are resolved; they are recorded here because the reasoning still applies to the roles.

• opnsense_dns had no delete task. The dns_delete_unmanaged step its own header described was never implemented, so renaming 17 hosts would have left 17 stale A records resolving to the same addresses, with ambiguous PTRs behind them. It is implemented now and gates both delete tasks — and it is the precedent opnsense_firewall lacked at the time.
• DHCP reconciles on MAC, which a rename does not change, so reservations updated in place with no duplicates and no orphans. dnsmasq is a whole-file template and GRUB configs are keyed by MAC, so both regenerated cleanly.
• The inventory directory rename had no runtime effect. Nothing on a running host reads the inventory path, so it was a git mv and six line edits.

Verification #

Each phase was verified before the next began. The checks used are not recorded, except for phase 13, whose verification is in Rename a Proxmox Node.

Undo #

Phases 2–3 were reversible with a git revert. Phase 8 was the first change a user could notice. Phase 13 has its own rollback in Rename a Proxmox Node. No undo is recorded for the other phases.

Outcome #

The rename completed in one morning. Phases 1–13 landed between 08:41 and 13:14, and the last related change, turning off Unbound’s self-registration, at 13:55. The runbook recorded it done on 2026-09-08.

Departures from the plan #

• Phase 10 landed out of order, and only in part. The switch took its new name at 13:14, after phase 13. OPNsense, the AP and the travel router still carry their old names, because each can only be set through its own web UI and no role sets a device’s own hostname.
• Three stale DHCP reservations were removed by hand: vyos-rt01 from the pre-migration flat network, provisioner-vm05, and the VyOS host as it left. The DHCP role pruned only hosts still in inventory, not hosts deleted from it. That gap was closed at 10:59 (net 13490c0).
• VyOS was dropped during the change (10:41–10:53: inventory dd58fbb, builder d749b26, net 5a0d781). This was not one of the thirteen phases; OPNsense is the committed perimeter.
• Unbound’s self-registration was turned off in code but not applied. Net PR #15 merged at 18:15. Applying it while clients still search deevnet.net breaks short-name resolution estate-wide, so it waits on net #14.

Follow-ups #