Last year when I went to Red Hat Summit, I saw a lot of use of Satellite. I’d tried the 5.x series’ upstream Spacewalk and it didn’t quite work out for me. But this time I would try it out, gosh darnit! I mean, with the Katello plugin it would even include Pulp, which I’d been interested in trying out before because it could cache RPMs during an upgrade. So I’ve been messing with it here and there. However,I don’t use Puppet scripts (it’s like Chef or Ansible in principle) and I don’t have the need to provision new machines or VMs (especially when that’s already pretty easy with Cockpit and/or Virt-Manager). It’s already easier and works more consistently for me to keep track of whether my computers are up to date (and update them if not) with Cockpit. The RPM caching part of it was neat, but recently it stopped working consistently. Upgrades are VERY fragile and messing up on installing a plugin could bork the whole system. Also the necessary files - puppet, katello-agent, etc were always behind in providing packages for Fedora. Turns out it was a bunch of extra work and frustration just to keep track of my computers - and I was already doing that in Dokuwiki.

Because I have this VM registered to Katello (Foreman plugin) to receive updates (basically as a way of both keeping track of the computers and VMs on my network and also to have a GUI to pulp for caching RPMs), I had to deal with Katello-Agent. The latest RPM in the official Foreman/Katello repos is unfortunately for Fedora 29. That version of Fedora has been out of maintenance for a long time. Maybe Foreman (upstream for Satellite) is just used by most of their customers for RHEL sites that don’t have any Fedora nodes? So I did find this copr that provides updated versions: https://copr.fedorainfracloud.org/coprs/slaanesh/system-management/

When it came to new dishes, April was all about bread. First, I made a no-knead bread with America’s Test Kitchen’s recipe.

Almost No-Knead Bread

It came out OK. I actually tried it again the following day to try and get a darker crust. The funny thing is that this is one of the easiest breads to make and yet it’s the one I’ve had the worst results with. The crumb wasn’t as open as it was supposed to be and for all the time it took to proof it was pretty meh.

As I mentioned in my k3s on Ubuntu 2020.04 post, I really thought that Ubuntu 2020.04’s server install was prety slick. I’m used to text-only server installs looking like this:

Arch Linux Installation Begins

Here’s a step-by-step collection of screenshots and my thoughts on each step of Ubuntu 2020.04’s server install:

Language Selection

Just starting off, with the language selection, you can see this isn’t the usual ugly ncurses install. It looks like a beautiful matte black.

Clearly there’s a lot I don’t get about Kubernetes and I didn’t install a GUI in that VM so I can’t use the dashboard (which can only be viewed at localhost - or so the instructions seem to indicate) So I decided to go back to basics and look at the Hello Minikube tutorial, but run it in my k3s VM.

kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4

So I think this is the first part of why I was having problems yesterday with the pod I created from Podman. A lot of the commands I saw online implied a deployment, but I hadn’t created one. This is evidenced by:

As I’ve been working on learning server tech, I’ve gone from virtualization to Docker containers and now Podman containers and Podman pods. The pod in Podman comes from a view towards Kubernetes. I moved to Podman because of the cgroupsv2 issue in Fedora 31 and so I figured why not think about going all the way and checking out Kubernetes? Kubernetes is often stylized as k8s and a few months back I found k3s, a lightweight Kubernetes distro that’s meant to work on edge devices (including Raspberry Pis!). For some reason (that I don’t seem to find on the main k3s site), I got it in my head that it was better tailored to Ubuntu than Red Hat, so I decided to also take Ubuntu Server 2020.04 for a spin.

Yesterday I mentioned some issues with my Ortek MCE VRC-1100 remote and certain buttons not working. Figured out that in addition to removing the XF…. entries in dconf, also have to remove them in gsettings. Specifically, I had to use the commands:

gsettings set org.gnome.settings-daemon.plugins.media-keys stop-static [’’]

gsettings set org.gnome.settings-daemon.plugins.media-keys play-static [’’]

gsettings set org.gnome.settings-daemon.plugins.media-keys pause-static [’’]

After that, everything was working as it should. So far no negatives to using Fedora Silverblue as our HTPC. We’ll see if that changes as I try to get Lutris to launch some Wine games.

One thing to know about Silverblue is that it’s a Gnome environment. I was already running Gnome for the HTPC, but I prefer KDE for my computers usually. When I was installing Silverblue there was no option to go for KDE or anything else. On Silverblue you install via Flatpaks. Any regular installs (ostree instead of rpms) also requires a reboot.

A few things to note based on getting Kodi setup:

Originally I was going to mess around with Silverblue in a VM before considering using it on my HTPC. In theory it sounded like it would work very well - an immutable, rollback-able OS seems like the perfect thing for the one computer that ALWAYS needs to work for less tech-savvy folks in the house. But the first release of Silverblue seemed to still be a bit rough around the edges. Lots of recent blog posts on Fedora Planet (a blog aggregator for folks who participate in the Fedora project) seemed to indicate that things were in a better place now for Silverblue. Still, I was going to first mess around in a VM. But then I had to reboot the computer after things went awry with the display and this time I wasn’t able to get around the Free Magic issue that had been plaguing me for a few months now since upgrading to Fedora 31 (in anticipation of Fedora 30 being out of the support window). The Free Magic issue basically would appear after the grub menu and while others’ reports on bugzilla seemed to indicate that a kernel upgrade fixed it for them, such was not the case for me. For a while it worked such that if I was there on reboot and hit enter on the grub entry, it would work (while it would fail if you left it to boot on its own). But tonight it would not yield. The computer had gone catatonic. So, I figured it was as good a time as any to try and move to Silverblue. As a bonus, I was going to move the installation to an SSD, so I still have the old, borked installation if things go completely wrong (although I’d still need to fix the Free Magic issue).

As things continue to happen in the commercial IoT space like Wink switching to requiring subscription fees, I continue to feel happy that I’m creating my own Internet of Things solutions rather than relying on commercial vendors who can decide to disappear or suddenly start charging fees. The cost for me is that things go at a slower pace and, obviously, don’t have sleek packaging. I think I can live with that.