Skip to main content

Stand-up Vanilla Hosts

We will now be standing up Vanilla Hosts.

For each host type below, you will have to do a handful of particulars before standing up the vanilla host. However, once those are complete, you will be running the same command on your control computer with different arguments. Something like:

apb Hosts/standup-vanilla.yml -e "rawhosts=hostName"

Before you set up your hosts as per their type, and before you run any commands, let's review the final code block we will be running. Open up Hosts/standup-vanilla.yml in an editor. This time, see if you can figure out what it's doing without heavily commented code. We suggest DuckDuckGoing anything you do not understand with a simple copy/past. However, if that is too in the weeds, we have heavily commented the Ansible plays for Hosts/prep-raw-pis-for-boot-from-usb.yml open that file to get a better rundown of Ansible files.

But, to broadly explain the Hosts/standup-vanilla.yml code that we will run for all hosts, the commands will do this:

  1. Add a handful of files to the ~/.HAB/inventory directory that will assist in planing and managing the cluster for later steps.
  2. Fact gather about the new hosts added in the command line, and add then to any previously added hosts.
  3. Check for host name validity and uniqueness.
  4. Make sure, according to OS, that the host is up-to-date, and the appropriate settings are set for being able to receive k3s.
  5. Also add some important quality of life improvements, like message-of-the-day when you ssh into a host.
  6. Assert and double check everything looks good to go.

With this in mind, let's now prep your hosts according to the type of host they are.

Stand-up Vanilla RPi​

Raspberry Pi's need no introduction. At this point in time, we should probably assume a great deal of pleb-nodes run on Raspberry Pis and much of the following should be familiar to all who run them.

Boot From SSD​

Running k3s in high availability mode—where there are three or more controlling nodes that can individually be killed without the cluster going down—may kill your SD card from too many etcd writes, and besides, your SD card read/write times are very slow in comparison to what is available. The docs suggest that running k3s in HA on a SD card is not a good idea. We could run the DB externally, and have 2 master nodes, but that feels antithetical—we'd rather have a third node to run in HA mode than a NFS external database managing node state—as said NFS may not be able to function as a full node itself.

In light of this, we will provision our pi's to boot from a SSD card connected to USB.

Prep Raw Raspberry Pi's​

danger

Be sure all hosts and all SD/SSD media do not have any information on them that is not backed up or can not be lost. Imaging will erase this information.

The purpose of this first official imaging is to gather data about our pis, to ssh in for the first time, and to make sure they are ready to boot from an external SSD. Only once they are ready to boot from an external drive, will we be able to stand up vanilla pis.

A few notes to keep in mind before embarking:

  • Host Count: If you only have one pi, that's fine.

  • SD Count: If you only have 1 SD card but multiple pis, you will have to run through this entire thing for each pi, individually, but it'll work.

  • Add a Pi Later: You must also go through these steps to add a new pi, regardless of the state of other pis (when adding a new pi, you only have to execute all actions against the one new pi, the other pis are golden)

  • User/Password: This guide and the Ansible scripts herein rely on a uniform user/password schema when in the raw and vanilla state. Though you can deviate from them, it will make your life just a little easier to stick with the same user and password for ALL hosts in the vanilla state. We will secure the host with far superior methods later on.

    danger

    With the first Pi imaging, it is important to stick with the given name and password. These are explicitly tied to a script and only used one time as such for the first imaging. Then you can change them.

  • Booting From USB: The recommended way of ensuring that booting from USB is enabled is simpler. However, this way will provide some more logging if things go south and will update firmware if needed.

First Imaging​

  1. If you are setting up multiple pis, none of the params in the below list will change pi to pi, thus, setting to always use means you do not have to do this for each image write when completed in parallel. Or if you only have 1 SD card, you can write one image and start at Step vii for each additional pi in This Step. In such a case, be sure to continue to Step 2 and 3, before moving on to the next pi. Repeat for each Raspberry Pi:

    1. Insert SD card into control computer
    2. In Raspberry Pi Imager, choose image: Raspberry Pi OS Lite (64-bit)
    3. Select appropriate SD card
    4. Click the ⚙️ Advanced Options:
      • Image customization options: to alwasy use
      • ✅ Enable SSH
        • ✅ User password authentication
      • ✅ Set username and password
      • Username: pi
      • Password: raspberryRaw
      • ✅ Set locale setting
        • Time zone: [your timezone]
        • Keyboard layout: [your keyboard layout]
        • ✅ Skip first-run wizard
        • If you are using wifi for this (not officially recommended, but doable), you should set that up here
    5. WRITE THE IMAGE
    6. Eject
    7. Put into appropriate RPi
    8. Attach pi to the network via Ethernet if you are using Ethernet
    9. Power on (aka, plug into power)

  2. Once all the pis are powered on (or once each pi is individually if you only have 1 SD card), run this command on your local computer, alter the subnet to the subnet your pis are on, it can be CIDR, a range, or a single IP—(it gets past to nmap in the play). Again, use the method we discussed in Ansible and review the code you are about to run before running, we have heavily commented it to help.

    apb Hosts/prep-raw-pis-for-boot-from-usb.yml -e "subnet=10.1.0.20-29"

    If all is well, Ansible will update the software, ensure that booting from USB is enabled, update firmware, log pertinent info, and shut down ALL the pis. If something fails, consult the Ansible logs and trouble shoot any issues.

  3. Once all the pis are shut down, remove the SD Card(s).

You should never have to do this step again for any pi that has already done it. But it's idempotent, so it doesn't matter if you do just to make sure—and thus the power of idempotence.

You can now boot from a USB attached drive, so, let's do that...

Second Imaging​

  1. Open Raspberry Pi Imager once again on control computer:
  2. This time, for each RPi:
    • Insert SSD (not to be confused with SD Card) into the control computer.
    • Choose image: Raspberry Pi OS Lite (64-bit)
    • Select appropriate SSD
    • Click the ⚙️ Advanced Options. If you are setting up multiple pis, the only param of the bellow settings that will change pi to pi is the hostname
      • Image customization options: to always use
      • ✅ Set the hostname. Use the hostname that is already defined in DHCP/DNS for the device the SSD belongs to: e.g. pi1.
      • ✅ Enable SSH
        • ✅ User password authentication
      • ✅ Set username and password (This password can be altered, but its just easier keep it as is. If you alter them, they must stay uniform across hosts)
        • Username: hab
        • Password: vanillaHab
      • ✅ Set locale setting
        • Time zone: [your timezone]
        • Keyboard layout: [your keyboard layout]
        • ✅ Skip first-run wizard
    • WRITE THE IMAGE
  3. Eject
  4. Put SSD into appropriate RPi
  5. Power on

If you didn't change the user/password, on the control machine, edit the host names below and run:

apb Hosts/standup-vanilla.yml -e "rawhosts=pi1,pi2,pi3,pi4,pi5"

If you did change the user and password, edit the host names, user, and password below and run:

apb Hosts/standup-vanilla.yml -e "rawhosts=pi1,pi2,pi3,pi4,pi5 user=pi pass=raspberryRaw"

If there are no failures, all raw pi's are now vanilla hosts 🙌

If you don't have any other computers, you can proceed to the section below. Otherwise, change the tab above to the next set of hosts.

tip

All the steps above will soon be irrelevant when netbooting—booting, imaging, and provisioning a Raspberry Pi (or any computer) remotely—makes it into the guide!