🦏
ETH Home Staking Collection
DVT Home Staking Curriculum
DVT Home Staking Curriculum
  • The DVT Home Staking Curriculum
  • Curriculum breakdown & timeline
  • Understanding ETH validators
    • Introduction to ETH Validators
    • Roles & Responsibilities of a node operator
    • Rewards and penalties
    • Importance of client diversity
    • Distributed Validator Technologies (DVTs)
    • Economics of using DVTs (WIP)
      • Diva Staking (WIP)
      • Obol (WIP)
      • SSV (WIP)
    • Bonded Validators
    • Economics of bonded validators (WIP)
  • Hardware & systems setup
    • Setup Overview
    • Hardware & system requirements
    • Procuring your hardware
    • Assemble your hardware
    • Practicing for free on Cloud VMs
      • Google Cloud
      • Alibaba Cloud
  • Linux OS, Networking, & Security
    • Install and prepare the OS
    • Networking & network security
    • Device level security setup
    • Verifying checksums
  • Installing & configuring your EL+CL clients
    • Set up and configure execution layer client
      • Nethermind
      • Besu
      • Geth
      • Erigon
      • Reth
    • Set up and configure consensus layer client
      • Teku BN
      • Nimbus BN
      • Lodestar BN
      • Lighthouse BN
      • Prysm BN
  • Keystore generation & MEV-Boost
    • Validator key generation
    • Set up and configure MEV-boost
  • Native Solo Staking Setup
    • Validator client setup
      • Teku VC
      • Nimbus VC
      • Lodestar VC
      • Lighthouse VC
      • Prysm VC
    • Depositing 32 ETH into your validator
    • Exiting your validator
  • Monitoring, Maintenance, and Updates
    • Set up monitoring suite
      • Installing & configuring Prometheus
      • Installing & configuring Node Exporter
      • Installing & configuring Grafana
      • Beaconcha.in App API
      • Client Uptime Check
    • Maintenance & Updates
      • Nethermind
      • Besu
      • Teku
      • Nimbus
      • Lodestar
      • Updating the monitoring suite
      • Preparing for Pectra
  • DVT Setup
    • Diva Staking
      • Diva Staking client setup
        • Default - All-in-one setup
        • Advanced - with standalone Lodestar VC
      • Registering your Diva node
      • Updating your Diva client
      • Monitoring your Diva Node
    • Obol
      • Techne Bronze Speedrun (Launchpad)
      • Obol + Bonded Validators (Techne Silver)
        • Obol + Lido CSM
    • SSV
      • SSV + Lido CSM (WIP)
      • SSV Operator
      • SSV Staker
  • Bonded Validators Setup
    • Lido CSM
      • Generating CSM keystores
      • Set Fee Recipient Address
        • Method 1: Configure on validator keys
        • Method 2: Configure on separate validator client
        • Verifying Fee Recipient Registered on MEV Relays
      • Upload/Remove/View validator keys
      • Rewards & bonds
      • Exiting CSM validators
        • "Lazy" exits (TESTNET ONLY)
        • Proper Exits
      • Role/Address management
      • Monitoring
      • Automations
        • CSM with ETHPillar
        • CSM with ETH Docker
        • CSM with Dappnode
    • Puffer
      • Non-Enclave: 2 ETH
    • Ether.fi
      • Receive distributed validator keyshares
    • Stader (WIP)
    • Rocketpool (WIP)
  • Liquid Staking Vaults
    • Stakewise V3
  • Mainnet
    • Mainnet Deployment
    • Heroglpyhs (WIP)
  • Best practices
    • Slashing prevention
    • Maximising uptime and performance
    • Optimising security
    • Managing your withdrawal wallet
  • Tips
    • Advanced networking
    • Downloading files from your node
  • Useful resources
    • General resources
    • Holesky Faucets
  • Automation/tools
    • ETHPillar
    • ETH Docker
    • Automated power on/off
      • Wake-on-LAN (WoL)
      • Network UPS Tools (NUT)
    • Validator Healthcheck Alerts
  • Solo Stakers Guild
    • Lido CSM+SSV+Obol (Testnet)
Powered by GitBook
On this page
  • Credits
  • Some context...
  • My Constraints
  • The Setup
  • Disclaimer
  1. Automation/tools

Automated power on/off

PreviousETH DockerNextWake-on-LAN (WoL)

Last updated 4 months ago

Credits

This section was inspired by Trevorn.eth's work: and my adaptation attempts to generalise the automatic power down/up setup for a wide range of UPS models.

Some context...

We want our validator node to gracefully shut down when the Uninterruptible Power Supply (UPS) is cut off from it's power supply and turn itself back on when power is restored.

However, I have not tested my UPS setup with an actual power outage followed by a power restoration. I also encountered several restrictions with my particular Prolink UPS model which makes testing of actual scenarios extremely time consuming. Further, all of my simulated power outage and recovery scenarios so far have not been successful using the Network UPS Tools (NUT) default settings. Hence I will be using custom shell scripts to respond to power events retrieved from the UPS.

To do this, I use a separate Raspberry Pi device to serve as a NUT server for automated shutdowns and as a Wake-on-LAN (WoL) server for automated power-ons. Fortunately, we can get Raspberry Pis from $35 onward.

An added benefit of having a WoL server is having more control over unexpected scenarios where your devices simply do not automatically turn themselves back on after power has been restored.

In general, my goal for this guide is to be applicable to as many USB-enabled UPS models as possible. As a result, it may not be the most optimal method for the pros.

My Constraints

  • My UPS does not turn itself back on after main line power has been restored following an automatic shutdown

  • The "low battery" threshold of my UPS is fixed at 35% and cannot be changed for testing

  • My UPS does not turn my NUC back on when main line power is restored to it

I reckon there will be more people who may face the same constraints as me so this guide optimises for a wide coverage of scenarios.

The Setup

My UPS model (Prolink Pro1201sfcu) has 4 outgoing power sockets and 1 USB port.

  • 4 power sockets: Modem, Router, Validator Node, Raspberry Pi

  • USB Socket: Connected to my Raspberry Pi to continuously monitor for when power has been cut off or restored to the UPS

The Raspberry Pi serves as both the NUT and WoL server and "talks" to the validator node via the router.

  • NUT server: Automatically shuts down the validator node during a power outage

  • WoL server: Automatically powers on the validator node after power has been restored

The Raspberry Pi automatically turns on when connected to a power source by default. It also does not store any critical data so I do not configure automated shutdowns for it.

A Telegram chatbot is also configured to manually and remotely trigger the Wake-on-LAN signal to power on the validator node in case the automation fails.

Disclaimer

My method involves some custom shell scripts (with the help of AI) to work around the limitations of my UPS model and my current understanding of NUT.

Though I try my best to implement security best practices here, please use this with caution as you will need to run custom scripts to gracefully shutdown your validator node during a power outage.

Protecting your Rocketpool node from power outages on the cheap