caddy: close out Plan 4
All five close-out greps return nothing: no sites-enabled handling outside roles/, no `systemctl reload caddy`, no caddy_sites_dir self-reference, no inline proxy unit writes. 37 playbooks syntax clean. The 14 Caddy site files and 6 proxy units on the hosts are byte-identical to the Stage 0 baseline. Seven play names still said "on vipy" while the play targeted a group. Renamed to "on the edge host" - the last place a play claimed a hostname after Plan 2. Documented the four vhosts in /etc/caddy/sites-enabled that no playbook writes (uptime-kuma, arbretstaging, bitcoininfra, scriberr) in the caddy_site README. None deleted. uptime-kuma.conf was going to be deleted as dead config. It is not dead: the louislam/uptime-kuma container is STILL RUNNING on watchtower - created 2026-02-07, restart=unless-stopped, healthy - and uptime.contrapeso.xyz returns 302, not the 502 a dead backend would give. The "decommissioning" retired the Ansible code and the vault credentials, not the service. PLAN_3 claimed "the tokens died with the server"; that is corrected there. The Caddyfile.* backups are kept: one per host, Nov-Dec 2025, not churning, and the only record of each Caddyfile before the import line was added. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
c4094b692f
commit
cea2523e15
7 changed files with 31 additions and 7 deletions
|
|
@ -92,3 +92,27 @@ upstream hostname` in every case. `datum-gateway` previously said `# Resolve via
|
|||
Tailscale MagicDNS`. Migrating it therefore rewrites one comment line, which
|
||||
Caddy ignores. Every other site renders byte-identical to what its playbook
|
||||
produced.
|
||||
|
||||
## Sites on the hosts that this role does NOT manage
|
||||
|
||||
Four vhosts exist in `/etc/caddy/sites-enabled/` that no playbook writes. They
|
||||
were made by hand. The role only ever writes the one file it is told to, so it
|
||||
leaves them alone — but nothing in the repo records them, and that is why they
|
||||
are listed here. Checked 2026-09-11:
|
||||
|
||||
| File | Host | Serves | State |
|
||||
|---|---|---|---|
|
||||
| `uptime-kuma.conf` | watchtower | `localhost:3001` | **HTTP 302 — still live**, see below |
|
||||
| `arbretstaging.conf` | vipy | `arbret-staging-box:80` via MagicDNS | HTTP 200 |
|
||||
| `bitcoininfra.conf` | vipy | static `file_server` from `/var/www/bitcoin-services-home` | HTTP 200 |
|
||||
| `scriberr.conf` | vipy | `scriberr-box:8080` via MagicDNS | HTTP 502 — upstream down |
|
||||
|
||||
**`uptime-kuma.conf` must not be deleted as dead config.** Uptime Kuma was
|
||||
"decommissioned" in the repo — its playbooks archived and its credentials pulled
|
||||
from the vault — but the container is **still running** on watchtower
|
||||
(`louislam/uptime-kuma:latest`, created 2026-02-07, `restart=unless-stopped`)
|
||||
and is still reachable at its public subdomain. Only the Ansible code was
|
||||
retired; the service was not. See `archive/uptime_kuma/`.
|
||||
|
||||
`scriberr` returning 502 is the one that looks like genuine rot: it proxies to a
|
||||
`scriberr-box` that is not answering, and `scriberr-box` is not in the inventory.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue