Stage 1 base config/hardening toolset, applied and verified on pve1

Splits the repo into Stage 1 (base host config/hardening, applies to any
node) and Stage 2 (future HA/Ceph cluster, deferred - pve1's mini-PC
hardware can't support the assumed split-disk/multi-NIC layout).

Adds the Stage 1 toolset: firewall deploy, named admin user creation,
unattended security upgrades, subscription-nag removal (with an apt hook
so the patch survives package updates), and a read-only audit script.
Fixes switch-to-no-subscription-repo.sh, which only handled the legacy
.list format and silently no-op'd against PVE 9's deb822 .sources files;
it now removes enterprise sources outright rather than commenting them
out. Shared logic (root check, idempotent file writes, backups) factored
into scripts/lib/common.sh.

Ran the full sequence against pve1 via scripts/bootstrap.sh +
create-admin-user.sh; scripts/audit.sh confirms all checks pass.

docs/00-overview.md

@@ -1,18 +1,65 @@
 # Overview & Roadmap
 
+## Staging
+
+This repo now targets two distinct stages, in order:
+
+- **Stage 1 (active)** — base configuration and hardening for a single
+  Proxmox host, applicable to *any* node regardless of eventual cluster
+  plans: repo/updates, SSH, firewall, PVE user/access hardening. This is
+  what `scripts/bootstrap.sh`, `scripts/audit.sh`, and
+  `04-security-hardening.md` cover, and what's being built out against
+  node 1 (`pve1`, an ASUS PN53 mini PC) right now.
+- **Stage 2 (future)** — the multi-node HA/Ceph cluster described below
+  and in `01-hardware-node1.md` / `02-storage-zfs-ceph.md` /
+  `03-networking.md`. Deliberately deferred: `pve1`'s hardware (2 NVMe
+  already merged into one ZFS mirror used for both boot and VM storage, a
+  single 2.5GbE NIC) can't support the separate boot/Ceph disks or
+  bonded/segregated networking those docs assume. Revisit once dedicated
+  cluster hardware (nodes 2/3) is actually being bought and provisioned;
+  until then treat the content below as a target design, not a
+  description of `pve1`.
+
 ## Background
 
-Current hardware requires disabling KVM hardware virtualization for VMs to
+Old hardware required disabling KVM hardware virtualization for VMs to
 start at all (falls back to software emulation — slow). This is a
-host/BIOS-level issue, not a Proxmox limitation, and shouldn't be needed on
-new hardware. Before reusing that workaround on the new box:
+host/BIOS-level issue, not a Proxmox limitation. Confirmed not present on
+`pve1` (ASUS PN53, Ryzen 7 7735HS): AMD-V and IOMMU both show enabled at
+boot (`dmesg | grep -i iommu`), no workaround needed. If this hardware line
+is reused for nodes 2/3, this should hold there too, but re-verify per
+node before assuming it.
 
-- Confirm VT-x (Intel) / AMD-V (AMD) is enabled in BIOS/UEFI.
-- Confirm IOMMU is enabled if passthrough is planned.
-- Update BIOS/microcode first.
-- Rule out running Proxmox nested inside another hypervisor.
+## Stage 1: base config & hardening (active)
 
-## End goal
+Applies to `pve1` now, and to every future node regardless of whether it
+ever joins the Stage 2 cluster. Covered by `04-security-hardening.md` and
+`scripts/bootstrap.sh` / `scripts/audit.sh`:
+
+1. Fresh PVE install; confirm VT-x/AMD-V + IOMMU per the note above.
+2. Switch off the enterprise repos, onto no-subscription
+   (`scripts/switch-to-no-subscription-repo.sh`).
+3. SSH hardening: key-only root login + fail2ban
+   (`scripts/harden-ssh.sh`).
+4. Unattended security upgrades, no auto-reboot
+   (`scripts/setup-unattended-upgrades.sh`).
+5. PVE datacenter firewall, default-deny, mgmt-only SSH/8006
+   (`scripts/deploy-firewall.sh`).
+6. Named PVE admin user (Administrator role) + 2FA, `root@pam` reserved
+   for emergencies (`scripts/create-admin-user.sh`, then manual TOTP
+   enrollment via the web UI).
+7. Verify with `scripts/audit.sh`.
+
+`pve1`'s actual disk/network layout (single ZFS mirror for boot + VMs, one
+2.5GbE NIC) is documented as-is in `01-hardware-node1.md` — Stage 1 doesn't
+require or assume the split-disk/multi-NIC layout Stage 2 wants.
+
+## Stage 2: HA cluster + Ceph (future, deferred)
+
+Everything below this point is the target design for when nodes 2 and 3
+are actually being provisioned. Not applicable to `pve1` as it stands.
+
+### End goal
 
 3-node Proxmox VE cluster with HA-managed VMs backed by **Ceph** — true
 distributed shared storage, sync replication, near-zero RPO on failover
@@ -25,7 +72,7 @@ goes live — as soon as nodes 2/3 join, VMs move onto Ceph rather than
 adopting ZFS replication as a stopgap. Simpler end state, one storage
 model to operate instead of two.
 
-## Cluster fundamentals (apply from node 1 onward)
+### Cluster fundamentals (apply from node 1 onward)
 
 - 3 nodes minimum for real quorum. If starting with 2, add a QDevice
   (small VM or Raspberry Pi) as tie-breaker.
@@ -38,16 +85,19 @@ model to operate instead of two.
   rather than `host` if nodes will ever have different CPUs — needed for
   clean live migration.
 
-## Rollout sequence
+### Rollout sequence (Stage 2, once dedicated cluster hardware exists)
 
-1. Build node 1 per `01-hardware-node1.md` — fresh PVE install on ZFS boot
-   mirror, Ceph-earmarked disks left idle (or as a temporary local ZFS
-   pool, to be wiped later — see `02-storage-zfs-ceph.md`).
-2. Migrate VMs off old hardware via `vzdump` → copy backups → `qmrestore`
-   onto the new ZFS storage (converts disks to ZVOLs). No HA yet — single
-   node.
-3. Apply hardening (`04-security-hardening.md`) and networking
-   (`03-networking.md`) before exposing the node beyond the LAN.
+1. Build node 1 per `01-hardware-node1.md`'s target design — fresh PVE
+   install on a dedicated ZFS boot mirror, Ceph-earmarked disks left idle
+   (or as a temporary local ZFS pool, to be wiped later — see
+   `02-storage-zfs-ceph.md`). Note: this assumes hardware with enough
+   disks/NICs to separate boot, Ceph, and network roles — `pve1` does not
+   have this and stays on Stage 1 only unless rebuilt on different
+   hardware.
+2. Migrate VMs onto the new node via `vzdump` → copy backups →
+   `qmrestore` (converts disks to ZVOLs). No HA yet — single node.
+3. Stage 1 base hardening already applied; layer on Stage 2 networking
+   (`03-networking.md`) before joining a cluster.
 4. Add nodes 2 and 3 identically (same disk/network layout).
 5. Join cluster, stand up dedicated corosync network.
 6. Wipe the Ceph-earmarked disks (if used as temporary ZFS) and