# 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 disk added to this VM in Proxmox as scsi1. Named here rather than
# left to the role default so that "which disk holds the blockchain" is a
# property of the machine, recorded next to the machine. The role only ever
# uses it to create the filesystem; the mount itself goes by UUID.
monero_data_device: /dev/sdb

# 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"