Frank
9bfa0be85d
- 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.
30 lines
1.8 KiB
Markdown
30 lines
1.8 KiB
Markdown
# 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:
|
|
1. If a service should be LAN-only, it is usually safe to remove its ordinary Porkbun A record while keeping Pi-hole local DNS.
|
|
2. Removing public DNS does not remove router port forwards or block direct IP access.
|
|
3. Do not casually remove public DNS for auth.franksdank.cloud; external login flows may need it.
|
|
4. 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.
|