counterweight
bf3d21fef7
Nothing in the repo pushes to, authenticates against, or is gated by Uptime
Kuma any more.
── The sixth instance of the banner bug ────────────────────────────────────
memos had `Restart memos` guarded by `uptime_kuma_enabled`, because the
deprecation banner was placed immediately above it and swept it in. It is a
HANDLER, so every memos config change since 2026-09-11 applied to disk and
silently never restarted the service. Ungated.
That is the same failure found in forgejo-runner's self-assert, phoenixd's timer
enable, mempool's three timer enables, fulcrum's restart handler and bitcoind's
restart handler. Every guard was read and asked "monitoring or deployment?"
before being deleted, which is the only reason this was caught.
── What was removed ────────────────────────────────────────────────────────
30 uptime_kuma_enabled guards across 7 unconverted service playbooks, and
the 29 Kuma monitor-creation tasks they gated (embedded Python that drove
the Kuma API, temp credential files, cleanup)
7 dead uptime_kuma_api_url definitions
7 stale DEPRECATED banners
uptime_kuma_enabled and subdomains.uptime_kuma from group_vars/all
healthcheck_push_urls from the vault - 30 push tokens
services/ntfy/setup_ntfy_uptime_kuma_notification.yml -> archive/
The explanatory comments in the six converted roles are KEPT on purpose. They
record why a handler is ungated, and deleting the explanation invites someone
to helpfully re-add the guard.
── The probes moved rather than died ───────────────────────────────────────
Eight per-service health checks were still pushing to Kuma. They are not
superseded by infra/401: that answers "is the unit running", these answer "does
the service actually respond" - an RPC call to bitcoind, a TCP connect to
Fulcrum's Electrum port, an HTTP fetch from Mempool's backend. A process can be
perfectly `active` and useless.
So they were repointed, not deleted. Gatus external endpoints take a POST with
a bearer token and success=true|false where Kuma took a GET with ?status=up, so
report() now maps up/down to true/false internally and no call site changed.
Registered by infra/403 as the `probe` group, one token per host.
Two bugs fixed while in there:
* forgejo-runner's check only ever reported SUCCESS - it exited before pushing
when the runner was down, so a failure was invisible until the heartbeat
window expired. Reporting the failure is the entire point of a check.
* All six healthcheck .service units were mode 0644 and now carry a bearer
token. They are 0600.
Verified: 91 endpoints, 91 UP, 0 DOWN. Every probe triggered by hand and
confirmed arriving. Zero Kuma URLs left in the vault, zero live references in
any playbook or role.
Still standing, deliberately: the Kuma container on watchtower, its Caddy vhost,
and the uptime.contrapeso.xyz DNS record. Turning the service off is a separate
decision from removing the code that talked to it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| defaults | ||
| handlers | ||
| tasks | ||
| templates | ||
| README.md | ||
datum_gateway
Builds and runs DATUM Gateway, the
solo/pooled mining gateway, on knots-box. The calling playbook adds two more
plays on the edge host: the dashboard via caddy_site, and the public Stratum
port via socket_proxy.
Converted from deploy_datum_gateway_playbook.yml (802 lines) under Plan 6. The
playbook is now 68 lines and keeps all three plays.
⚠ This is half of a system
The Bitcoin Knots node on the same host feeds this gateway through
blocknotify=killall -USR1 datum_gateway in bitcoin.conf — see
roles/bitcoin_knots/README.md, where that line was found to be missing from the
template entirely. Changing either config means thinking about both.
Interrupting Stratum costs mining shares. Check before any run that restarts it:
ss -tn state established '( sport = :23334 )'
Two pieces of drift where the node was right
The repo and the node had diverged on values that matter, and the deployment would have applied the repo's:
| node (correct) | repo said | |
|---|---|---|
datum_mining_address |
bc1qvrj3g84… |
bc1qdse9dsg… |
pool_pass_workers / _full_users |
false |
true |
The address is the one that would have hurt: it is where block rewards are
paid, and unlike fulcrum and bitcoin-knots the Restart datum-gateway handler
here was never gated, so the change would have applied immediately rather than
sitting inert. Both corrected in the vault and defaults, with notes.
Verify semantics rather than text when touching config.json — render it and
compare parsed JSON, because the live file is single-line and the template is
pretty-printed, so a textual diff is all noise:
json.load(open('live.json')) == json.load(open('rendered.json'))
config.json holds real secrets — diff is suppressed
The file carries bitcoind.rpcpassword and api.admin_password. --diff
prints rendered content, so the task sets diff: false by default; pass
-e datum_reveal_config=true to opt in.
Note pool_pass_workers / pool_pass_full_users are booleans, not
passwords, despite the names — they control DATUM's pool-password passthrough.
mining.pool_address is a Bitcoin address and public by nature.
Expect changed on the compile every run
Configure cmake build and Compile datum_gateway are bare command: tasks
with no changed_when, so they always report changed and always re-run. The
build is reproducible — Install datum_gateway binary sees identical content and
does not replace it, so the installed binary keeps its original timestamp — but
the compile itself is wasted work on every run. That is the idempotent floor, not
drift.
Monitoring: one variable, no product knowledge
The check tests the gateway API and records the answer in its exit code, which
systemd keeps: systemctl is-failed datum-gateway-healthcheck.service. Set
healthcheck_push_url to report anywhere accepting an HTTP ping.
Unlike the other services here, only the health-check timer handler was gated
by uptime_kuma_enabled; the main deployment restart worked throughout.