From a6a419bad7aa1bb2d01f77dfe1a0756dd71be1ad Mon Sep 17 00:00:00 2001
From: beatzaplenty <wayne.bennett@live.com>
Date: Fri, 24 Jul 2026 06:22:31 +1000
Subject: [PATCH] updated structure

---
 .../.gitea/workflows/secret-scan.yml          |   28 +
 .../.github/workflows/secret-scan.yml         |   28 +
 .../debian-restructure/.gitleaks.toml         |   41 +
 .../debian-restructure/pihole/apply-config.sh |   60 +
 .../config/dnsmasq.d/99-ipxe-chainload.conf   |   20 +
 .../pihole/config/pihole.toml                 | 1767 +++++++++++++++++
 .../debian-restructure/pihole/pull-config.sh  |   51 +
 .../pihole/sanitize-config.sh                 |   40 +
 .../debian-restructure/proxmox/.gitignore     |    2 +
 .../debian-restructure/proxmox/CLAUDE.md      |   84 +
 .../debian-restructure/proxmox/README.md      |   55 +
 .../config/pve-firewall/cluster.fw.example    |   44 +
 .../proxmox/docs/00-overview.md               |  116 ++
 .../proxmox/docs/01-hardware-node1.md         |   92 +
 .../proxmox/docs/02-storage-zfs-ceph.md       |   66 +
 .../proxmox/docs/03-networking.md             |   66 +
 .../proxmox/docs/04-security-hardening.md     |  112 ++
 .../proxmox/docs/05-node-roles.md             |   83 +
 .../proxmox/docs/06-pve-test-wifi-network.md  |  191 ++
 .../proxmox/scripts/audit.sh                  |  133 ++
 .../proxmox/scripts/bootstrap.sh              |   67 +
 .../proxmox/scripts/create-admin-user.sh      |   43 +
 .../proxmox/scripts/deploy-firewall.sh        |   48 +
 .../scripts/disable-subscription-nag.sh       |   24 +
 .../proxmox/scripts/harden-ssh.sh             |   43 +
 .../proxmox/scripts/lib/common.sh             |   47 +
 .../proxmox/scripts/lib/nag-patch.sh          |   22 +
 .../proxmox/scripts/setup-admin-sudo.sh       |   61 +
 .../proxmox/scripts/setup-linux-admin-user.sh |   82 +
 .../scripts/setup-unattended-upgrades.sh      |   46 +
 .../scripts/setup-wifi-bond-network.sh        |  133 ++
 .../scripts/switch-to-no-subscription-repo.sh |   42 +
 .../scripts/check-secrets.sh                  |   80 +
 .../scripts/install-hooks.sh                  |   17 +
 34 files changed, 3834 insertions(+)
 create mode 100644 .claude/worktrees/debian-restructure/.gitea/workflows/secret-scan.yml
 create mode 100644 .claude/worktrees/debian-restructure/.github/workflows/secret-scan.yml
 create mode 100644 .claude/worktrees/debian-restructure/.gitleaks.toml
 create mode 100755 .claude/worktrees/debian-restructure/pihole/apply-config.sh
 create mode 100644 .claude/worktrees/debian-restructure/pihole/config/dnsmasq.d/99-ipxe-chainload.conf
 create mode 100644 .claude/worktrees/debian-restructure/pihole/config/pihole.toml
 create mode 100755 .claude/worktrees/debian-restructure/pihole/pull-config.sh
 create mode 100755 .claude/worktrees/debian-restructure/pihole/sanitize-config.sh
 create mode 100644 .claude/worktrees/debian-restructure/proxmox/.gitignore
 create mode 100644 .claude/worktrees/debian-restructure/proxmox/CLAUDE.md
 create mode 100644 .claude/worktrees/debian-restructure/proxmox/README.md
 create mode 100644 .claude/worktrees/debian-restructure/proxmox/config/pve-firewall/cluster.fw.example
 create mode 100644 .claude/worktrees/debian-restructure/proxmox/docs/00-overview.md
 create mode 100644 .claude/worktrees/debian-restructure/proxmox/docs/01-hardware-node1.md
 create mode 100644 .claude/worktrees/debian-restructure/proxmox/docs/02-storage-zfs-ceph.md
 create mode 100644 .claude/worktrees/debian-restructure/proxmox/docs/03-networking.md
 create mode 100644 .claude/worktrees/debian-restructure/proxmox/docs/04-security-hardening.md
 create mode 100644 .claude/worktrees/debian-restructure/proxmox/docs/05-node-roles.md
 create mode 100644 .claude/worktrees/debian-restructure/proxmox/docs/06-pve-test-wifi-network.md
 create mode 100755 .claude/worktrees/debian-restructure/proxmox/scripts/audit.sh
 create mode 100755 .claude/worktrees/debian-restructure/proxmox/scripts/bootstrap.sh
 create mode 100755 .claude/worktrees/debian-restructure/proxmox/scripts/create-admin-user.sh
 create mode 100755 .claude/worktrees/debian-restructure/proxmox/scripts/deploy-firewall.sh
 create mode 100755 .claude/worktrees/debian-restructure/proxmox/scripts/disable-subscription-nag.sh
 create mode 100755 .claude/worktrees/debian-restructure/proxmox/scripts/harden-ssh.sh
 create mode 100755 .claude/worktrees/debian-restructure/proxmox/scripts/lib/common.sh
 create mode 100755 .claude/worktrees/debian-restructure/proxmox/scripts/lib/nag-patch.sh
 create mode 100755 .claude/worktrees/debian-restructure/proxmox/scripts/setup-admin-sudo.sh
 create mode 100755 .claude/worktrees/debian-restructure/proxmox/scripts/setup-linux-admin-user.sh
 create mode 100755 .claude/worktrees/debian-restructure/proxmox/scripts/setup-unattended-upgrades.sh
 create mode 100755 .claude/worktrees/debian-restructure/proxmox/scripts/setup-wifi-bond-network.sh
 create mode 100755 .claude/worktrees/debian-restructure/proxmox/scripts/switch-to-no-subscription-repo.sh
 create mode 100755 .claude/worktrees/debian-restructure/scripts/check-secrets.sh
 create mode 100755 .claude/worktrees/debian-restructure/scripts/install-hooks.sh

