Some background

I’ve setup a fairly reliable system at home for monitoring and maintaining my Chia farming setup, so I decided to write up what I have done for anyone who needs a little guidance on doing similar. This was inspired in no small part by still seeing after all this time, the occasional person seeking support who is running a dozen or more versions prior to the current. Folks seem shocked to hear that “set it and forget it” is a bad idea and that they have been missing out on potential blocks due to soft forks, etc.

This is not the be-all, end-all definitive guide for every use case, but it’s meant to be a starting point for folks who have yet to start anywhere. There might be other ways some folks would like to do some things, and that’s fine. You might have different preferred tools (mine’s Ansible) or esoteric environment setups that require extra steps that might make you think my advice is bad. It’s not, it’s just different… to each their own.

Base assumptions

For my setup, we’re going off a few basic assumptions here:

1. You have Ubuntu or a similar Linux environment for your setup running as a CLI (personally, I feel it’s not advisable that you are running Windows or Mac with the GUI for a high availability background server farming setup)
2. You have installed via the official release packages. (While it’s perfectly reasonable to install via source for specific needs from development branches, betas, or other troubleshooting/testing purposes, for a set-it-and-forget-it farmer setup, a release package install is the officially supported path.)
3. Things like setting up Ansible and manually adding the Chia release packages to your apt repository are out of scope for this.

My setup

In my case, I have my farm divided into my primary farmer with most of the harvesting on that same system, as well as a remote harvester on a Synology NAS (any space not currently allocated to my NAS for it’s primary use that is left over, is allocated to as many plot files as I can fit with 1TB of empty space overhead. Anytime I use up more of that space, I delete a few plot files to keep my overhead), and my Node running on a dedicated VM.

I have this setup because I have a few various test and development things running, and being able to have them all talk to the same node is convenient (and bandwidth friendly) as well as putting me in an easy-recovery state for my node if it has issues, without impacting my farm.

For the Farmer/Harvester and the Node, I have installed Chia via the Ubuntu package, and I use the official docker container on the Synology in Harvester-only mode.

Farmer

For my farmer, it’s an Ubuntu system simply running the farmer, harvester, and wallet services.

The default settings for a wallet service when it is not running on the same device as a full Node, is to talk to a random Node on the internet. In order to avoid duplicated bandwidth usages from the Farmer’s wallet service due to this, if you have a node that is on a remote instance like I have, then you need to do the following:

Step 1: Change the wallet config on the farmer server to:

wallet:
    connect_to_unknown_peers: False
    trusted_peers:
        0ThisisanexampleNodeID7ff9d60f1c3fa270c213c0ad0cb89c01274634a7c3cb9: anything_can_go_here

For the NodeID for trusted peer, get this by doing chia show -s and copying the node ID on the node instance)

Step 2: Change your Node instance’s config to:

full_node:
   exempt_peer_networks: ["192.168.1.0/24"]

This will make sure your Node ALWAYS accepts connections from your farmer, even if it’s peer count is full. (Obviously use the right CIDR notation for your own IP range.)

I also have custom defined services setup for the farmer and node, to make management and restarts much easier, as well as making Ansible runbooks far simpler.

Farmer chia.service

[Unit]
Description=Chia Farmer Service
[Service]
Type=forking
User=my_user
WorkingDirectory=/home/my_user/
ExecStart=chia start farmer-only harvester wallet
ExecStop=chia stop -d all
Restart=no
[Install]
WantedBy=multi-user.target

Node chia.service

[Unit]
Description=Chia Node Service
[Service]
Type=forking
User=my_user
WorkingDirectory=/home/my_user
ExecStart=/usr/bin/bash -c "chia start node"
ExecStop=/usr/bin/bash -c "chia stop -d all"
Restart=always
[Install]
WantedBy=multi-user.target

Monitor

For monitoring, I am using chia-monitor. It’s not the single best solution, but it works for my needs and while seemingly no longer updated much, I’ve had zero issues and if it ain’t broke don’t fix it! (Though I do plan to replace it down the road with the CNI-developed chia-exporter sooner or later, probably when 2.0 comes out in a few weeks after this writing.) It creates a simple status output text page, that Prometheus can scrape for me and feed into Grafana. For simplicity, I have setup a service to manage it.

The monitor application, and the service config, are setup on both the farmer and the node.

[Unit]
Description=chia-monitor prometheus exporter
Wants=network-online.target chia-farmer.service
After=network.target network-online.target chia-farmer.service
Requires=chia-farmer.service
BindsTo=chia-farmer.service
StartLimitIntervalSec=0

[Service]
Restart=always
User=my_user
ExecStartPre=/bin/sleep 60
ExecStart=/usr/bin/env bash -c 'cd ~/monitoring_chia/chia-monitor; pipenv run python -m monitor'

[Install]
WantedBy=multi-user.target

Making life easier for updating

Now for the the point of all the above work. Once you have set things up, updating Chia becomes trivial, which is the important part of all of this!

This simple runbook will:

1. connect to all my chia_prod hosts (which are defined elsewhere within Ansible as the farmer and node)
2. update their package repo
3. update the code
4. restart the services
5. restart the monitors for good measure. (They can get cranky if you restart Chia but not them after).

(There is a secondary runbook triggered by this one not covered here that will also rebuild the Docker container on the Synology NAS to the latest version as well, by making a quick call to my Portainer agent on that device.)

The Ansible playbook

---
- hosts: chia_prod
  become: yes
  tasks:
  - name: Stop Chia service
    ansible.builtin.service:
      name: chia
      state: stopped

  - name: Update the repository cache and update Chia to latest version
    ansible.builtin.apt:
      name: chia-blockchain-cli
      state: latest
      update_cache: yes

  - name: Start chia service
    ansible.builtin.service:
      name: chia
      state: started

  - name: Restart monitroing service
    ansible.builtin.service:
      name: chia-monitor
      state: restarted

That’s it! If you take a little time to the above leg work, one simple command of

ansible-playbook chia-update.yml

Will do everything you need to update Chia across you device, each time a new release comes out, across however many systems you have!