Auto-discover jails and add WireGuard peer info to status page

Replace the per-jail check scripts with checks/jails.sh, which lists
running jails via jls and resolves each one's IPv4 (falling back to
jexec+ifconfig for VNET jails, which don't set the ip4.addr jail
parameter). New jails now show up without adding a script; the
trade-off is a stopped jail just disappears rather than showing down,
since jls only lists what's running.

checks/wireguard.sh now also reports each configured peer's allowed-IP
and time since last handshake, parsed from `wg show wg0 dump`.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

1 files changed, 42 insertions, 3 deletions

diff --git a/statuspage/README.md b/statuspage/README.md
index 3c2ae85..2b1026d 100644
--- a/statuspage/README.md
+++ b/statuspage/README.md
@@ -63,6 +63,22 @@ That's it - no changes to `render.sh`, no template edits. It picks up any
 executable `checks/*.sh` file automatically and renders whatever sections
 it finds.
 
+### Jails are auto-discovered, not one script per jail
+
+`checks/jails.sh` is the exception to "one script per metric" - instead of
+a `jail-<name>.sh` per jail, it calls `jls -n name` once and reports every
+*currently running* jail it finds, resolving each one's IPv4 address (via
+the `ip4.addr` jail parameter for classic jails, falling back to `jexec
+<name> ifconfig` for VNET jails, which manage their own network stack and
+usually don't have `ip4.addr` set) and probing port 80 on it.
+
+Roll a new jail and it shows up on the next render automatically - no file
+to add. The trade-off: a jail that's *supposed* to exist but isn't running
+won't show up as a `down` row, it just won't appear at all, since `jls`
+only lists running jails. If you need "this jail should exist and
+doesn't" alerting, that needs an explicit expected-jails list, which isn't
+implemented here.
+
 ## Failure isolation
 
 `render.sh` runs each check script and handles three failure modes without
@@ -86,23 +102,46 @@ ever need to emit richer JSON (nested objects, arrays), the awk parser in
 
 ## Deployment
 
+`/usr/local/etc/statuspage` is a symlink to this checkout
+(`~/projects/console/statuspage` on the server). Deploying an update is
+just `git pull` there - cron picks up the change on its next run.
+
 Cron (as root):
 
 ```
 * * * * * /usr/local/etc/statuspage/render.sh
 ```
 
-Caddyfile (bind to the WireGuard interface IP only):
+Caddyfile - served over a real, browser-trusted cert via DNS-01 (Porkbun),
+but bound only to the WireGuard interface so it's unreachable from the
+public internet even though the hostname resolves via public DNS:
 
 ```
-172.16.0.1:8080 {
+status.dandokmang.com {
+    bind 172.16.0.1
+    tls {
+        dns porkbun {
+            api_key {env.PORKBUN_API_KEY}
+            api_secret_key {env.PORKBUN_SECRET_KEY}
+        }
+    }
     root * /usr/local/www/status
     file_server
 }
 ```
 
+This requires:
+- A Caddy build with the `github.com/caddy-dns/porkbun` module (the
+  pkg-installed FreeBSD binary doesn't include it - get one from
+  [caddyserver.com/download](https://caddyserver.com/download)).
+- `status.dandokmang.com` set as an explicit A record -> `172.16.0.1` in
+  Porkbun DNS, overriding the `*.dandokmang.com` wildcard that otherwise
+  points to the public IP.
+- `PORKBUN_API_KEY` / `PORKBUN_SECRET_KEY` set in the environment Caddy's
+  service reads (Porkbun account -> API Access, enabled per-domain).
+
 Reload Caddy after editing: `service caddy reload`.
-Access from a WireGuard peer: `http://172.16.0.1:8080`.
+Access from a WireGuard peer: `https://status.dandokmang.com`.
 
 `render.sh` writes to `/usr/local/www/status/index.html` by default;
 override with the `STATUSPAGE_OUT` environment variable (useful for local