hermes-skills/devops/rke2-cluster-administration/references/workload-assessment-authelia-influxdb-2026-07.md

Workload Assessment: Authelia Decommission + InfluxDB Evaluation — 2026-07-14

Context

After Gitea migration to K8s, user asked "was wäre die nächste Workload für eine Migration auf den K8s?" — triggering a full infrastructure inventory and workload migration candidate assessment.

Authelia (CT112) — Decommissioned Instead of Migrated

Assessment Findings

Authelia appeared in the initial assessment as the #1 migration candidate (dependency for Traefik migration). Deep investigation revealed it was completely unused:

Check	Finding
Traefik middleware	NO router used Authelia as forwardAuth — only a route TO Authelia existed
Registered users	2 (admin + dominik), neither actively logging in
DB freshness	SQLite 305 KB, last modified August 2025 (11 months stale)
Domain	Configured for familie-schoen.com (old domain, active is schoen.codes)
2FA	TOTP configured but default_policy: one_factor (password only)

Decision: Stop + Delete (Not Migrate)

# Stop CT
ssh -i ~/.ssh/id_ed25519_proxmox root@10.0.20.10 \
  "ssh root@proxmox6 'pct stop 112'"
# Remove Traefik routes (authelia + authelia-admin routers + services)
# Delete CT with storage
pct destroy 112 --purge  # fails if RBD already gone → see ct-deletion-stale-config ref
rm -f /etc/pve/lxc/112.conf  # cleanup stale config

Traefik Config Editing on CT99999

Removed Authelia routers + services from /etc/traefik/conf.d/explicit-http.yml on CT99999 (10.0.60.10). Traefik runs as systemd service (not Docker).

Backtick escaping: YAML rules contain Host(\domain`)` with backtick-delimited expressions. SSH heredoc breaks these (shell interprets backticks as command substitution). Solution: base64-encode locally, decode on remote:

cat << 'EOF' | base64 -w0
http:
  routers:
    myapp:
      rule: "Host(`myapp.example.com`)"
...
EOF
# SSH to remote:
ssh root@10.0.60.10 "echo '<BASE64>' | base64 -d > /etc/traefik/conf.d/myfile.yml"

After editing: backup old config (cp file{,.bak-$(date +%F)}), apply new config, systemctl restart traefik, check /var/log/traefik/traefik.log (not journald — Traefik logs to files on this host).

InfluxDB (CT109 + CT134) — Next Migration Candidate

Assessment Findings

CT	Role	Effective Data	Allocated Disk	Status
CT109	Hot (90d retention)	4.0 GB (76 shards, ~53 MB/day)	30 GB	Active — HA writes continuously
CT134	Archive (5y retention)	368 KB	50 GB	Dead — bolt file last modified 12 days ago

Key Finding: CT134 Is Dead

CT134 (archive) receives no data. The InfluxDB bolt file was last modified July 2 (12 days ago). The ha_archive_5y_5m bucket has 368 KB of data. 50 GB disk allocated for 368 KB of data — pure waste.

Storage Analysis Method

# Find InfluxDB data path (v2 uses /var/lib/influxdb/, not /var/lib/influxdb2/)
pct exec 109 -- bash -c "du -sh /var/lib/influxdb/"
# Check shard count and sizes:
pct exec 109 -- bash -c "du -sh /var/lib/influxdb/engine/data/BUCKET_ID/autogen/*/ | sort -rh | head -5"
# Check bolt file mtime (staleness indicator):
pct exec 134 -- bash -c "stat /var/lib/influxdb/influxd.bolt | grep Modify"
# List buckets:
pct exec 109 -- influx bucket list

Migration Recommendation

Consolidate CT109 + CT134 → single K8s InfluxDB with two buckets:

• ha_hot_90d (90-day retention, ~4 GB)
• ha_archive_5y (5-year retention, downsamples from hot)

10 Gi PVC sufficient (4 GB current + growth buffer). Frees 2 CTs on proxmox6 (the busiest node). Official Helm chart influxdata/influxdb2. Data migration via influx backup → influx restore.

CT134 Action

CT134 can be deleted immediately — it receives no data and wastes 50 GB. Whether to reactivate the archive (configure InfluxDB downsampling task) or abandon archiving is a user decision.

Old Docker Host (10.0.30.100) InfluxDB Investigation

User recalled "mehrere Jahre HomeAssistant Daten" on 10.0.30.100. Deep forensic search (see references/docker-volume-forensics-2026-07.md in docker-host-administration skill) found:

• InfluxDB v1 container was removed years ago — only a 15 KB skeleton volume remained (influxd.bolt + influxd.sqlite from Jan 2023)
• Shell history showed collectd + cadvisor databases (2017-era system monitoring), NOT HomeAssistant data
• No .tsm files anywhere on the host (root, ZFS pool, Docker volumes)
• The old InfluxDB v1 was a different service (system monitoring via collectd/cadvisor) than the current InfluxDB v2 on CT109 (HA sensors)
• HA data was never on 10.0.30.100 — the HA→InfluxDB v2 integration writes to CT109 directly

Lesson: "Running" ≠ "had the data you're looking for." The old InfluxDB v1 served a different purpose (system metrics) than the current v2 (HA sensor data). Cross-reference what databases existed historically (shell history, config files) before assuming data loss.