Infrastructure/docs/todo.md

Homelab Network Overhaul — TODO

Living checklist. See status.md for the full decisions/context behind each item.

Switch wiring — in progress

• SG2016P wired in and adopted; AP moved over to it (PoE-powered).
• SSID plan implemented: Trusted (10), Guest (40), IoT (20, hidden) all working on their correct VLAN subnets. Root cause of the initial "Trusted Wi-Fi won't get an IP" bug: the switch's uplink port to the ER605 was missing VLAN 10 from its tagged list — same bug independently blocked the partner's PC from getting onto Trusted directly. Fixed by adding all VLANs to that uplink port's tagged list.
• OctoPrint Pi wired to IoT, confirmed reachable.
• Printer moved to IoT (after fixing its port — was left as untagged-Default with IoT only tagged, which a VLAN-unaware printer could never actually reach; fixed to native/untagged = IoT).
• DHCP reservations done for devices with stable MACs.
• Guest VLAN enabled as a safety net on currently-in-use switch ports, so anything unexpectedly plugged in lands isolated by default.
• Synology NAS → Servers (30), DHCP-reserved.
• Windows gaming PC and partner's PC both on Trusted (the uplink-port VLAN bug above was what had blocked them).
• Still to wire/move: homeserver (NUC), blocked until the NUC itself is provisioned. David's own Linux desktop deliberately stays on Default for now (it hosts the Omada Controller) — moves to Trusted once the Controller moves to the NUC, which is also when the Default network can finally be retired.

Next up

• Hardware shopping list: EAP650 (2nd AP) + ES205GP (living-room PoE switch); flat Cat6 patch cables for the cupboard (deleyCON flat U/UTP, pure copper — 25 cm 5-pack for short links, plus 0.5 m / 1 m / 2 m, and a 3 m for the PC runs if a string measurement of the real path is over ~1.7 m; verify on each listing that it says copper and is the flat U/UTP version); optionally a colored multi-length round Cat6 set for grab-and-go spares (flat only matters for the permanent cupboard cables); socket strips — two, each plugged into a different wall outlet, no daisy-chaining, wall-mountable metal-housing (screws, no adhesive), VDE/GS/ÖVE mark, 3×1.5 mm² cable, surge-protected for the desk/PC strip, and no switch (or a guarded one) for the strip carrying router/switch/NAS. PoE-powered cables (to the APs) should be round pure-copper cable, not flat/thin ones.

• Living-room second AP + switch (decided — see status.md Wi-Fi and Living room sections): buy an EAP650 (same as the first AP) and an ES205GP (the PoE+ variant, not the plain ES205G). Mount both above the TV, one cable run from the wall to there. Then: adopt both, set the ES205GP uplink + AP ports as trunks (Trusted/IoT/Guest tagged) and the SG2016P port feeding it likewise, TV port → access on IoT, Pi port → access on Trusted. Re-measure the couch afterward (baseline was -70 dBm).

• Mount the office AP at its final ceiling position, then re-measure the couch and the other rooms (baseline readings recorded in status.md) — cheap to do first, and useful as the before/after reference for the second AP.

• Omada Controller auto-backup enabled, set to daily (config is changing a lot right now). Weekly switch tracked separately in Backlog. Original notes: top priority, cheap insurance for all the VLAN/ACL/VPN config already built. Scope for now: local only — backups stay on the machine running the Controller (accepted for now); also download a manual copy occasionally. The off-machine copy to the Synology is deferred, see "Later". Note auto-backups live in the container's data volume, so docker compose down -v deletes them along with everything else.

• Robot vacuum and cat feeder connected to the IoT Wi-Fi SSID, named in the Controller for easy recognition. No DHCP reservation — not needed for devices only reached via their own cloud apps.

• Synology NAS access: QuickConnect disabled — NAS is now only reachable via the WireGuard VPN, confirmed working. Synology Drive/Photos apps switched from QuickConnect ID to manual local-address login (David's phone done; partner's accounts still to do — planned for tomorrow).

