2026-08-08 15:19:11 +02:00
|
|
|
# phoenixd Configuration Variables
|
|
|
|
|
# https://phoenix.acinq.co/server
|
|
|
|
|
|
|
|
|
|
# Version - pin to a specific release tag
|
|
|
|
|
phoenixd_version: "0.9.0"
|
|
|
|
|
phoenixd_arch: "linux-x64"
|
|
|
|
|
phoenixd_url: "https://github.com/ACINQ/phoenixd/releases/download/v{{ phoenixd_version }}/phoenixd-{{ phoenixd_version }}-{{ phoenixd_arch }}.zip"
|
|
|
|
|
|
|
|
|
|
# Service user
|
|
|
|
|
phoenixd_user: phoenix
|
|
|
|
|
phoenixd_group: phoenix
|
|
|
|
|
|
|
|
|
|
# Directories
|
|
|
|
|
phoenixd_home: /opt/phoenixd
|
|
|
|
|
# phoenixd resolves its data dir from PHOENIX_DATADIR; seed.dat, phoenix.conf
|
|
|
|
|
# and the channel db all live here.
|
|
|
|
|
phoenixd_data_dir: "{{ phoenixd_home }}/.phoenix"
|
|
|
|
|
phoenixd_bin_dir: /usr/local/bin
|
|
|
|
|
|
|
|
|
|
# Lightning settings
|
|
|
|
|
phoenixd_chain: mainnet
|
|
|
|
|
# Amount automatically requested when inbound liquidity is needed: off, 2m, 5m, 10m
|
|
|
|
|
phoenixd_auto_liquidity: "2m"
|
|
|
|
|
# Max mining fee for on-chain operations, in sats. Empty means phoenixd's default.
|
|
|
|
|
phoenixd_max_mining_fee: ""
|
|
|
|
|
# Required for non-interactive deployment
|
|
|
|
|
phoenixd_agree_tos: true
|
|
|
|
|
|
|
|
|
|
# HTTP API
|
|
|
|
|
# Stays on loopback: phoenixd is never exposed through Caddy, only local
|
|
|
|
|
# consumers (e.g. LNBits on the same host) talk to it.
|
|
|
|
|
phoenixd_http_bind_ip: "127.0.0.1"
|
|
|
|
|
phoenixd_http_bind_port: 9740
|
|
|
|
|
|
|
|
|
|
# Optional webhook for payment events. Leave empty to disable.
|
|
|
|
|
phoenixd_webhook_url: ""
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
phoenixd: convert to a role, de-Uptime-Kuma the health check
552-line playbook becomes 18 lines plus a 411-line role
(install/service/healthcheck phases, four templates, two handlers).
phoenixd_vars.yml is deleted; its content is the role's defaults.
Task-list diff vs the old playbook shows ONLY the eight Uptime Kuma tasks
removed - everything else identical and in the same order.
phoenixd holds a Lightning node, so the run was checked against a pre-flight:
before: channel 6c25fa83..., balanceSat 1550723, capacitySat 3114830,
blockHeight 966692, active since 2026-09-02
after: identical, and still active since 2026-09-02 - it did NOT restart
`Create phoenixd systemd service` came back unchanged, which is what proves the
template reproduces the live unit byte-for-byte. changed=3 was the health check
script, its unit (Environment rename), and the timer restart. Second run:
changed=0.
Two things the conversion fixed, both symptoms of the deprecation banner having
been applied to contiguous blocks rather than to individual tasks:
- The health check logged "ERROR: UPTIME_KUMA_PUSH_URL not set" on every fire -
about 1,400 times a day - because its Environment= was emptied at
decommissioning. The exit code was still correct so nothing was broken, but it
is exactly the kind of noise that trains you to ignore a log. An unset push
URL is now normal and silent.
- `Enable and start phoenixd health check timer` was guarded by
uptime_kuma_enabled and so had not run since the decommissioning, while the
timer itself was still live on the host from before. Ansible had quietly
stopped managing something that was still running. Ungated.
Noted, not changed: seed.dat is mode 0644 on the host. That is phoenixd's own
doing, but it is a Lightning seed and worth tightening.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-12 18:21:24 +02:00
|
|
|
|
|
|
|
|
# --- Health check -----------------------------------------------------------
|
|
|
|
|
# The check asks phoenixd itself whether it is healthy (service active AND the
|
|
|
|
|
# node answers getinfo with a nodeId) and records the answer in its exit code,
|
|
|
|
|
# which systemd keeps:
|
|
|
|
|
# systemctl is-failed phoenixd-healthcheck.service
|
|
|
|
|
# That is a complete answer with no monitoring system involved.
|
|
|
|
|
phoenixd_healthcheck_script_path: /usr/local/bin/phoenixd-healthcheck-push.sh
|
|
|
|
|
phoenixd_healthcheck_service_name: phoenixd-healthcheck
|
|
|
|
|
|
|
|
|
|
# WHERE TO REPORT HEALTH — the one place to plug in monitoring.
|
|
|
|
|
# Empty means check, log, exit honestly, report nowhere. Any endpoint that
|
|
|
|
|
# accepts an HTTP ping works; nothing here is specific to a monitoring product.
|
|
|
|
|
healthcheck_push_url: ""
|
uptime kuma: remove every live reference, repoint the probes to Gatus
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>
2026-09-14 10:30:28 +02:00
|
|
|
# Bearer token for the Gatus external endpoint. Required whenever a push URL
|
|
|
|
|
# is set: Gatus rejects an unauthenticated push with 401.
|
|
|
|
|
healthcheck_push_token: ""
|