diff --git a/docs/planning/SERENITY_CLEANUP_WAVE_1.md b/docs/planning/SERENITY_CLEANUP_WAVE_1.md index 942066d..c022972 100644 --- a/docs/planning/SERENITY_CLEANUP_WAVE_1.md +++ b/docs/planning/SERENITY_CLEANUP_WAVE_1.md @@ -73,8 +73,8 @@ From the live Serenity audit: Live execution on 2026-05-25 established: - `Huntarr` and `omegabrr` were low-risk stale stopped containers and were removed from Serenity - the recent non-running `Created` containers (`calibre-web`, `SuggestArr`, `Cleanuparr`, `calibre`, `agregarr`) were not blindly pruned because their metadata was touched recently and they may represent intentional but inactive templates -- `Unraid-Cloudflared-Tunnel` is not currently dead: it still has a live tunnel token and active Cloudflare edge registrations, so removal requires a separate usage audit first -- the Serenity Pi-hole HA stack is also not safe to remove blindly yet: `10.5.30.53` is still answering DNS and Serenity is running a backup `keepalived`/Pi-hole stack, so Pi-hole retirement must stay gated on the broader DNS cutover verification +- `Unraid-Cloudflared-Tunnel` was audited, stopped, and removed after verification showed it was only transport-alive and no current public traffic depended on it +- the Serenity Pi-hole HA stack (`binhex-official-pihole`, `pihole-serenity`, `unbound-pihole-serenity`, `keepalived-pihole-serenity`) was then stopped and removed after live mixed-host DNS checks confirmed the Technitium path remained healthy without it ## Wave 1-A: legacy Pi-hole removal @@ -113,10 +113,13 @@ Before removal, verify only these read-only checks: ### Verification after removal -- Serenity Technitium container remains healthy -- PD and NOMAD Technitium backup flow still looks normal -- no client-facing DNS complaints appear -- no scripts or bookmarks fail because of removed Pi-hole UI endpoints +- Serenity Technitium container remained healthy +- mixed-host DNS checks stayed good after removal: + - from NOMAD, `10.5.30.8` and `10.5.30.10` still resolved both public and homelab names + - from PD, `10.5.30.9` and `10.5.30.10` still resolved both public and homelab names +- `10.5.30.53` continued answering DNS even after Serenity Pi-hole removal, confirming it is no longer tied to the removed Serenity Pi-hole containers +- no immediate client-facing DNS regression was observed during the removal window +- no public regression was observed on sampled hostnames such as `panel.paccoco.com` and `audiobookshelf.paccoco.com` ## Wave 1-B: stale container pruning @@ -206,6 +209,10 @@ Status after live audit: 3. keep `/mnt/user/appdata/cloudflared` during a cooling-off window even though it appears empty/unneeded 4. later, from the Cloudflare side, delete or repoint the stale tunnel config/hostnames if they still exist there +Status: +- completed on 2026-05-25: `Unraid-Cloudflared-Tunnel` was stopped and removed +- sampled public checks (`panel.paccoco.com`, `audiobookshelf.paccoco.com`) remained healthy after removal + ## Wave 1-D: DB-backed migration ordering These apps should not be deleted in wave 1. diff --git a/docs/planning/SERENITY_DOCKER_AUDIT.md b/docs/planning/SERENITY_DOCKER_AUDIT.md index 748e1c5..f4417f3 100644 --- a/docs/planning/SERENITY_DOCKER_AUDIT.md +++ b/docs/planning/SERENITY_DOCKER_AUDIT.md @@ -67,14 +67,13 @@ These should be treated as cleanup targets unless a specific live dependency is - `Unraid-Cloudflared-Tunnel` - live audit on 2026-05-25 showed a remote-managed Cloudflare Tunnel with stale legacy `192.168.1.x` origins and zero observed proxied requests on the current run - - public hostnames in its remote config now appear to be served elsewhere, so it should be removed after a brief stop/remove observation window rather than treated as an active dependency + - stopped and removed on 2026-05-25 after post-stop checks showed sampled public hostnames remained healthy without it - `binhex-official-pihole` - `pihole-serenity` - `unbound-pihole-serenity` - `keepalived-pihole-serenity` - - these are legacy DNS/HA remnants now that Technitium is the active resolver strategy - - repo docs now describe the Technitium trio as the active DHCP-advertised internal DNS path - - operator confirmed Technitium covers the intended DNS role, so these should be treated as removable at the next cleanup window + - these were legacy DNS/HA remnants once Technitium became the intended resolver strategy + - mixed-host DNS verification passed during retirement on 2026-05-25, and the Serenity Pi-hole HA stack was then stopped and removed without immediate DNS regression - `postgresql15` - `MariaDB-Official` - both are live, but they are suspicious because current docs position PD as the shared database home diff --git a/docs/troubleshooting/KNOWN_QUIRKS.md b/docs/troubleshooting/KNOWN_QUIRKS.md index a67bea7..7d321f2 100644 --- a/docs/troubleshooting/KNOWN_QUIRKS.md +++ b/docs/troubleshooting/KNOWN_QUIRKS.md @@ -70,11 +70,11 @@ Per-service gotchas that aren't bugs but will bite you if you forget them. ### Unraid-Cloudflared-Tunnel - Older notes called this dead, but live inspection on 2026-05-25 showed active Cloudflare QUIC edge registrations and a configured tunnel token. - Follow-up audit showed it is only transport-alive: current-run metrics reported zero proxied requests, its remote-managed ingress config still points at legacy `192.168.1.x` origins, and the listed public hostnames appear to be served elsewhere now. -- Treat it as removable stale Cloudflare deadwood after a brief stop/remove observation window; preserve appdata during the cooling-off period and clean up Cloudflare-side tunnel config separately. +- Retired on 2026-05-25: the container was stopped and removed, sampled public hostnames stayed healthy, and Cloudflare-side cleanup can now happen separately from Serenity runtime cleanup. ### Serenity Wave 1 cleanup guardrails -- Do not assume `Unraid-Cloudflared-Tunnel` is dead just because it looked obsolete in older notes; live inspection on 2026-05-25 showed active Cloudflare tunnel registrations, so audit usage before removal. -- Do not remove Serenity's Pi-hole HA containers blindly while `10.5.30.53` still answers DNS; verify the full Technitium cutover path first. +- `Unraid-Cloudflared-Tunnel` has already been retired from Serenity runtime; any remaining cleanup is Cloudflare-side control-plane cleanup, not local container cleanup. +- Serenity's legacy Pi-hole HA containers were retired on 2026-05-25 after mixed-host DNS verification; if future DNS issues appear, investigate the surviving Technitium/other-resolver path rather than trying to resurrect those old Pi-hole containers by default. - Recent `Created` containers on Unraid may represent intentionally retained templates rather than stale debris; distinguish them from long-dead exited containers before pruning. ### Serenity Newt / Pangolin stale health-check IP drift