personal_infra/ansible/roles/monero

monero

A Monero full node (monerod) on Debian 13, bare metal, systemd, no Docker. Runs on monerod-box (Proxmox VMID 2400), reachable from Feather over the WAN.

Why the published binary and not a build from source

The intent was to build from source and check the result against the published binary checksums. That is not achievable for the current release, and it is worth writing down why so nobody re-litigates it:

• contrib/guix, the reproducible-build system that produces a byte-identical tarball, exists only on monero master. At tag v0.18.5.1 contrib/ contains gitian, not guix.
• Reproducing v0.18.5.1 therefore means Gitian, whose README requires an Ubuntu 18.04 host (EOL 2023), LXC or Docker, and python-cheetah (Python 2).
• A plain make release-static is not reproducible. It would give us a self-built binary whose hash matches nothing - not upstream's, not anyone else's - so it satisfies neither half of "build it ourselves AND check the checksum".

So the role installs the published binary and proves its provenance instead. That chain is real, and it is the strongest claim available for this release:

1. binaryFate's public 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 anyway (81AC591FE9C4B65C5806AFC3F0AF4D462A0BDF92), so a swapped file is caught.
2. hashes.txt is downloaded and its clearsigned signature verified. The assertion is on gpg's VALIDSIG <fingerprint> status line, not on the string "Good signature" - bitcoin_knots greps for the latter, which passes for any key in the keyring.
3. The verified plaintext is written out by gpg --decrypt, and the tarball's SHA256 is looked up in that, not in the raw clearsigned file.
4. The lookup requires the hash and the filename on one line, so a hash belonging to a different artefact cannot satisfy it.

monero_sha256 in defaults/ is a second, in-git assertion passed to get_url. It is not the security control - step 4 is - but it means a version bump cannot happen without the checksum moving in the same diff.

Bumping the version: change monero_version and monero_sha256 together.

The forward path

The published monero-linux-x64-v0.18.5.1.tar.bz2 unpacks to monero-x86_64-linux-gnu-v0.18.5.1/ - that is the Guix DISTNAME, renamed at publish time. So once v0.19 ships with Guix on the release branch, sha256(guix output) == hashes.txt entry holds exactly, and a guix install method can be added here without changing anything else.

The data disk

The blockchain is on a dedicated 500 GB disk (scsi1), not on the 10 GB root filesystem. tasks/storage.yml creates the filesystem and the fstab entry.

This is done in code on purpose. knots-box mounts /mnt/knots_data (~875 GB of chain) entirely by hand, and that mount appears nowhere in Ansible - a rebuild of that host would come up with the chain silently missing.

Three things there are load-bearing:

• The whole device, no partition table. One disk, one job; a partition table is just another layer that can disagree with itself.
• The device name is read once, ever. Each run first looks for a filesystem labelled monero-data; if it exists, monero_data_device is not consulted and the mount goes by that filesystem's UUID. Only a blank disk is found by name, and that name is the Proxmox slot as published under /dev/disk/by-id (...drive-scsi1), fixed before the VM boots and kept across qm disk move. Never /dev/sdX: the kernel assigns those in probe order, and on 2026-10-04 a reboot swapped sda and sdb, leaving the old /dev/sdb value naming the root disk. The root-disk guard caught it - but a routine run should never have been reading the name in the first place.
• RequiresMountsFor= in the unit. nofail in fstab means a missing disk does not drop a headless VM into an emergency shell - but without RequiresMountsFor monerod would then start, find an empty directory, and begin writing a ~300 GB chain onto a 10 GB root disk. With it, the unit refuses to start and infra/401 reports it within five minutes.

The mount-point task and the post-mount ownership task deliberately use the same owner and mode. Writing the obvious root:root 0755 on the first made the two disagree, and every run flipped the directory back and forth.

Exposure: one HTTPS vhost, no new open ports

• P2P is outbound only. Nothing forwards 18080 to this box. The node dials out, syncs fully and serves us; it just does not relay for strangers. no-igd=1 follows - with nothing forwarded there is nothing for UPnP to do except announce us to the router.

• Two RPC servers, not one.

  • unrestricted on 127.0.0.1:18081 - administration and the health check.
  • restricted on :18089 - the only surface anything off-box touches.

  This is rpc-restricted-bind-port, deliberately not restricted-rpc=1. That flag restricts the loopback server too, and then we could not ask our own node anything useful. 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. Both ports answer an unauthenticated request with 401.

• Caddy on the edge host terminates TLS and nothing else. No caddy_site_basic_auth: Caddy's Basic challenge would collide with the Digest challenge Feather expects. monerod's own auth is the authentication.

No UFW rule, and that is correct

Traffic arriving over the tailnet bypasses UFW entirely. Verified on mempool-box: UFW is active with default-deny-incoming and 22/tcp as its only allow rule, yet the edge host reaches its frontend port - because iptables -S INPUT puts -A INPUT -j ts-input ahead of every ufw-* chain. Adding a UFW allow here would be cargo cult.

Monitoring

Four Gatus endpoints, all verified passing:

Endpoint	Source	Answers
liveness/monerod_box_local	infra/400	is the host up
disk/monerod_box_local	infra/400	is it running out of space
services/monerod-box-local/monerod	infra/401 via monitored_services	is the unit active
probe/monerod	this role + infra/403	does monerod actually answer RPC

The probe deliberately does not check synchronized. A full initial sync takes days. A check requiring synchronized: true would report DOWN for every one of those days, which is not a monitor - it is an alarm with the batteries taken out. Answering RPC is the health question; height and sync state go in the message so they are visible without being alertable.

The timer carries no Requires=monerod.service. Requires on a timer stops the timer when the watched unit stops - "if the thing I am watching goes down, stop watching it" - and leaves nothing to re-arm it. Fulcrum's timer carried it and sat active/enabled for seven months without firing once. bitcoin_knots still carries it; do not copy that.

Enable and restart the monerod health check timer reports changed on every run. That is intentional and matches datum_gateway: state: restarted is how a timer gets re-armed, and started is a no-op on an already-active timer.

Backups: none, deliberately

The blockchain is re-syncable public data and there is no wallet on this node, so a backup job would move hundreds of GB around to protect nothing. This follows the phoenixd precedent (Plan 5, Model C) of recording an exclusion as a decision rather than leaving it to look like an oversight.

Known constraint: RAM

The VM has 2 GB and no swap. Mid-sync, monerod's RSS was already 1,333 MiB of 1,973 MiB with ~100 MiB free. No OOM kill has happened yet, but the working set grows with the database and there is no swap to absorb a spike. out-peers and in-peers are held down (16/8) partly for this reason.

8 GB is the recommendation. Bumping it means editing memory_mb in tofu/nodito/vms.auto.tfvars and resizing the VM in the Proxmox UI - the vm resource sets ignore_changes = all, so tofu will not do it for you.