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 | ||
fulcrum
Deploys Fulcrum, an Electrum server
indexing the Bitcoin Knots node, on fulcrum-box. The second play in the
calling playbook publishes its SSL port from the edge host via socket_proxy.
Converted from deploy_fulcrum_playbook.yml (685 lines) under Plan 6. The
playbook is now 33 lines.
The index is the expensive thing
{{ fulcrum_db_dir }} is ~192 GB and takes days to rebuild. Nothing in this role
touches it beyond state: directory with the ownership it already has
(fulcrum:fulcrum 0755). Restarting Fulcrum re-opens the database; it does not
reindex.
Three things this conversion fixed, all pre-existing
bitcoind pointed at the wrong machine. The vars file carried
bitcoin_rpc_host: "192.168.1.140" commented "IP of knots_box_local", but .140
is fulcrum-box itself — knots-box is .135. The DHCP leases had reshuffled.
The live config had already been hand-corrected to knots-box; running the
playbook would have reverted it and broken indexing. Now addressed by Tailscale
name, like everything else in this repo.
The restart handler was inert. It carried
when: uptime_kuma_enabled | default(false), so the three tasks that notify it
(SSL certificate, fulcrum.conf, systemd unit) could not restart anything. A
configuration change would write to disk, report success, and silently never take
effect. Ungated.
db_mem was about to quadruple. The role computes a share of RAM; on this
5931 MB host 75% is 4448 MB, leaving ~1.4 GB for the OS and Fulcrum's non-cache
memory. The live value had been hand-tuned to 2048. fulcrum_db_mem_mb_override
pins it. Note set_fact outranks role defaults, so the calculation has to
honour the override — pinning it in defaults/ alone is silently ignored.
The health check timer, and how to read it
The timer is OnBootSec + OnUnitActiveSec with no OnCalendar. That
combination has a failure mode worth knowing: OnBootSec is monotonic and
elapses once; OnUnitActiveSec schedules relative to the service last being
active. If the service does not run in a given boot, there is no reference to
schedule from and the timer sits active and enabled doing nothing. That is
exactly what had happened here — last trigger 2026-02-17, seven months of no
health check, with every surface-level indicator green.
Restarting the timer does not supply that reference; running the service does. So the role runs the check once after enabling the timer, which is both the fix and a smoke test.
Diagnosing this is easy to get wrong: NextElapseUSecRealtime is always
empty for a monotonic timer, so it looks broken even when it is fine. Read
NextElapseUSecMonotonic, or just use systemctl list-timers.
The timer also no longer carries Requires=fulcrum.service. On a timer that
means "stop watching when the watched thing stops", which is backwards for a
health check.
Monitoring: one variable, no product knowledge
The check tests the Electrum TCP port and records the answer in its exit code,
which systemd keeps: systemctl is-failed fulcrum-healthcheck.service. To report
elsewhere set healthcheck_push_url to any endpoint accepting an HTTP ping. The
Uptime Kuma API calls, monitor creation and token handling are gone.