• Decide whether IoT devices should use Pi-hole for DNS: the NAS (running Pi-hole as a Docker container) sits on Servers (30), same as always planned. The existing IoT → !IoT deny ACL rule currently blocks IoT from reaching Pi-hole too — meaning any IoT device pointed at it for DNS would fail to resolve. Left as-is for now (IoT just uses ER605/ISP DNS directly, no ad-blocking there). If wanted later: add a narrow exception, Network: IoT → Network: Servers, port 53 only, Direction LAN-LAN, Allow — evaluated before the broader IoT deny-all rule.

• Backup strategy for the NUC/homeserver's own data — Home Assistant config, Docker volumes, Omada Controller data, etc. Not addressed anywhere yet; the Synology's own backups don't cover this.

• ▶ Synology NAS backup — first run in progress (2026-09-26, overnight). Task is created (Multiple versions, Folders and Packages, all shared folders + homes + all applications, config backup + encryption on, key in Enpass, no schedule). Next: (1) check the run finished without per-folder/per-app errors, (2) test-restore a personal Drive file and a personal photo for both users to confirm the Drive Server / Photos application backups really cover personal data, (3) eject in DSM and unplug, (4) set the every-two-weeks reminder, then tick this item. Full setup notes are in status.md's Backups section. Original notes: (currently no backup existed at all — top data-safety item): 6TB USB drive on hand, but the USB 3.0 Micro-B cable is misplaced (find it, or buy a replacement). Chosen workflow: manually connected, not permanently attached — the offline drive also protects against ransomware/accidental deletion. Steps: format the drive as ext4 in DSM (Control Panel → External Devices → Format; erases it — check for existing data first), install Hyper Backup, create a Data backup task ("Local folder & USB") covering the important shared folders + Applications, encryption on (password in Enpass), version retention (Smart Recycle) + periodic integrity check, DSM notifications on failure, and test-restore one folder. To run: plug in, "Back up now", eject in DSM (Control Panel → External Devices → Eject) before unplugging, store the drive away from the NAS. DSM 7 has no plug-in-triggered backup, so the habit needs a recurring calendar reminder — chosen cadence: every two weeks (see how it goes; also run one before big photo imports or major DSM updates). Drive was exFAT out of the box (DSM couldn't cleanly mount it and reported "not ejected safely" — exFAT has no journal); reformatted to ext4 in DSM. The first full backup will be slow on the DS223j's 1 GB RAM — run it overnight. Later: an occasional off-site copy (3-2-1 rule) since one drive at home doesn't cover fire/theft.

• Real (non-self-signed) certificate for the NAS's own DSM access — not crucial, DSM's cert warning is just cosmetic for local access. Leaning toward mkcert (local CA, install its root cert as trusted on your own devices once, zero external credentials/services involved) over Let's Encrypt DNS-01 through INWX — the latter would need either a scoped INWX API key (check if INWX offers one) or acme.sh's manual mode (no credentials, but manual renewal every ~90 days); full INWX account credentials handed to a script was correctly ruled out as too broad a permission grant for this.

Ansible — learning, started 2026-09-27