diff --git a/.claude/worktrees/debian-restructure/.gitea/workflows/secret-scan.yml b/.claude/worktrees/debian-restructure/.gitea/workflows/secret-scan.yml
new file mode 100644
index 0000000..8aae27d
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/.gitea/workflows/secret-scan.yml
@@ -0,0 +1,28 @@
+name: Secret Scan
+
+on:
+  push:
+    branches: ["**"]
+  pull_request:
+    branches: ["**"]
+
+jobs:
+  secret-scan:
+    name: Scan for secrets and sensitive config
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0   # full history for gitleaks git-log scan
+
+      - name: Install gitleaks
+        run: |
+          GITLEAKS_VERSION="8.21.2"
+          curl -sSL "https://github.com/gitleaks/gitleaks/releases/download/v${GITLEAKS_VERSION}/gitleaks_${GITLEAKS_VERSION}_linux_x64.tar.gz" \
+            | tar -xz -C /usr/local/bin gitleaks
+          gitleaks version
+
+      - name: Run secret scan
+        run: bash scripts/check-secrets.sh
diff --git a/.claude/worktrees/debian-restructure/.github/workflows/secret-scan.yml b/.claude/worktrees/debian-restructure/.github/workflows/secret-scan.yml
new file mode 100644
index 0000000..8aae27d
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/.github/workflows/secret-scan.yml
@@ -0,0 +1,28 @@
+name: Secret Scan
+
+on:
+  push:
+    branches: ["**"]
+  pull_request:
+    branches: ["**"]
+
+jobs:
+  secret-scan:
+    name: Scan for secrets and sensitive config
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0   # full history for gitleaks git-log scan
+
+      - name: Install gitleaks
+        run: |
+          GITLEAKS_VERSION="8.21.2"
+          curl -sSL "https://github.com/gitleaks/gitleaks/releases/download/v${GITLEAKS_VERSION}/gitleaks_${GITLEAKS_VERSION}_linux_x64.tar.gz" \
+            | tar -xz -C /usr/local/bin gitleaks
+          gitleaks version
+
+      - name: Run secret scan
+        run: bash scripts/check-secrets.sh
diff --git a/.claude/worktrees/debian-restructure/.gitleaks.toml b/.claude/worktrees/debian-restructure/.gitleaks.toml
new file mode 100644
index 0000000..2bc8a26
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/.gitleaks.toml
@@ -0,0 +1,41 @@
+# Gitleaks configuration for debian-configuration repo.
+# Extends the default ruleset with Pi-hole-specific secret patterns.
+# https://github.com/gitleaks/gitleaks
+
+title = "debian-configuration secret scan"
+
+[extend]
+  useDefault = true
+
+# ── Custom rules ───────────────────────────────────────────────────────────────
+
+[[rules]]
+  id          = "pihole-pwhash"
+  description = "Pi-hole password hash (pihole.toml webserver.api.pwhash)"
+  regex       = '''pwhash\s*=\s*"[^"]{10,}"'''
+  tags        = ["pihole", "password"]
+
+[[rules]]
+  id          = "pihole-totp-secret"
+  description = "Pi-hole 2FA TOTP secret"
+  regex       = '''totp_secret\s*=\s*"[^"]{10,}"'''
+  tags        = ["pihole", "2fa"]
+
+[[rules]]
+  id          = "pihole-app-pwhash"
+  description = "Pi-hole app password hash"
+  regex       = '''app_pwhash\s*=\s*"[^"]{10,}"'''
+  tags        = ["pihole", "password"]
+
+# ── Allowlist ──────────────────────────────────────────────────────────────────
+
+[allowlist]
+  description = "Known-safe patterns in this repo"
+  regexes     = [
+    # TLS cert path reference — not the key itself
+    '''cert\s*=\s*"/etc/pihole/tls\.pem"''',
+  ]
+  paths       = [
+    # Example/template files are intentionally non-live
+    '''\.example$''',
+  ]
diff --git a/.claude/worktrees/debian-restructure/pihole/apply-config.sh b/.claude/worktrees/debian-restructure/pihole/apply-config.sh
new file mode 100755
index 0000000..97f5a83
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/pihole/apply-config.sh
@@ -0,0 +1,60 @@
+#!/usr/bin/env bash
+# Apply a Pi-hole configuration directory to a destination Pi-hole instance.
+#
+# Usage: apply-config.sh <source-dir> <dest-host>
+#   source-dir   Local directory containing config files (as written by pull-config.sh)
+#   dest-host    SSH-reachable hostname or IP of the destination Pi-hole
+#
+# Example:
+#   ./apply-config.sh ./config root@pihole-new
+#   ./apply-config.sh /backup/pihole-20260723 root@192.168.2.101
+#
+# The destination Pi-hole must already have Pi-hole v6 installed.
+# pihole-FTL is restarted at the end to apply the new config.
+
+set -euo pipefail
+
+usage() {
+  echo "Usage: $(basename "$0") <source-dir> <dest-host>" >&2
+  echo "  source-dir   Local directory with config files (from pull-config.sh)" >&2
+  echo "  dest-host    SSH target for the destination Pi-hole (e.g. root@pihole)" >&2
+  exit 1
+}
+
+[[ $# -eq 2 ]] || usage
+
+SOURCE="$1"
+DEST="$2"
+
+[[ -d "${SOURCE}" ]] || { echo "Error: source directory '${SOURCE}' not found" >&2; exit 1; }
+[[ -f "${SOURCE}/pihole.toml" ]] || { echo "Error: '${SOURCE}/pihole.toml' not found — is this a valid config dir?" >&2; exit 1; }
+
+echo "Applying Pi-hole config from ${SOURCE} → ${DEST}"
+
+# ── Verify destination is running Pi-hole ──────────────────────────────────────
+ssh "${DEST}" "command -v pihole-FTL >/dev/null 2>&1 || { echo 'pihole-FTL not found on destination'; exit 1; }"
+
+# ── pihole.toml ────────────────────────────────────────────────────────────────
+echo "  pihole.toml"
+ssh "${DEST}" "cp /etc/pihole/pihole.toml /etc/pihole/pihole.toml.pre-apply 2>/dev/null || true"
+scp "${SOURCE}/pihole.toml" "${DEST}:/etc/pihole/pihole.toml"
+ssh "${DEST}" "chown pihole:pihole /etc/pihole/pihole.toml; chmod 640 /etc/pihole/pihole.toml"
+
+# ── custom dnsmasq drop-ins ────────────────────────────────────────────────────
+if [[ -d "${SOURCE}/dnsmasq.d" ]] && [[ -n "$(ls "${SOURCE}/dnsmasq.d/"*.conf 2>/dev/null)" ]]; then
+  echo "  dnsmasq.d/ (custom drop-ins)"
+  for f in "${SOURCE}/dnsmasq.d/"*.conf; do
+    name="$(basename "$f")"
+    echo "    ${name}"
+    scp "${f}" "${DEST}:/etc/dnsmasq.d/${name}"
+  done
+fi
+
+# ── Restart pihole-FTL ─────────────────────────────────────────────────────────
+echo "  Restarting pihole-FTL"
+ssh "${DEST}" "systemctl restart pihole-FTL"
+sleep 2
+ssh "${DEST}" "systemctl is-active pihole-FTL"
+
+echo "Done. Config applied to ${DEST}."
+echo "Note: gravity (blocklists) is not transferred — run 'pihole updateGravity' on ${DEST} to rebuild."
diff --git a/.claude/worktrees/debian-restructure/pihole/config/dnsmasq.d/99-ipxe-chainload.conf b/.claude/worktrees/debian-restructure/pihole/config/dnsmasq.d/99-ipxe-chainload.conf
new file mode 100644
index 0000000..f9e9eda
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/pihole/config/dnsmasq.d/99-ipxe-chainload.conf
@@ -0,0 +1,20 @@
+# Detect iPXE clients (already running iPXE).
+dhcp-match=set:ipxe,175
+dhcp-userclass=set:ipxe,iPXE
+
+# Detect UEFI x86_64 clients by client architecture.
+dhcp-match=set:efi64,option:client-arch,7
+dhcp-match=set:efi64,option:client-arch,9
+
+# Boot file selection — more positive tags = higher priority.
+# EFI iPXE (2 tags): already running iPXE on EFI, chain to HTTP menu.
+dhcp-boot=tag:ipxe,tag:efi64,http://192.168.2.247/boot.ipxe
+
+# BIOS iPXE (1 tag): already running iPXE, chain to HTTP menu.
+dhcp-boot=tag:ipxe,http://192.168.2.247/boot.ipxe
+
+# EFI non-iPXE (1 tag): send the EFI iPXE binary.
+dhcp-boot=tag:efi64,ipxe.efi,,192.168.2.247
+
+# BIOS/legacy fallback (0 tags): send the BIOS iPXE binary.
+dhcp-boot=undionly.kpxe,,192.168.2.247
diff --git a/.claude/worktrees/debian-restructure/pihole/config/pihole.toml b/.claude/worktrees/debian-restructure/pihole/config/pihole.toml
new file mode 100644
index 0000000..1dd17f1
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/pihole/config/pihole.toml
@@ -0,0 +1,1767 @@
+# Pi-hole configuration file (v6.7)
+# Encoding: UTF-8
+# This file is managed by pihole-FTL
+# Last updated on 2026-07-23 02:11:01 UTC
+
+[dns]
+  # Upstream DNS Servers to be used by Pi-hole. If this is not set, Pi-hole will not
+  # resolve any non-local queries.
+  #
+  # Example: [ "8.8.8.8", "127.0.0.1#5335", "docker-resolver" ]
+  #
+  # Allowed values are:
+  #     Array of IP addresses and/or hostnames, optionally with a port (#...)
+  upstreams = [
+    "45.90.28.142",
+    "45.90.30.142"
+  ] ### CHANGED, default = []
+
+  # Use this option to control deep CNAME inspection. Disabling it might be beneficial
+  # for very low-end devices
+  #
+  # Allowed values are:
+  #     true or false
+  CNAMEdeepInspect = true
+
+  # Should _esni. subdomains of blocked domains also be blocked by default? Encrypted
+  # Server Name Indication (ESNI) is certainly a good step into the right direction to
+  # enhance privacy on the web. It prevents on-path observers, including ISPs, coffee
+  # shop owners and firewalls, from intercepting the TLS Server Name Indication (SNI)
+  # extension by encrypting it. This prevents the SNI from being used to determine which
+  # websites users are visiting.
+  #
+  # ESNI will obviously cause issues for pixelserv-tls which will be unable to generate
+  # matching certificates on-the-fly when it cannot read the SNI. According to the IETF
+  # draft (link above), we can easily restore pixelserv-tls's operation by replying
+  # NXDOMAIN to _esni. subdomains of blocked domains as this mimics a "not configured
+  # for this domain" behavior.
+  #
+  # ESNI is mostly obsolete. It was previously rolled out by Cloudflare and Firefox, but
+  # they, as well as almost every client and server, are now using Encrypted Client
+  # Hello (ECH) instead of ESNI. ECH is served via the HTTPS record on the same RRname,
+  # so it will automatically be blocked.
+  #
+  # Allowed values are:
+  #     true or false
+  blockESNI = true
+
+  # Should we overwrite the query source when client information is provided through
+  # EDNS0 client subnet (ECS) information? This allows Pi-hole to obtain client IPs even
+  # if they are hidden behind the NAT of a router. This feature has been requested and
+  # discussed on Discourse where further information how to use it can be found:
+  # https://discourse.pi-hole.net/t/support-for-add-subnet-option-from-dnsmasq-ecs-edns0-client-subnet/35940
+  #
+  # Allowed values are:
+  #     true or false
+  EDNS0ECS = true
+
+  # Should FTL hide queries made by localhost?
+  #
+  # Allowed values are:
+  #     true or false
+  ignoreLocalhost = false
+
+  # Should FTL analyze and show internally generated DNSSEC queries?
+  #
+  # Allowed values are:
+  #     true or false
+  showDNSSEC = true
+
+  # Should FTL analyze *only* A and AAAA queries?
+  #
+  # Allowed values are:
+  #     true or false
+  analyzeOnlyAandAAAA = false
+
+  # Controls whether and how FTL will reply with for address for which a local interface
+  # exists. Changing this setting causes FTL to restart.
+  #
+  # Allowed values are:
+  #   - "NONE"
+  #       Pi-hole will not respond automatically on PTR requests to local interface
+  #       addresses. Ensure pi.hole and/or hostname records exist elsewhere.
+  #   - "HOSTNAME"
+  #       Serve the machine's hostname. The hostname is queried from the kernel through
+  #       uname(2)->nodename. If the machine has multiple network interfaces, it can
+  #       also have multiple nodenames. In this case, it is unspecified and up to the
+  #       kernel which one will be returned. On Linux, the returned string is what has
+  #       been set using sethostname(2) which is typically what has been set in
+  #       /etc/hostname.
+  #   - "HOSTNAMEFQDN"
+  #       Serve the machine's hostname (see limitations above) as fully qualified domain
+  #       by adding the local domain. If no local domain has been defined (config option
+  #       dns.domain.name), FTL tries to query the domain name from the kernel using
+  #       getdomainname(2). If this fails, FTL appends ".no_fqdn_available" to the
+  #       hostname.
+  #   - "PI.HOLE"
+  #       Respond with "pi.hole".
+  piholePTR = "HOSTNAME" ### CHANGED, default = "PI.HOLE"
+
+  # How should FTL handle queries when the gravity database is not available?
+  #
+  # Allowed values are:
+  #   - "BLOCK"
+  #       Block all queries when the database is busy.
+  #   - "ALLOW"
+  #       Allow all queries when the database is busy.
+  #   - "REFUSE"
+  #       Refuse all queries which arrive while the database is busy.
+  #   - "DROP"
+  #       Just drop the queries, i.e., never reply to them at all. Despite "REFUSE"
+  #       sounding similar to "DROP", it turned out that many clients will just
+  #       immediately retry, causing up to several thousands of queries per second. This
+  #       does not happen in "DROP" mode.
+  replyWhenBusy = "ALLOW"
+
+  # FTL's internal TTL to be handed out for blocked queries in seconds. This settings
+  # allows users to select a value different from the dnsmasq config option local-ttl.
+  # This is useful in context of locally used hostnames that are known to stay constant
+  # over long times (printers, etc.).
+  #
+  # Note that large values may render whitelisting ineffective due to client-side
+  # caching of blocked queries.
+  #
+  # Allowed values are:
+  #     A positive integer value in seconds
+  blockTTL = 2
+
+  # Array of custom DNS records
+  #
+  # Example: [ "127.0.0.1 mylocal", "192.168.0.1 therouter" ]
+  #
+  # Allowed values are:
+  #     Array of custom DNS records each one in HOSTS form: "IP HOSTNAME [HOSTNAME ...]"
+  hosts = [
+    "192.168.2.253 pihole",
+    "192.168.2.254 router",
+    "192.168.2.252 server",
+    "192.168.2.250 win11",
+    "192.168.2.249 docker",
+    "192.168.2.108 pbs",
+    "192.168.2.108 pbs.sweet.home",
+    "192.168.2.250 pve1",
+    "192.168.2.250 pve1.sweet.home",
+    "192.168.2.248 pdm",
+    "192.168.2.248 pdm.sweet.home",
+    "192.168.2.251 pve-test",
+    "192.168.2.251 pve-test.sweet.home"
+  ] ### CHANGED, default = []
+
+  # If set, queries for plain names, without dots or domain parts, are never forwarded to
+  # upstream nameservers
+  #
+  # Allowed values are:
+  #     true or false
+  domainNeeded = false
+
+  # If set, the domain is added to simple names (without a period) in /etc/hosts in the
+  # same way as for DHCP-derived names
+  #
+  # Allowed values are:
+  #     true or false
+  expandHosts = false
+
+  # Should all reverse lookups for private IP ranges (i.e., 192.168.x.y, etc) which are
+  # not found in /etc/hosts or the DHCP leases file be answered with "no such domain"
+  # rather than being forwarded upstream?
+  #
+  # Allowed values are:
+  #     true or false
+  bogusPriv = true
+
+  # Validate DNS replies using DNSSEC?
+  #
+  # Allowed values are:
+  #     true or false
+  dnssec = false
+
+  # Interface to use for DNS (see also dns.listeningMode) and DHCP (if enabled). Leave
+  # empty for auto-detection.
+  #
+  # Allowed values are:
+  #     a valid interface name
+  interface = "eth0" ### CHANGED, default = ""
+
+  # Add an A, AAAA and PTR record to the DNS. This adds a singular name to the DNS with
+  # associated IPv4 (A) and IPv6 (AAAA) records
+  #
+  # Example: "laptop,laptop.lan,192.168.0.1,1234::100"
+  #
+  # Allowed values are:
+  #     A string in the format
+  #     "<name>[,<name>....],[<IPv4-address>],[<IPv6-address>][,<TTL>]"
+  hostRecord = ""
+
+  # Pi-hole interface listening modes
+  #
+  # Allowed values are:
+  #   - "LOCAL"
+  #       Allow only local requests. This setting accepts DNS queries only from hosts
+  #       whose address is on a local subnet, i.e., a subnet for which an interface
+  #       exists on the server. It is intended to be set as a default on installation,
+  #       to allow unconfigured installations to be useful but also safe from being used
+  #       for DNS amplification attacks if (accidentally) running public.
+  #   - "SINGLE"
+  #       Permit all origins, accept only on the specified interface. Respond only to
+  #       queries arriving on the specified interface. The loopback (lo) interface is
+  #       automatically added to the list of interfaces to use when this option is used.
+  #       Make sure your Pi-hole is properly firewalled!
+  #   - "BIND"
+  #       By default, FTL binds the wildcard address. If this is not what you want, you
+  #       can use this option as it forces FTL to really bind only the interfaces it is
+  #       listening on. Note that this may result in issues when the interface may go
+  #       down (cable unplugged, etc.). About the only time when this is useful is when
+  #       running another nameserver on the same port on the same machine. This may also
+  #       happen if you run a virtualization API such as libvirt. When this option is
+  #       used, IP alias interface labels (e.g. enp2s0:0) are checked rather than
+  #       interface names.
+  #   - "ALL"
+  #       Permit all origins, accept on all interfaces. Make sure your Pi-hole is
+  #       properly firewalled! This truly allows any traffic to be replied to and is a
+  #       dangerous thing to do as your Pi-hole could become an open resolver. You
+  #       should always ask yourself if the first option doesn't work for you as well.
+  #   - "NONE"
+  #       Do not add any configuration concerning the listening mode to the dnsmasq
+  #       configuration file. This is useful if you want to manually configure the
+  #       listening mode in auxiliary configuration files. This option is really meant
+  #       for advanced users only, support for this option may be limited.
+  listeningMode = "LOCAL"
+
+  # Log DNS queries and replies to pihole.log
+  #
+  # Allowed values are:
+  #     true or false
+  queryLogging = true
+
+  # List of CNAME records which indicate that <cname> is really <target>. If the <TTL> is
+  # given, it overwrites the value of local-ttl
+  #
+  # Allowed values are:
+  #     Array of CNAMEs, each one in the following form: "<cname>,<target>[,<TTL>]"
+  cnameRecords = []
+
+  # Port used by the DNS server
+  #
+  # Allowed values are:
+  #     Any available valid (1 - 65535) port number
+  port = 53
+
+  # Enable/Disable the localise-queries option of dnsmasq. When this setting is disabled
+  # dnsmasq will return all possible values for local DNS Records. Enabled by default
+  #
+  # Allowed values are:
+  #     true or false
+  localise = true
+
+  # Reverse server (formerly called "conditional forwarding")
+  #
+  # If not configured as your DHCP server, Pi-hole typically won't be able to determine
+  # the names of devices on your local network. As a result, tables such as Top Clients
+  # will only show IP addresses.
+  #
+  # One solution for this is to configure Pi-hole to forward these requests to your DHCP
+  # server (most likely your router), but only for devices on your home network. To
+  # configure this we will need to know the IP address of your DHCP server and which
+  # addresses belong to your local network.
+  #
+  # Example: [ "true,192.168.0.0/24,192.168.0.1,fritz.box" ]
+  #
+  # Allowed values are:
+  #     Array of reverse servers each one in the following form:
+  #    
+  #     "<enabled>,<ip-address>[/<prefix-len>],<server>[#<port>][,<domain>]"
+  #    
+  #    Explanation of individual components:
+  #    
+  #     - "<enabled>": either "true" or "false"
+  #    
+  #     - "<ip-address>[/<prefix-len>]": Address range for the reverse server feature in
+  #     CIDR notation. If the prefix length is omitted, either 32 (IPv4) or 128 (IPv6)
+  #     are substituted (exact address match). This is almost certainly not what you
+  #     want here.
+  #     Example: "192.168.0.0/24" for the range 192.168.0.1 - 192.168.0.255
+  #    
+  #     - "<server>[#<port>]": Target server to be used for the reverse server feature
+  #     Example: "192.168.0.1#53"
+  #    
+  #     - "<domain>": Domain used for the reverse server feature (e.g., "fritz.box")
+  #     Example: "fritz.box"
+  revServers = [
+    "true,100.0.0.0/8,100.100.100.100,ts.net"
+  ] ### CHANGED, default = []
+
+  [dns.domain]
+    # The DNS domain used by your Pi-hole.
+    #
+    # This DNS domain is purely local. FTL may answer queries from its local cache and
+    # configuration but *never* forwards any requests upstream *unless* you have
+    # configured a dns.revServer exactly for this domain. In the latter case, all queries
+    # for this domain are sent exclusively to this server (including reverse lookups).
+    #
+    # For DHCP, this has two effects; firstly it causes the DHCP server to return the
+    # domain to any hosts which request it, and secondly it sets the domain which it is
+    # legal for DHCP-configured hosts to claim. The intention is to constrain hostnames so
+    # that an untrusted host on the LAN cannot advertise its name via DHCP as e.g.
+    # "google.com" and capture traffic not meant for it. If no domain suffix is specified,
+    # then any DHCP hostname with a domain part (ie with a period) will be disallowed and
+    # logged. If a domain is specified, then hostnames with a domain part are allowed,
+    # provided the domain part matches the suffix. In addition, when a suffix is set then
+    # hostnames without a domain part have the suffix added as an optional domain part.
+    # For instance, we can set domain=mylab.com and have a machine whose DHCP hostname is
+    # "laptop". The IP address for that machine is available both as "laptop" and
+    # "laptop.mylab.com".
+    #
+    # You can disable setting a domain by setting this option to an empty string.
+    #
+    # Allowed values are:
+    #     Any valid domain
+    name = "sweet.home" ### CHANGED, default = "lan"
+
+    # If set, the domain configured by dns.domain.name is considered local and queries for
+    # this domain are never forwarded upstream unless a dns.revServer is configured for
+    # this domain.
+    #
+    # If unset, queries for this domain are forwarded upstream to (possibly public) server
+    # which is probably not what you want *unless* you have added extra configuration for
+    # this domain *or* your upstream servers are able to handle local domains (e.g.,
+    # router).
+    #
+    # Allowed values are:
+    #     true or false
+    local = true
+
+  [dns.cache]
+    # Cache size of the DNS server. Note that expiring cache entries naturally make room
+    # for new insertions over time.
+    #
+    #Setting this number too high will have an adverse effect as not only more space is
+    # needed, but also lookup speed gets degraded in the 10,000+ range. dnsmasq may issue
+    # a warning when you go beyond 10,000+ cache entries.
+    #
+    # Allowed values are:
+    #     A positive integer value
+    size = 10000
+
+    # Query cache optimizer: If a DNS name exists in the cache, but its time-to-live has
+    # expired only recently, the data will be used anyway (a refreshing from upstream is
+    # triggered). This can improve DNS query delays especially over unreliable Internet
+    # connections. This feature comes at the expense of possibly sometimes returning
+    # out-of-date data and less efficient cache utilization, since old data cannot be
+    # flushed when its TTL expires, so the cache becomes mostly least-recently-used. To
+    # mitigate issues caused by massively outdated DNS replies, the maximum overaging of
+    # cached records is limited. We strongly recommend staying below 86400 (1 day) with
+    # this option.
+    #
+    # Setting the TTL excess time to zero will serve stale cache data regardless how long
+    # it has expired. This is not recommended as it may lead to stale data being served
+    # for a long time. Setting this option to any negative value will disable this feature
+    # altogether.
+    #
+    # Allowed values are:
+    #     A positive integer value in seconds, or any negative to disable this feature
+    optimizer = 3600
+
+    # This setting allows you to specify the TTL used for queries blocked upstream. Once
+    # the TTL expires, the query will be forwarded to the upstream server again to check
+    # if the block is still valid. Defaults to caching for one day (86400 seconds).
+    # Setting this value to zero disables caching of queries blocked upstream.
+    #
+    # Allowed values are:
+    #     A positive integer value in seconds, or zero to disable caching of upstream
+    #     blocked queries
+    upstreamBlockedTTL = 86400
+
+    # This is dnsmasq's --cache-rr option, which allows you to define which DNS record
+    # types should be cached by PiHole. This option can take a comma-separated list of
+    # RR-types as input. The default value ANY caches all record types.
+    #
+    # Allowed values are:
+    #     Valid DNS record types in the following form: <rrtype>[,<rrtype>...]
+    rrtype = "ANY"
+
+  [dns.blocking]
+    # Should FTL block queries?
+    #
+    # Allowed values are:
+    #     true or false
+    active = true
+
+    # How should FTL reply to blocked queries?
+    #
+    # Allowed values are:
+    #   - "NULL"
+    #       In NULL mode, which is both the default and recommended mode for Pi-hole
+    #       FTLDNS, blocked queries will be answered with the "unspecified address"
+    #       (0.0.0.0 or ::). The "unspecified address" is a reserved IP address specified
+    #       by RFC 3513 - Internet Protocol Version 6 (IPv6) Addressing Architecture,
+    #       section 2.5.2.
+    #   - "IP_NODATA_AAAA"
+    #       In IP-NODATA-AAAA mode, blocked queries will be answered with the local IPv4
+    #       addresses of your Pi-hole. Blocked AAAA queries will be answered with
+    #       NODATA-IPV6 and clients will only try to reach your Pi-hole over its static
+    #       IPv4 address.
+    #   - "IP"
+    #       In IP mode, blocked queries will be answered with the local IP addresses of
+    #       your Pi-hole.
+    #   - "NX"
+    #       In NXDOMAIN mode, blocked queries will be answered with an empty response
+    #       (i.e., there won't be an answer section) and status NXDOMAIN. A NXDOMAIN
+    #       response should indicate that there is no such domain to the client making the
+    #       query.
+    #   - "NODATA"
+    #       In NODATA mode, blocked queries will be answered with an empty response (no
+    #       answer section) and status NODATA. A NODATA response indicates that the domain
+    #       exists, but there is no record for the requested query type.
+    mode = "NULL"
+
+    # Should FTL enrich blocked replies with EDNS0 information?
+    #
+    # Allowed values are:
+    #   - "NONE"
+    #       In NONE mode, no additional EDNS information is added to blocked queries
+    #   - "CODE"
+    #       In CODE mode, blocked queries will be enriched with EDNS info-code BLOCKED (15)
+    #   - "TEXT"
+    #       In TEXT mode, blocked queries will be enriched with EDNS info-code BLOCKED (15)
+    #       and a text message describing the reason for the block
+    edns = "TEXT"
+
+  [dns.specialDomains]
+    # Should Pi-hole always reply with NXDOMAIN to A and AAAA queries of
+    # use-application-dns.net to disable Firefox automatic DNS-over-HTTP?
+    #
+    # This follows the recommendation on
+    # https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https
+    #
+    # Allowed values are:
+    #     true or false
+    mozillaCanary = true
+
+    # Should Pi-hole always reply with NXDOMAIN to A and AAAA queries of mask.icloud.com
+    # and mask-h2.icloud.com to disable Apple's iCloud Private Relay to prevent Apple
+    # devices from bypassing Pi-hole?
+    #
+    # This follows the recommendation on
+    # https://developer.apple.com/support/prepare-your-network-for-icloud-private-relay
+    #
+    # Allowed values are:
+    #     true or false
+    iCloudPrivateRelay = true
+
+    # Should Pi-hole always reply with NODATA to all queries to zone resolver.arpa to
+    # prevent devices from bypassing Pi-hole using Discovery of Designated Resolvers?
+    #
+    # This is based on recommendations at the end of RFC 9462, section 4.
+    #
+    # Allowed values are:
+    #     true or false
+    designatedResolver = true
+
+    [dns.reply.host]
+      # Use a specific IPv4 address for the Pi-hole host? By default, FTL determines the
+      # address of the interface a query arrived on and uses this address for replying to A
+      # queries with the most suitable address for the requesting client.
+      #
+      # This setting can be used to use a fixed, rather than the dynamically obtained,
+      # address when Pi-hole responds to the following names:
+      # - "pi.hole"
+      # - "<the device's hostname>"
+      # - "pi.hole.<local domain>"
+      # - "<the device's hostname>.<local domain>"
+      #
+      # Allowed values are:
+      #     true or false
+      force4 = false
+
+      # Custom IPv4 address for the Pi-hole host
+      #
+      # Allowed values are:
+      #     A valid IPv4 address or empty string ("")
+      IPv4 = ""
+
+      # Use a specific IPv6 address for the Pi-hole host? See description for the IPv4
+      # variant above for further details.
+      #
+      # Allowed values are:
+      #     true or false
+      force6 = false
+
+      # Custom IPv6 address for the Pi-hole host
+      #
+      # Allowed values are:
+      #     A valid IPv6 address or empty string ("")
+      IPv6 = ""
+
+    [dns.reply.blocking]
+      # Use a specific IPv4 address in IP blocking mode? By default, FTL determines the
+      # address of the interface a query arrived on and uses this address for replying to A
+      # queries with the most suitable address for the requesting client.
+      #
+      # This setting can be used to use a fixed, rather than the dynamically obtained,
+      # address when Pi-hole responds in the following cases:
+      # - IP blocking mode is used and this query is to be blocked
+      # - regular expressions with the ;reply=IP regex extension.
+      #
+      # Allowed values are:
+      #     true or false
+      force4 = false
+
+      # Custom IPv4 address for IP blocking mode
+      #
+      # Allowed values are:
+      #     A valid IPv4 address or empty string ("")
+      IPv4 = ""
+
+      # Use a specific IPv6 address in IP blocking mode? See description for the IPv4 variant
+      # above for further details.
+      #
+      # Allowed values are:
+      #     true or false
+      force6 = false
+
+      # Custom IPv6 address for IP blocking mode
+      #
+      # Allowed values are:
+      #     A valid IPv6 address or empty string ("")
+      IPv6 = ""
+
+  [dns.rateLimit]
+    # Rate-limited queries are answered with a REFUSED reply and not further processed by
+    # FTL.
+    #
+    # The default settings for FTL's rate-limiting are to permit no more than 1000 queries
+    # in 60 seconds. Both numbers can be customized independently. It is important to note
+    # that rate-limiting is happening on a per-client basis. Other clients can continue to
+    # use FTL while rate-limited clients are short-circuited at the same time.
+    #
+    # For this setting, both numbers, the maximum number of queries within a given time,
+    # and the length of the time interval (seconds) have to be specified. For instance, if
+    # you want to set a rate limit of 1 query per hour, the option should look like
+    # dns.rateLimit.count=1 and dns.rateLimit.interval=3600. The time interval is relative
+    # to when FTL has finished starting (start of the daemon + possible delay by
+    # DELAY_STARTUP) then it will advance in steps of the rate-limiting interval. If a
+    # client reaches the maximum number of queries it will be blocked until the end of the
+    # current interval. This will be logged to /var/log/pihole/FTL.log, e.g. Rate-limiting
+    # 10.0.1.39 for at least 44 seconds. If the client continues to send queries while
+    # being blocked already and this number of queries during the blocking exceeds the
+    # limit the client will continue to be blocked until the end of the next interval
+    # (FTL.log will contain lines like Still rate-limiting 10.0.1.39 as it made additional
+    # 5007 queries). As soon as the client requests less than the set limit, it will be
+    # unblocked (Ending rate-limitation of 10.0.1.39).
+    #
+    # Rate-limiting may be disabled altogether by setting both values to zero (this
+    # results in the same behavior as before FTL v5.7).
+    #
+    # How many queries are permitted...
+    #
+    # Allowed values are:
+    #     A positive integer value
+    count = 1000
+
+    # ... in the set interval before rate-limiting?
+    #
+    # Allowed values are:
+    #     A positive integer value in seconds
+    interval = 60
+
+[dhcp]
+  # Is the embedded DHCP server enabled?
+  #
+  # Allowed values are:
+  #     true or false
+  active = true ### CHANGED, default = false
+
+  # Start address of the DHCP address pool
+  #
+  # Example: "192.168.0.10"
+  #
+  # Allowed values are:
+  #     A valid IPv4 address, or empty string ("")
+  start = "192.168.2.100" ### CHANGED, default = ""
+
+  # End address of the DHCP address pool
+  #
+  # Example: "192.168.0.250"
+  #
+  # Allowed values are:
+  #     A valid IPv4 address, or empty string ("")
+  end = "192.168.2.150" ### CHANGED, default = ""
+
+  # Address of the gateway to be used (typically the address of your router in a home
+  # installation)
+  #
+  # Example: "192.168.0.1"
+  #
+  # Allowed values are:
+  #     A valid IPv4 address, or empty string ("")
+  router = "192.168.2.254" ### CHANGED, default = ""
+
+  # The netmask used by your Pi-hole. For directly connected networks (i.e., networks on
+  # which the machine running Pi-hole has an interface) the netmask is optional and may
+  # be set to an empty string (""): it will then be determined from the interface
+  # configuration itself.
+  #
+  # For networks which receive DHCP service via a relay agent, we cannot determine the
+  # netmask itself, so it should explicitly be specified, otherwise Pi-hole guesses
+  # based on the class (A, B or C) of the network address.
+  #
+  # Example: "255.255.255.0"
+  #
+  # Allowed values are:
+  #     Any valid netmask, or an empty string ("") for auto-discovery
+  netmask = "255.255.255.0" ### CHANGED, default = ""
+
+  # If the lease time is given, then leases will be given for that length of time. If not
+  # given, the default lease time is one hour for IPv4 and one day for IPv6.
+  #
+  # Allowed values are:
+  #     The lease time can be in seconds, or minutes (e.g., "45m") or hours (e.g., "1h")
+  #     or days (like "2d") or even weeks ("1w"). You may also use "infinite" as string
+  #     but be aware of the drawbacks
+  leaseTime = "24h" ### CHANGED, default = ""
+
+  # Should Pi-hole make an attempt to also satisfy IPv6 address requests (be aware that
+  # IPv6 works a whole lot different than IPv4)
+  #
+  # Allowed values are:
+  #     true or false
+  ipv6 = true ### CHANGED, default = false
+
+  # Enable DHCPv4 Rapid Commit Option specified in RFC 4039. Should only be enabled if
+  # either the server is the only server for the subnet to avoid conflicts
+  #
+  # Allowed values are:
+  #     true or false
+  rapidCommit = false
+
+  # Advertise DNS server multiple times to clients. Some devices will add their own
+  # proprietary DNS servers to the list of DNS servers, which can cause issues with
+  # Pi-hole. This option will advertise the Pi-hole DNS server multiple times to
+  # clients, which should prevent this from happening.
+  #
+  # Allowed values are:
+  #     true or false
+  multiDNS = false
+
+  # Enable logging for DHCP. This will log all relevant DHCP-related activity, including,
+  # e.g., all the options sent to DHCP clients and the tags used to determine them (if
+  # any). This can be useful for debugging DHCP issues. The generated output is saved to
+  # the file specified by files.log.dnsmasq below.
+  #
+  # Allowed values are:
+  #     true or false
+  logging = false
+
+  # Ignore unknown DHCP clients.
+  # If this option is set, Pi-hole ignores all clients which are not explicitly
+  # configured through dhcp.hosts. This can be useful to prevent unauthorized clients
+  # from getting an IP address from the DHCP server.
+  #
+  # It should be noted that this option is not a security feature, as clients can still
+  # assign themselves an IP address and use the network. It is merely a convenience
+  # feature to prevent unknown clients from getting a valid IP configuration assigned
+  # automatically.
+  #
+  # Note that you will need to configure new clients manually in dhcp.hosts before they
+  # can use the network when this feature is enabled.
+  #
+  # Allowed values are:
+  #     true or false
+  ignoreUnknownClients = false
+
+  # Per host parameters for the DHCP server. This allows a machine with a particular
+  # hardware address to be always allocated the same hostname, IP address and lease time
+  # or to specify static DHCP leases
+  #
+  # Example: [ "00:20:e0:3b:13:af,192.168.0.123,laptop,24h",
+  # "00:20:e0:ab:cd:ef,192.168.0.124,desktop,24h"]
+  #
+  # Allowed values are:
+  #     Array of static leases each one in the following form:
+  #     "[<hwaddr>][,id:<client_id>|*][,set:<tag>][,tag:<tag>][,<ipaddr>][,<hostname>][,<lease_time>][,ignore]"
+  hosts = [
+    "BC:24:11:D6:B6:D3,192.168.2.252,server",
+    "BC:24:11:32:79:DF,192.168.2.249,docker",
+    "bc:24:11:15:97:41,192.168.2.108,pbs",
+    "BC:24:11:FE:BE:C1,192.168.2.247,pxe-boot",
+    "bc:24:11:8b:be:21,192.168.2.107,tor-relay",
+    "BC:24:11:52:99:6E,192.168.2.120,nix-cache",
+    "BC:24:11:2C:33:56,192.168.2.248,pdm"
+  ] ### CHANGED, default = []
+
+  [ntp.ipv4]
+    # Should FTL act as network time protocol (NTP) server (IPv4)?
+    #
+    # Allowed values are:
+    #     true or false
+    active = true
+
+    # IPv4 address to listen on for NTP requests
+    #
+    # Allowed values are:
+    #     A valid IPv4 address, or empty string (""). For wildcard (0.0.0.0)
+    address = ""
+
+  [ntp.ipv6]
+    # Should FTL act as network time protocol (NTP) server (IPv6)?
+    #
+    # Allowed values are:
+    #     true or false
+    active = true
+
+    # IPv6 address to listen on for NTP requests
+    #
+    # Allowed values are:
+    #     A valid IPv6 address, or empty string (""). For wildcard (::)
+    address = ""
+
+  [ntp.sync]
+    # Should FTL try to synchronize the system time with an upstream NTP server?
+    #
+    # Allowed values are:
+    #     true or false
+    active = true
+
+    # NTP upstream server to sync with, e.g., "pool.ntp.org". Note that the NTP server
+    # should be located as close as possible to you in order to minimize the time offset
+    # possibly introduced by different routing paths.
+    #
+    # Allowed values are:
+    #     A valid NTP upstream server
+    server = "pool.ntp.org"
+
+    # Interval in seconds between successive synchronization attempts with the NTP server
+    #
+    # Allowed values are:
+    #     A positive integer value in seconds
+    interval = 3600
+
+    # Number of NTP syncs to perform and average before updating the system time
+    #
+    # Allowed values are:
+    #     A positive integer value
+    count = 8
+
+    [ntp.sync.rtc]
+      # Should FTL update a real-time clock (RTC) if available?
+      #
+      # Allowed values are:
+      #     true or false
+      set = false
+
+      # Path to the RTC device to update.
+      #
+      # Example: "/dev/rtc0"
+      #
+      # Allowed values are:
+      #     A valid RTC device path, or empty string ("") for auto-discovery
+      device = ""
+
+      # Should the RTC be set to UTC?
+      #
+      # Allowed values are:
+      #     true or false
+      utc = true
+
+[resolver]
+  # Should FTL try to resolve IPv4 addresses to hostnames?
+  #
+  # Allowed values are:
+  #     true or false
+  resolveIPv4 = true
+
+  # Should FTL try to resolve IPv6 addresses to hostnames?
+  #
+  # Allowed values are:
+  #     true or false
+  resolveIPv6 = true
+
+  # Control whether FTL should attempt to obtain client names from the network table by
+  # MAC address.
+  #
+  #This can provide hostnames for devices that do not have a hostname or have multiple
+  # IP addresses (e.g. IPv4 and IPv6).
+  #However, MAC-derived names can be ambiguous (e.g., when a MAC appears for multiple
+  # IPs due to a router/NAT or MAC reuse), which may lead to incorrect hostnames being
+  # shown. Disabling this option can prevent such issues but may lead to more clients
+  # without hostnames.
+  #
+  # Allowed values are:
+  #     true or false
+  macNames = true
+
+  # Control whether FTL should use the fallback option to try to obtain client names from
+  # checking the network table. This behavior can be disabled with this option.
+  #
+  # Assume an IPv6 client without a host names. However, the network table knows -
+  # though the client's MAC address - that this is the same device where we have a host
+  # name for another IP address (e.g., a DHCP server managed IPv4 address). In this
+  # case, we use the host name associated to the other address as this is the same
+  # device.
+  #
+  # Allowed values are:
+  #     true or false
+  networkNames = true
+
+  # With this option, you can change how (and if) hourly PTR requests are made to check
+  # for changes in client and upstream server hostnames.
+  #
+  # Allowed values are:
+  #   - "IPV4_ONLY"
+  #       Do hourly PTR lookups only for IPv4 addresses. This is the new default since
+  #       Pi-hole FTL v5.3.2. It should resolve issues with more and more very
+  #       short-lived PE IPv6 addresses coming up in a lot of networks.
+  #   - "ALL"
+  #       Do hourly PTR lookups for all addresses. This was the default until FTL
+  #       v5.3(.1). It has been replaced as it can create a lot of PTR queries for those
+  #       with many IPv6 addresses in their networks.
+  #   - "UNKNOWN"
+  #       Only resolve unknown hostnames. Already existing hostnames are never refreshed,
+  #       i.e., there will be no PTR queries made for clients where hostnames are known.
+  #       This also means that known hostnames will not be updated once known.
+  #   - "NONE"
+  #       Don't do any hourly PTR lookups. This means we look host names up exactly once
+  #       (when we first see a client) and never again. You may miss future changes of
+  #       host names.
+  refreshNames = "IPV4_ONLY"
+
+[database]
+  # Should FTL load information from the database on startup to be aware of the most
+  # recent history?
+  #
+  # Allowed values are:
+  #     true or false
+  DBimport = true
+
+  # How long should queries be stored in the database [days]?
+  #
+  # Allowed values are:
+  #     A positive integer value in days, or 0 to disable the database
+  maxDBdays = 91
+
+  # How often do we store queries in FTL's database [seconds]?
+  #
+  # Allowed values are:
+  #     A positive integer value in seconds
+  DBinterval = 60
+
+  # Should FTL enable Write-Ahead Log (WAL) mode for the on-disk query database
+  # (configured via files.database)?
+  #
+  # It is recommended to leave this setting enabled for performance reasons. About the
+  # only reason to disable WAL mode is if you are experiencing specific issues with it,
+  # e.g., when using a database that is accessed from multiple hosts via a network
+  # share. When this setting is disabled, FTL will use SQLite3's default journal mode
+  # (rollback journal in DELETE mode).
+  #
+  # Allowed values are:
+  #     true or false
+  useWAL = true
+
+  # Should FTL force the use of disk storage for the history database? By default, FTL
+  # uses an in-memory database for much improved performance when browsing the history
+  # from the dashboard. However, on systems with very limited RAM and only occasional
+  # usage of the web interface, it may be useful to force the use of disk storage
+  # instead of holding everything in memory.
+  #
+  # Note that using disk storage *will* reduce performance, especially on systems with
+  # slow storage media (e.g., SD cards).
+  #
+  # Allowed values are:
+  #     true or false
+  forceDisk = false
+
+  [database.network]
+    # Should FTL analyze the local ARP cache? When disabled, client identification and the
+    # network table will stop working reliably.
+    #
+    # Allowed values are:
+    #     true or false
+    parseARPcache = true
+
+    # How long should IP addresses be kept in the network_addresses table [days]? IP
+    # addresses (and associated host names) older than the specified number of days are
+    # removed to avoid dead entries in the network overview table.
+    #
+    # Allowed values are:
+    #     A positive integer value in days
+    expire = 91
+
+[webserver]
+  # On which domain is the web interface served?
+  #
+  # Allowed values are:
+  #     A valid domain
+  domain = "pi.hole"
+
+  # Webserver access control list (ACL) allowing for restrictions to be put on the list
+  # of IP addresses which have access to the web server. The ACL is a comma separated
+  # list of IP subnets, where each subnet is prepended by either a - or a + sign. A plus
+  # sign means allow, where a minus sign means deny.
+  #
+  # If a subnet mask is omitted, such as -1.2.3.4, this means to deny only that single
+  # IP address. If this value is not set (empty string), all accesses are allowed.
+  # Otherwise, the default setting is to deny all accesses. On each request the full
+  # list is traversed, and the last (!) match wins. IPv6 addresses may be specified in
+  # CIDR-form [a:b::c]/64.
+  #
+  # Example 1: "+127.0.0.1,+[::1]" ---> deny all access, except from 127.0.0.1 and ::1
+  #
+  # Example 2: "+192.168.0.0/16" ---> deny all accesses, except from the 192.168.0.0/16
+  # subnet
+  #
+  # Example 3: "+[::]/0" ---> allow only IPv6 access.
+  #
+  # Allowed values are:
+  #     A valid ACL
+  acl = ""
+
+  # Ports to be used by the webserver.
+  #
+  # Comma-separated list of ports to listen on. It is possible to specify an IP address
+  # to bind to. In this case, an IP address and a colon must be prepended to the port
+  # number. For example, to bind to the loopback interface on port 80 (IPv4) and to all
+  # interfaces port 8080 (IPv4), use "127.0.0.1:80,8080". "[::]:80" can be used to
+  # listen to IPv6 connections to port 80. IPv6 addresses of network interfaces can be
+  # specified as well, e.g. "[::1]:80" for the IPv6 loopback interface. "[::]:80" will
+  # bind to port 80 IPv6 only.
+  #
+  # In order to use port 80 for all interfaces, both IPv4 and IPv6, use either the
+  # configuration "80,[::]:80" (create one socket for IPv4 and one for IPv6 only), or
+  # "+80" (create one socket for both, IPv4 and IPv6). The '+' notation to use IPv4 and
+  # IPv6 will only work if no network interface is specified. Depending on your
+  # operating system version and IPv6 network environment, some configurations might not
+  # work as expected, so you have to test to find the configuration most suitable for
+  # your needs. In case "+80" does not work for your environment, you need to use
+  # "80,[::]:80".
+  #
+  # If the port is TLS/SSL, a letter 's' (secure) must be appended, for example,
+  # "80,443s" will open port 80 and port 443, and connections on port 443 will be
+  # encrypted. For non-encrypted ports, it is allowed to append letter 'r' (as in
+  # redirect). Redirected ports will redirect all their traffic to the first configured
+  # SSL port. For example, if webserver.port is "80r,443s", then all HTTP traffic coming
+  # at port 80 will be redirected to HTTPS port 443.
+  #
+  # When specifying 'o' (optional) behind a port, inability to use this port is not
+  # considered an error. For instance, specifying "80o,8080o" will allow the webserver
+  # to listen on either 80, 8080, both or even none of the two ports. This flag may be
+  # combined with 'r' and 's' like "80or,443os,8080,4443s" (80 redirecting to SSL if
+  # available, 443 encrypted if available, 8080 mandatory and unencrypted, 4443
+  # mandatory and encrypted).
+  #
+  # If this value is not set (empty string), the web server will not be started and,
+  # hence, the API will not be available.
+  #
+  # Allowed values are:
+  #     A comma-separated list of <[ip_address:]port>
+  port = "80o,443os,[::]:80o,[::]:443os"
+
+  # Maximum number of worker threads allowed.
+  #
+  # The Pi-hole web server handles each incoming connection in a separate thread.
+  # Therefore, the value of this option is effectively the number of concurrent HTTP
+  # connections that can be handled. Any other connections are queued until they can be
+  # processed by a unoccupied thread.
+  #
+  # The total number of threads you see may be lower than the configured value as
+  # threads are only created when needed due to incoming connections.
+  #
+  # The value 0 means the number of threads is 50 (as per default settings of CivetWeb)
+  # for backwards-compatible behavior.
+  #
+  # Allowed values are:
+  #     A positive integer value, or 0 for default (50)
+  threads = 50
+
+  # Additional HTTP headers added to the web server responses.
+  #
+  # The headers are added to all responses, including those for the API.
+  # Note about the default additional headers:
+  # - X-DNS-Prefetch-Control: off: Usually browsers proactively perform domain name
+  # resolution on links that the user may choose to follow. We disable DNS prefetching
+  # here.
+  # - Content-Security-Policy: [...] 'unsafe-inline' is both required by Chart.js
+  # styling some elements directly, and index.html containing some inlined Javascript
+  # code.
+  # - X-Frame-Options: DENY: The page can not be displayed in a frame, regardless of the
+  # site attempting to do so.
+  # - X-Xss-Protection: 0: Disables XSS filtering in browsers that support it. This
+  # header is usually enabled by default in browsers, and is not recommended as it can
+  # hurt the security of the site.
+  # (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection).
+  # - X-Content-Type-Options: nosniff: Marker used by the server to indicate that the
+  # MIME types advertised in the  Content-Type headers should not be changed and be
+  # followed. This allows to opt-out of MIME type sniffing, or, in other words, it is a
+  # way to say that the webmasters knew what they were doing. Site security testers
+  # usually expect this header to be set.
+  # - Referrer-Policy: strict-origin-when-cross-origin: A referrer will be sent for
+  # same-site origins, but cross-origin requests will send no referrer information.
+  # The latter four headers are set as expected by https://securityheaders.io
+  #
+  # Allowed values are:
+  #     An array of HTTP headers
+  headers = [
+    "Content-Security-Policy: default-src 'self' 'unsafe-inline';",
+    "X-Frame-Options: DENY",
+    "X-XSS-Protection: 0",
+    "X-Content-Type-Options: nosniff",
+    "Referrer-Policy: strict-origin-when-cross-origin"
+  ] ### CHANGED, default = [ "X-DNS-Prefetch-Control: off", "Content-Security-Policy: default-src 'none'; connect-src 'self'; font-src 'self'; frame-ancestors 'none'; img-src 'self'; manifest-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; form-action 'self'", "X-Frame-Options: DENY", "X-XSS-Protection: 0", "X-Content-Type-Options: nosniff", "Referrer-Policy: strict-origin-when-cross-origin" ]
+
+  # Should the web server serve all files in webserver.paths.webroot directory?
+  #
+  # If disabled, only files within the path defined through webserver.paths.webhome and
+  # /api will be served.
+  #
+  # Allowed values are:
+  #     true or false
+  serve_all = false
+
+  # Additional options passed directly to the web server.
+  #
+  # This can be used to set any option supported by the underlying web server
+  # (CivetWeb). See the CivetWeb documentation for a list of supported options. The
+  # options are passed as an array of strings, where each string is an option in the
+  # form "<option>=<value>". Be aware that this is an advanced option and that setting
+  # options here may break the web server if invalid or conflicting with other settings
+  # applied based on other settings in this file. The config options specified here are
+  # added to the end of the passed options. This makes it possible to overwrite settings
+  # set by Pi-hole (only the last values is used when a config option is specified
+  # multiple times). Use with caution.
+  #
+  # Example: [ "ssl_protocol_version=4", "ssl_cipher_list=AES128:!MD5" ]
+  #
+  # Allowed values are:
+  #     An array of valid CivetWeb options
+  advancedOpts = []
+
+  [webserver.session]
+    # Session timeout in seconds.
+    #
+    # If a session is inactive for more than this time, it will be terminated. Sessions
+    # are continuously refreshed by the web interface, preventing sessions from timing out
+    # while the web interface is open.
+    #
+    # This option may also be used to make logins persistent for long times, e.g. 86400
+    # seconds (24 hours), 604800 seconds (7 days) or 2592000 seconds (30 days). Note that
+    # the total number of concurrent sessions is limited so setting this value too high
+    # may result in users being rejected and unable to log in if there are already too
+    # many sessions active.
+    #
+    # Allowed values are:
+    #     A positive integer value in seconds
+    timeout = 1800
+
+    # Should Pi-hole backup and restore sessions from the database?
+    #
+    # This is useful if you want to keep your sessions after a restart of the web
+    # interface.
+    #
+    # Allowed values are:
+    #     true or false
+    restore = true
+
+  [webserver.tls]
+    # Path to the TLS (SSL) certificate file.
+    #
+    # All directories along the path must be readable and accessible by the user running
+    # FTL (typically 'pihole'). This option is only required when at least one of
+    # webserver.port is TLS. The file must be in PEM format, and it must have both,
+    # private key and certificate (the *.pem file created must contain a 'CERTIFICATE'
+    # section as well as a 'PRIVATE KEY' section).
+    #
+    # The *.pem file can be created using `cp server.crt server.pem && cat server.key >>
+    # server.pem` if you have these files instead
+    #
+    # Allowed values are:
+    #     A valid TLS certificate file (*.pem)
+    cert = "/etc/pihole/tls.pem"
+
+    # Number of days the automatically generated self-signed TLS/SSL certificate will be
+    # valid for.
+    #
+    # Defaults to 47 days. A minimum of 7 days is enforced.
+    # Some devices may enforce shorter validity ranges. Note that defining a lower
+    # validity range may require you to accept the self-signed certificate more often in
+    # your browser.
+    # Pi-hole will regenerate certificates it created itself two days prior to expiration.
+    # If you are using your own certificate, you need to regenerate it yourself. In this
+    # case, it is advised to set the validity range to 0 days, so that Pi-hole does not
+    # try to regenerate your certificate. If you set the validity range to 0 days and
+    # still try to generate a certificate, Pi-hole will set a fixed validity range of
+    # roughly 30 years for the certificate.
+    validity = 47
+
+  [webserver.paths]
+    # Server root on the host
+    #
+    # Allowed values are:
+    #     A valid path
+    webroot = "/var/www/html"
+
+    # Sub-directory of the root containing the web interface
+    #
+    # Allowed values are:
+    #     A valid subpath, both slashes are needed!
+    webhome = "/admin/"
+
+    # Prefix where the web interface is served
+    #
+    # This is useful when you are using a reverse proxy serving the web interface, e.g.,
+    # at http://<ip>/pihole/admin/ instead of http://<ip>/admin/. In this example, the
+    # prefix would be "/pihole". Note that the prefix has to be stripped away by the
+    # reverse proxy, e.g., for traefik:
+    # - traefik.http.routers.pihole.rule=PathPrefix(`/pihole`)
+    # - traefik.http.middlewares.piholehttp.stripprefix.prefixes=/pihole
+    # The prefix should start with a slash. If you don't use a prefix, leave this field
+    # empty. Setting this field to an incorrect value may result in the web interface not
+    # being accessible.
+    # Don't use this setting if you are not using a reverse proxy!
+    #
+    # Allowed values are:
+    #     A valid URL prefix or empty
+    prefix = ""
+
+  [webserver.interface]
+    # Should the web interface use the boxed layout?
+    #
+    # Allowed values are:
+    #     true or false
+    boxed = true
+
+    # Theme used by the Pi-hole web interface
+    #
+    # Allowed values are:
+    #   - "default-auto"
+    #       Pi-hole auto
+    #   - "default-light"
+    #       Pi-hole day
+    #   - "default-dark"
+    #       Pi-hole midnight
+    #   - "default-darker"
+    #       Pi-hole deep-midnight
+    #   - "high-contrast"
+    #       High-contrast light
+    #   - "high-contrast-dark"
+    #       High-contrast dark
+    #   - "lcars"
+    #       Star Trek LCARS
+    theme = "default-dark" ### CHANGED, default = "default-auto"
+
+  [webserver.api]
+    # Number of concurrent sessions allowed for the API. If the number of sessions exceeds
+    # this value, no new sessions will be allowed until the number of sessions drops due
+    # to session expiration or logout.
+    #
+    # Note that the number of concurrent sessions is irrelevant if authentication is
+    # disabled as no sessions are used in this case.
+    #
+    # Allowed values are:
+    #     A positive integer value
+    max_sessions = 16
+
+    # Should FTL prettify the API output (add extra spaces, newlines and indentation)?
+    #
+    # Allowed values are:
+    #     true or false
+    prettyJSON = false
+
+    # API password hash
+    #
+    # Allowed values are:
+    #     A valid Pi-hole password hash
+    pwhash = ""
+
+    # Pi-hole 2FA TOTP secret. When set to something different than an empty string, 2FA
+    # authentication will be enforced for the API and the web interface. This setting is
+    # write-only, the secret itself cannot be read back, but the CLI will show "********"
+    # to indicate that 2FA is configured.
+    #
+    # Allowed values are:
+    #     A valid TOTP secret (20 Bytes in Base32 encoding)
+    totp_secret = ""
+
+    # Pi-hole application password.
+    #
+    # After you turn on two-factor (2FA) verification and set up an Authenticator app, you
+    # may run into issues if you use apps or other services that don't support two-step
+    # verification. In this case, you can create and use an app password to sign in.
+    #
+    # An app password is a long, randomly generated password that can be used instead of
+    # your regular password + TOTP token when signing in to the API. The app password can
+    # be generated through the API and will be shown only once.
+    #
+    # You can revoke the app password at any time. If you revoke the app password, be sure
+    # to generate a new one and update your app with the new password.
+    #
+    # Allowed values are:
+    #     A valid Pi-hole password hash
+    app_pwhash = ""
+
+    # Should application password API sessions be allowed to modify config settings?
+    #
+    # Setting this to true allows third-party applications using the application password
+    # to modify settings, e.g., the upstream DNS servers, DHCP server settings, or
+    # changing passwords. This setting should only be enabled if really needed and only if
+    # you trust the applications using the application password.
+    #
+    # Allowed values are:
+    #     true or false
+    app_sudo = false
+
+    # Should FTL create a temporary CLI password?
+    #
+    # This password is stored in clear in /etc/pihole and can be used by the CLI (pihole
+    # ...  commands) to authenticate against the API. Note that the password is only valid
+    # for the current session and regenerated on each FTL restart. Sessions initiated with
+    # this password cannot modify the Pi-hole configuration (change passwords, etc.) for
+    # security reasons but can still use the API to query data and manage lists.
+    #
+    # Allowed values are:
+    #     true or false
+    cli_pw = true
+
+    # Array of clients to be excluded from certain API responses (regex):
+    # - Query Log (/api/queries)
+    # - Top Clients (/api/stats/top_clients)
+    # This setting accepts both IP addresses (IPv4 and IPv6) as well as hostnames.
+    # Note that backslashes "\" need to be escaped, i.e. "\\" in this setting
+    #
+    # Example: [ "^192\\.168\\.2\\.56$", "^fe80::341:[0-9a-f]*$", "^localhost$" ]
+    #
+    # Allowed values are:
+    #     An array of regular expressions describing clients
+    excludeClients = []
+
+    # Array of domains to be excluded from certain API responses (regex):
+    # - Query Log (/api/queries)
+    # - Top Clients (/api/stats/top_domains)
+    # Note that backslashes "\" need to be escaped, i.e. "\\" in this setting
+    #
+    # Example: [ "(^|\\.)\\.google\\.de$", "\\.pi-hole\\.net$" ]
+    #
+    # Allowed values are:
+    #     An array of regular expressions describing domains
+    excludeDomains = []
+
+    # How much history should be imported from the database and returned by the API
+    # [seconds]? (max 24hrs = 86400)
+    #
+    # Allowed values are:
+    #     A positive integer value in seconds up to 86400
+    maxHistory = 86400
+
+    # Up to how many clients should be returned in the activity graph endpoint
+    # (/api/history/clients)?
+    #
+    # This setting can be overwritten at run-time using the parameter N. Setting this to 0
+    # will always send all clients. Be aware that this may be challenging for the GUI if
+    # you have many (think > 1.000 clients) in your network
+    #
+    # Allowed values are:
+    #     A positive integer value
+    maxClients = 10
+
+    # How should the API compute the most active clients? If set to true, the API will
+    # return the clients with the most queries globally (within 24 hours). If set to
+    # false, the API will return the clients with the most queries per time slot
+    # individually.
+    #
+    # Allowed values are:
+    #     true or false
+    client_history_global_max = true
+
+    # Allow destructive API calls (e.g. restart DNS server, flush logs, ...)
+    #
+    # Allowed values are:
+    #     true or false
+    allow_destructive = true
+
+    [webserver.api.temp]
+      # Which upper temperature limit should be used by Pi-hole? Temperatures above this
+      # limit will be shown as "hot". The number specified here is in the unit defined below
+      #
+      # Allowed values are:
+      #     A positive floating point value in the unit defined below
+      limit = 60.000000
+
+      # Which temperature unit should be used for temperatures processed by FTL?
+      #
+      # Allowed values are:
+      #   - "C"
+      #       Celsius
+      #   - "F"
+      #       Fahrenheit
+      #   - "K"
+      #       Kelvin
+      unit = "C"
+
+[files]
+  # The location of FTL's long-term database
+  #
+  # Allowed values are:
+  #     Any FTL database
+  database = "/etc/pihole/pihole-FTL.db"
+
+  # The location of FTL's short-term temporary database (only used when
+  # database.forceDisk is true)
+  #
+  # Allowed values are:
+  #     Any FTL database
+  tmp_db = "/etc/pihole/pihole-tmp.db"
+
+  # The location of Pi-hole's gravity database
+  #
+  # Allowed values are:
+  #     Any Pi-hole gravity database
+  gravity = "/etc/pihole/gravity.db"
+
+  # A temporary directory where Pi-hole can store files during gravity updates. This
+  # directory must be writable by the user running gravity (typically pihole).
+  #
+  # Allowed values are:
+  #     Any existing world-writable writable directory
+  gravity_tmp = "/tmp"
+
+  # The database containing MAC -> Vendor information for the network table
+  #
+  # Allowed values are:
+  #     Any Pi-hole macvendor database
+  macvendor = "/etc/pihole/macvendor.db"
+
+  # An optional file containing a pcap capture of the network traffic. This file is used
+  # for debugging purposes only. If you don't know what this is, you don't need it.
+  #
+  # Setting this to an empty string disables pcap recording. The file must be writable
+  # by the user running FTL (typically pihole). Failure to write to this file will
+  # prevent the DNS resolver from starting. The file is appended to if it already
+  # exists.
+  #
+  # Allowed values are:
+  #     Any writable pcap file
+  pcap = ""
+
+  [files.log]
+    # The location of FTL's log file
+    #
+    # Allowed values are:
+    #     any writable file
+    ftl = "/var/log/pihole/FTL.log"
+
+    # The log file used by the embedded dnsmasq DNS server
+    #
+    # Allowed values are:
+    #     Any writable file
+    dnsmasq = "/var/log/pihole/pihole.log"
+
+    # The log file used by the webserver
+    #
+    # Allowed values are:
+    #     Any writable file
+    webserver = "/var/log/pihole/webserver.log"
+
+[misc]
+  # Using privacy levels you can specify which level of detail you want to see in your
+  # Pi-hole statistics. Changing this setting will trigger a restart of FTL
+  #
+  # Allowed values are:
+  #   - 0
+  #       Don't hide anything, all statistics are available.
+  #   - 1
+  #       Hide domains. This setting disables Top Domains and Top Ads
+  #   - 2
+  #       Hide domains and clients. This setting disables Top Domains, Top Ads, Top
+  #       Clients and Clients over time.
+  #   - 3
+  #       Anonymize everything. This setting disables almost any statistics and query
+  #       analysis. There will be no long-term database logging and no Query Log. You
+  #       will also lose most regex features.
+  privacylevel = 0
+
+  # During startup, in some configurations, network interfaces appear only late during
+  # system startup and are not ready when FTL tries to bind to them. Therefore, you may
+  # want FTL to wait a given amount of time before trying to start the DNS resolver.
+  #
+  # This setting takes any integer value between 0 and 300 seconds. To prevent delayed
+  # startup while the system is already running and FTL is restarted, the delay only
+  # takes place within the first 180 seconds (hard-coded) after booting.
+  #
+  # Allowed values are:
+  #     A positive integer value between 0 and 300
+  delay_startup = 0
+
+  # Set niceness of pihole-FTL. Defaults to -10 and can be disabled altogether by setting
+  # a value of -999. The nice value is an attribute that can be used to influence the
+  # CPU scheduler to favor or disfavor a process in scheduling decisions.
+  #
+  # The range of the nice value varies across UNIX systems. On modern Linux, the range
+  # is -20 (high priority = not very nice to other processes) to +19 (low priority).
+  #
+  # Allowed values are:
+  #     A signed integer value between -20 and 19, or -999 to disable niceness
+  nice = -10
+
+  # Should FTL translate its own stack addresses into code lines during the bug
+  # backtrace? This improves the analysis of crashed significantly. It is recommended to
+  # leave the option enabled.
+  #
+  # This option should only be disabled when addr2line is known to not be working
+  # correctly on the machine because, in this case, the malfunctioning addr2line can
+  # prevent from generating any backtrace at all.
+  #
+  # Allowed values are:
+  #     true or false
+  addr2line = true
+
+  # Should FTL load additional dnsmasq configuration files from /etc/dnsmasq.d/?
+  #
+  # Warning: This is an advanced setting and should only be used with care.
+  # Incorrectly formatted or config files specifying options which can only be defined
+  # once can result in conflicts with the automatic configuration of Pi-hole (see
+  # /etc/pihole/dnsmasq.conf) and may stop DNS resolution from working.
+  #
+  # Allowed values are:
+  #     true or false
+  etc_dnsmasq_d = true ### CHANGED, default = false
+
+  # Additional lines to inject into the generated dnsmasq configuration.
+  # Warning: This is an advanced setting and should only be used with care. Incorrectly
+  # formatted or duplicated lines as well as lines conflicting with the automatic
+  # configuration of Pi-hole can break the embedded dnsmasq and will stop DNS resolution
+  # from working.
+  #
+  # Use this option with extra care.
+  #
+  # Example: [ "address=/example.com/192.168.0.1", "address=/example.org/192.168.0.2",
+  # "address=/example.net/192.168.0.3" ]
+  #
+  # Allowed values are:
+  #     Array of valid dnsmasq config line options
+  dnsmasq_lines = []
+
+  # Log additional information about queries and replies to pihole.log
+  #
+  # When this setting is enabled, the log has extra information at the start of each
+  # line. This consists of a serial number which ties together the log lines associated
+  # with an individual query, and the IP address of the requestor. This setting is only
+  # effective if dns.queryLogging is enabled, too. This option is only useful for
+  # debugging and is not recommended for normal use.
+  #
+  # Allowed values are:
+  #     true or false
+  extraLogging = false
+
+  # Put configuration into read-only mode. This will prevent any changes to the
+  # configuration file via the API or CLI. This setting useful when a configuration is
+  # to be forced/modified by some third-party application (like infrastructure-as-code
+  # providers) and should not be changed by any means.
+  #
+  # Allowed values are:
+  #     true or false
+  readOnly = false
+
+  # Should FTL normalize reported CPU usage?
+  #
+  # On multi-core systems, a high workload can lead to CPU usage numbers exceeding 100%
+  # (e.g., 200% on a quad-core system if two out of four cores are fully utilized). This
+  # may look alarming at first glance even though the system is not actually overloaded.
+  # Enabling this setting will divide the CPU usage by the number of cores, leading to
+  # more intuitive numbers (e.g., 50% for the same load on a quad-core system).
+  # Note that this setting only affects how CPU usage is *reported*, it does not change
+  # the actual CPU usage.
+  #
+  # Allowed values are:
+  #     true or false
+  normalizeCPU = true
+
+  # Should FTL hide warnings coming from dnsmasq?
+  #
+  # By default, FTL reports warnings coming from the embedded dnsmasq DNS server to the
+  # FTL log file. These warnings can be useful to identify misconfigurations or problems
+  # with the DNS server. However, some warnings may be harmless and can be ignored in
+  # certain setups. Enabling this setting will hide all dnsmasq warnings.
+  #
+  # Allowed values are:
+  #     true or false
+  hide_dnsmasq_warn = false
+
+  # Should FTL hide network connection errors?
+  #
+  # By default, FTL reports network connection errors (e.g., Connection prematurely
+  # closed by remote server) to the FTL log file. These warnings can be useful to
+  # identify intermittent network problems or general problem with upstream servers.
+  # However, in some setups, these warnings may be expected (e.g. due to low-quality
+  # Internet connectivity) and cannot be fixed. Enabling this setting will hide all
+  # connection warnings.
+  #
+  # Allowed values are:
+  #     true or false
+  hide_connection_error = false
+
+  [misc.check]
+    # Pi-hole is very lightweight on resources. Nevertheless, this does not mean that you
+    # should run Pi-hole on a server that is otherwise extremely busy as queuing on the
+    # system can lead to unnecessary delays in DNS operation as the system becomes less
+    # and less usable as the system load increases because all resources are permanently
+    # in use. To account for this, FTL regularly checks the system load. To bring this to
+    # your attention, FTL warns about excessive load when the 15 minute system load
+    # average exceeds the number of cores.
+    #
+    # This check can be disabled with this setting.
+    #
+    # Allowed values are:
+    #     true or false
+    load = true
+
+    # FTL stores history in shared memory to allow inter-process communication with forked
+    # dedicated TCP workers. If FTL runs out of memory, it cannot continue to work as
+    # queries cannot be analyzed any further. Hence, FTL checks if enough shared memory is
+    # available on your system and warns you if this is not the case.
+    # By default, FTL warns if the shared-memory usage exceeds 90%. You can set any
+    # integer limit between 0 to 100 (interpreted as percentages) where 0 means that
+    # checking of shared-memory usage is disabled.
+    #
+    # Allowed values are:
+    #     A positive integer value between 0 and 100
+    shmem = 90
+
+    # FTL stores its long-term history in a database file on disk. Furthermore, FTL stores
+    # log files. By default, FTL warns if usage of the disk holding any crucial file
+    # exceeds 90%. You can set any integer limit between 0 to 100 (interpreted as
+    # percentages) where 0 means that checking of disk usage is disabled.
+    #
+    # Allowed values are:
+    #     A positive integer value between 0 and 100
+    disk = 90
+
+[debug]
+  # Print debugging information about database actions. This prints performed SQL
+  # statements as well as some general information such as the time it took to store the
+  # queries and how many have been saved to the database.
+  #
+  # Allowed values are:
+  #     true or false
+  database = false
+
+  # Prints a list of the detected interfaces on the startup of pihole-FTL. Also, prints
+  # whether these interfaces are IPv4 or IPv6 interfaces.
+  #
+  # Allowed values are:
+  #     true or false
+  networking = false
+
+  # Print information about shared memory locks. Messages will be generated when waiting,
+  # obtaining, and releasing a lock.
+  #
+  # Allowed values are:
+  #     true or false
+  locks = false
+
+  # Print extensive query information (domains, types, replies, etc.). This has always
+  # been part of the legacy debug mode of pihole-FTL.
+  #
+  # Allowed values are:
+  #     true or false
+  queries = false
+
+  # Print flags of queries received by the DNS hooks. Only effective when DEBUG_QUERIES
+  # is enabled as well.
+  #
+  # Allowed values are:
+  #     true or false
+  flags = false
+
+  # Print information about shared memory buffers. Messages are either about creating or
+  # enlarging shmem objects or string injections.
+  #
+  # Allowed values are:
+  #     true or false
+  shmem = false
+
+  # Print information about garbage collection (GC): What is to be removed, how many have
+  # been removed and how long did GC take.
+  #
+  # Allowed values are:
+  #     true or false
+  gc = false
+
+  # Print information about ARP table processing: How long did parsing take, whether read
+  # MAC addresses are valid, and if the macvendor.db file exists.
+  #
+  # Allowed values are:
+  #     true or false
+  arp = false
+
+  # Controls if FTLDNS should print extended details about regex matching into FTL.log.
+  #
+  # Allowed values are:
+  #     true or false
+  regex = false
+
+  # Print extra debugging information concerning API calls. This includes the request,
+  # the request parameters, and the internal details about how the algorithms decide
+  # which data to present and in what form. This very verbose output should only be used
+  # when debugging specific API issues and can be helpful, e.g., when a client cannot
+  # connect due to an obscure API error. Furthermore, this setting enables logging of
+  # all API requests (auth log) and details about user authentication attempts.
+  #
+  # Allowed values are:
+  #     true or false
+  api = false
+
+  # Print extra debugging information about TLS connections. This includes the TLS
+  # version, the cipher suite, the certificate chain and much more. This very verbose
+  # output should only be used when debugging specific TLS issues and can be helpful,
+  # e.g., when a client cannot connect due to an obscure TLS error as modern browsers do
+  # not provide much information about the underlying TLS connection and most often give
+  # only very generic error messages without much/any underlying technical information.
+  #
+  # Allowed values are:
+  #     true or false
+  tls = false
+
+  # Print information about overTime memory operations, such as initializing or moving
+  # overTime slots.
+  #
+  # Allowed values are:
+  #     true or false
+  overtime = false
+
+  # Print information about status changes for individual queries. This can be useful to
+  # identify unexpected unknown queries.
+  #
+  # Allowed values are:
+  #     true or false
+  status = false
+
+  # Print information about capabilities granted to the pihole-FTL process. The current
+  # capabilities are printed on receipt of SIGHUP, i.e., the current set of capabilities
+  # can be queried without restarting pihole-FTL (by setting DEBUG_CAPS=true and
+  # thereafter sending killall -HUP pihole-FTL).
+  #
+  # Allowed values are:
+  #     true or false
+  caps = false
+
+  # Print information about DNSSEC activity
+  #
+  # Allowed values are:
+  #     true or false
+  dnssec = false
+
+  # FTL uses dynamically allocated vectors for various tasks. This config option enables
+  # extensive debugging information such as information about allocation, referencing,
+  # deletion, and appending.
+  #
+  # Allowed values are:
+  #     true or false
+  vectors = false
+
+  # Extensive information about hostname resolution like which DNS servers are used in
+  # the first and second hostname resolving tries (only affecting internally generated
+  # PTR queries).
+  #
+  # Allowed values are:
+  #     true or false
+  resolver = false
+
+  # Print debugging information about received EDNS(0) data.
+  #
+  # Allowed values are:
+  #     true or false
+  edns0 = false
+
+  # Log various important client events such as change of interface (e.g., client
+  # switching from WiFi to wired or VPN connection), as well as extensive reporting
+  # about how clients were assigned to its groups.
+  #
+  # Allowed values are:
+  #     true or false
+  clients = false
+
+  # Log information related to alias-client processing.
+  #
+  # Allowed values are:
+  #     true or false
+  aliasclients = false
+
+  # Log information regarding FTL's embedded event handling queue.
+  #
+  # Allowed values are:
+  #     true or false
+  events = false
+
+  # Log information about script helpers, e.g., due to dhcp-script.
+  #
+  # Allowed values are:
+  #     true or false
+  helper = false
+
+  # Print config parsing details
+  #
+  # Allowed values are:
+  #     true or false
+  config = false
+
+  # Debug monitoring of /etc/pihole filesystem events
+  #
+  # Allowed values are:
+  #     true or false
+  inotify = false
+
+  # Debug monitoring of the webserver (CivetWeb) events
+  #
+  # Allowed values are:
+  #     true or false
+  webserver = false
+
+  # Temporary flag that may print additional information. This debug flag is meant to be
+  # used whenever needed for temporary investigations. The logged content may change
+  # without further notice at any time.
+  #
+  # Allowed values are:
+  #     true or false
+  extra = false
+
+  # Reserved debug flag
+  #
+  # Allowed values are:
+  #     true or false
+  reserved = false
+
+  # Print information about NTP synchronization
+  #
+  # Allowed values are:
+  #     true or false
+  ntp = false
+
+  # Print information about netlink communication and parsing
+  #
+  # Allowed values are:
+  #     true or false
+  netlink = false
+
+  # Print timing information from various parts of FTL
+  #
+  # Allowed values are:
+  #     true or false
+  timing = false
+
+  # Log gravity lookup and FTL DNS cache performance statistics every 5 minutes. For each
+  # operation type (gravity, antigravity, denylist, allowlist), reports the call count,
+  # average and maximum latency, and percentage of slow queries (>1 ms). Also reports
+  # the FTL cache hit/miss ratio, indicating how often gravity.db is queried at all.
+  #
+  # Allowed values are:
+  #     true or false
+  performance = false
+
+  # Set all debug flags at once. This is a convenience option to enable all debug flags
+  # at once. Note that this option is not persistent, setting it to true will enable all
+  # *remaining* debug flags but unsetting it will disable *all* debug flags.
+  all = false
+
+# Configuration statistics:
+# 167 total entries out of which 150 entries are default
+# --> 17 entries are modified
+
diff --git a/.claude/worktrees/debian-restructure/pihole/pull-config.sh b/.claude/worktrees/debian-restructure/pihole/pull-config.sh
new file mode 100755
index 0000000..27dbf6a
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/pihole/pull-config.sh
@@ -0,0 +1,51 @@
+#!/usr/bin/env bash
+# Pull Pi-hole configuration from a running instance to a local directory.
+# Sensitive fields (password hashes, TOTP secrets) are redacted automatically.
+#
+# Usage: pull-config.sh <source-host> <dest-dir>
+#   source-host  SSH-reachable hostname or IP of the source Pi-hole
+#   dest-dir     Local directory to write config into (created if absent)
+#
+# Example:
+#   ./pull-config.sh root@pihole ./config
+#   ./pull-config.sh root@192.168.2.253 /backup/pihole-$(date +%Y%m%d)
+
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+
+usage() {
+  echo "Usage: $(basename "$0") <source-host> <dest-dir>" >&2
+  echo "  source-host  SSH target for the source Pi-hole (e.g. root@pihole)" >&2
+  echo "  dest-dir     Local directory to write config files into" >&2
+  exit 1
+}
+
+[[ $# -eq 2 ]] || usage
+
+SOURCE="$1"
+DEST="$2"
+
+echo "Pulling Pi-hole config from ${SOURCE} → ${DEST}"
+
+mkdir -p "${DEST}/dnsmasq.d"
+
+# ── pihole.toml ────────────────────────────────────────────────────────────────
+echo "  pihole.toml"
+ssh "${SOURCE}" "cat /etc/pihole/pihole.toml" > "${DEST}/pihole.toml"
+"${SCRIPT_DIR}/sanitize-config.sh" "${DEST}/pihole.toml"
+
+# ── custom dnsmasq drop-ins ────────────────────────────────────────────────────
+# Pi-hole manages its own generated config; we only capture user-added files.
+echo "  dnsmasq.d/ (custom drop-ins)"
+ssh "${SOURCE}" "ls /etc/dnsmasq.d/*.conf 2>/dev/null || true" | while read -r f; do
+  name="$(basename "$f")"
+  echo "    ${name}"
+  ssh "${SOURCE}" "cat '${f}'" > "${DEST}/dnsmasq.d/${name}"
+done
+
+# ── DHCP static leases ─────────────────────────────────────────────────────────
+echo "  dhcp.leases"
+ssh "${SOURCE}" "cat /etc/pihole/dhcp.leases 2>/dev/null || true" > "${DEST}/dhcp.leases"
+
+echo "Done. Config written to ${DEST}/"
diff --git a/.claude/worktrees/debian-restructure/pihole/sanitize-config.sh b/.claude/worktrees/debian-restructure/pihole/sanitize-config.sh
new file mode 100755
index 0000000..f7be72a
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/pihole/sanitize-config.sh
@@ -0,0 +1,40 @@
+#!/usr/bin/env bash
+# Redact sensitive fields from a Pi-hole pihole.toml before committing.
+# Called automatically by pull-config.sh; can also be run manually.
+#
+# Usage: sanitize-config.sh <pihole.toml>
+#   Edits the file in-place, replacing sensitive field values with "".
+
+set -euo pipefail
+
+usage() {
+  echo "Usage: $(basename "$0") <pihole.toml>" >&2
+  exit 1
+}
+
+[[ $# -eq 1 ]] || usage
+FILE="$1"
+[[ -f "$FILE" ]] || { echo "Error: file not found: $FILE" >&2; exit 1; }
+
+REDACTED=0
+
+redact_field() {
+  local field="$1"
+  # Match lines like:  pwhash = "some-value"  and blank the value
+  if grep -qE "^\s+${field}\s*=\s*\"[^\"]{1,}\"" "$FILE"; then
+    sed -i -E "s|^(\s+${field}\s*=\s*)\"[^\"]*\"|\1\"\"|" "$FILE"
+    echo "  redacted: ${field}"
+    REDACTED=$((REDACTED + 1))
+  fi
+}
+
+echo "Sanitizing $(basename "$FILE")..."
+redact_field "pwhash"
+redact_field "app_pwhash"
+redact_field "totp_secret"
+
+if [[ $REDACTED -eq 0 ]]; then
+  echo "  (nothing to redact)"
+else
+  echo "  ${REDACTED} field(s) redacted."
+fi
diff --git a/.claude/worktrees/debian-restructure/proxmox/.gitignore b/.claude/worktrees/debian-restructure/proxmox/.gitignore
new file mode 100644
index 0000000..2437a07
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/.gitignore
@@ -0,0 +1,2 @@
+.claude/settings.local.json
+*.swp
diff --git a/.claude/worktrees/debian-restructure/proxmox/CLAUDE.md b/.claude/worktrees/debian-restructure/proxmox/CLAUDE.md
new file mode 100644
index 0000000..033ce36
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/CLAUDE.md
@@ -0,0 +1,84 @@
+# CLAUDE.md
+
+Guidance for Claude Code working in this repo. IMPORTANT: these
+instructions OVERRIDE any default behavior and must be followed exactly
+as written.
+
+## Repo purpose
+
+Base configuration/hardening toolset and planning docs for Proxmox VE
+hosts (`scripts/`, `config/`, `docs/`) — see `README.md` and
+`docs/00-overview.md`. Scripts in this repo are meant to be run **on**
+the target Proxmox host itself (as root), not orchestrated remotely.
+
+## Two Proxmox nodes: `pve1` (production) and `pve-test` (sandbox)
+
+Two SSH-reachable Proxmox nodes exist on the LAN. They are **not
+interchangeable** — see `docs/05-node-roles.md` for full background on
+what each one is and why.
+
+### `pve1` (production — off-limits to Claude by default)
+
+A real, live Proxmox node hosting production VMs/containers (see
+`docs/05-node-roles.md` for the current guest list) — not a sandbox, and
+not Claude's to touch by default.
+
+- **Off-limits at all times unless the operator has given explicit,
+  same-session instructions to act on this specific host.** That
+  authorization is scoped to the task it was given for — don't carry it
+  forward to unrelated later work in the same conversation, and never
+  assume it from a previous session.
+- **Read-only for existing state is always fine, authorization or not.**
+  SSH in (or use `pvesm`, `qm list`, `pct list`, `qm config`, `pct
+  config`, the Proxmox API, etc.) to inspect config, storage, and any
+  existing VM/container freely.
+- **Never** modify, stop, restart, delete, reconfigure, or create
+  anything on this node (`qm set`, `pct set`, `qm destroy`, `pct
+  destroy`, `qm stop`, `pct stop`, `qm create`, `pct create`, snapshot
+  operations, storage changes, running any script in this repo against
+  it, etc.) without that explicit go-ahead. Use `pve-test` for anything
+  exploratory instead.
+- If a guest on `pve1` is HA-managed, be aware of the self-fence hazard
+  described in `docs/05-node-roles.md`'s cluster-teardown section before
+  doing anything that could cost the node quorum.
+
+### `pve-test` (sandbox — Claude's default target)
+
+A separate node set aside for testing — safe to create, interrogate, and
+destroy scratch VMs/containers on without asking first.
+
+- **Test VMs/containers are allowed, but must be torn down.** Anything
+  created this way must be destroyed again in the same session, before
+  ending the task. Use an obviously-scratch VMID/name.
+- **Node-level config is still not yours to change by default.**
+  Creating/destroying your own scratch guests is fine; Proxmox host
+  config, storage pools, and networking on `pve-test` itself need the
+  operator's explicit go-ahead too, same as on `pve1` — the "sandbox"
+  status covers guest-level experimentation, not the host's own
+  identity. (`pve-test`'s current network config, `docs/06-pve-test-wifi-network.md`,
+  was applied under exactly that kind of explicit, same-session
+  authorization — it's not a standing invitation to keep changing it
+  further without asking again.)
+- **Never re-cluster `pve-test` with `pve1`** without the operator
+  explicitly asking for it and being aware of the wifi/corosync
+  incompatibility in `docs/06-pve-test-wifi-network.md` — the two were
+  deliberately de-clustered for this reason once already.
+
+## Safety rules
+
+- Any script in `scripts/` that isn't `audit.sh` (read-only) makes real
+  changes when run for real. Don't run one against `pve1`, or against
+  `pve-test`'s node-level config, without the same-session go-ahead
+  described above. Running a script *against pve-test's own guests* — a
+  scratch VM/CT you created for this task — doesn't need separate
+  permission.
+- Do not commit secrets: SSH private keys, wifi passphrases, sops/age
+  keys, or PVE credentials. `scripts/setup-wifi-bond-network.sh` takes
+  the SSID/passphrase via environment variables for exactly this reason
+  — never hardcode them into the script or a committed config file.
+- Live changes to a node's own management network (the interface/bridge
+  carrying the SSH session you're using) can strand the box — see the
+  "what went wrong once" section in `docs/06-pve-test-wifi-network.md`
+  before touching `pve-test`'s networking again. Prefer applying via
+  `ifreload -a` over raw `ip link` surgery, and arm an auto-revert
+  watchdog first when acting without someone physically at the console.
diff --git a/.claude/worktrees/debian-restructure/proxmox/README.md b/.claude/worktrees/debian-restructure/proxmox/README.md
new file mode 100644
index 0000000..79bc503
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/README.md
@@ -0,0 +1,55 @@
+# Proxmox Configuration
+
+Base configuration and hardening toolset for Proxmox VE hosts, plus planning
+docs for eventually growing this into a 3-node HA/Ceph cluster. See
+`docs/00-overview.md` for the staging: **Stage 1** (base config/hardening,
+applies to any host — active) vs. **Stage 2** (multi-node HA/Ceph — future,
+deferred).
+
+## Goals
+
+- Stage 1: a reusable, idempotent base-hardening toolset (`scripts/`) that
+  can be run against any new Proxmox host — repo/updates, SSH, firewall, PVE
+  user/access hardening — verified with `scripts/audit.sh`.
+- Stage 2 (future): 3-node cluster, quorum via corosync, HA-managed VMs
+  backed by Ceph. Needs dedicated hardware node 1 (`pve1`, an ASUS PN53 mini
+  PC) doesn't have — see `docs/01-hardware-node1.md`.
+
+See `CLAUDE.md` for the guardrails Claude Code follows when working
+against these hosts (`pve1` is production and off-limits by default;
+`pve-test` is the sandbox).
+
+## Repo layout
+
+- `docs/` — planning docs: hardware layout, storage migration, networking,
+  security hardening, node roles. Read `docs/00-overview.md` first, then
+  `docs/05-node-roles.md` for what `pve1`/`pve-test` actually are.
+- `scripts/` — scripts to apply configuration on a node (SSH hardening, repo
+  switch, firewall, updates, wifi/bond networking, etc). Idempotent, safe
+  to re-run. `scripts/bootstrap.sh` runs the full Stage 1 sequence end to
+  end; `scripts/audit.sh` verifies it (read-only).
+  `scripts/setup-wifi-bond-network.sh` reproduces `pve-test`'s wifi
+  network (see `docs/06-pve-test-wifi-network.md`). `scripts/lib/` holds
+  shared helpers (`common.sh`) sourced by the other scripts.
+- `config/` — reference config files/snippets to drop onto a node (firewall
+  rules, sshd config, etc.).
+
+## Quick start (Stage 1, on a fresh node)
+
+```
+MGMT_CIDR=192.168.2.0/24 ./scripts/bootstrap.sh
+./scripts/create-admin-user.sh <username>
+# then enable 2FA for that user + root@pam via the web UI
+./scripts/audit.sh
+```
+
+## Status
+
+`pve1` built (ASUS PN53 mini PC, ZFS mirror boot+VM storage, single
+2.5GbE NIC) and already running production VMs/CTs. Stage 1 base
+hardening applied and verified (`scripts/audit.sh` all green): enterprise
+repos removed, SSH key-only + fail2ban, unattended security upgrades,
+PVE firewall (mgmt-only), subscription nag disabled, named admin user
+(`wayne@pve`) created. Remaining manual step: enable 2FA/TOTP for
+`wayne@pve` and `root@pam` via the web UI. Stage 2 (cluster/Ceph) not
+started — needs nodes 2/3 on hardware that can actually support it.
diff --git a/.claude/worktrees/debian-restructure/proxmox/config/pve-firewall/cluster.fw.example b/.claude/worktrees/debian-restructure/proxmox/config/pve-firewall/cluster.fw.example
new file mode 100644
index 0000000..f25ae41
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/config/pve-firewall/cluster.fw.example
@@ -0,0 +1,44 @@
+# Example cluster-wide firewall rules for /etc/pve/firewall/cluster.fw
+#
+# Stage 1 (single host, current): only the mgmt IPSET applies. Applied
+# automatically by scripts/deploy-firewall.sh, which fills in <MGMT_CIDR>.
+#
+# Stage 2 (future cluster/Ceph): the corosync and Ceph rules below are
+# commented out placeholders. Uncomment and fill in <COROSYNC_CIDR> /
+# <CEPH_CIDR> when nodes 2/3 join and those networks actually exist -
+# leaving them active on a single node with no corosync/Ceph traffic is
+# just dead config, and a literal `<COROSYNC_CIDR>` is invalid syntax if
+# left uncommented and unfilled.
+#
+# Copy to /etc/pve/firewall/cluster.fw and edit before enabling (or use
+# scripts/deploy-firewall.sh).
+
+[OPTIONS]
+enable: 1
+policy_in: DROP
+policy_out: ACCEPT
+
+[IPSET mgmt]
+<MGMT_CIDR>
+
+[RULES]
+# Web UI + SSH only from the management network
+IN ACCEPT -source +mgmt -p tcp -dport 8006 -log nolog
+IN ACCEPT -source +mgmt -p tcp -dport 22 -log nolog
+
+# ICMP echo (ping) from the management network - diagnostic convenience
+# only, nothing else depends on it. Without this, policy_in DROP silently
+# eats ping while SSH/web UI keep working - looks like an outage during
+# troubleshooting when the host is actually fine. See
+# docs/06-pve-test-wifi-network.md for a case this caused real confusion.
+IN ACCEPT -source +mgmt -p icmp -icmp-type echo-request -log nolog
+
+# Stage 2: Corosync (cluster quorum) - uncomment once node 2/3 join and
+# the corosync network/VLAN exists.
+# IN ACCEPT -source <COROSYNC_CIDR> -p udp -dport 5404:5405 -log nolog
+
+# Stage 2: Ceph (uncomment once Ceph is live; ports: mon 3300,6789,
+# osd/mgr/mds 6800-7300)
+# IN ACCEPT -source <CEPH_CIDR> -p tcp -dport 3300 -log nolog
+# IN ACCEPT -source <CEPH_CIDR> -p tcp -dport 6789 -log nolog
+# IN ACCEPT -source <CEPH_CIDR> -p tcp -dport 6800:7300 -log nolog
diff --git a/.claude/worktrees/debian-restructure/proxmox/docs/00-overview.md b/.claude/worktrees/debian-restructure/proxmox/docs/00-overview.md
new file mode 100644
index 0000000..297c9ed
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/docs/00-overview.md
@@ -0,0 +1,116 @@
+# 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
+
+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. 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.
+
+## Stage 1: base config & hardening (active)
+
+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.
+
+**`pve-test` existing does not mean node 2 exists.** A second physical
+node (`pve-test`) does run alongside `pve1` — see `05-node-roles.md` —
+but it's a sandbox/test box, not built to this Stage 2 design, and as of
+this writing runs on **wifi** networking
+(`06-pve-test-wifi-network.md`), which is directly incompatible with
+corosync's latency/jitter requirements below. `pve-test` and `pve1` were
+briefly clustered and then deliberately de-clustered for exactly this
+reason. Don't treat `pve-test` as progress toward Stage 2 without a
+deliberate decision to rebuild its networking first.
+
+### 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
+(see `02-storage-zfs-ceph.md`). Ceph needs 3+ nodes and a fast dedicated
+network, so it can't exist until nodes 2 and 3 are up.
+
+Deliberately no intermediate "ZFS + storage replication" HA step. Node 1
+runs local ZFS for boot + VM storage with no cluster-wide HA until Ceph
+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)
+
+- 3 nodes minimum for real quorum. If starting with 2, add a QDevice
+  (small VM or Raspberry Pi) as tie-breaker.
+- Dedicated network for corosync (cluster/quorum traffic) — never shared
+  with VM or storage traffic. Needs low, consistent latency (well under
+  5ms); jitter matters more than bandwidth.
+- All nodes on the same PVE version, NTP-synced, SSH reachable between
+  nodes.
+- Set VM CPU type to a portable type (e.g. `x86-64-v2-AES` or `kvm64`)
+  rather than `host` if nodes will ever have different CPUs — needed for
+  clean live migration.
+
+### Rollout sequence (Stage 2, once dedicated cluster hardware exists)
+
+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
+   initialize Ceph across all 3 nodes.
+7. Migrate VMs from local ZFS onto Ceph-backed storage, then configure HA
+   groups.
diff --git a/.claude/worktrees/debian-restructure/proxmox/docs/01-hardware-node1.md b/.claude/worktrees/debian-restructure/proxmox/docs/01-hardware-node1.md
new file mode 100644
index 0000000..865d1bf
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/docs/01-hardware-node1.md
@@ -0,0 +1,92 @@
+# Node 1 Hardware Layout
+
+## pve1 as built (current reality)
+
+`pve1` is an ASUS PN53 mini PC (Ryzen 7 7735HS, 32GB RAM), not the
+dedicated-server hardware the target design below assumes:
+
+- **Disks**: 2x 2TB NVMe (Crucial CT2000E100SSD8), both in a single ZFS
+  mirror (`rpool`) that serves as both the boot pool and VM storage
+  (`local-zfs` = `rpool/data`). No spare disks to earmark for Ceph — the
+  chassis only has 2 NVMe slots.
+- **Network**: one physical NIC (Realtek RTL8125, 2.5GbE), bridged as
+  `vmbr0`. No second NIC for a dedicated corosync/Ceph link. (An unused
+  `nic1` stanza in `/etc/network/interfaces` is a leftover from the
+  installer template — there is no second NIC on this hardware.)
+
+This is sufficient and correct for **Stage 1** (see `00-overview.md`) —
+base config and hardening don't need split disks or multiple NICs. It is
+*not* sufficient for **Stage 2** (Ceph/HA) as designed below without
+either different hardware or a materially different plan (e.g.
+USB/Thunderbolt-attached OSD storage, which trades away the
+enterprise-SSD/PLP guidance below — not recommended, revisit when
+actually provisioning nodes 2/3). Treat everything from here down as the
+Stage 2 target design for purpose-built hardware, not a description of
+`pve1`.
+
+## Target design (Stage 2, future dedicated hardware)
+
+Build node 1 so nodes 2/3 are drop-in identical later — don't re-architect
+disks or network when the cluster grows.
+
+## Disks — two roles, physically separate devices
+
+1. **Boot/OS pool (`rpool`)** — 2x small SSDs (240-480GB plenty), ZFS
+   mirror. Proxmox itself only. Never share with Ceph OSDs.
+2. **Future Ceph OSD disks** — must end up as raw, unformatted devices —
+   no ZFS/RAID/LVM underneath (Ceph does its own replication; anything
+   underneath just doubles copy-on-write/checksumming and hurts
+   performance). Use enterprise SATA/NVMe SSDs with power-loss protection
+   (PLP) — matters far more for Ceph write latency than for general ZFS
+   use. Ceph needs 3 nodes minimum to go live, so on node 1 these disks
+   either sit idle or run as a temporary local ZFS pool (all VMs live
+   here until nodes 2/3 exist), to be wiped and handed to Ceph once the
+   cluster can actually run it. See `02-storage-zfs-ceph.md`.
+
+No permanent local-ZFS "replicated tier" — once Ceph is live, it's the
+only HA storage; local ZFS is boot pool + this temporary pre-Ceph staging
+role, not an ongoing parallel tier. Avoid consumer QLC SSDs for either
+role — Ceph punishes it on latency, ZFS on sync writes/scrub.
+
+## Networking — cable and provision for the final topology now
+
+Logically separate networks (ideally separate NICs/VLANs):
+
+- **Management** — web UI / SSH
+- **Corosync** — cluster quorum traffic, low-latency, unshared
+- **Ceph public** — VM-to-OSD traffic
+- **Ceph cluster/backend** — OSD-to-OSD replication (heaviest load)
+
+Practical layout: 2x 10/25GbE bonded or split — one pair for Ceph, one
+for mgmt + corosync + VM traffic, with corosync on its own VLAN even if
+sharing a physical NIC. Get switch/cabling right on node 1 so nodes 2/3
+are identical drops.
+
+## CPU / RAM sizing
+
+Size for the end state, not day one — RAM is the hardest thing to
+retrofit. Budget covers:
+
+- OS + ZFS ARC (ZFS wants RAM, not just disk)
+- Ceph OSD daemons — realistically 3-5GB per OSD once running
+- Actual VM workloads
+
+Roughly a core per OSD on top of what VMs need. If OSDs won't be active
+for a while, that's headway, but buy for 3 nodes' worth of eventual OSD
+load.
+
+## Backup target (PBS)
+
+Keep it off the Ceph/compute nodes if possible — its failure domain
+should be independent of the cluster. Modest separate machine or NAS:
+ZFS mirror or raidz2, ECC RAM if possible, capacity for retention policy.
+If it has to run as a VM inside the cluster short-term, that's a known
+compromise, not the end state.
+
+## Node 1 install sequence
+
+1. Install Proxmox VE fresh onto the ZFS boot mirror.
+2. Provision the Ceph-earmarked disks as a temporary local ZFS pool and
+   run all VMs from it (or leave idle if VMs aren't moving over yet).
+3. Once nodes 2/3 join and Ceph goes live: wipe this pool, hand the disks
+   to Ceph, migrate VMs onto Ceph-backed storage.
diff --git a/.claude/worktrees/debian-restructure/proxmox/docs/02-storage-zfs-ceph.md b/.claude/worktrees/debian-restructure/proxmox/docs/02-storage-zfs-ceph.md
new file mode 100644
index 0000000..f23b0b9
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/docs/02-storage-zfs-ceph.md
@@ -0,0 +1,66 @@
+# Storage: LVM-thin → ZFS → Ceph
+
+**Stage 2 (future).** Describes the target storage model once dedicated
+cluster hardware exists. `pve1`'s current single ZFS mirror (boot + VM
+storage combined, see `01-hardware-node1.md`) is the Stage 1 end state for
+now, not an intermediate step being actively migrated from.
+
+## Why move off LVM-thin
+
+Neither ZFS nor LVM-thin is shared storage — both are node-local. HA needs
+a VM's disk reachable from more than one node so it can restart elsewhere
+on host failure. LVM-thin has no answer for that. Ceph does, natively.
+
+## Storage model: single node → 3-node cluster
+
+No intermediate "ZFS + replication" HA step. The plan is deliberately a
+single storage model at the end (Ceph), not two to operate long-term:
+
+- **Single node (node 1 only)**: local ZFS pool, no cluster-wide HA. This
+  is a temporary state, not a design to build tooling around.
+- **3 nodes with Ceph live**: VMs run on Ceph-backed storage — true
+  distributed, synchronous storage across all nodes, near-zero RPO on
+  failover. Needs 3+ nodes and a fast dedicated network (see
+  `03-networking.md`), which is exactly why it can't exist before then.
+
+## Migration plan (old hardware → new hardware)
+
+Don't convert the old LVM-thin box in place. Rebuild fresh on new
+hardware with ZFS from the installer (mirror if 2+ disks), then move VMs:
+
+1. On the old host: `vzdump` each VM to a backup file (external drive,
+   NFS share, or PBS if available).
+2. Copy backups to the new host.
+3. `qmrestore` onto the new ZFS storage — disks land as ZVOLs.
+
+Alternative if both hosts can see each other on the network: temporarily
+cluster them and use the GUI "Migrate" with a storage move (offline only
+— live migration doesn't cross storage types).
+
+## Standing up Ceph once nodes 2 and 3 exist
+
+1. Wipe the temporary local ZFS pool on the Ceph-earmarked disks (see
+   `01-hardware-node1.md`) on all 3 nodes — they need to end up raw,
+   unformatted.
+2. Install the Ceph packages on all 3 nodes (`pveceph install`) and
+   initialize the cluster (`pveceph init`), using the dedicated Ceph
+   network from `03-networking.md`.
+3. Create Ceph monitors and managers (3 mons for quorum, matching node
+   count).
+4. Create OSDs directly on the raw disks on each node — no ZFS/RAID
+   underneath.
+5. Create a Ceph pool sized for your VM storage needs (replica count,
+   typically 3 for full redundancy across 3 nodes).
+6. Add the pool as PVE storage (RBD), then migrate VMs from local ZFS
+   onto it — offline migration if crossing storage types, or storage
+   migration via the GUI.
+7. Configure HA groups once VMs are on Ceph-backed storage.
+
+## Notes
+
+- Ceph RAM/CPU overhead is real — budget per `01-hardware-node1.md`
+  (roughly 3-5GB RAM and a core per OSD, on top of VM workloads).
+- Enterprise SSDs with power-loss protection (PLP) matter far more here
+  than for plain ZFS — Ceph write latency is sensitive to it.
+- Once Ceph is live, local ZFS remains only for each node's boot pool —
+  it's not a fallback tier for VM storage going forward.
diff --git a/.claude/worktrees/debian-restructure/proxmox/docs/03-networking.md b/.claude/worktrees/debian-restructure/proxmox/docs/03-networking.md
new file mode 100644
index 0000000..c03a4a1
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/docs/03-networking.md
@@ -0,0 +1,66 @@
+# Networking
+
+## pve1 as built (Stage 1, current)
+
+Single NIC (2.5GbE), single bridge `vmbr0` on the flat LAN
+(`192.168.2.0/24`), no VLANs. There is no corosync or Ceph traffic to
+separate yet — this node isn't clustered. Segmentation for Stage 1 is
+done at the firewall, not the network: `scripts/deploy-firewall.sh`
+restricts SSH (22) and the web UI (8006) to the management CIDR via the
+PVE datacenter firewall (default-deny inbound otherwise). That's
+sufficient until Stage 2 needs actual separate physical/VLAN paths for
+corosync and Ceph traffic — see below.
+
+## pve-test as built (sandbox, current)
+
+Different node, different design, not a Stage 1/2 example to generalize
+from: `pve-test` runs `vmbr0` bridged over a wifi NIC in 4addr client mode
+(active-backup bonded with a wired NIC as an automatic fallback). Full
+detail, including why this is normally impossible and how it was
+validated before trusting it with the management IP, in
+`06-pve-test-wifi-network.md`. This is intentionally a one-off for a
+standalone sandbox box — never extend it to a node that's clustered or
+Ceph-connected (see the Stage 2 note in `00-overview.md`).
+
+## Target design (Stage 2, future cluster)
+
+## Required separation
+
+Keep these on logically separate networks/VLANs, ideally separate NICs:
+
+- **Management** — web UI (8006), SSH
+- **Corosync** — cluster quorum. Low, *consistent* latency (well under
+  5ms) matters more than bandwidth. Never share with VM/storage traffic.
+- **Ceph public** — VM-to-OSD traffic (once Ceph is live)
+- **Ceph cluster/backend** — OSD-to-OSD replication, heaviest load
+
+## Practical layout
+
+2x 10/25GbE bonded or split:
+
+- Link pair A → Ceph (public + backend, or split further if 4 NICs
+  available)
+- Link pair B → management + corosync + VM traffic, with corosync on its
+  own VLAN even when sharing a physical NIC with the rest
+
+## Cluster join requirements
+
+- All nodes reachable to each other on SSH (22) and the corosync network
+- Same PVE version across nodes
+- NTP-synced clocks
+
+## Firewall
+
+Proxmox's built-in firewall operates at datacenter and node level.
+Default-deny, then whitelist:
+
+- SSH from the management network/VLAN only
+- Web UI (8006) from the management network/VLAN only
+- Corosync ports between cluster nodes
+- Ceph ports between cluster nodes (once Ceph is live)
+
+Enforce the network separation above at the firewall — corosync and Ceph
+traffic shouldn't be reachable from the VM network even if they end up
+sharing a physical link.
+
+See `config/pve-firewall/` for a starting rule set.
diff --git a/.claude/worktrees/debian-restructure/proxmox/docs/04-security-hardening.md b/.claude/worktrees/debian-restructure/proxmox/docs/04-security-hardening.md
new file mode 100644
index 0000000..995d54d
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/docs/04-security-hardening.md
@@ -0,0 +1,112 @@
+# Security Hardening
+
+Stage 1 (see `00-overview.md`) — applies to any Proxmox host, independent
+of cluster plans. Proxmox has no `sudo` out of the box — everything
+defaults to root. That's the install default, not the recommended end
+state. Two layers to harden separately.
+
+## Checklist / script mapping
+
+Run `scripts/bootstrap.sh` for everything except the admin user (needs a
+username decision) and 2FA enrollment (must be done interactively via the
+web UI — there's no safe way to script TOTP secret generation over SSH).
+Then run `scripts/audit.sh` to verify. Order matters (matches
+`bootstrap.sh`):
+
+| # | Item | Script | Manual step required? |
+|---|------|--------|------------------------|
+| 1 | Remove enterprise repos, switch to no-subscription | `switch-to-no-subscription-repo.sh` | no |
+| 2 | Linux admin user with SSH key + sudo access | `setup-linux-admin-user.sh <user> <pubkey>` | yes — choose a username and provide your SSH public key. Run this **before** SSH hardening or pass `ADMIN_USER`/`ADMIN_SSH_KEY` to `bootstrap.sh` so it runs automatically at the right point |
+| 3 | Passwordless sudo for pvesh/qm/pct | `setup-admin-sudo.sh <username>` | yes — same username as step 2 |
+| 4 | SSH: key-only root login + fail2ban | `harden-ssh.sh` | no — step 2 ensures authorized_keys are in place first |
+| 5 | Unattended security upgrades, no auto-reboot | `setup-unattended-upgrades.sh` | no |
+| 6 | PVE firewall, default-deny, mgmt-only SSH/8006 | `deploy-firewall.sh` | needs `MGMT_CIDR` set |
+| 7 | Disable subscription nag (cosmetic) | `disable-subscription-nag.sh` | no |
+| 8 | Named PVE admin user, Administrator role | `create-admin-user.sh <username>` | yes — pick the username, change the generated password on first login |
+| 9 | 2FA/TOTP on that user and `root@pam` | — | yes — web UI only: Datacenter → Permissions → Two Factor, or user menu → TFA |
+| 10 | Verify everything above | `audit.sh` | no |
+
+## Linux/SSH layer
+
+- A named Linux system user (created by `setup-linux-admin-user.sh`) with an
+  SSH authorized key and `sudo` group membership is the primary SSH login
+  account. Root SSH is locked to key-only after `harden-ssh.sh` runs; the
+  Linux admin user is how you get shell access day-to-day without using root.
+- `setup-admin-sudo.sh` adds a narrower, password-free sudoers rule for the
+  Proxmox management tools (`pvesh`, `qm`, `pct`) specifically — needed for
+  non-interactive automation scripts that SSH in and run these tools without a
+  TTY.
+- `PermitRootLogin prohibit-password` in `sshd_config` — root can only
+  log in via SSH key, never password. Kills most brute-force attempts.
+- fail2ban jail for SSH on top of that.
+- Restrict SSH to the management VLAN/trusted IPs via the Proxmox
+  firewall (see `03-networking.md`) rather than exposing broadly.
+
+## PVE/web layer (the one that actually matters day-to-day)
+
+- Keep `root@pam` for emergencies only.
+- Create a named user (e.g. `wayne@pve`) with the Administrator role for
+  routine cluster management — `create-admin-user.sh` does this, or
+  Datacenter → Permissions → Users manually.
+- Enable 2FA (TOTP or hardware key) on both that account and `root@pam`:
+  Datacenter → Permissions → Realms/Users.
+- For API integrations (monitoring, automation, Terraform, etc.), issue
+  scoped API tokens with least-privilege roles (e.g. `PVEAuditor` or a
+  custom role) — never hand out root credentials.
+
+## Firewall
+
+Default-deny at datacenter/node level, whitelist only what's needed (see
+`03-networking.md` for the specifics). Template in
+`config/pve-firewall/cluster.fw.example`, applied by
+`scripts/deploy-firewall.sh`.
+
+**ICMP echo (ping) is explicitly allowed from the management network**,
+alongside SSH/8006 — not required for anything to function, but without
+it `policy_in: DROP` silently eats ping while SSH/web UI keep working.
+That split (ping dead, everything else fine) reads exactly like a real
+outage mid-troubleshooting; see `06-pve-test-wifi-network.md` for a case
+this caused genuine confusion after a network change. If you ever debug
+"can't ping but can SSH", check this firewall before assuming the
+network itself is broken.
+
+**This file is cluster-wide, not per-node**: `cluster.fw` lives in
+`/etc/pve/firewall/` — shared via pmxcfs across every node in a cluster.
+A node that joins a cluster inherits whatever's already there, and (per
+`docs/05-node-roles.md`) keeps its own local copy after leaving. Don't
+assume a node's firewall state matches what `deploy-firewall.sh` was
+last run with directly against it — check `pve-firewall status` /
+`/etc/pve/firewall/cluster.fw` on the actual node.
+
+## Repos and updates
+
+Fresh installs point at the enterprise repo, which fails on `apt update`
+without a subscription. `scripts/switch-to-no-subscription-repo.sh`
+removes the enterprise sources entirely (renamed `.disabled`, not just
+commented out) and switches to the no-subscription repo — handles both
+the legacy `.list` format and the deb822 `.sources` format current
+installers write. Keep the host patched — hypervisor CVEs are high-value
+targets; `scripts/setup-unattended-upgrades.sh` automates security
+patches (deliberately no auto-reboot on a hypervisor — check
+`/var/run/reboot-required` and reboot during a planned window).
+
+The web UI's "No valid subscription" popup and dashboard indicator are
+cosmetic upsell, not a security control, but with no subscription they'll
+nag on every login — `scripts/disable-subscription-nag.sh` patches
+`proxmox-widget-toolkit`'s JS to suppress them, and installs an apt
+`Post-Invoke` hook that reapplies the patch automatically after every
+`apt`/`dpkg` run, since a `proxmox-widget-toolkit` package upgrade
+overwrites the patched file.
+
+## Misc
+
+- Management interface on a network you trust, not the same broadcast
+  domain as guest VM traffic.
+- If the web UI is ever needed outside the LAN, put it behind a VPN —
+  don't port-forward 8006 directly.
+
+## Further reading / not yet automated here
+
+- CIS Benchmark for Proxmox VE
+- Community PVE hardening guides (kernel parameters, audit logging,
+  storage encryption)
diff --git a/.claude/worktrees/debian-restructure/proxmox/docs/05-node-roles.md b/.claude/worktrees/debian-restructure/proxmox/docs/05-node-roles.md
new file mode 100644
index 0000000..7d16298
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/docs/05-node-roles.md
@@ -0,0 +1,83 @@
+# Node Roles: pve1 and pve-test
+
+Two Proxmox VE hosts exist on the LAN. They are **not interchangeable** —
+different purpose, different risk tolerance, different guardrails. See
+`CLAUDE.md` for the actual rules Claude follows; this doc is the
+background/context those rules assume.
+
+## pve1 (production)
+
+ASUS PN53 mini PC (Ryzen 7 7735HS, 32GB RAM) — see `01-hardware-node1.md`
+for the full hardware layout. Stage 1 base hardening applied and verified
+(`04-security-hardening.md`).
+
+Runs real production workloads:
+
+- `server-nixos` (VM) and LXC containers `pihole`, `claude`, `nix-cache`,
+  `docker`, `pdm`, `pxe-boot` — DNS, this Claude Code environment itself,
+  the LAN's Nix binary cache, etc.
+
+Off-limits to Claude by default — see `CLAUDE.md`.
+
+## pve-test (sandbox)
+
+A separate physical node kept for testing. Has a capable GPU (earmarked
+for future GPU workloads — transcoding, local inference, etc. — nothing
+built on it yet as of this writing). No production guests run here.
+
+Safe for Claude to create/destroy scratch VMs and containers on without
+asking — see `CLAUDE.md` for the exact boundary (node-level config is
+still not free-for-all even here).
+
+### History: briefly clustered with pve1, then deliberately separated
+
+On 2026-07-21/22, pve-test was joined to pve1 in a 2-node Proxmox cluster
+(corosync + shared `/etc/pve`) for a period, then the cluster was
+**intentionally destroyed** at the operator's explicit request — not a
+failure or accident. Rationale: the operator wanted pve-test moved onto
+wifi networking (see `06-pve-test-wifi-network.md`), and wifi is
+fundamentally unsuitable for corosync's latency/jitter requirements (token
+timeouts, flapping membership). Rather than fight that, the cluster was
+torn down first, then wifi was configured on the now-standalone node.
+
+Teardown procedure used (safe to repeat if pve-test or pve1 is ever
+reclustered and needs separating again):
+
+1. Un-manage any HA-assigned resources first if HA is in use
+   (`ha-manager remove <sid>` per resource) — **critical**: if a node has
+   HA-managed guests and its watchdog is still armed when it loses
+   quorum, HA's self-fence behavior can force-reboot it. Removing the
+   resource assignments first (not stopping the guests — just
+   un-managing them) prevents this.
+2. Stop `pve-ha-lrm`/`pve-ha-crm` on all nodes once no resources remain
+   assigned, confirm via `ha-manager status` that fencing is no longer
+   armed.
+3. From a node that will remain in the cluster: `pvecm delnode <name>`
+   for the node being removed. In a 2-node cluster with no QDevice, this
+   can itself cause the *remaining* node to transiently lose quorum
+   (killing a node's live corosync membership drops total votes below
+   expected votes before the nodelist file can be rewritten to match) —
+   this is expected, not a failure; proceed to step 4 regardless.
+4. On **each** node being separated (including one you just ran `delnode`
+   from, if it's also being decoupled): `systemctl stop pve-cluster
+   corosync`, `pmxcfs -l` (local mode, bypasses the quorum requirement
+   for local writes), remove `/etc/pve/corosync.conf` and
+   `/etc/corosync/*`, `killall pmxcfs`, `systemctl start pve-cluster`.
+   This is the official "separate a node without reinstalling" procedure
+   and doesn't touch any running VM/CT — they're independent OS
+   processes, unaffected by corosync/pmxcfs state either way.
+5. Optional cosmetic cleanup: the node(s) staying up may retain a stale
+   `/etc/pve/nodes/<removed-node>/` directory (cached VM/CT configs from
+   when they were clustered) — safe to `rm -rf` once separation is
+   confirmed; it's dead data, not a live reference to anything.
+
+Guests were never at risk during this procedure (confirmed: all 7 of
+pve1's guests ran continuously throughout) — the only real hazard is the
+HA/watchdog self-fence path in step 1, and losing corosync-provided quorum
+temporarily blocking `/etc/pve` writes (not guest execution) in step 3.
+
+### Current state: standalone, wifi-primary networking
+
+pve-test now runs entirely independently of pve1, on the network design
+documented in `06-pve-test-wifi-network.md`. **Do not re-cluster
+pve-test while it's on wifi** — see that doc for why.
diff --git a/.claude/worktrees/debian-restructure/proxmox/docs/06-pve-test-wifi-network.md b/.claude/worktrees/debian-restructure/proxmox/docs/06-pve-test-wifi-network.md
new file mode 100644
index 0000000..f77900f
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/docs/06-pve-test-wifi-network.md
@@ -0,0 +1,191 @@
+# pve-test's Wifi-Primary Network
+
+Non-standard, deliberately chosen against normal Proxmox guidance (a
+hypervisor's management network is not supposed to be wireless). Applies
+**only** to `pve-test` as a standalone sandbox node — see
+`05-node-roles.md` for why this and cluster membership don't mix, and
+never apply this pattern to a node that's joined (or might join) a
+cluster.
+
+## Why this works at all
+
+Wifi (802.11) normally cannot be bridged the way Ethernet can: an access
+point only accepts frames whose source MAC matches the MAC that
+associated with it. A Linux bridge with a wifi port as a member sends
+frames tagged with whatever MAC actually generated them (the bridge's own
+MAC, a VM's MAC, etc.) — none of which match the wifi card's hardware
+MAC, so the AP silently drops them. This isn't a Linux/Proxmox limitation,
+it's how WiFi association works.
+
+**4addr (WDS) client mode** is the exception: if both the wifi driver and
+the AP support it, the client tags frames with a 4th address field
+carrying the original MAC, and the AP forwards them like a real Ethernet
+segment. Most consumer routers do **not** support this (it's common on
+OpenWrt/DD-WRT/enterprise APs, rare on stock ISP hardware) — it has to be
+confirmed empirically, per-AP, before trusting it with a management IP.
+
+pve-test's card (Intel AX200, `iwlwifi` driver, interface `wlp3s0`)
+supports 4addr client-side generically (this is a `mac80211` core
+feature, not driver-specific). The home AP it associates to
+(`nbn-fttp-net-5G`) was confirmed to honor it — see validation method
+below.
+
+## Validate before ever touching a live management IP
+
+Don't add the wifi NIC straight into your real bridge to "see if it
+works" — if 4addr isn't actually honored, you lose access to the box with
+no diagnostic trail (association succeeds; only the *data plane* silently
+fails). Test in an isolated scratch namespace first:
+
+```bash
+# assumes wlp3s0 already associated with 4addr on (see systemd unit below)
+ip link add testbr0 type bridge && ip link set testbr0 up
+ip link set wlp3s0 master testbr0 && ip link set wlp3s0 up
+
+ip netns add wifitest
+ip link add veth-host type veth peer name veth-ns
+ip link set veth-host master testbr0 && ip link set veth-host up
+ip link set veth-ns netns wifitest
+ip netns exec wifitest ip link set veth-ns address 02:11:22:33:44:55  # deliberately NOT the wifi card's MAC
+ip netns exec wifitest ip link set veth-ns up
+ip netns exec wifitest ip link set lo up
+
+ip netns exec wifitest dhclient -v -1 veth-ns   # real DHCP lease = AP forwards foreign MACs = 4addr genuinely works
+```
+
+If that gets a lease (or at minimum a ping reply from the gateway) from a
+MAC that was never the one that associated, the AP is forwarding
+arbitrary-MAC frames — real bridge mode will work. If not, don't proceed
+to bridge mode; fall back to a routed/NAT design instead (wifi gets its
+own IP via DHCP, VMs NAT out through it — never covered here since it
+wasn't needed, but keep this fallback in mind if reproducing on different
+hardware/AP).
+
+Tear the test namespace/bridge down afterwards (`ip netns del wifitest;
+ip link del veth-host; ip link set wlp3s0 nomaster; ip link del testbr0`)
+— it's scratch, not part of the real config.
+
+## Final architecture
+
+```
+wlp3s0 (wifi, 4addr client mode) ─┐
+                                    ├─ bond0 (active-backup, wlp3s0 primary) ─ vmbr0 (192.168.2.251/24)
+nic0 (wired, LAN backup)          ─┘
+```
+
+- **`wpa-4addr-<iface>.service`** (systemd unit, `Before=network-pre.target`) —
+  sets 4addr mode and starts `wpa_supplicant` *before* ifupdown2 processes
+  `/etc/network/interfaces`. Deliberately not using `wpasupplicant`'s own
+  `wpa-conf` ifupdown2 hook integration — its ordering relative to a
+  custom `pre-up iw ... set 4addr on` line is implementation-specific and
+  not worth gambling on for something this hard to debug if it's wrong.
+  The systemd unit gives full, deterministic control over sequencing
+  instead.
+- **`bond0`** — active-backup bonding, `wlp3s0` as `bond-primary`,
+  `nic0` as backup, `bond-miimon 100`. Bonding a wifi interface works here
+  because `mac80211`/`iwlwifi` properly reports carrier state
+  (`netif_carrier_on/off`) on association/disassociation, which is what
+  bonding's `miimon` (with the default `use_carrier=1`) actually watches
+  — it doesn't require a "real" MII-capable NIC.
+- **`vmbr0`** — unchanged IP (`192.168.2.251/24`), bridged over `bond0`
+  instead of directly over a physical NIC.
+
+Reproduce with `scripts/setup-wifi-bond-network.sh` — see its header
+comment for usage and required env vars (SSID/passphrase, management
+address/gateway). It stages `/etc/network/interfaces` and the systemd
+unit but does **not** auto-apply (`ifreload -a`) — see the next section
+for why that step needs care, not automation.
+
+## Applying a live bridge-port change: what went wrong once, and what worked
+
+Moving `vmbr0`'s underlying port live — while SSH'd in over the very
+address that lives on that bridge — is inherently risky: if the new port
+doesn't actually pass traffic, you lose the connection you're using to
+fix it.
+
+**What failed**: doing the port swap via raw `ip link set nic0 nomaster`
++ `ip link set nic0 down` (with `wlp3s0` already added as a second bridge
+member) caused an extended outage that needed a physical power-cycle to
+recover — `nic0` never came back up on its own even well past a 60s
+auto-revert watchdog's deadline. Importantly, the *host itself* never
+crashed — `journalctl -b -1` showed completely normal operation (a
+`pvestatd` polling loop, no gaps, no panic/OOM/watchdog trigger) right up
+until a keyboard was plugged in and it was manually reset. So the failure
+was specifically in the live network transition, not the OS — root cause
+unconfirmed, but plausibly bridge FDB/MAC-identity handling when a port
+carrying an already-live IP is swapped out via raw `ip link` rather than
+a coordinated reconfiguration.
+
+**What worked**: writing the final state into `/etc/network/interfaces`
+and applying with `ifreload -a` (Proxmox's own supported hot-reload path)
+instead. Same end state, same risk window, but ifupdown2 evidently
+sequences the transition in a way raw `ip link` surgery didn't. This
+succeeded on the first retry using this method.
+
+**Either way, expect ~30-60 seconds of apparent breakage even on a
+successful change** — the upstream switch/AP needs to relearn which port
+`192.168.2.251`'s MAC now lives behind. Don't judge success/failure
+before that window passes; a `ping`/SSH failure at the 5-10s mark is not
+yet a sign anything is wrong.
+
+**Recommended safety net for any future live change here**: arm a
+backgrounded auto-revert-on-timeout before applying, e.g.:
+
+```bash
+cp /etc/network/interfaces /etc/network/interfaces.bak
+cat > /root/revert.sh <<'EOF'
+#!/bin/bash
+cp /etc/network/interfaces.bak /etc/network/interfaces
+ifreload -a
+EOF
+chmod +x /root/revert.sh
+setsid nohup bash -c "sleep 45 && /root/revert.sh" >/root/revert.log 2>&1 < /dev/null &
+disown
+# now apply the real change, e.g.: ifreload -a
+# once confirmed working: pkill -f "sleep 45 && /root/revert.sh"
+```
+
+This only self-heals if the box stays responsive enough for the
+backgrounded job to run to completion — it is not a substitute for
+physical/console access being available, just a way to avoid needing it
+for the common case.
+
+## Troubleshooting: "can't ping it, web UI won't load" isn't necessarily an outage
+
+Two independent things can make `pve-test` look dead when it isn't:
+
+1. **Stale ARP after any change to `vmbr0`'s active port.** `vmbr0`'s MAC
+   address follows whichever interface is currently active in `bond0`
+   (`wlp3s0`'s MAC while wifi is primary, `nic0`'s if it fails over) — it
+   is *not* fixed. Other devices on the LAN (including your own
+   workstation) that cached the old MAC before a change won't notice
+   until their ARP entry naturally expires or gets flushed
+   (`ip neigh flush <ip>` / `arp -d <ip>`). Symptom: intermittent or
+   totally dead connectivity from one specific device while others (or
+   the host itself) are fine.
+2. **ICMP ping is blocked by the management firewall, unrelated to
+   network health.** See `04-security-hardening.md`'s firewall section —
+   `cluster.fw`'s `policy_in: DROP` only explicitly allows TCP 22/8006
+   (now also ICMP echo-request, after this was hit) from the mgmt
+   network. Before that rule was added, `ping` failed 100% *even with a
+   perfectly correct, fresh ARP entry and full SSH/web UI access* —
+   nothing to do with wifi, bonding, or the network being down. This is
+   exactly what happened once: alarming "can't ping, web UI not loading"
+   turned out to be a stale-ARP moment (which resolved itself) plus a
+   pre-existing firewall policy (ping was never going to work,
+   regardless of wifi).
+
+**When `pve-test` seems unreachable, check in this order before assuming
+a real outage**: SSH (`ssh root@pve-test.sweet.home`) → web UI via `curl
+-sk -o /dev/null -w '%{http_code}' https://pve-test.sweet.home:8006/` →
+only then worry about `ping` specifically, and check
+`/etc/pve/firewall/cluster.fw` before blaming the network.
+
+## Known limitation history
+
+`nic0` (the bond's backup slave) initially had no cable physically
+connected when this was first set up — the bond was correctly configured
+but inert until a cable was plugged in. As of this writing a cable is
+connected and the backup slave is live (confirm with `cat
+/proc/net/bonding/bond0`) — if reproducing this setup, verify the same
+before assuming LAN failover will actually work.
diff --git a/.claude/worktrees/debian-restructure/proxmox/scripts/audit.sh b/.claude/worktrees/debian-restructure/proxmox/scripts/audit.sh
new file mode 100755
index 0000000..f06c500
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/scripts/audit.sh
@@ -0,0 +1,133 @@
+#!/bin/bash
+# Read-only Stage 1 base-hardening audit. Checks the current state of a PVE
+# host against the checklist in docs/04-security-hardening.md and prints
+# PASS/FAIL per item. Exits non-zero if anything fails, so it can gate CI or
+# be run periodically as a compliance check. Makes no changes.
+#
+# Usage: ./audit.sh   (run as root on the PVE host)
+set -uo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+# shellcheck source=lib/common.sh
+source "${SCRIPT_DIR}/lib/common.sh"
+require_root
+
+AUDIT_FAIL=0
+
+# --- apt repos: no enabled enterprise source ---
+ENTERPRISE_ENABLED=0
+for f in /etc/apt/sources.list.d/*.sources /etc/apt/sources.list.d/*.list; do
+    [ -f "$f" ] || continue
+    grep -qi 'enterprise.proxmox.com' "$f" 2>/dev/null && ENTERPRISE_ENABLED=1
+done
+if [ "$ENTERPRISE_ENABLED" -eq 0 ]; then
+    audit_pass "no enabled enterprise apt repo"
+else
+    audit_fail "an enterprise apt repo is still enabled (needs a subscription to update)"
+fi
+
+# --- SSH ---
+SSHD_T="$(sshd -T 2>/dev/null)"
+if echo "$SSHD_T" | grep -qiE '^permitrootlogin (prohibit-password|without-password)'; then
+    audit_pass "sshd: PermitRootLogin prohibit-password (key-only)"
+else
+    audit_fail "sshd: PermitRootLogin is not key-only (prohibit-password/without-password)"
+fi
+if echo "$SSHD_T" | grep -qi '^passwordauthentication no'; then
+    audit_pass "sshd: PasswordAuthentication no"
+else
+    audit_fail "sshd: PasswordAuthentication is not disabled"
+fi
+
+# --- fail2ban ---
+if systemctl is-active --quiet fail2ban 2>/dev/null; then
+    audit_pass "fail2ban is active"
+else
+    audit_fail "fail2ban is not active"
+fi
+
+# --- PVE firewall ---
+FW_STATUS="$(pve-firewall status 2>/dev/null || true)"
+if echo "$FW_STATUS" | grep -qi '^Status: enabled'; then
+    audit_pass "pve-firewall is enabled"
+else
+    audit_fail "pve-firewall is not enabled (status: ${FW_STATUS:-unknown})"
+fi
+if [ -f /etc/pve/firewall/cluster.fw ] && grep -qi '^policy_in:\s*DROP' /etc/pve/firewall/cluster.fw 2>/dev/null; then
+    audit_pass "cluster.fw has default-deny inbound policy"
+else
+    audit_fail "cluster.fw missing or does not default-deny inbound"
+fi
+
+# --- unattended-upgrades ---
+if dpkg -s unattended-upgrades >/dev/null 2>&1 && systemctl is-enabled --quiet unattended-upgrades 2>/dev/null; then
+    audit_pass "unattended-upgrades installed and enabled"
+else
+    audit_fail "unattended-upgrades not installed/enabled"
+fi
+if [ -f /var/run/reboot-required ]; then
+    audit_warn "a reboot is pending (/var/run/reboot-required) - schedule one"
+fi
+
+# --- Linux admin user with SSH key (for non-root SSH login) ---
+LINUX_ADMIN_OK=0
+for auth_file in /home/*/.ssh/authorized_keys; do
+    [ -f "$auth_file" ] || continue
+    # Must have at least one non-comment, non-empty key line.
+    if grep -qE '^(ssh-rsa|ssh-ed25519|ecdsa-sha2-nistp[0-9]+) ' "$auth_file" 2>/dev/null; then
+        LINUX_ADMIN_OK=1
+        break
+    fi
+done
+if [ "$LINUX_ADMIN_OK" -eq 1 ]; then
+    audit_pass "a non-root Linux user has an SSH authorized key"
+else
+    audit_fail "no non-root Linux user has an authorized SSH key (run setup-linux-admin-user.sh)"
+fi
+
+# --- named admin user (not just root@pam) ---
+if pveum user list --output-format json 2>/dev/null | grep -q '"userid":"[^"]*@pve"'; then
+    audit_pass "a named @pve admin user exists (root@pam is not the only account)"
+else
+    audit_fail "no named @pve user found - root@pam is the only account"
+fi
+
+# --- passwordless sudo for pvesh/qm/pct ---
+# The nixos flake's create-proxmox-resource.sh runs pvesh/qm/pct over
+# non-interactive SSH, so the admin user needs NOPASSWD for these tools.
+SUDO_OK=0
+for f in /etc/sudoers.d/*-proxmox; do
+    [ -f "$f" ] || continue
+    if grep -qE 'NOPASSWD:.*pvesh' "$f" && grep -qE 'NOPASSWD:.*\bqm\b' "$f" && grep -qE 'NOPASSWD:.*\bpct\b' "$f"; then
+        SUDO_OK=1
+        break
+    fi
+done
+if [ "$SUDO_OK" -eq 1 ]; then
+    audit_pass "admin user has NOPASSWD sudo for pvesh/qm/pct"
+else
+    audit_fail "no sudoers file grants NOPASSWD for pvesh/qm/pct (run setup-admin-sudo.sh <username>)"
+fi
+
+# --- time sync ---
+if timedatectl show -p NTPSynchronized --value 2>/dev/null | grep -qx 'yes'; then
+    audit_pass "clock is NTP-synchronized"
+else
+    audit_fail "clock is not NTP-synchronized"
+fi
+
+# --- subscription nag (cosmetic - warn only, never fails the audit) ---
+JS_FILE="/usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js"
+if [ -f "$JS_FILE" ] && ! grep -qF "data.status.toLowerCase() !== 'active'" "$JS_FILE"; then
+    audit_pass "subscription nag patch applied"
+else
+    audit_warn "subscription nag patch not applied (cosmetic only, see scripts/disable-subscription-nag.sh)"
+fi
+
+echo
+if [ "$AUDIT_FAIL" -eq 0 ]; then
+    echo "All Stage 1 base-hardening checks passed."
+else
+    echo "One or more checks failed - see FAIL lines above."
+fi
+exit "$AUDIT_FAIL"
diff --git a/.claude/worktrees/debian-restructure/proxmox/scripts/bootstrap.sh b/.claude/worktrees/debian-restructure/proxmox/scripts/bootstrap.sh
new file mode 100755
index 0000000..9b82a05
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/scripts/bootstrap.sh
@@ -0,0 +1,67 @@
+#!/bin/bash
+# Stage 1 base config + hardening, end to end, for a single fresh PVE host.
+# Runs the individual scripts in order. Idempotent - safe to re-run.
+#
+# If ADMIN_USER and ADMIN_SSH_KEY are set, a Linux system user is created
+# with SSH key access and sudo before SSH hardening runs - so key-based
+# login is in place before password auth is disabled. If they are not set,
+# a reminder is printed at the end to run setup-linux-admin-user.sh manually
+# (but do this BEFORE disconnecting, since password auth will be disabled).
+#
+# Usage:
+#   MGMT_CIDR=192.168.2.0/24 ./bootstrap.sh
+#   MGMT_CIDR=192.168.2.0/24 ADMIN_USER=wayne ADMIN_SSH_KEY="ssh-ed25519 ..." ./bootstrap.sh
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+# shellcheck source=lib/common.sh
+source "${SCRIPT_DIR}/lib/common.sh"
+require_root
+
+if [ -z "${MGMT_CIDR:-}" ]; then
+    echo "MGMT_CIDR is not set. Example: MGMT_CIDR=192.168.2.0/24 $0" >&2
+    exit 1
+fi
+
+STEP=0
+next_step() { STEP=$((STEP + 1)); echo; echo "=== ${STEP}: $* ==="; }
+
+next_step "remove enterprise repos, switch to no-subscription"
+"${SCRIPT_DIR}/switch-to-no-subscription-repo.sh"
+
+# Create the Linux admin user before SSH hardening so that authorized_keys
+# is in place before password auth is disabled.
+if [ -n "${ADMIN_USER:-}" ] && [ -n "${ADMIN_SSH_KEY:-}" ]; then
+    next_step "Linux admin user '${ADMIN_USER}' + SSH key + sudo group"
+    "${SCRIPT_DIR}/setup-linux-admin-user.sh" "$ADMIN_USER" "$ADMIN_SSH_KEY"
+
+    next_step "passwordless sudo for pvesh/qm/pct (${ADMIN_USER})"
+    "${SCRIPT_DIR}/setup-admin-sudo.sh" "$ADMIN_USER"
+else
+    echo
+    echo "WARNING: ADMIN_USER / ADMIN_SSH_KEY not set -- skipping Linux user setup."
+    echo "  Run setup-linux-admin-user.sh and setup-admin-sudo.sh BEFORE disconnecting"
+    echo "  from this session, since the next step disables password authentication."
+fi
+
+next_step "SSH hardening (key-only root login + fail2ban)"
+"${SCRIPT_DIR}/harden-ssh.sh"
+
+next_step "unattended security upgrades"
+"${SCRIPT_DIR}/setup-unattended-upgrades.sh"
+
+next_step "PVE firewall (mgmt-only SSH/8006)"
+MGMT_CIDR="$MGMT_CIDR" "${SCRIPT_DIR}/deploy-firewall.sh"
+
+next_step "disable subscription nag (cosmetic)"
+"${SCRIPT_DIR}/disable-subscription-nag.sh"
+
+echo
+echo "=== Base hardening applied. Remaining manual/deliberate steps: ==="
+if [ -z "${ADMIN_USER:-}" ]; then
+    echo "  - ${SCRIPT_DIR}/setup-linux-admin-user.sh <username> <ssh-pubkey>"
+    echo "  - ${SCRIPT_DIR}/setup-admin-sudo.sh <username>   (NOPASSWD for pvesh/qm/pct)"
+fi
+echo "  - ${SCRIPT_DIR}/create-admin-user.sh <username>   (PVE web UI account)"
+echo "  - Enable 2FA/TOTP for that user and root@pam via the web UI"
+echo "  - ${SCRIPT_DIR}/audit.sh   (verify everything above)"
diff --git a/.claude/worktrees/debian-restructure/proxmox/scripts/create-admin-user.sh b/.claude/worktrees/debian-restructure/proxmox/scripts/create-admin-user.sh
new file mode 100755
index 0000000..a172e22
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/scripts/create-admin-user.sh
@@ -0,0 +1,43 @@
+#!/bin/bash
+# Create a named PVE admin user (Administrator role) so root@pam can be
+# reserved for emergencies. Generates a random initial password, printed
+# once - change it and enable TOTP on first login (Datacenter -> Permissions
+# -> Two Factor, or the user icon menu in the top right).
+#
+# Idempotent - if the user already exists, does nothing (won't reset an
+# existing password). Run as root on the PVE host.
+#
+# Usage: ./create-admin-user.sh <username>   (realm is always @pve)
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+# shellcheck source=lib/common.sh
+source "${SCRIPT_DIR}/lib/common.sh"
+require_root
+
+USERNAME="${1:-}"
+if [ -z "$USERNAME" ]; then
+    echo "Usage: $0 <username>" >&2
+    exit 1
+fi
+
+USERID="${USERNAME}@pve"
+
+if pveum user list --output-format json 2>/dev/null | grep -q "\"${USERID}\""; then
+    echo "${USERID} already exists - not touching password or role. Skipping."
+    exit 0
+fi
+
+PASSWORD="$(openssl rand -base64 24)"
+
+pveum user add "$USERID" --password "$PASSWORD" --comment "Named admin account, created by create-admin-user.sh"
+pveum acl modify / --users "$USERID" --roles Administrator
+
+echo
+echo "Created ${USERID} with the Administrator role."
+echo "Initial password (shown once - not logged anywhere): ${PASSWORD}"
+echo
+echo "Next steps (do these before relying on this account):"
+echo "  1. Log in as ${USERID} and change the password."
+echo "  2. Enable TOTP/2FA for ${USERID} (and for root@pam)."
+echo "  3. Reserve root@pam for emergencies only from here on."
diff --git a/.claude/worktrees/debian-restructure/proxmox/scripts/deploy-firewall.sh b/.claude/worktrees/debian-restructure/proxmox/scripts/deploy-firewall.sh
new file mode 100755
index 0000000..d6f4b69
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/scripts/deploy-firewall.sh
@@ -0,0 +1,48 @@
+#!/bin/bash
+# Deploy the Proxmox datacenter-level firewall from
+# config/pve-firewall/cluster.fw.example, with the management CIDR filled
+# in, and enable it. Default-deny inbound; allow SSH/8006 from mgmt only.
+#
+# Idempotent - safe to re-run. Run as root on the PVE host.
+#
+# Usage: MGMT_CIDR=192.168.2.0/24 ./deploy-firewall.sh
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+# shellcheck source=lib/common.sh
+source "${SCRIPT_DIR}/lib/common.sh"
+require_root
+
+if [ -z "${MGMT_CIDR:-}" ]; then
+    echo "MGMT_CIDR is not set. Example: MGMT_CIDR=192.168.2.0/24 $0" >&2
+    exit 1
+fi
+
+if ! [[ "$MGMT_CIDR" =~ ^([0-9]{1,3}\.){3}[0-9]{1,3}/[0-9]{1,2}$ ]]; then
+    echo "MGMT_CIDR '${MGMT_CIDR}' doesn't look like a CIDR (e.g. 192.168.2.0/24)." >&2
+    exit 1
+fi
+
+TEMPLATE="${SCRIPT_DIR}/../config/pve-firewall/cluster.fw.example"
+if [ ! -f "$TEMPLATE" ]; then
+    echo "Template not found: $TEMPLATE" >&2
+    exit 1
+fi
+
+# Corosync/Ceph rules stay commented placeholders until Stage 2 (cluster);
+# only the mgmt IPSET is real for a single Stage 1 node.
+mkdir -p /etc/pve/firewall
+write_if_changed "/etc/pve/firewall/cluster.fw" "$(sed "s|<MGMT_CIDR>|${MGMT_CIDR}|" "$TEMPLATE")"
+
+echo "Validating ruleset..."
+pve-firewall compile
+
+echo "Restarting pve-firewall..."
+pve-firewall restart
+sleep 1
+pve-firewall status
+
+echo
+echo "Firewall enabled. SSH (22) and the web UI (8006) are now only reachable"
+echo "from ${MGMT_CIDR}. If your current SSH session is NOT from that range,"
+echo "reconnect and verify access before closing this session."
diff --git a/.claude/worktrees/debian-restructure/proxmox/scripts/disable-subscription-nag.sh b/.claude/worktrees/debian-restructure/proxmox/scripts/disable-subscription-nag.sh
new file mode 100755
index 0000000..a37fa6d
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/scripts/disable-subscription-nag.sh
@@ -0,0 +1,24 @@
+#!/bin/bash
+# Install the subscription-nag patch (lib/nag-patch.sh) as a persistent
+# standalone script under /usr/local/sbin, plus an apt Post-Invoke hook that
+# re-applies it after every dpkg run - a proxmox-widget-toolkit package
+# upgrade overwrites the patched file, so without the hook the patch would
+# silently revert on the next `apt upgrade`.
+#
+# Idempotent - safe to re-run. Run as root on the PVE host.
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+# shellcheck source=lib/common.sh
+source "${SCRIPT_DIR}/lib/common.sh"
+require_root
+
+INSTALLED="/usr/local/sbin/pve-disable-subscription-nag.sh"
+write_if_changed "$INSTALLED" "$(cat "${SCRIPT_DIR}/lib/nag-patch.sh")"
+chmod +x "$INSTALLED"
+
+HOOK="/etc/apt/apt.conf.d/85pve-nosubnag"
+write_if_changed "$HOOK" 'DPkg::Post-Invoke { "test -x /usr/local/sbin/pve-disable-subscription-nag.sh && /usr/local/sbin/pve-disable-subscription-nag.sh || true"; };'
+
+"$INSTALLED"
+echo "Subscription nag patch installed; will reapply automatically after updates."
diff --git a/.claude/worktrees/debian-restructure/proxmox/scripts/harden-ssh.sh b/.claude/worktrees/debian-restructure/proxmox/scripts/harden-ssh.sh
new file mode 100755
index 0000000..081f53e
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/scripts/harden-ssh.sh
@@ -0,0 +1,43 @@
+#!/bin/bash
+# Apply baseline SSH hardening to a Proxmox VE node: key-only root login
+# + fail2ban. Idempotent - safe to re-run. Run as root on the PVE host.
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+# shellcheck source=lib/common.sh
+source "${SCRIPT_DIR}/lib/common.sh"
+require_root
+
+if ! authorized_keys_present=$(find /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys -type f 2>/dev/null | head -n1); then
+    authorized_keys_present=""
+fi
+if [ -z "$authorized_keys_present" ]; then
+    echo "WARNING: no authorized_keys found for any user yet." >&2
+    echo "Add your SSH public key before disconnecting, or you'll lock yourself out." >&2
+fi
+
+mkdir -p /etc/ssh/sshd_config.d
+write_if_changed "/etc/ssh/sshd_config.d/99-hardening.conf" "PermitRootLogin prohibit-password
+PasswordAuthentication no"
+
+sshd -t
+systemctl reload sshd
+echo "sshd reloaded with key-only root login."
+
+if ! dpkg -s fail2ban >/dev/null 2>&1; then
+    apt-get update
+    apt-get install -y fail2ban
+fi
+
+mkdir -p /etc/fail2ban/jail.d
+write_if_changed "/etc/fail2ban/jail.d/sshd.local" "[sshd]
+enabled = true
+port = ssh
+backend = systemd
+maxretry = 5
+bantime = 1h
+findtime = 10m"
+
+systemctl enable --now fail2ban
+systemctl restart fail2ban
+echo "fail2ban enabled for sshd."
diff --git a/.claude/worktrees/debian-restructure/proxmox/scripts/lib/common.sh b/.claude/worktrees/debian-restructure/proxmox/scripts/lib/common.sh
new file mode 100755
index 0000000..10035ed
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/scripts/lib/common.sh
@@ -0,0 +1,47 @@
+#!/bin/bash
+# Shared helpers for proxmox-configuration scripts. Sourced, not executed
+# directly:
+#   SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+#   source "${SCRIPT_DIR}/lib/common.sh"
+
+require_root() {
+    if [ "$(id -u)" -ne 0 ]; then
+        echo "Must run as root." >&2
+        exit 1
+    fi
+}
+
+# Codename of the running Debian/PVE release, e.g. "trixie".
+pve_codename() {
+    (. /etc/os-release && echo "$VERSION_CODENAME")
+}
+
+# backup_file <path>
+# Copies an existing file to <path>.bak.<epoch>. No-op if it doesn't exist.
+backup_file() {
+    local path="$1"
+    if [ -f "$path" ]; then
+        cp "$path" "${path}.bak.$(date +%s)"
+        echo "Backed up ${path}"
+    fi
+}
+
+# write_if_changed <path> <content>
+# Writes content to path only if it differs from what's already there,
+# backing up the previous version first. Prints what happened.
+write_if_changed() {
+    local path="$1" content="$2"
+    if [ -f "$path" ] && [ "$(cat "$path")" = "$content" ]; then
+        echo "Already up to date: $path"
+        return 0
+    fi
+    backup_file "$path"
+    printf '%s\n' "$content" > "$path"
+    echo "Wrote $path"
+}
+
+# --- audit.sh status helpers ---
+# Callers should initialize: AUDIT_FAIL=0
+audit_pass() { echo "PASS  $1"; }
+audit_fail() { echo "FAIL  $1"; AUDIT_FAIL=1; }
+audit_warn() { echo "WARN  $1"; }
diff --git a/.claude/worktrees/debian-restructure/proxmox/scripts/lib/nag-patch.sh b/.claude/worktrees/debian-restructure/proxmox/scripts/lib/nag-patch.sh
new file mode 100755
index 0000000..7f08924
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/scripts/lib/nag-patch.sh
@@ -0,0 +1,22 @@
+#!/bin/bash
+# Neutralizes the Proxmox "No valid subscription" nag (login popup and the
+# dashboard subscription indicator) by patching proxmox-widget-toolkit's
+# proxmoxlib.js. Cosmetic only - doesn't create or spoof a subscription
+# anywhere except this UI check.
+#
+# This file is not run from the repo directly - disable-subscription-nag.sh
+# installs a copy of it to /usr/local/sbin and wires it into an apt
+# Post-Invoke hook, because a proxmox-widget-toolkit package upgrade
+# overwrites proxmoxlib.js and reverts the patch. Idempotent: exits quietly
+# if already patched or if the file isn't present.
+set -euo pipefail
+
+JS_FILE="/usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js"
+[ -f "$JS_FILE" ] || exit 0
+
+PATTERN="data.status.toLowerCase() !== 'active'"
+grep -qF "$PATTERN" "$JS_FILE" || exit 0
+
+cp "$JS_FILE" "${JS_FILE}.bak.$(date +%s)"
+sed -i "s/${PATTERN}/false/g" "$JS_FILE"
+echo "Patched subscription nag in $JS_FILE"
diff --git a/.claude/worktrees/debian-restructure/proxmox/scripts/setup-admin-sudo.sh b/.claude/worktrees/debian-restructure/proxmox/scripts/setup-admin-sudo.sh
new file mode 100755
index 0000000..ae1f426
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/scripts/setup-admin-sudo.sh
@@ -0,0 +1,61 @@
+#!/bin/bash
+# Grant a named admin user passwordless sudo for Proxmox management tools
+# (pvesh, qm, pct) and the Nix package manager so that scripts in the
+# nixos flake repo can run these over non-interactive SSH without a TTY.
+#
+# Nix is included because single-user Nix installations (common on PVE
+# hosts bootstrapped via codex-setup.sh) are owned by root; non-root
+# users can't touch the Nix store lock without sudo.
+#
+# Idempotent - safe to re-run (rewrites if paths have changed). Run as
+# root on the PVE host.
+#
+# Usage: ./setup-admin-sudo.sh <username>
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+# shellcheck source=lib/common.sh
+source "${SCRIPT_DIR}/lib/common.sh"
+require_root
+
+USERNAME="${1:-}"
+if [ -z "$USERNAME" ]; then
+    echo "Usage: $0 <username>" >&2
+    exit 1
+fi
+
+# Resolve actual binary paths at script time -- they differ across Proxmox
+# versions (pvesh moved from /usr/sbin to /usr/bin in PVE 8.x) and the
+# sudoers rule must match the real path or sudo will fall back to
+# prompting for a password.
+resolve_bin() {
+    command -v "$1" 2>/dev/null || { echo "ERROR: $1 not found on PATH" >&2; exit 1; }
+}
+
+PVESH="$(resolve_bin pvesh)"
+QM="$(resolve_bin qm)"
+PCT="$(resolve_bin pct)"
+# Nix installs to a fixed path regardless of which user bootstrapped it.
+NIX_BIN="/nix/var/nix/profiles/default/bin/nix"
+if [ ! -x "$NIX_BIN" ]; then
+    echo "WARNING: $NIX_BIN not found -- Nix may not be installed yet." >&2
+    echo "         Re-run this script after running codex-setup.sh on the node." >&2
+    NIX_BIN=""
+fi
+
+SUDOERS_FILE="/etc/sudoers.d/${USERNAME}-proxmox"
+NIX_ENTRY="${NIX_BIN:+, ${NIX_BIN}}"
+CONTENT="${USERNAME} ALL=(root) NOPASSWD: ${PVESH}, ${QM}, ${PCT}${NIX_ENTRY}"
+
+write_if_changed "$SUDOERS_FILE" "$CONTENT"
+
+# visudo -c validates the file we just wrote before we walk away.
+if visudo -c -f "$SUDOERS_FILE" >/dev/null 2>&1; then
+    chmod 0440 "$SUDOERS_FILE"
+    echo "Sudoers rule for ${USERNAME} is valid and in place."
+    echo "  ${CONTENT}"
+else
+    echo "ERROR: sudoers validation failed -- removing bad file." >&2
+    rm -f "$SUDOERS_FILE"
+    exit 1
+fi
diff --git a/.claude/worktrees/debian-restructure/proxmox/scripts/setup-linux-admin-user.sh b/.claude/worktrees/debian-restructure/proxmox/scripts/setup-linux-admin-user.sh
new file mode 100755
index 0000000..a920299
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/scripts/setup-linux-admin-user.sh
@@ -0,0 +1,82 @@
+#!/bin/bash
+# Create a Linux system user for SSH access and sudo, and install their
+# authorized SSH public key. Run this before harden-ssh.sh so that
+# key-based access is in place before password authentication is disabled.
+#
+# Idempotent - safe to re-run. Run as root on the PVE host.
+#
+# Usage:
+#   ./setup-linux-admin-user.sh <username> <ssh-public-key>
+#   ./setup-linux-admin-user.sh <username> --key-file <path-to-.pub>
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+# shellcheck source=lib/common.sh
+source "${SCRIPT_DIR}/lib/common.sh"
+require_root
+
+USERNAME="${1:-}"
+if [ -z "$USERNAME" ]; then
+    echo "Usage: $0 <username> <ssh-public-key>" >&2
+    echo "       $0 <username> --key-file <path-to-.pub>" >&2
+    exit 1
+fi
+
+shift
+SSH_KEY=""
+if [ "${1:-}" = "--key-file" ]; then
+    KEY_FILE="${2:-}"
+    [ -z "$KEY_FILE" ] && { echo "ERROR: --key-file requires a path." >&2; exit 1; }
+    [ -f "$KEY_FILE" ] || { echo "ERROR: key file not found: $KEY_FILE" >&2; exit 1; }
+    SSH_KEY="$(cat "$KEY_FILE")"
+else
+    SSH_KEY="${1:-}"
+fi
+
+if [ -z "$SSH_KEY" ]; then
+    echo "ERROR: an SSH public key is required (key string or --key-file <path>)." >&2
+    exit 1
+fi
+
+if ! echo "$SSH_KEY" | grep -qE '^(ssh-rsa|ssh-ed25519|ecdsa-sha2-nistp[0-9]+) [A-Za-z0-9+/=]'; then
+    echo "ERROR: argument doesn't look like a valid SSH public key." >&2
+    exit 1
+fi
+
+# --- create Linux user if missing ---
+if id "$USERNAME" >/dev/null 2>&1; then
+    echo "User '${USERNAME}' already exists - skipping useradd."
+else
+    useradd --create-home --shell /bin/bash "$USERNAME"
+    echo "Created Linux user '${USERNAME}'."
+fi
+
+# --- sudo group membership ---
+if id -nG "$USERNAME" | grep -qw sudo; then
+    echo "User '${USERNAME}' is already in the sudo group."
+else
+    usermod --append --groups sudo "$USERNAME"
+    echo "Added '${USERNAME}' to the sudo group."
+fi
+
+# --- install authorized SSH key ---
+HOME_DIR="$(getent passwd "$USERNAME" | cut -d: -f6)"
+SSH_DIR="${HOME_DIR}/.ssh"
+AUTH_FILE="${SSH_DIR}/authorized_keys"
+
+mkdir -p "$SSH_DIR"
+chmod 700 "$SSH_DIR"
+touch "$AUTH_FILE"
+chmod 600 "$AUTH_FILE"
+chown -R "${USERNAME}:${USERNAME}" "$SSH_DIR"
+
+if grep -qF "$SSH_KEY" "$AUTH_FILE" 2>/dev/null; then
+    echo "SSH key is already present in ${AUTH_FILE}."
+else
+    echo "$SSH_KEY" >> "$AUTH_FILE"
+    echo "Installed SSH key in ${AUTH_FILE}."
+fi
+
+echo
+echo "Linux user '${USERNAME}' is ready for SSH key-based login with sudo access."
+echo "Next: run setup-admin-sudo.sh ${USERNAME} to grant NOPASSWD for pvesh/qm/pct."
diff --git a/.claude/worktrees/debian-restructure/proxmox/scripts/setup-unattended-upgrades.sh b/.claude/worktrees/debian-restructure/proxmox/scripts/setup-unattended-upgrades.sh
new file mode 100755
index 0000000..2db85a4
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/scripts/setup-unattended-upgrades.sh
@@ -0,0 +1,46 @@
+#!/bin/bash
+# Install and configure unattended-upgrades for security patches. Deliberately
+# conservative for a hypervisor: security-only origins (Debian security +
+# the active PVE repo), no automatic reboot ever - a flag file is left at
+# /var/run/reboot-required for you to act on manually.
+#
+# Idempotent - safe to re-run. Run as root on the PVE host.
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+# shellcheck source=lib/common.sh
+source "${SCRIPT_DIR}/lib/common.sh"
+require_root
+
+if ! dpkg -s unattended-upgrades >/dev/null 2>&1; then
+    apt-get update
+    apt-get install -y unattended-upgrades
+fi
+
+CODENAME="$(pve_codename)"
+
+write_if_changed "/etc/apt/apt.conf.d/51pve-unattended-upgrades.conf" "// Managed by proxmox-configuration/scripts/setup-unattended-upgrades.sh
+Unattended-Upgrade::Origins-Pattern {
+        \"origin=Debian,codename=${CODENAME},label=Debian-Security\";
+        \"origin=Debian,codename=${CODENAME}-security,label=Debian-Security\";
+        \"origin=Proxmox\";
+};
+
+// Never auto-reboot a hypervisor. Check /var/run/reboot-required manually
+// (or via scripts/audit.sh) and reboot during a planned maintenance window.
+Unattended-Upgrade::Automatic-Reboot \"false\";
+
+// Don't remove packages automatically; review before doing so by hand.
+Unattended-Upgrade::Remove-Unused-Dependencies \"false\";
+Unattended-Upgrade::Remove-Unused-Kernel-Packages \"false\";"
+
+write_if_changed "/etc/apt/apt.conf.d/20auto-upgrades" '// Managed by proxmox-configuration/scripts/setup-unattended-upgrades.sh
+APT::Periodic::Update-Package-Lists "1";
+APT::Periodic::Unattended-Upgrade "1";
+APT::Periodic::Download-Upgradeable-Packages "1";
+APT::Periodic::AutocleanInterval "7";'
+
+systemctl enable --now unattended-upgrades.service >/dev/null
+echo "unattended-upgrades enabled (security-only origins, no auto-reboot)."
+echo "Dry run:"
+unattended-upgrade --dry-run --debug 2>&1 | tail -20
diff --git a/.claude/worktrees/debian-restructure/proxmox/scripts/setup-wifi-bond-network.sh b/.claude/worktrees/debian-restructure/proxmox/scripts/setup-wifi-bond-network.sh
new file mode 100755
index 0000000..86f0fe7
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/scripts/setup-wifi-bond-network.sh
@@ -0,0 +1,133 @@
+#!/bin/bash
+# Reproduces pve-test's wifi-primary networking: vmbr0 bridged over a wifi
+# NIC in 4addr (WDS) client-bridge mode, active-backup bonded with a wired
+# NIC as an automatic LAN fallback. See docs/06-pve-test-wifi-network.md for
+# why this exists and how it was validated. Idempotent - safe to re-run.
+#
+# Requires: a wifi NIC whose driver/AP both support 4addr mode (verify with
+# docs/06-pve-test-wifi-network.md's isolated-namespace test *before*
+# trusting this against a live management IP - a wifi NIC or AP that
+# doesn't support 4addr will associate fine but silently drop bridged
+# frames from any MAC other than the card's own).
+#
+# Usage (run as root on the target PVE host):
+#   WIFI_SSID="..." WIFI_PASSPHRASE="..." \
+#   MGMT_ADDR=192.168.2.251/24 MGMT_GATEWAY=192.168.2.254 \
+#   ./setup-wifi-bond-network.sh
+#
+# Optional overrides: WIFI_IFACE (default wlp3s0), LAN_IFACE (default nic0)
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+# shellcheck source=lib/common.sh
+source "${SCRIPT_DIR}/lib/common.sh"
+require_root
+
+WIFI_IFACE="${WIFI_IFACE:-wlp3s0}"
+LAN_IFACE="${LAN_IFACE:-nic0}"
+
+for var in WIFI_SSID WIFI_PASSPHRASE MGMT_ADDR MGMT_GATEWAY; do
+    if [ -z "${!var:-}" ]; then
+        echo "$var is not set. See usage in this script's header." >&2
+        exit 1
+    fi
+done
+
+if ! ip link show "$WIFI_IFACE" >/dev/null 2>&1; then
+    echo "No interface named $WIFI_IFACE on this host. Run 'ip -br link' and set WIFI_IFACE=..." >&2
+    exit 1
+fi
+if ! ip link show "$LAN_IFACE" >/dev/null 2>&1; then
+    echo "No interface named $LAN_IFACE on this host. Run 'ip -br link' and set LAN_IFACE=..." >&2
+    exit 1
+fi
+
+echo "=== 1/4: wifi tooling ==="
+apt-get install -y iw wpasupplicant >/dev/null
+echo "installed iw, wpasupplicant"
+
+echo
+echo "=== 2/4: wpa_supplicant config (SSID: $WIFI_SSID, iface: $WIFI_IFACE) ==="
+WPA_CONF="/etc/wpa_supplicant/wpa_supplicant-${WIFI_IFACE}.conf"
+wpa_passphrase "$WIFI_SSID" "$WIFI_PASSPHRASE" > "$WPA_CONF"
+sed -i '/^\s*#psk=/d' "$WPA_CONF"
+chmod 600 "$WPA_CONF"
+echo "wrote $WPA_CONF (passphrase hashed, not stored in plaintext)"
+
+echo
+echo "=== 3/4: systemd unit to set 4addr mode + start wpa_supplicant ==="
+UNIT="/etc/systemd/system/wpa-4addr-${WIFI_IFACE}.service"
+write_if_changed "$UNIT" "[Unit]
+Description=wpa_supplicant on ${WIFI_IFACE} with 4addr mode enabled
+Before=network-pre.target
+Wants=network-pre.target
+
+[Service]
+Type=simple
+ExecStartPre=/sbin/ip link set ${WIFI_IFACE} down
+ExecStartPre=/sbin/iw dev ${WIFI_IFACE} set 4addr on
+ExecStartPre=/sbin/ip link set ${WIFI_IFACE} up
+ExecStart=/sbin/wpa_supplicant -i ${WIFI_IFACE} -c ${WPA_CONF}
+Restart=on-failure
+RestartSec=3
+
+[Install]
+WantedBy=multi-user.target"
+systemctl daemon-reload
+systemctl enable --now "wpa-4addr-${WIFI_IFACE}.service"
+sleep 5
+if ! iw dev "$WIFI_IFACE" link | grep -q "^Connected"; then
+    echo "WARNING: ${WIFI_IFACE} did not associate to '$WIFI_SSID' within 5s - check:" >&2
+    echo "  systemctl status wpa-4addr-${WIFI_IFACE}.service" >&2
+    echo "  journalctl -u wpa-4addr-${WIFI_IFACE}.service" >&2
+    exit 1
+fi
+echo "associated: $(iw dev "$WIFI_IFACE" link | grep '^Connected')"
+
+echo
+echo "=== 4/4: /etc/network/interfaces (bond0 active-backup: ${WIFI_IFACE} primary, ${LAN_IFACE} backup) ==="
+IFACES_FILE="/etc/network/interfaces"
+backup_file "$IFACES_FILE"
+cat > "$IFACES_FILE" <<EOF
+auto lo
+iface lo inet loopback
+
+iface ${LAN_IFACE} inet manual
+
+iface ${WIFI_IFACE} inet manual
+
+auto bond0
+iface bond0 inet manual
+	bond-slaves ${WIFI_IFACE} ${LAN_IFACE}
+	bond-mode active-backup
+	bond-miimon 100
+	bond-primary ${WIFI_IFACE}
+	bond-updelay 200
+	bond-downdelay 200
+
+auto vmbr0
+iface vmbr0 inet static
+	address ${MGMT_ADDR}
+	gateway ${MGMT_GATEWAY}
+	bridge-ports bond0
+	bridge-stp off
+	bridge-fd 0
+
+source /etc/network/interfaces.d/*
+EOF
+echo "wrote $IFACES_FILE"
+
+echo
+echo "Config staged but NOT applied yet - applying it live can drop your"
+echo "current management connection for ~30-60s while the switch/AP"
+echo "relearns MAC locations (expected, self-resolves; see"
+echo "docs/06-pve-test-wifi-network.md). Recommended: run this from the"
+echo "physical console, or arm a revert-on-timeout watchdog first, e.g.:"
+echo
+echo "  cp ${IFACES_FILE}.bak.* /tmp/interfaces.orig  # pick the backup just made"
+echo "  (sleep 45 && cp /tmp/interfaces.orig ${IFACES_FILE} && ifreload -a) &"
+echo "  ifreload -a"
+echo "  # then kill the backgrounded revert job once you confirm connectivity"
+echo
+echo "Apply now with: ifreload -a"
+echo "Verify after with: cat /proc/net/bonding/bond0 ; ip -4 -br addr show vmbr0"
diff --git a/.claude/worktrees/debian-restructure/proxmox/scripts/switch-to-no-subscription-repo.sh b/.claude/worktrees/debian-restructure/proxmox/scripts/switch-to-no-subscription-repo.sh
new file mode 100755
index 0000000..8ec73d2
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/proxmox/scripts/switch-to-no-subscription-repo.sh
@@ -0,0 +1,42 @@
+#!/bin/bash
+# Remove the Proxmox/Ceph enterprise apt sources (which fail on apt update
+# without a paid subscription) and switch to the no-subscription repo.
+# Handles both the legacy one-line .list format and the deb822 .sources
+# format current PVE installers write.
+# Idempotent - safe to re-run. Run as root on the PVE host.
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+# shellcheck source=lib/common.sh
+source "${SCRIPT_DIR}/lib/common.sh"
+require_root
+
+SOURCES_DIR="/etc/apt/sources.list.d"
+
+# Any sources file pointing at the enterprise host gets moved out of apt's
+# way entirely (renamed .disabled) rather than commented out in place -
+# apt only reads *.sources/*.list, so this fully removes it from
+# consideration while keeping a copy on disk for reference.
+for f in "${SOURCES_DIR}"/*.sources "${SOURCES_DIR}"/*.list; do
+    [ -f "$f" ] || continue
+    grep -qi 'enterprise.proxmox.com' "$f" 2>/dev/null || continue
+    mv "$f" "${f}.disabled"
+    echo "Removed enterprise source (renamed to .disabled): $f"
+done
+
+write_if_changed "${SOURCES_DIR}/pve-no-subscription.sources" "Types: deb
+URIs: http://download.proxmox.com/debian/pve
+Suites: $(pve_codename)
+Components: pve-no-subscription
+Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg"
+
+# Clean up a legacy-format no-subscription file from a previous run of an
+# older version of this script, to avoid two sources for the same repo.
+LEGACY_NOSUB="${SOURCES_DIR}/pve-no-subscription.list"
+if [ -f "$LEGACY_NOSUB" ]; then
+    rm -f "$LEGACY_NOSUB"
+    echo "Removed superseded $LEGACY_NOSUB"
+fi
+
+apt-get update
+echo "Repo switched. Review 'apt list --upgradable' before upgrading."
diff --git a/.claude/worktrees/debian-restructure/scripts/check-secrets.sh b/.claude/worktrees/debian-restructure/scripts/check-secrets.sh
new file mode 100755
index 0000000..047960f
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/scripts/check-secrets.sh
@@ -0,0 +1,80 @@
+#!/usr/bin/env bash
+# Scan the repo for secrets and sensitive config values.
+# Runs via CI (GitHub/Gitea Actions) and locally as a pre-commit check.
+#
+# Usage: scripts/check-secrets.sh [--staged-only]
+#   --staged-only  Only check files staged for commit (for pre-commit hook use)
+#
+# Requires gitleaks on PATH, or falls back to Docker if available.
+# Install gitleaks: https://github.com/gitleaks/gitleaks#installing
+
+set -euo pipefail
+
+REPO_ROOT="$(git -C "$(dirname "$0")" rev-parse --show-toplevel)"
+STAGED_ONLY=false
+FAILURES=0
+
+for arg in "$@"; do
+  [[ "$arg" == "--staged-only" ]] && STAGED_ONLY=true
+done
+
+cd "$REPO_ROOT"
+
+# ── Resolve gitleaks binary ────────────────────────────────────────────────────
+if command -v gitleaks &>/dev/null; then
+  GITLEAKS="gitleaks"
+elif command -v docker &>/dev/null; then
+  GITLEAKS="docker run --rm -v ${REPO_ROOT}:/repo zricethezav/gitleaks:latest"
+  # Adjust paths for docker context
+  REPO_ROOT="/repo"
+else
+  echo "ERROR: gitleaks not found. Install it or ensure Docker is available." >&2
+  echo "  https://github.com/gitleaks/gitleaks#installing" >&2
+  exit 1
+fi
+
+echo "=== Secret scan ==="
+
+if [[ "$STAGED_ONLY" == "true" ]]; then
+  # Pre-commit mode: scan only staged content
+  echo "Mode: staged files only"
+  if ! $GITLEAKS protect --staged --config="${REPO_ROOT}/.gitleaks.toml" --source="${REPO_ROOT}" 2>&1; then
+    FAILURES=$((FAILURES + 1))
+  fi
+else
+  # CI mode: scan full git history
+  echo "Mode: full git history"
+  if ! $GITLEAKS detect --config="${REPO_ROOT}/.gitleaks.toml" --source="${REPO_ROOT}" 2>&1; then
+    FAILURES=$((FAILURES + 1))
+  fi
+fi
+
+# ── Pi-hole specific checks ────────────────────────────────────────────────────
+echo ""
+echo "=== Pi-hole config checks ==="
+
+PIHOLE_TOML="${REPO_ROOT}/pihole/config/pihole.toml"
+
+if [[ -f "$PIHOLE_TOML" ]]; then
+  # Check that known sensitive fields are empty
+  for field in pwhash totp_secret app_pwhash; do
+    value=$(grep -E "^\s+${field}\s*=" "$PIHOLE_TOML" | sed 's/.*=\s*"\(.*\)".*/\1/' | tr -d '[:space:]' || true)
+    if [[ -n "$value" && "$value" != '""' ]]; then
+      echo "FAIL: pihole.toml contains a non-empty '${field}' — run pihole/sanitize-config.sh before committing" >&2
+      FAILURES=$((FAILURES + 1))
+    else
+      echo "  OK: ${field} is empty"
+    fi
+  done
+else
+  echo "  (pihole/config/pihole.toml not present, skipping Pi-hole checks)"
+fi
+
+# ── Summary ────────────────────────────────────────────────────────────────────
+echo ""
+if [[ $FAILURES -gt 0 ]]; then
+  echo "FAILED: ${FAILURES} issue(s) found. Fix before committing." >&2
+  exit 1
+else
+  echo "All checks passed."
+fi
diff --git a/.claude/worktrees/debian-restructure/scripts/install-hooks.sh b/.claude/worktrees/debian-restructure/scripts/install-hooks.sh
new file mode 100755
index 0000000..8b17bc2
--- /dev/null
+++ b/.claude/worktrees/debian-restructure/scripts/install-hooks.sh
@@ -0,0 +1,17 @@
+#!/usr/bin/env bash
+# Install git hooks that run the secret scan before every commit.
+# Run once after cloning: bash scripts/install-hooks.sh
+
+set -euo pipefail
+
+REPO_ROOT="$(git -C "$(dirname "$0")" rev-parse --show-toplevel)"
+HOOK="${REPO_ROOT}/.git/hooks/pre-commit"
+
+cat > "$HOOK" << 'HOOK'
+#!/usr/bin/env bash
+exec "$(git rev-parse --show-toplevel)/scripts/check-secrets.sh" --staged-only
+HOOK
+
+chmod +x "$HOOK"
+echo "Installed pre-commit hook → ${HOOK}"
+echo "The secret scan will run automatically before every commit."