counterweight
71dbfbe5ff
After the chain disk moved to the SSD, a reboot on 2026-10-04 swapped sda and sdb, and monero_data_device: /dev/sdb then named the ROOT disk. The root-disk guard caught it, but a routine run should never have been reading a device name at all. Every run now looks for the filesystem labelled monero-data first. If it is there, monero_data_device is never consulted and the mount goes by that filesystem's UUID. Only a blank disk is found by name, and the name is now /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1: Proxmox passes the slot in as the serial, so it is fixed before boot and survives `qm disk move`. The by-id path is resolved with readlink before the root-disk guard compares it, since a symlink path is never a prefix of /dev/sdb1 and the guard would otherwise always pass. The UUID assert now also fails on two disks carrying the same label. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
118 lines
5.7 KiB
YAML
118 lines
5.7 KiB
YAML
# Monero node (monerod) configuration variables.
|
|
# https://docs.getmonero.org/interacting/monerod-reference/
|
|
|
|
# --- Version and artefact ---------------------------------------------------
|
|
# Bump monero_version and monero_sha256 TOGETHER. The sha256 here is a second,
|
|
# in-git assertion; the one that actually matters is the grep against the
|
|
# GPG-signed hashes.txt in install.yml. Having both means a version bump cannot
|
|
# be done silently - the checksum has to move in the same diff.
|
|
monero_version: "0.18.5.1"
|
|
monero_platform: "linux-x64"
|
|
monero_tarball: "monero-{{ monero_platform }}-v{{ monero_version }}.tar.bz2"
|
|
monero_url: "https://downloads.getmonero.org/cli/{{ monero_tarball }}"
|
|
monero_sha256: "22a7dda7b0cb699fdd6b7674c3b4a4465b337cc98a54983523b759e1e7cc9958"
|
|
|
|
# The signed list of checksums for every published Monero artefact.
|
|
monero_hashes_url: "https://www.getmonero.org/downloads/hashes.txt"
|
|
|
|
# binaryFate, the release signing key. The .asc is vendored in files/ rather
|
|
# than fetched at deploy time: a trust root downloaded over the network at the
|
|
# moment you need it is not a trust root. The fingerprint is asserted after
|
|
# import anyway, so a swapped file cannot go unnoticed.
|
|
monero_signing_fingerprint: "81AC591FE9C4B65C5806AFC3F0AF4D462A0BDF92"
|
|
|
|
# --- Service user -----------------------------------------------------------
|
|
monero_user: monero
|
|
monero_group: monero
|
|
|
|
# --- Directories ------------------------------------------------------------
|
|
monero_conf_dir: /etc/monero
|
|
monero_log_dir: /var/log/monero
|
|
monero_bin_dir: /usr/local/bin
|
|
|
|
# The blockchain. This is the mount point of the dedicated 500 GB disk, NOT a
|
|
# directory on the 10 GB root filesystem - see storage.yml.
|
|
monero_data_dir: /var/lib/monero
|
|
|
|
# --- The data disk ----------------------------------------------------------
|
|
# The whole device, no partition table: this disk has one job and a partition
|
|
# table would only add a layer that can disagree with itself.
|
|
#
|
|
# The disk is known by two names, for two different moments:
|
|
#
|
|
# monero_data_label is its identity once it holds a filesystem. Every run looks
|
|
# for it first, and if it is there the device name is never consulted at all -
|
|
# a routine run cannot be broken by a device name, because it does not read one.
|
|
#
|
|
# monero_data_device is used ONLY on the first run, to find the blank disk and
|
|
# create that filesystem. It must be a name fixed before the VM boots: Proxmox
|
|
# passes the slot ("scsi1") in as the disk's serial, and udev publishes it under
|
|
# /dev/disk/by-id. That survives reboots and `qm disk move` alike. NEVER
|
|
# /dev/sdX: the kernel hands those out in probe order, and on 2026-10-04 a reboot
|
|
# after moving this disk to the SSD swapped sda and sdb - the value written here
|
|
# then named the ROOT disk.
|
|
monero_data_label: monero-data
|
|
monero_data_device: /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1
|
|
monero_data_fstype: ext4
|
|
# -m 0: the 5% ext4 reserve exists to stop root-owned daemons deadlocking a full
|
|
# root filesystem. On a dedicated data disk it is 25 GB thrown away.
|
|
monero_data_mkfs_opts: "-m 0 -L {{ monero_data_label }}"
|
|
|
|
# --- Network ----------------------------------------------------------------
|
|
# P2P is OUTBOUND ONLY. No inbound port is published from the edge host, so the
|
|
# node dials out to peers and never receives. It syncs and serves us completely;
|
|
# it just does not relay for strangers. no-igd follows from that: with nothing
|
|
# forwarded there is nothing for UPnP to do but tell the router about us.
|
|
monero_p2p_port: 18080
|
|
|
|
# Unrestricted RPC, loopback only: administration and the health check.
|
|
monero_rpc_bind_ip: "127.0.0.1"
|
|
monero_rpc_port: 18081
|
|
|
|
# The RESTRICTED RPC is a second server on its own port, reachable over the
|
|
# tailnet and published by Caddy on the edge host. This is deliberately
|
|
# rpc-restricted-bind-port and NOT `restricted-rpc=1` - the latter would
|
|
# restrict the loopback server too, and then we could not ask our own node
|
|
# anything useful.
|
|
#
|
|
# The authoritative value for the live deployment is in
|
|
# host_vars/monerod_box_local/main.yml, which the edge play also reads; the
|
|
# value here is the upstream default so the role still works standalone.
|
|
monero_restricted_rpc_port: 18089
|
|
|
|
# Peer counts kept modest on purpose: this VM has 2 GB of RAM. See README.
|
|
monero_out_peers: 16
|
|
monero_in_peers: 8
|
|
|
|
# --- RPC credentials --------------------------------------------------------
|
|
# monerod's --rpc-login is HTTP Digest (contrib/epee/src/http_auth.cpp) and the
|
|
# same login guards BOTH the loopback and the restricted server. Feather sends
|
|
# these as the node username/password.
|
|
monero_rpc_user: ""
|
|
monero_rpc_password: ""
|
|
|
|
# monerod.conf holds the RPC login, so --diff is suppressed by default.
|
|
# Pass -e monero_reveal_config=true to see what moved.
|
|
monero_reveal_config: false
|
|
|
|
# --- Health check -----------------------------------------------------------
|
|
# WHERE TO REPORT HEALTH — the one place to plug in monitoring. Empty means
|
|
# check, exit honestly, report nowhere. Any endpoint accepting an HTTP ping
|
|
# works; nothing here is specific to a monitoring product.
|
|
healthcheck_push_url: ""
|
|
# Bearer token for the Gatus external endpoint. Required whenever a push URL
|
|
# is set: Gatus rejects an unauthenticated push with 401.
|
|
healthcheck_push_token: ""
|
|
|
|
# WHEN TO CHECK. Daily, at a fixed hour, rather than an OnUnitActiveSec
|
|
# interval that drifts with every restart.
|
|
#
|
|
# Prefixed because the generic `healthcheck` role owns the unprefixed
|
|
# healthcheck_on_calendar; an unprefixed default here would shadow it for any
|
|
# play that includes both.
|
|
#
|
|
# Paired with the 26h Gatus heartbeat in
|
|
# infra/403_service_probe_registration.yml. Change one and you must change the
|
|
# other: the window has to stay above the interval or the check alerts on its
|
|
# own jitter.
|
|
monero_healthcheck_on_calendar: "*-*-* 05:00:00"
|