Setup lives in ../ansible/. OctoPrint Pi is the guinea pig; the NUC is the real goal (status.md: Ansible from David's PC, no footprint on the server).

• SSH key auth to the Pi: one key per client device (id_ed25519_homelab), not per server; ~/.ssh/config entry with IdentitiesOnly yes.
• ansible octoprint -m ping works; update.yml run for real on 2026-09-27 (248 packages, kernel → 6.12.109). Gotchas: David's sudo needs a password → run with -K; Raspberry Pi OS does not create /var/run/reboot-required after kernel updates, so the playbook compares the running kernel with the newest installed one of the same flavour.
• Audit the Pi's hand-made changes so a rebuild can reproduce them: apt-mark showmanual, enabled services, crontabs, /boot/firmware/config.txt, installed OctoPrint plugins. Removed by hand 2026-09-27 (one-off cleanups don't belong in the config playbook — it describes what should be there, and an "ensure absent" task would fight future experiments): Docker (installed Sep 2026 for a Spoolman test, Spoolman already gone — packages, docker.list repo + docker.asc key, /var/lib/docker, /var/lib/containerd, docker group) and nginx (only the default site, never listening — haproxy holds 80/443 and fronts OctoPrint on 127.0.0.1:5000). Rule going forward: experiment by hand, then either add it to the playbook or remove it; spool-manager-type services belong on the NUC anyway. The Pi 4 (1 GB RAM) boots the 32-bit rpi-v7 kernel instead of the Bookworm default (64-bit v8 kernel, 32-bit userland) — config.txt has an explicit arm_64bit=0, which appears to come with the OctoPi image (apt history shows the Pi is essentially a stock OctoPi flash, not years of in-place upgrades). Decided: leave it. With 1 GB there's no RAM to gain, and 32-bit userland uses slightly less memory; switching only the kernel isn't worth it before the rebuild. For the rebuild: a 32-bit OctoPi image is fine on this Pi, using whatever kernel it boots by default. Still wanted from the audit: config.txt, enabled services, apt history.
• First configuration playbook playbooks/octoprint.yml (run 2026-09-27; verified: password SSH refused, timezone set, no Bluetooth device): timezone, ModemManager masked (probes the printer's serial port), Bluetooth off (services + dtoverlay=disable-bt), SSH password login off. Wi-Fi stays on — the Pi is on the IoT Wi-Fi now, no longer on the cable. nginx removal checked: webcam uses MJPEG (webcamd), not the HLS stream (ffmpeg_hls, which needed nginx).
• Rebuild procedure (document once tested): flash current 32-bit OctoPi with Raspberry Pi Imager's OS customisation — hostname, user david, IoT Wi-Fi, SSH public-key only with id_ed25519_homelab.pub (Wi-Fi password stays out of the repo) → ansible-playbook playbooks/octoprint.yml -K → restore the OctoPrint backup. Test on a spare SD card.
• Automated OctoPrint backups (deferred — basics first). Rebuild plan: flash card → run playbook → restore OctoPrint backup; OctoPrint's own state (settings, plugins, profiles) comes from its Backup & Restore zip, not Ansible (OctoPrint rewrites its own config.yaml, so templating it would fight the UI). Plan:
  1. Ansible deploys a nightly timer on the Pi running the backup CLI (octoprint plugins backup:backup — verify syntax/exclude flags first), excluding uploads/timelapses, keeping the last few. Alternative: the "Backup Scheduler" plugin, but that's UI config outside the repo.
  2. Off-device copy must be pulled — the IoT → !IoT ACL means the Pi can't push to the NAS (keep it that way). Interim: update.yml takes a backup and fetches it to David's PC before upgrading. Later: nightly pull from the NUC (Servers → IoT allowed) with a dedicated key restricted via rrsync to read-only access to the backup folder.
  3. Backup zips contain user hashes + API keys — store outside this repo (decide location, e.g. NAS share).
• Split into roles (common, updates) + group_vars; ansible-vault for any secrets (e.g. OctoPrint API key for a "skip while printing" check).
• Add the two personal Linux machines (community.general.pacman for Arch-based ones — not fully unattended, Arch updates occasionally need manual steps).
• Provision the NUC with it (common role + Docker + Compose stacks).

Backlog / lower priority

• Change the Omada Controller auto-backup from daily to weekly — daily is deliberate for now because so much config is changing; revisit once the switch/AP/VLAN work has settled and changes become infrequent.
• UPS/power protection for the always-on gear (router/switch/homeserver/NAS) — optional cost/complexity tradeoff, not urgent.
• Basic uptime/service monitoring (e.g. Uptime Kuma) once the NUC exists — nice-to-have, not essential.

Later

• Local DNS + reverse proxy plan: implemented ahead of schedule, running temporarily on the Synology rather than waiting for the NUC. NPM deployed (SQLite-based), remapped to ports 9080/9443/9081 since DSM's own internal nginx already held 80/443/81 — proxied HTTPS URLs need an explicit :9443 until this moves to the NUC, where a clean 80/443/81 mapping will work with no conflict (revert docker/npm/docker-compose.yml's ports: at that point). Pi-hole Local DNS Records in use (e.g. pihole.home.staffenberger.at, nas.home.staffenberger.at) rather than the wildcard approach so far — worth switching to the wildcard dnsmasq config later to stop needing a new record per service.
• TLS certs for NPM: same decision as the NAS's own cert (see above) — leaning mkcert over Let's Encrypt DNS-01/INWX for the same credential-scope reasons. Decide once NPM proxy hosts are actually being used for more than testing.
• Off-machine Omada Controller backups to the Synology — set this up on the NUC after the migration rather than on the desktop. Decided approach: a scheduled rsync job on the Controller host copying the Controller's autobackup folder (believed to be /opt/tplink/EAPController/data/autobackup inside the container — verify with docker exec omada-controller ls once a backup has run) to the NAS. Not a NAS folder mounted into the container (avoids the container's startup depending on the NAS, and keeps a failed copy from affecting the Controller). Use a dedicated Synology user with a small storage quota and key-based auth, so the credential on the Controller host can only touch that one backup folder — check that the DS223j's volume filesystem supports user quotas, and how DSM allows a non-admin user to do rsync/SFTP (SSH is admin-only by default). Backups contain secrets (Device Account, WireGuard keys, DDNS settings), so restrict the folder to that user and keep the files out of this Git repo. Once the Synology's own Hyper Backup to the 6TB drive exists, these are covered there too.
• Migrate Omada Controller from the desktop to the NUC once the NUC is provisioned — see omada-controller-migration.md.

