- 31 new managed skills (anubis/arr/authentik/hermes/freetoken/podman/llm-swap runbooks etc.) now tracked. - Removed superseded skills: omp_harness_config, peon_ping_integration (replaced by user-authored peon-ping-* managed skills), rocmfp4-strix-benchmark-orchestration. - New memory-root skills: niri_compositor_ops, omp_git_workflow, omp_model_config, quadlet-media-migration, homelab-service-triage, hermes-dankclaw-ops, frank-default-large-ops, caddy-auth-dns-playbook.
1.8 KiB
1.8 KiB
Caddy, Authentik, Anubis, and split-DNS playbook
Use this when modifying franksdank.cloud routes, DNS records, or auth wrapping.
Architecture:
- Single Caddy container on Dankclaw fronts services on Dankclaw and Dankserver.
- LAN DNS via Pi-hole resolves service names to 192.168.0.143.
- Public DNS via Porkbun points exposed names to WAN IP 71.227.227.172.
- TLS uses Porkbun DNS-01 wildcard certificates; ordinary A-record deletion does not break wildcard renewal.
- Porkbun credentials are machine-local secrets, never tracked.
Caddy rules:
- Keep Caddy admin enabled on 127.0.0.1:2019 inside the container so file watcher hot-reload works.
- Caddy routes by Host header; it does not care whether the name resolved via Pi-hole or Porkbun.
DNS changes:
- If a service should be LAN-only, it is usually safe to remove its ordinary Porkbun A record while keeping Pi-hole local DNS.
- Removing public DNS does not remove router port forwards or block direct IP access.
- Do not casually remove public DNS for auth.franksdank.cloud; external login flows may need it.
- Be cautious with gitea.franksdank.cloud because external git smart-HTTP use may depend on public DNS.
Auth wrapping:
- Protected via Authentik forward_auth: homepage, SearXNG, Hermes, Prometheus, RomM, Copyparty.
- Usually bypass forward_auth because they have native auth: Grafana, Gitea, OpenWebUI, Jellyfin, *arr, Pi-hole.
Verification pitfalls:
- Curl or bot-like clients may get Anubis JS challenge page with HTTP 200. That does not prove the app or outpost succeeded.
- Authentik outpost provider matching depends on exact Host header. Missing/wrong Host in CLI probes can produce misleading 404s.
- Verify end-to-end login in a real browser after solving Anubis. Use logs to debug outpost 404/provider host-match failures.