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>

ansible/roles/monero/tasks/storage.yml

@@ -0,0 +1,133 @@
+---
+# The 500 GB data disk.
+#
+# knots-box does this by hand: /mnt/knots_data holds ~875 GB of blockchain and
+# appears nowhere in Ansible, so a rebuild of that host would come up with the
+# chain silently missing. This role does it in code instead.
+
+- name: Check the Monero data device
+  ansible.builtin.stat:
+    path: "{{ monero_data_device }}"
+  register: monero_device
+
+- name: Find the device backing the root filesystem
+  ansible.builtin.command: findmnt -no SOURCE /
+  register: monero_root_source
+  changed_when: false
+  check_mode: false
+
+# A guard, not ceremony. mkfs on the wrong device is unrecoverable, and
+# /dev/sdX names are assigned by the kernel at boot - the whole reason
+# everything below this point works by UUID.
+- name: Assert the data device is a real block device and is not the root disk
+  ansible.builtin.assert:
+    that:
+      - monero_device.stat.exists
+      - monero_device.stat.isblk | default(false)
+      - not monero_root_source.stdout.startswith(monero_data_device)
+    quiet: true
+    fail_msg: >-
+      {{ monero_data_device }} is not a usable data device, or it is the disk
+      the root filesystem lives on ({{ monero_root_source.stdout }}).
+      Refusing to touch it. Check `lsblk` on the host.
+
+- name: Read any existing filesystem on the data device
+  ansible.builtin.command: "blkid -o value -s TYPE {{ monero_data_device }}"
+  register: monero_existing_fs
+  changed_when: false
+  failed_when: false
+  check_mode: false
+
+# community.general.filesystem is idempotent and will not rebuild a filesystem
+# that is already the requested type, but it would happily create one on a disk
+# holding something it does not recognise. Say so out loud instead.
+- name: Refuse to reformat a disk that already carries a different filesystem
+  ansible.builtin.assert:
+    that:
+      - monero_existing_fs.stdout | trim in ['', monero_data_fstype]
+    quiet: true
+    fail_msg: >-
+      {{ monero_data_device }} already holds a '{{ monero_existing_fs.stdout | trim }}'
+      filesystem, not '{{ monero_data_fstype }}'. Refusing to overwrite it.
+
+- name: Create the filesystem on the data device
+  community.general.filesystem:
+    fstype: "{{ monero_data_fstype }}"
+    dev: "{{ monero_data_device }}"
+    opts: "{{ monero_data_mkfs_opts }}"
+
+- name: Read the filesystem UUID
+  ansible.builtin.command: "blkid -o value -s UUID {{ monero_data_device }}"
+  register: monero_fs_uuid
+  changed_when: false
+  failed_when: false
+  check_mode: false
+
+# Everything past this point mounts by UUID, so there is nothing sensible to do
+# without one. On a --check run against a disk that has no filesystem yet this
+# is expected and unavoidable: check mode did not create the filesystem, so
+# there is no UUID to read. Say that, rather than leaving a bare blkid rc=2.
+- name: Assert the UUID looks like a UUID
+  ansible.builtin.assert:
+    that:
+      - monero_fs_uuid.stdout | trim | length == 36
+    quiet: true
+    fail_msg: >-
+      No filesystem UUID on {{ monero_data_device }}.
+      {% if ansible_check_mode %}This is expected under --check when the disk
+      has not been formatted yet - check mode cannot create the filesystem, so
+      it cannot dry-run the mount either. Run without --check once, then
+      --check is meaningful from then on.{% else %}mkfs appears to have failed;
+      check `lsblk` and `blkid` on the host.{% endif %}
+
+# Same owner and mode as the "Own the mounted data directory" task below, and
+# that is deliberate rather than duplication. Before the disk is mounted this
+# creates the mount point; afterwards it targets the mounted filesystem and is a
+# no-op. Giving it root:root 0755 here - the obvious thing to write - made the
+# two tasks disagree, and each run flipped the directory back and forth.
+- name: Create the Monero data directory as a mount point
+  ansible.builtin.file:
+    path: "{{ monero_data_dir }}"
+    state: directory
+    owner: "{{ monero_user }}"
+    group: "{{ monero_group }}"
+    mode: '0750'
+
+# By UUID, never by /dev/sdb. nofail so a missing disk does not drop a headless
+# VM into an emergency shell - monerod is stopped from starting by
+# RequiresMountsFor= in its unit instead, which the systemd monitor then reports.
+# noatime because LMDB touches a lot of pages and none of it wants an atime write.
+- name: Mount the data disk by UUID
+  ansible.posix.mount:
+    path: "{{ monero_data_dir }}"
+    src: "UUID={{ monero_fs_uuid.stdout | trim }}"
+    fstype: "{{ monero_data_fstype }}"
+    opts: defaults,noatime,nofail
+    state: mounted
+
+# AFTER the mount, never before: chowning the mount point first sets permissions
+# on the directory the mount then hides, and the blockchain lands on a root-owned
+# filesystem that monerod cannot write to.
+- name: Own the mounted data directory
+  ansible.builtin.file:
+    path: "{{ monero_data_dir }}"
+    state: directory
+    owner: "{{ monero_user }}"
+    group: "{{ monero_group }}"
+    mode: '0750'
+
+- name: Confirm the data directory is a mount point and not the root filesystem
+  ansible.builtin.command: "findmnt -no SOURCE --target {{ monero_data_dir }}"
+  register: monero_mounted_source
+  changed_when: false
+  check_mode: false
+
+- name: Assert the blockchain will land on the data disk
+  ansible.builtin.assert:
+    that:
+      - monero_mounted_source.stdout | trim != monero_root_source.stdout | trim
+    quiet: true
+    fail_msg: >-
+      {{ monero_data_dir }} resolves to {{ monero_mounted_source.stdout | trim }},
+      which is the root filesystem. The 500 GB disk is not mounted and a full
+      sync would fill the 10 GB root disk.