Future ideas

• Parents' network overhaul: plan refined after discussion — not a site-to-site link, not adopting their hardware into this Omada Controller (TP-Link Deco is a separate, incompatible ecosystem — can't be adopted into Omada Controller under any configuration; a "workaround" of switching Deco to AP mode just makes it a dumber Wi-Fi extender still managed by the Deco app, doesn't add controller compatibility).
  • Buy a second ER605 to replace their current limited ISP-provided modem/router — get their modem into bridge mode (same pattern as home), ER605 becomes their real router.
  • Switch their existing Deco units into Access Point Mode (a supported Deco app toggle) so they stop doing their own NAT/DHCP behind the new ER605 — otherwise double-NAT. Note: even in AP mode, Deco can't map SSIDs to VLANs like the EAP650 can — it just bridges onto whatever single network the port it's plugged into carries. Since they don't need segmentation (confirmed — no IoT/multi-trust-tier need there), this doesn't matter: one flat subnet is enough, no VLANs needed on their side.
  • Pick a subnet clearly distinct from home's (192.168.10/20/30/40/66/99.0/24) — e.g. 10.50.0.0/24, using a different address family entirely so it's visually obvious which network you're on.
  • Set up an independent WireGuard VPN server on that second ER605 (own DynDNS entry via INWX, same pattern as home) with its own client IP pool distinct from home's 192.168.66.0/24 — not a site-to-site link. Connect to it only on-demand from your own devices when help is actually needed; no persistent link between the two networks, no changes/risk to your own network at all.
  • Doesn't remove the Deco mesh's own reliance on TP-Link's cloud for its own management (that's inherent to Deco) — separate, optional concern from the remote-access goal, not solved by any of the above.
  • Next actual step: investigate their current ISP/modem situation (does it support bridge mode? which ISP?) before buying anything.