I have been planning to migrate my monitoring to my Raspberry PI 4, from its current location on a VM which is fine unless there is a fault with the VM or the host but this has happened (today in fact). It monitors these hosts and it is helpful to know what is going on if there is a problem. My intention is to also shutdown the VM host in the event of a power outage (to extend UPS battery runtime) and it would be nice for monitoring to continue during the outage.

I did have a bit of an internal debate about whether to use Raspberry Pi OS (formerly Raspbian) or Debian’s official images. On the Raspbetty PI 4, there is no requirement for the binary blob needed to boot on the older hardware and my other systems all use vanilla Debian Stable. I decided to try the Debian images instead.

I downloaded the latest Buster image and used Fedora Media Writer to write it to a 64GB MicroSD card using my laptop’s built in MicroSD slot. Then I just popped the card into my Raspberry PI and it booted without any problem.

Configuration

I currently use SaltStack for configuration management accross all of my systems, although I am considering switching to Ansible. This required configuring the network, then installing salt-minion and link to my salt master.

I reconfigured the DHCP and DNS servers to give the PI the hostname ‘starfleet-intelligence’, previously belonging to the VM. I also modified /etc/hostname (echo "starfleet-intelligence" > /etc/hostname) before using hostname -F /etc/hostname to update the hostname on the PI (so the salt-minion will present the correct name to the master). Finally I used ifdown eth0; ifup eth0 to force the network interface to reconfigure and get the correct IP address etc.

Next, I updated the base image using the usual apt-get update, apt-get upgrade, apt-get dist-upgrade recipe and rebooted (new kernel).

Before installing the salt-minion, I deleted the old key using salt-key -d starfleet-intelligence.* from the salt master. Although fixable, it seemed easier to avoid the key conflict that will arise from having a new install with the same name (in theory I could also have copied the existing key from one client to the other but it seems sensible to generate a new key for a new install).

On the PI, I then installed the salt-minion with apt-get install salt-minion.

I ended up generating a dh4096.pem file on my laptop and copying it over to /etc/ssl/dh4096.pem- it took a couple of minutes on my 8th-generation i7 processor but I cancelled the intiial attempt of the Raspberry PI after it had been runing (without completing) for over 10 hours.

Returning to the salt master, I accepted the new minion’s key with salt-key -a before running a test of the highstate to see what would be applied; salt starfleet-intelligence.* state.highstate test=True

After this, running the state.highstate a couple of times (until there were no more changes) and everything was setup.

Originally I was thinking about copying the historic monitoring data over from the old system, but I decided that it would be neater to have a clean break between the old system and the new.