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>
52 lines
2.4 KiB
YAML
52 lines
2.4 KiB
YAML
# monerod-box: the Monero node.
|
|
#
|
|
# These ports are read twice: by the role that deploys the service here, and by
|
|
# the Caddy play that runs on the EDGE host and publishes the restricted RPC.
|
|
# A role default is invisible to that second play, which is why they live in
|
|
# host_vars - the edge play reads them as
|
|
# hostvars['monerod_box_local'].<name>, and the role picks them up
|
|
# automatically because host_vars outranks role defaults.
|
|
monero_p2p_port: 18080
|
|
monero_restricted_rpc_port: 18089
|
|
|
|
# The explorer's HTTP port, read by the Caddy play on the edge host.
|
|
xmrblocks_port: 8081
|
|
|
|
# The 500 GB chain disk, attached in Proxmox as scsi1. Named by that slot, which
|
|
# is fixed when the disk is attached and survives reboots and storage moves -
|
|
# not /dev/sdb, which it stopped being on 2026-10-04. Only read when the disk has
|
|
# no monero-data filesystem yet; see roles/monero/defaults/main.yml.
|
|
monero_data_device: /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1
|
|
|
|
# Systemd services deployed on this host, monitored every 5 minutes.
|
|
#
|
|
# The fact lives with the machine rather than in a central map, for the same
|
|
# reason the cross-host ports do: "what runs here" is a property of the host,
|
|
# and a central list is one more thing to forget to update when a service moves.
|
|
#
|
|
# Only units WE deploy belong here. Distro units (ssh, cron) have their own
|
|
# supervision and would be noise.
|
|
monitored_services:
|
|
- monerod
|
|
- xmrblocks
|
|
|
|
# ...but on THIS host, once a day rather than every five minutes.
|
|
#
|
|
# Both units are a Monero node in the middle of a multi-week initial sync on a
|
|
# rotating disk. There is nothing a 5-minute poll reports that a daily one does
|
|
# not, and every failing poll was another Signal message - 83 of them in six
|
|
# hours while the explorer was wedged.
|
|
#
|
|
# This is safe to scope to the host because monerod-box runs ONLY Monero units.
|
|
# Do not copy it to a box with a mixed workload: the timer is one per host and
|
|
# iterates every unit in monitored_services, so slowing it slows all of them.
|
|
#
|
|
# 26h, not 24h: the window must EXCEED the push interval, or a check reporting
|
|
# exactly on schedule races its own deadline and alerts on jitter alone. The
|
|
# 900s randomized delay puts the real worst case at ~24h15m.
|
|
#
|
|
# Host liveness and disk are deliberately NOT slowed - they answer "is the box
|
|
# alive", which is still wanted within minutes. See infra/400.
|
|
service_health_on_calendar: "*-*-* 05:15:00"
|
|
service_health_randomized_delay: "900"
|
|
service_health_heartbeat: "26h"
|