Homelab

In this post, I will describe my failed attempts of booting Tinkerbell’s in-memory HookOS directly on a Pi 4, without iPXE or UEFI. This is part 5 of my Tinkerbell series. In my previous post, I described how I provisioned a Pi 4 using Tinkerbell’s standard way via UEFI and iPXE. This was a complicated and convoluted process, requiring heavy use of Dnsmasq on the side and bouncing between requests to said Dnsmasq and Tinkerbell itself. In the end, I was only able to do it after completely switching off Tinkerbell’s DHCP functionality. I wasn’t particularly fond of that option, because I quite liked how it worked for provisioning the VM in my first experiments. I didn’t want to completely switch off DHCP in Tinkerbell just because of the Pi 4. ...

With release 4.4.0 Mastodon introduced a Prometheus exporter. In this post, I will configure it and show the data it provides. With the new release, Mastodon provides metrics from Ruby and Sidekiq. I’ve attached examples for both to this post, see here for Ruby and here for Sidekiq. The information is not actually that interesting, it’s just generic process data. But I did find at least the Sidekiq data worth gathering. It will provide an interesting future look into my usage of Mastodon and perhaps even the activity in the Fediverse (or at least the part I’m connected to) overall. ...

In this post, I will show how I provisioned a Raspberry Pi 4 with an attached USB SSD via Tinkerbell. This is part 4 of my Tinkerbell series. The main goal of this post is to get this little guy to boot into Tinkerbell’s HookOS and install an Ubuntu 24.04 Raspberry Pi image onto the SSD: My experimental setup. ...

In this post, I will describe how I deployed Tinkerbell into my k3s cluster and provisioned the first Ubuntu VM with it. This is part 3 of my Tinkerbell series. Deploying Tinkerbell The first step is to deploy Tinkerbell into the k3s cluster I set up in the previous post. For this, I used the official Helm chart, which can be found here. My values.yaml file looks like this: publicIP: "203.0.113.200" trustedProxies: - "10.42.0.0/24" artifactsFileServer: "http://203.0.113.200:7173" deployment: envs: tinkController: enableLeaderElection: false smee: dhcpMode: "proxy" globals: enableRufioController: false enableSecondstar: false logLevel: 3 init: enabled: true service: lbClass: "" optional: hookos: service: lbClass: "" kernelVersion: "both" persistence: existingClaim: "hookos-volume" kubevip: enabled: false The first setting, publicIP, is the public IP under which Tinkerbell’s services will be available to other machines. It will be used in DHCP responses for the next server, download URLs for iPXE scripting and so forth. It will also be set as the loadBalancerIP in the Service manifest created by the chart. In my case, this is a VIP controlled by a kube-vip deployment I will go into more detail on later. The trustedProxies entry is just the CIDR for Pods in my k3s cluster. The artifactsFileServer is the address for the HookOS artifacts, in this case the kernel and initrd. The Tinkerbell chart sets up a small Nginx deployment for this and automatically downloads the newest HookOS artifacts to it. This is configured under optional.hookos. I’m also disabling a few things because I don’t intend to use them. One of those is leader elections for Tinkerbell - as I will only have one deployment, those seem unnecessary. I disable Rufio and SecondStar as well. Rufio is a component to talk to baseboard management controllers usually found on enterprise equipment. As I don’t have any such gear, it’s unnecessary. Finally, SecondStar is a serial over SSH service I also don’t need. ...

A description of my lab setup for tinkering with Tinkerbell. This is part 2 of my Tinkerbell series. For my Tinkerbell tinkering lab Actually, no. Let’s start with: How did I not come up with “tinkering with Tinkerbell” until the second post of this series? You may tsk tsk tsk disapprovingly at your screen now. For my Tinkerbell tinkering lab, I decided to run it on my desktop machine. This is because previous work on network booting has shown that I definitely want direct access to the netbooting machine’s TTY. And that’s easiest when it runs on my desktop. Also makes stuff like packet capturing easier. So I needed the following things in my lab setup: ...