Patching #
Day 2 maintenance and security updates for substrate hosts.
How patching is done today #
No role or playbook applies updates. A patch is a change, and goes through Change Management like any other: a change record, the update applied to the host, and verification afterwards. How a patch is chosen is Vulnerability Management.
| What | Where it comes from | Procedure |
|---|---|---|
| OS packages, at install | The staged install tree on the artifact server — no internet needed | Build a Management-Hypervisor VM |
| OS packages, after install | Public Fedora mirrors — the host needs internet access | Per change record |
| Proxmox VE (both hypervisors) | Proxmox’s Debian repositories, in place. A major version is only reached through the one before it, following Proxmox’s upgrade path (pve8to9 before 8 → 9) | Per change record; the 8 → 9 move was the Hypervisor Uplift |
| OPNsense (core router) | OPNsense’s firmware updates, in place, one major release after another in order, then make backup-router | Per change record |
| Omada controller | A staged image on the artifact server | Omada Controller Upgrade |
| Switch and AP firmware | Firmware staged on the artifact server | Per change record: CHG-0006 (switch), CHG-0005 (AP) |
What is not covered #
Post-install updates need the internet. There is no local package mirror, so an air-gapped site cannot patch its hosts. The options (accept internet access, a full local mirror at roughly 200 GB per Fedora release, or security updates only) are recorded in the Substrate package mirror candidate. Maintenance windows, patch testing and rollback criteria are routine operations, not roadmap items; knowing when a patch is needed is the Patch Awareness roadmap project.