Adds a transparent nginx passthrough that logs auth-related request
headers (Authorization, X-Emby-Authorization, X-Emby-Token,
X-MediaBrowser-Token, User-Agent) to diagnose why the Filebar iOS app
gets 400s on /Users/AuthenticateByName against Jellyfin 12.0. All
traffic still reaches the real jellyfin Service unchanged. Revert the
Ingress backend and remove jellyfin-header-debug.yaml once captured.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016EQrGkfXFae4PZG9QfPRf4
10.11.11 can't read the schema Jellyfin 12.0 already migrated the config
DB to (SQLite errors on every user query), which broke login entirely.
Pin to 12.0 instead of :latest to restore service and stop future
silent version jumps.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016EQrGkfXFae4PZG9QfPRf4
manifests/media/gluetun-proxy.yaml (the standalone Gluetun/OpenVPN
HTTP proxy, NodePort 30888) is now fully replaced by
manifests/multus/30-browser-vpn-proxy.yaml, live and validated
end-to-end (connectivity, DNS-through-proxy, PIA egress, fail-closed
kill switch). Removing the file from git - the live Deployment/Service
still need a separate kubectl delete, since media has prune: false.
Note gluetun.home.arpa (the dashy VPN-IP-banner hostname, and the
Certificate/IngressRoute in qbittorrent.yaml routing it to that pod's
ip-reporter sidecar) is unrelated and unaffected - it never pointed at
this standalone proxy.
Update the root README's VLAN 50 status table with browser-vpn-proxy
and this removal, including the exact commit to restore the old file
from if ever needed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
qbittorrent.yaml and jdownloader.yaml's own header comments still
pointed at manifests/media/rollback/*-gluetun.yaml and described the
migration as pending approval/preconditions - both are live and
validated now, and that directory is being removed (no kept on-disk
Gluetun copy). Rewrite both headers as a status note instead, pointing
rollback at git history (with the exact pre-migration commit) to match
the root README's rollback table, which gets the same exact-commit
treatment here instead of the vaguer reference from the previous
commit.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
minisforum, debian, mac-mini, and gpu-node all moved from
192.168.7.0/24 to 10.10.40.0/24. Updates K3s server/agent config and
node IPs (including gpu-node's host_vars override), NFS export
allow-list and exports template, Pi-hole DNS records and
kube-vip/loadBalancerIP pins, WireGuard's pushed DNS/AllowedIPs, and
the NFS server IP baked into Jellyfin/Kavita/gitea-backup PVs and the
Ollama URL used by ai-gateway/Dashy.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Not used enough to justify chasing the stale-NFS-handle issue on its
photos-art mount. Removes manifests/media/immich.yaml (Namespace, PVCs,
Deployments, Service, Certificate, IngressRoute), its secret script and
sealed secret, immich.home.arpa from both Pi-hole values files, its Dashy
dashboard tile, and all other repo references (READMEs, secrets-leak-scanner
scope, regen-sealed-secret example, .env.example).
Per explicit confirmation: this also means the live namespace's PVCs
(immich-library 50Gi, immich-postgres-data 20Gi, immich-ml-cache 10Gi, all
local-path with Delete reclaim policy) are intended to be deleted along with
it -- any photos actually uploaded to Immich's own library are gone once the
namespace is deleted, separately from the read-only NFS folders it browsed
(untouched either way, those live independently on nik-debian).
Git removal alone does not delete the live cluster resources -- the media
Application has prune: false. Manual `kubectl delete namespace immich` still
needed to actually free the namespace/PVCs/data.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Both Deployments' rolling update briefly ran an old+new pod pair on the same
node (node-role: storage), sharing the same config storage (qbittorrent's PVC,
jdownloader's hostPath) -- both apps are effectively singletons that lock
their config directory, so the new instance conflicted with the still-running
old one:
- qbittorrent: hit a known qbittorrent:5.2.0 image bug (linuxserver/
docker-qbittorrent#432) where a stale WebUI lockfile prevents the server
from ever binding its port while a second instance is present -- surfaced
as the new pod's readiness probe getting "connection refused" indefinitely.
On top of that, my livenessProbe (30s/30s) was killing the container
(exitCode 137) before qbittorrent had any chance to come up at all. Dropped
the livenessProbe (readiness alone can never kill a container, only mark it
not-ready) and loosened the readinessProbe timing.
- jdownloader: the new pod's app process detected the old instance's lock in
the shared /data/jdownloader hostPath and exited cleanly (exitCode 0) rather
than run a duplicate copy -- nothing to do with probe timing.
Both Deployments now use `strategy: Recreate` instead of the RollingUpdate
default, so any future rollout fully stops the old pod before starting the
new one -- this is the actual fix (matches the pattern immich.yaml already
used). Applying this will briefly restart both currently-running pods to
verify it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Stage 7 of REFACTOR_PLAN.md (findings #16). Covers dashy, glances,
ca-installer, authentik-proxy-outpost, jellyfin, qbittorrent/jdownloader main
containers (their gluetun sidecars already had probes), and all 4 Immich
Deployments -- previously none of these had any protection against one
workload starving another on this fixed-capacity cluster, nor automatic
restart on hang.
Values are sized from live `kubectl top pod` baselines gathered this session
(not guessed): e.g. Jellyfin/Immich-server were observed at ~3.1-3.3Gi
resident, so their limits give headroom above that (4Gi) rather than an
arbitrary round number. Used tcpSocket probes instead of httpGet wherever I
wasn't certain of an app's exact health-check path (Immich, Postgres/Redis),
to avoid a wrong path causing false probe failures on a live service.
This is Kubernetes-native and takes effect on next pod restart, but should
still be rolled out watching `kubectl top`/restart counts rather than pushed
and forgotten -- limits set too low can OOMKill under real load.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
feat: update qBittorrent deployment to expose gluetun API on port 8000 and add TLS certificate for secure access
feat: add gluetun DNS entry to Pi-hole configuration for improved network management
