counterweight/personal_infra
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
personal_infra/ansible/site.yml

94 lines
5.6 KiB
YAML
Raw Normal View History

ansible: add site.yml, and rename the monitoring group off the host's name site.yml is a TABLE OF CONTENTS, not a second source of truth. It is 25 import_playbook: lines and comments - no `hosts:`, no `roles:`. Which hosts get what stays on the `hosts:` line inside each playbook, exactly where it already was; nothing moved. Every role is already wrapped in a thin playbook carrying its own `hosts:` line, so there is no roles-vs-playbooks split to reconcile: from here everything is a playbook. What it buys: What runs on a host? ansible-playbook site.yml --limit <host> --list-hosts Who gets thing Y? the `hosts:` line in Y's own playbook What is a host? ansible-inventory --graph Note --list-hosts, not --list-tasks: the latter prints every play regardless of --limit, so it will happily show you the bitcoin play under memos-box. Nine playbooks are deliberately excluded and the file names every one with a reason, so it accounts for all of them: the three infra/4xx monitoring plays (still assert on the removed Uptime Kuma credentials and fail immediately), 910_docker (says `hosts: managed`, but Docker is on 5 of 11 managed hosts and those 5 are exactly the ones that need it - running it installs Docker on the Bitcoin node and the hypervisor), two nodito one-shots, the Kuma notification setup, and two deliberate manual actions. Writing it surfaced an inventory collision. There is a HOST named `monitoring` in [vps] AND a group [monitoring], so Ansible warned and resolved `hosts: monitoring` to the host: [WARNING]: Found both group and host with same name: monitoring The group is renamed to [observability]; the host keeps its name. [caddy:children] and the two ntfy playbooks follow. Behaviour is unchanged - `hosts: monitoring` already resolved to the host - but the ambiguity is gone and the warning with it. Verified: inventory graph is warning-free, site.yml passes --syntax-check, and per-host play counts are identical before and after the rename. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-13 21:24:09 +02:00
---
# Everything, in the order it has to happen.
#
# This file is a TABLE OF CONTENTS, not a second source of truth. It says what
# runs and in what order. It does NOT say which hosts get what — that stays on
# the `hosts:` line inside each playbook, exactly where it is today. Nothing
# moves; this file only makes the set readable in one place.
#
# What runs on a host? ansible-playbook site.yml --limit <host> --list-hosts
# Who gets thing Y? the `hosts:` line in Y's own playbook
# What is a host? ansible-inventory --graph
#
# Run a slice with --limit, or run one playbook directly as before. Nothing here
# changes how any individual playbook behaves.
# ── Baseline: every managed machine ─────────────────────────────────────────
- import_playbook: infra/01_user_and_access_setup_playbook.yml
- import_playbook: infra/02_firewall_and_fail2ban_playbook.yml
- import_playbook: infra/900_install_rsync.yml
- import_playbook: infra/920_join_headscale_mesh.yml
monitoring: retire the Uptime-Kuma-era checks, add ZFS pool capacity Five things deprecated, each verified against the DEPLOYED script before being deleted rather than assumed superseded: infra/410_disk_usage_alerts.yml -> disk-usage check (infra/400) infra/420_system_healthcheck.yml -> liveness check (infra/400) infra/430_cpu_temp_alerts.yml -> cpu-temp check (infra/400) 32_zfs play 2 (monitoring half) -> zfs-health check (infra/400) 34_nut play 2 (entirely) -> ups-status check (infra/400) Nothing is lost by the swap. The old system_healthcheck.sh only computed uptime and pushed, which is exactly a liveness heartbeat. The old disk monitor was WEAKER than its replacement: it checked "/" alone at 80%, where the new one walks every real filesystem at 85%. Deleting the playbooks was not the hard part. The units they installed live on the hosts, enabled, and keep firing regardless of what the repo says - two of them were still pushing to uptime.contrapeso.xyz every 15 minutes across nine machines. A playbook deleted without a cleanup leaves its output running forever with nothing left to explain it. So infra/409_remove_legacy_monitoring stops, disables and removes the units, deletes /opt/{disk-monitoring, system-healthcheck,nodito-monitoring,zfs-monitoring}, and removes the orphaned hand-written ups-heartbeat.sh. It ends by grepping for any surviving Kuma reference and reporting it. Kept permanently and idempotent, so a rebuilt or restored host cannot quietly bring them back. A trap avoided: the monthly ZFS scrub lived INSIDE 32_zfs play 2. Deleting the play wholesale would have silently stopped scrubbing the pool - and an unscrubbed pool makes the health check meaningless, because it would have nothing true to report. That play is now scrub-only and check-runs ok=5 changed=0. ZFS pool capacity added as a sixth condition to the zfs-health check. `zpool status` reports a 95% full pool as perfectly ONLINE, so capacity has to be read separately with `zpool list` - and it is the failure you get warning of rather than the one you discover. Threshold 80%, because ZFS allocation degrades badly past roughly that and fragmentation is hard to undo. The pool is at 47%. Verified both directions: passes on the real pool, and a simulated 91% exits 1. Also fixed the waste recorded in c2de6db: the healthcheck role installed its dependencies once per CHECK rather than per HOST - 29 apt transactions estate-wide for a curl already present, and the slowest part of every deploy. It now deduplicates within a play run, and the redundant standalone daemon_reload is gone (the systemd task already does one). site.yml updated, which exposed that services/gatus was never in it. It now runs before the three registration playbooks, since registering endpoints against a Gatus that is not yet serving would simply fail. Verified: no legacy timer remains on any host; 83 endpoints, 83 UP, 0 DOWN. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-14 10:18:57 +02:00
# Idempotent and kept permanently: guarantees a rebuilt or restored host cannot
# quietly bring the Uptime-Kuma-era monitoring back.
- import_playbook: infra/409_remove_legacy_monitoring.yml
# ── Monitoring ──────────────────────────────────────────────────────────────
# Gatus first: the three plays below register endpoints with it, and registering
# against a host that is not serving yet would simply fail.
- import_playbook: services/gatus/deploy_gatus_playbook.yml
alerting: Signal via signal-cli-rest-api, and faster failure detection Three changes: detection windows tightened, a Signal transport deployed, and alerts attached to all 84 non-transport endpoints. ── Failing faster ────────────────────────────────────────────────────────── The heartbeat is a TICKER, not a deadline: Gatus wakes every interval and asks "did anything arrive in the last interval", so real detection is 1-2x the window. And a window can only ever be as tight as the push frequency - which is why two checks moved rather than just having their numbers changed. liveness, cpu, ups, service-health, probes 16m -> 11m disk, zfs daily/30h -> 6-hourly/7h backup store + pull job daily/30h -> 6-hourly/7h DNS records 24h -> 6h backup dump 30h -> 26h backup-dump stays slow because the dump genuinely is daily. The store-side check catches the same fault within 6h by reading the source's dump timestamp out of the artefact filename, so 26h is a backstop rather than the primary signal. ── Thresholds differ by check type, deliberately ─────────────────────────── `failure-threshold` counts consecutive failures, but "consecutive" is a different amount of wall-clock time per check: a push endpoint produces one failure per heartbeat window, a pulled one per interval. The default of 3 would mean 33 minutes on an 11m heartbeat and over a day on a 7h one. More importantly the heartbeat window ALREADY encodes the tolerance - an 11m window on a 5-minute push is exactly "one missed push forgiven" - so stacking a threshold of 3 triples a tolerance that was already chosen. Hence: push/heartbeat endpoints failure-threshold 1 pulled, 5m (public) failure-threshold 3 (= 15 minutes) pulled, 6h/24h (dns, domain) failure-threshold 1 ── The Signal transport ──────────────────────────────────────────────────── roles/signal_api runs signal-cli-rest-api on the observability host, pinned by digest, MODE=native. It publishes NO PORTS. The API has no authentication of any kind - anything that reaches it can send messages as you and read your Signal. Gatus talks to it over a shared docker network by service name, which is also WHY the network exists: Gatus runs in a container, so the host's loopback is unreachable from it and a port published on 127.0.0.1 would not have worked. MODE=native and not json-rpc because this VPS has 464MB of RAM and already runs Gatus and Caddy. The json-rpc modes hold a resident JVM; native runs a binary per request, and alerts are rare enough that startup cost per alert is the right trade. Monitored - Gatus polls /v1/health over the same network path the alerts take, so it proves the delivery route rather than mere container liveness. Deliberately NOT backed up: the data directory holds Signal private keys and the recovery path is to link the device again from the phone. Neither the signal-api endpoint nor Gatus's self-check carries a Signal alert. If either is down, Signal is precisely what cannot deliver the alert. ── Four traps hit while linking, all now in the role README ──────────────── * /v1/qrcodelink is BROKEN in native mode - returns "no data to encode" while the binary itself emits a perfectly good URI. Not worked around by switching MODE, which would put a JVM in the path of every alert permanently. * The data dir must be owned by uid 1000, not root. A root-owned 0700 dir cannot be traversed by the container user, so linking silently never completes and /v1/accounts returns "Failed to read local accounts list". * `docker exec` runs as ROOT while the service runs as uid 1000, so without --config the account is written to /root/... on the container's ephemeral layer. It reports success and is destroyed on the next recreate. * The phone reporting "network error" was IPv6: chat.signal.org resolves to dualstack AAAA records first, the container has no IPv6 address, and this host's IPv6 path is broken - the same edge that 404'd the Go tarball. Fixed with a mounted gai.conf that prefers IPv4. Verified: provider loads (configuredProviders=[signal]), a test message was delivered and confirmed received, 84 endpoints carry alerts, 86 UP / 0 DOWN. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-14 21:40:37 +02:00
# The Signal transport for Gatus alerts. Shares a docker network with Gatus and
# publishes no ports - the API has no authentication. Needs a one-time manual
# device link; see roles/signal_api/README.md.
- import_playbook: services/signal-api/deploy_signal_api_playbook.yml
monitoring: retire the Uptime-Kuma-era checks, add ZFS pool capacity Five things deprecated, each verified against the DEPLOYED script before being deleted rather than assumed superseded: infra/410_disk_usage_alerts.yml -> disk-usage check (infra/400) infra/420_system_healthcheck.yml -> liveness check (infra/400) infra/430_cpu_temp_alerts.yml -> cpu-temp check (infra/400) 32_zfs play 2 (monitoring half) -> zfs-health check (infra/400) 34_nut play 2 (entirely) -> ups-status check (infra/400) Nothing is lost by the swap. The old system_healthcheck.sh only computed uptime and pushed, which is exactly a liveness heartbeat. The old disk monitor was WEAKER than its replacement: it checked "/" alone at 80%, where the new one walks every real filesystem at 85%. Deleting the playbooks was not the hard part. The units they installed live on the hosts, enabled, and keep firing regardless of what the repo says - two of them were still pushing to uptime.contrapeso.xyz every 15 minutes across nine machines. A playbook deleted without a cleanup leaves its output running forever with nothing left to explain it. So infra/409_remove_legacy_monitoring stops, disables and removes the units, deletes /opt/{disk-monitoring, system-healthcheck,nodito-monitoring,zfs-monitoring}, and removes the orphaned hand-written ups-heartbeat.sh. It ends by grepping for any surviving Kuma reference and reporting it. Kept permanently and idempotent, so a rebuilt or restored host cannot quietly bring them back. A trap avoided: the monthly ZFS scrub lived INSIDE 32_zfs play 2. Deleting the play wholesale would have silently stopped scrubbing the pool - and an unscrubbed pool makes the health check meaningless, because it would have nothing true to report. That play is now scrub-only and check-runs ok=5 changed=0. ZFS pool capacity added as a sixth condition to the zfs-health check. `zpool status` reports a 95% full pool as perfectly ONLINE, so capacity has to be read separately with `zpool list` - and it is the failure you get warning of rather than the one you discover. Threshold 80%, because ZFS allocation degrades badly past roughly that and fragmentation is hard to undo. The pool is at 47%. Verified both directions: passes on the real pool, and a simulated 91% exits 1. Also fixed the waste recorded in c2de6db: the healthcheck role installed its dependencies once per CHECK rather than per HOST - 29 apt transactions estate-wide for a curl already present, and the slowest part of every deploy. It now deduplicates within a play run, and the redundant standalone daemon_reload is gone (the systemd task already does one). site.yml updated, which exposed that services/gatus was never in it. It now runs before the three registration playbooks, since registering endpoints against a Gatus that is not yet serving would simply fail. Verified: no legacy timer remains on any host; 83 endpoints, 83 UP, 0 DOWN. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-14 10:18:57 +02:00
- import_playbook: infra/400_host_monitoring.yml
- import_playbook: infra/401_service_monitoring.yml
- import_playbook: infra/402_public_monitoring.yml
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
# Registers where the per-service probes report. The probes themselves are
# deployed by each service's own playbook further down; the endpoints must exist
# before the first push arrives.
- import_playbook: infra/403_service_probe_registration.yml
ansible: add site.yml, and rename the monitoring group off the host's name site.yml is a TABLE OF CONTENTS, not a second source of truth. It is 25 import_playbook: lines and comments - no `hosts:`, no `roles:`. Which hosts get what stays on the `hosts:` line inside each playbook, exactly where it already was; nothing moved. Every role is already wrapped in a thin playbook carrying its own `hosts:` line, so there is no roles-vs-playbooks split to reconcile: from here everything is a playbook. What it buys: What runs on a host? ansible-playbook site.yml --limit <host> --list-hosts Who gets thing Y? the `hosts:` line in Y's own playbook What is a host? ansible-inventory --graph Note --list-hosts, not --list-tasks: the latter prints every play regardless of --limit, so it will happily show you the bitcoin play under memos-box. Nine playbooks are deliberately excluded and the file names every one with a reason, so it accounts for all of them: the three infra/4xx monitoring plays (still assert on the removed Uptime Kuma credentials and fail immediately), 910_docker (says `hosts: managed`, but Docker is on 5 of 11 managed hosts and those 5 are exactly the ones that need it - running it installs Docker on the Bitcoin node and the hypervisor), two nodito one-shots, the Kuma notification setup, and two deliberate manual actions. Writing it surfaced an inventory collision. There is a HOST named `monitoring` in [vps] AND a group [monitoring], so Ansible warned and resolved `hosts: monitoring` to the host: [WARNING]: Found both group and host with same name: monitoring The group is renamed to [observability]; the host keeps its name. [caddy:children] and the two ntfy playbooks follow. Behaviour is unchanged - `hosts: monitoring` already resolved to the host - but the ambiguity is gone and the warning with it. Verified: inventory graph is warning-free, site.yml passes --syntax-check, and per-host play counts are identical before and after the rename. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-13 21:24:09 +02:00
# 910_docker says `hosts: managed`, but only 5 of 11 managed hosts have or need
# Docker. Left out until it has a [docker] group — see the note in PLAN_7.
# ── The hypervisor ──────────────────────────────────────────────────────────
- import_playbook: infra/nodito/31_proxmox_community_repos_playbook.yml
- import_playbook: infra/nodito/32_zfs_pool_setup_playbook.yml
- import_playbook: infra/nodito/34_nut_ups_setup_playbook.yml
# ── Reverse proxy, before anything that registers a vhost ───────────────────
- import_playbook: services/caddy_playbook.yml
# ── Services ────────────────────────────────────────────────────────────────
- import_playbook: services/bitcoin-knots/deploy_bitcoin_knots_playbook.yml
- import_playbook: services/fulcrum/deploy_fulcrum_playbook.yml
- import_playbook: services/datum-gateway/deploy_datum_gateway_playbook.yml
- import_playbook: services/mempool/deploy_mempool_playbook.yml
monero: a full node on its own box, reachable from Feather over the WAN monerod v0.18.5.1 on monerod-box (VMID 2400), Debian 13, systemd, no Docker. Syncing at 24% as of this commit, 0 restarts, 0 OOM kills. ── The build-from-source requirement could not be met ────────────────────── The intent was to build it ourselves and check the result against the published checksums. That is not achievable for this release, and the role's README says so at length so nobody re-derives it: contrib/guix - the reproducible build that yields a byte-identical tarball - exists ONLY on monero master. At tag v0.18.5.1 contrib/ contains `gitian`, whose README wants an Ubuntu 18.04 host (EOL 2023) and python-cheetah. A plain `make release-static` is not reproducible at all, so it produces a binary whose hash matches nothing - failing both halves of the ask. So we install the published binary and prove its provenance instead: 1. binaryFate's key is VENDORED at files/binaryfate.asc. A trust root fetched over the network at the moment you need it is not a trust root. Its fingerprint is asserted after import regardless. 2. hashes.txt is verified, and the assertion is on gpg's `VALIDSIG <fpr>` status line - NOT on the string "Good signature", which is what bitcoin_knots greps for and which passes for any key in the keyring. 3. The hash is looked up in the output of `gpg --decrypt`, not in the raw clearsigned file, so nothing unsigned is ever searched. 4. The lookup requires hash AND filename on one line. Tested with a positive and a negative control before deploying: the real tarball matches, a corrupted hash correctly fails. monero_sha256 in defaults/ is a second in-git assertion so a version bump cannot happen without the checksum moving in the same diff. When v0.19 ships with guix on the release branch this gets easier, and the README records why: the published monero-linux-x64 tarball unpacks to monero-x86_64-linux-gnu-v0.18.5.1/, i.e. it IS the guix DISTNAME renamed, so sha256(guix output) will equal the hashes.txt entry exactly. ── The 500 GB disk is provisioned in code ────────────────────────────────── knots-box mounts /mnt/knots_data (~875 GB of chain) entirely by hand; that mount appears nowhere in Ansible and a rebuild of that host would come up with the blockchain silently missing. tasks/storage.yml does not repeat it. Whole device, no partition table. Everything after mkfs goes by UUID, because /dev/sdX is assigned by the kernel at boot and this estate has been bitten eight times by an identifier written down once whose thing then moved. monero_data_device is used ONLY to create the filesystem. Guards refuse to touch the root disk or to overwrite an unrecognised filesystem, and a final assert confirms the data directory is not still on /. fstab gets `nofail` so a missing disk cannot drop a headless VM into an emergency shell - and the unit gets `RequiresMountsFor=`, without which monerod would then start, find an empty directory, and write a 300 GB chain onto a 10 GB root disk. With it the unit refuses to start and infra/401 says so within five minutes. The mount-point task and the ownership task deliberately share owner and mode. Writing the obvious root:root 0755 on the first made them disagree and every run flipped the directory back and forth; caught by re-running --check. ── Exposure: one HTTPS vhost, zero new open ports ────────────────────────── Two RPC servers, not one: unrestricted on 127.0.0.1:18081 for administration and the health check, restricted on :18089 for everything else. That is `rpc-restricted-bind-port` and deliberately NOT `restricted-rpc=1`, which would restrict the loopback server too. Verified live: the restricted port reports restricted=true and blanks version and start_time. --rpc-login is HTTP Digest (contrib/epee/src/http_auth.cpp) and core_rpc_server::init hands the same login to both servers. Caddy on vipy does TLS and routing only - no caddy_site_basic_auth, because a Basic challenge would collide with the Digest challenge Feather answers. Verified end to end from the WAN: 401 unauthenticated, get_block_count over /json_rpc when authenticated, 401 again with a wrong password. No UFW rule, and that is correct: tailnet traffic bypasses UFW entirely because `-A INPUT -j ts-input` sits ahead of every ufw-* chain. Confirmed on mempool-box before relying on it here. P2P is outbound only. Nothing forwards 18080, so the node dials out, syncs and serves us without relaying for strangers; no-igd follows from that. ── Monitoring: infra, systemd, public. No backups ────────────────────────── Six Gatus endpoints, all green: liveness, disk, services/monerod-box-local/ monerod, probe/monerod, dns/monero.contrapeso.xyz, public/monero. The probe does NOT assert `synchronized`. A full sync takes days and a check requiring it would report DOWN for every one of them - an alarm with the batteries taken out. Height and sync state go in the message instead. The timer carries no `Requires=monerod.service`. Fulcrum's did, and sat active+enabled for seven months without firing once. public/monero asserts 401, not 200, so it goes red if rpc-login ever stops being enforced. No backups, deliberately, following the phoenixd precedent: the chain is re-syncable public data and there is no wallet on this node. ── Known constraint ──────────────────────────────────────────────────────── The VM has 2 GB and no swap; monerod's RSS is ~1.3 GB mid-sync. It is holding (0 OOM kills, ~1 GB available, kernel reclaiming cache) but 8 GB is the recommendation once the initial sync is done. out-peers/in-peers are held at 16/8 partly for this reason. Bumping it is a Proxmox resize plus memory_mb here, since the vm resource sets ignore_changes = all. The 500 GB data disk is likewise invisible to tofu - it was attached in the UI and the vm resource ignores it - so vms.auto.tfvars now carries a comment saying where it is and what mounts it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-19 17:50:46 +02:00
- import_playbook: services/monero/deploy_monero_playbook.yml
xmrblocks: the Monero explorer, built off-box because 2 GB cannot compile it The Onion Monero Blockchain Explorer on monerod-box, published at exmrplore.contrapeso.xyz. Ten Gatus endpoints green across the node and the explorer. ── It needs a compiled monero source tree, not a running monerod ─────────── xmrblocks is not an RPC client. cmake/FindMonero.cmake imports 21 STATIC libraries out of a monero build tree and includes its headers, because it opens the LMDB directly. The release tarball we install for the daemon ships only executables - no .a files, no headers - so there is nothing on the box to link against, and building it means compiling monero first. Measured on Debian 13, building only the libraries it links: peak RSS, one cc1plus ~3.2 GB peak RSS at -j4 ~5.5 GB wall time at -j4 167 s source + build tree 195 MB toolchain 1.6 GB That rules the box out at ANY parallelism: 768 MiB and 1800 MiB were both OOM-killed at -j1 and -j2, because a single translation unit over 3 GB is not something lower -j works around. My first estimate of "~10 GB of disk" was wrong by two orders of magnitude - that figure describes upstream's full `make`, which also builds monerod, both wallets and the test suite, none of it linked here. Disk was never the constraint. So scripts/build-xmrblocks.sh does the build in a debian:13 container. An artefact only one machine can produce is one nobody can audit; this way any host with Docker and ~6 GB reproduces it. It verifies the monero source against binaryFate's signature exactly as roles/monero does for the daemon, and the role asserts the resulting sha256 ON THE CONTROL NODE before copying a single byte. ── Three upstream problems, none documented anywhere ─────────────────────── Found by building, not by reading: 1. libasio-dev is absent from upstream's dependency list. That list is Ubuntu-based; Crow wants standalone asio.hpp, not boost/asio.hpp, and on Debian 13 the build dies outright. 2. The explorer does not compile against monero v0.18.5.1. v0.18.5.0 changed get_pruned_transaction_hash from returning the hash to returning bool with an out-param, and src/page.h still calls the old form. Upstream's Dockerfile pins v0.18.4.0, which is why nobody has hit it. Patched from an exact-line anchor, so if upstream fixes it the build STOPS rather than quietly doing something else. We patch instead of building against 0.18.4.0 because the signed hashes.txt only covers the current release - using the older source would mean dropping the provenance chain. LMDB is VERSION 5 in both, so either reads the other's database. 3. FindMonero.cmake hunts for miniupnpc inside the monero build tree with NO_DEFAULT_PATH, but monero stopped vendoring miniupnp as a submodule. Fixed with a cache override rather than patching their cmake. USE_DEVICE_TREZOR=OFF as well - an explorer has no use for hardware wallets and it drops the generated protobuf units. Verified that xmrblocks still links. ── Two things in the unit that look wrong and are not ────────────────────── WorkingDirectory is load-bearing: page.h hardcodes TMPL_DIR as "./templates", resolved relative to cwd at REQUEST time. Get it wrong and the service starts, binds 8081, and 500s every page. That is also why the health check fetches a real page and greps it instead of probing the port. ReadWritePaths must include the blockchain directory even though the database is opened read-only: monero sets mdb_flags = MDB_RDONLY WITHOUT MDB_NOLOCK, so LMDB still registers this reader in lock.mdb. With ProtectSystem=strict and nothing writable the open fails. "It only reads, so grant it nothing" is wrong. ── Timeouts are measured, not guessed ────────────────────────────────────── proxmox-tank-1 is a spinning-disk mirror and xmrblocks says so on startup. First start took 98s to open the LMDB before binding (wait_for now allows 300s), and a COLD index page took 68 SECONDS where the next two took 0.87s and 0.012s (the check now allows 90s, its unit 180s). The first pass used 90s and 25s and produced exactly the false failures you would expect. A stat() bug was caught the same way: `stat` computes a sha1 by default, so checking that data.mdb exists was hashing the entire 40 GB blockchain. --check found it before a real run did. ── Exposure ──────────────────────────────────────────────────────────────── Caddy on vipy terminates TLS; the upstream is reached over the tailnet, which needed a headscale ACL entry for tag:monerod-box:8081 - without it the node is invisible, not merely unreachable, and the symptom is a 502 "no such host". No authentication, deliberately: it is a block explorer over public chain data. That includes --enable-pusher, so a visitor can relay a raw transaction through our node. A choice, not an oversight; flip xmrblocks_enable_pusher to close it. ── Also ──────────────────────────────────────────────────────────────────── monerod-box raised 2048 -> 6144 MiB. Not for the explorer: monerod alone had outgrown 2 GB past ~39% of the chain and was OOM-killed twice in a morning at 1.74 GB anon-rss. Recorded in vms.auto.tfvars because ignore_changes = all means tofu will not reconcile it. The box now idles at ~1.2 GB of 5.9 GB with both services up. No backups, deliberately - binary, templates and chain are all reproducible. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-20 17:06:30 +02:00
- import_playbook: services/xmrblocks/deploy_xmrblocks_playbook.yml
ansible: add site.yml, and rename the monitoring group off the host's name site.yml is a TABLE OF CONTENTS, not a second source of truth. It is 25 import_playbook: lines and comments - no `hosts:`, no `roles:`. Which hosts get what stays on the `hosts:` line inside each playbook, exactly where it already was; nothing moved. Every role is already wrapped in a thin playbook carrying its own `hosts:` line, so there is no roles-vs-playbooks split to reconcile: from here everything is a playbook. What it buys: What runs on a host? ansible-playbook site.yml --limit <host> --list-hosts Who gets thing Y? the `hosts:` line in Y's own playbook What is a host? ansible-inventory --graph Note --list-hosts, not --list-tasks: the latter prints every play regardless of --limit, so it will happily show you the bitcoin play under memos-box. Nine playbooks are deliberately excluded and the file names every one with a reason, so it accounts for all of them: the three infra/4xx monitoring plays (still assert on the removed Uptime Kuma credentials and fail immediately), 910_docker (says `hosts: managed`, but Docker is on 5 of 11 managed hosts and those 5 are exactly the ones that need it - running it installs Docker on the Bitcoin node and the hypervisor), two nodito one-shots, the Kuma notification setup, and two deliberate manual actions. Writing it surfaced an inventory collision. There is a HOST named `monitoring` in [vps] AND a group [monitoring], so Ansible warned and resolved `hosts: monitoring` to the host: [WARNING]: Found both group and host with same name: monitoring The group is renamed to [observability]; the host keeps its name. [caddy:children] and the two ntfy playbooks follow. Behaviour is unchanged - `hosts: monitoring` already resolved to the host - but the ambiguity is gone and the warning with it. Verified: inventory graph is warning-free, site.yml passes --syntax-check, and per-host play counts are identical before and after the rename. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-13 21:24:09 +02:00
- import_playbook: services/memos/deploy_memos_playbook.yml
navidrome: a music server on its own box, with beets in front of it Navidrome 0.64.0 on music-box (nodito VM 8200, 1 core / 1 GB / 50 GB), public at music.contrapeso.xyz. A single Go binary with a SQLite database; the only external dependency is ffmpeg for transcoding. Plus beets, the CLI that fixes tags before Navidrome ever indexes them. ── Exposed without basic auth, on purpose ───────────────────────────────── Navidrome speaks two protocols on one port: its web UI, and the Subsonic API (/rest/*) that every mobile client actually uses. A Subsonic client authenticates with ?u=&t=md5(password+salt)&s= in the query string and has nowhere to carry a second credential, so Basic Auth in front of the site is invisible to most of them. The choice is a proxy credential or a working phone. Same call this estate already made for monerod's restricted RPC, for the same reason: proxied bare so Feather can reach it, with the service's own auth doing the authenticating. The cost is stated rather than glossed: the login page and the whole /rest/* surface are reachable by anyone who finds the hostname, and Navidrome has no rate limiting and no 2FA. A fail2ban jail on vipy reads a per-vhost Caddy access log and catches WEB UI brute force, where a bad login returns 401. It very likely does NOT catch Subsonic brute force, because that protocol answers a bad password with HTTP 200 and puts the failure in the body - which Caddy never sees. Nor can it be fixed on the music box: the request arrives from vipy over the tailnet, so the only address fail2ban could ban there is vipy's, which would take down every service behind the edge. Banning has to happen at the edge; the edge cannot see the failure. So /rest/* is protected by password strength alone, and the README carries a one-line curl to re-check that after every upgrade. ── Passwords are stored reversibly, and cannot not be ───────────────────── The Subsonic API requires the server to compute md5(password+salt) per request, so Navidrome cannot hash passwords one-way. It encrypts them at rest with PasswordEncryptionKey instead. Two real consequences, both in the README: root on that box means every Navidrome password in plaintext, so the password must be unique to this service; and changing the key invalidates every stored password, so it is set before the first account and left alone. ── beets is not a service, deliberately ─────────────────────────────────── `beet import` is interactive and it MOVES AND RENAMES FILES. A timer that reorganises a music library unattended is a way to lose one. Installed and configured, run by hand. /srv/music is counterweight:navidrome mode 2750 and the setgid bit is load-bearing: without it beets' files land in the curator's own group, Navidrome cannot read them, and the symptom is an EMPTY LIBRARY rather than a permission error. ReplayGain and lyrics are auto: no - on one core they turn a two-minute import into a twenty-minute one. ── Monitoring ───────────────────────────────────────────────────────────── Host liveness and disk (400), the systemd unit (401), a probe that fetches /app/ and greps it (403), and public reachability plus cert expiry (402). /app/ was chosen by testing all three candidates against 0.64.0: /ping returns a bare "." and proves only that something listens; /rest/ping.view identifies the server but logs two warnings per call, ~576 a day; /app/ returns <title>Navidrome</title> and logs nothing. 402 asserts 200 on /app/ and not on "/", because "/" answers 302 - checked live rather than assumed. ── Also ─────────────────────────────────────────────────────────────────── The headscale ACL grants tag:prd-vipy exactly tag:music-box:4533. Without a rule the node is invisible rather than unreachable, which surfaces as a Caddy 502 "no such host". inventory lan_ip was read off nodito's ARP table for the VM's own MAC, not guessed - and .149 had belonged to another machine, whose stale host key made SSH refuse the connection. That is the designed behaviour, not a fault. 50 GB is the LIBRARY ceiling, not just the OS: /srv/music is on the root disk, so roughly 300-450 albums in FLAC. 1 GB is fine for serving and tight for the initial scan, which is the memory peak. No backups, deliberately. The music files would swamp the age-encrypted nightly path, and navidrome.db is a rebuildable index. What is NOT rebuildable is playlists, play counts, ratings and accounts - there are none today, which is what makes the trade fair, and the README names this as the decision to revisit if that changes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-27 11:09:40 +02:00
- import_playbook: services/navidrome/deploy_navidrome_playbook.yml
ansible: add site.yml, and rename the monitoring group off the host's name site.yml is a TABLE OF CONTENTS, not a second source of truth. It is 25 import_playbook: lines and comments - no `hosts:`, no `roles:`. Which hosts get what stays on the `hosts:` line inside each playbook, exactly where it already was; nothing moved. Every role is already wrapped in a thin playbook carrying its own `hosts:` line, so there is no roles-vs-playbooks split to reconcile: from here everything is a playbook. What it buys: What runs on a host? ansible-playbook site.yml --limit <host> --list-hosts Who gets thing Y? the `hosts:` line in Y's own playbook What is a host? ansible-inventory --graph Note --list-hosts, not --list-tasks: the latter prints every play regardless of --limit, so it will happily show you the bitcoin play under memos-box. Nine playbooks are deliberately excluded and the file names every one with a reason, so it accounts for all of them: the three infra/4xx monitoring plays (still assert on the removed Uptime Kuma credentials and fail immediately), 910_docker (says `hosts: managed`, but Docker is on 5 of 11 managed hosts and those 5 are exactly the ones that need it - running it installs Docker on the Bitcoin node and the hypervisor), two nodito one-shots, the Kuma notification setup, and two deliberate manual actions. Writing it surfaced an inventory collision. There is a HOST named `monitoring` in [vps] AND a group [monitoring], so Ansible warned and resolved `hosts: monitoring` to the host: [WARNING]: Found both group and host with same name: monitoring The group is renamed to [observability]; the host keeps its name. [caddy:children] and the two ntfy playbooks follow. Behaviour is unchanged - `hosts: monitoring` already resolved to the host - but the ambiguity is gone and the warning with it. Verified: inventory graph is warning-free, site.yml passes --syntax-check, and per-host play counts are identical before and after the rename. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-13 21:24:09 +02:00
- import_playbook: services/forgejo-runner/deploy_forgejo_runner_playbook.yml
- import_playbook: services/phoenixd/deploy_phoenixd_playbook.yml
- import_playbook: services/headscale/deploy_headscale_playbook.yml
- import_playbook: services/vaultwarden/deploy_vaultwarden_playbook.yml
- import_playbook: services/forgejo/deploy_forgejo_playbook.yml
- import_playbook: services/lnbits/deploy_lnbits_playbook.yml
- import_playbook: services/ntfy-emergency-app/deploy_ntfy_emergency_app_playbook.yml
- import_playbook: services/personal-blog/deploy_personal_blog_playbook.yml
# ── Backups: each source dumps itself, the box pulls ────────────────────────
- import_playbook: services/headscale/setup_backup_headscale.yml
- import_playbook: services/vaultwarden/setup_backup_vaultwarden.yml
- import_playbook: services/forgejo/setup_backup_forgejo.yml
- import_playbook: services/lnbits/setup_backup_lnbits.yml
- import_playbook: services/memos/setup_backup_memos.yml
- import_playbook: playbooks/backups.yml
# Deliberately not here. Every playbook in the repo is either imported above or
# listed below, so this file accounts for all of them:
#
# infra/910_docker_playbook.yml says `hosts: managed`, but Docker is on 5
# of 11 managed hosts and those 5 are exactly
# the ones that need it. Running it would
# install Docker on the Bitcoin node and the
# hypervisor. Needs a [docker] group first.
#
# infra/nodito/30_proxmox_bootstrap one-shot: bare-metal bootstrap, run once
# infra/nodito/33_..._cloud_template one-shot: builds the VM template
#
#
# services/vaultwarden/disable_ deliberate manual actions, not convergence
# vaultwarden_sign_ups_playbook.yml
# services/personal-blog/setup_
# deploy_alias_lapy.yml
Reference in a new issue Copy permalink