What I do
I work as a software developer, mostly with Scala and Python, and operator/system engineer for satellite mission planning. I contribute to ground systems of scientific satellite missions in my day job.
Outside of my job, I dabble with Rust and fiddle with my Arch Linux systems. Sometimes I write about this here.
What I enjoy
- Bouldering, though I'm much worse than I'd like to be.
- My single speed bike.
- Books about history and philosophy.
- The Disk World series by Terry Pratchett who passed away too early. I love Nanny Ogg, Rincewind and Moist von Lipwig.
- Playing old video games. I still hope to go through Baldur's Gate 2 at least once in my life time, and I still enjoy the Gothic series.
- Playing AAA games sometimes. Witcher 3 is an all time favorite; the central quest of the Heart of Stone expansion is the single best thing I ever saw in a video game.
- Writing Rust code; the language and its tooling just do so many things right in my opinion.
- Arch Linux, because it's simple to set up, never gets in my way, and has a reasonable and pragmatic approach to distribution packaging.
Install Arch with Secure boot, TPM2-based LUKS encryption, and systemd-homed
Update: I no longer use
dracut, and the corresponding part of this blog post no longer reflects my setup.
This article describes my Arch Linux setup which combines Secure Boot with custom keys, TPM2-based full disk encryption and systemd-homed into a fully encrypted and authenticated, yet convenient Linux system.
This setup draws inspiration from Authenticated Boot and Disk Encryption on Linux and Unlocking LUKS2 volumes with TPM2, FIDO2, PKCS#11 Security Hardware on systemd 248 by Lennart Poettering, and combines my previous posts Unlock LUKS rootfs with TPM2 key, Secure boot on Arch Linux with sbctl and dracut, and Arch Linux with LUKS and (almost) no configuration.
Unlock LUKS rootfs with TPM2 key
Historically cryptsetup and LUKS only supported good old passwords; however recent systemd versions extend cryptsetup with additional key types such as FIDO tokens and TPM devices.
I like the idea of encrypting the rootfs with a TPM2 key; it allows booting without ugly LUKS password prompts but still it keeps data encrypted at rest, and when combined with secure boot also still protects the running system against unauthorized access.
Secure boot will prevent others from placing custom kernels on the unencrypted EFI system partition and booting these, or changing the kernel cmdline, in order to obtain root access to the unlocked rootfs. LUKS encryption with a TPM-based key bound to secure boot state protects the data if someone removes the hard disk and attempts to access it offline, or tries to disable secure boot in order to boot a custom kernel.
I’ve covered secure boot setup in a past article; this article talks about the TPM2-based encryption.
I just learned a nice trick: On Linux I can actually define custom sequences for the Compose key.
I just need to create a
~/.XComposefile and can start to define new sequences for e.g. emojis:
include "%S/en_US.UTF-8/Compose" <Multi_key> <period> <p> <r> <a> <y> : "🙏" <Multi_key> <period> <less> <3> <parenright> : "😍" <Multi_key> <period> <less> <3> <period> : "❤️" <Multi_key> <period> <less> <3> <asterisk> : "😘"
man 5 Composedocuments the format, though Gtk doesn’t seem to support all of it: It doesn’t handle includes apparently, and always seems to include its own hard-coded list of compose sequences.
I found a nice Gist with some sequences, and I started to write my own.
The mysterious disapperance of Docker images
A node hosts a Gitlab runner and a small k3s cluster which runs a few services as regular kubernetes deployments. A CI job pinned to that runner builds Docker images for these services services, updates the image of the corresponding deployments, and starts a few system and acceptance tests. The CI job does not push those images to the in-house registry; to avoid polluting the registry with hundreds of images it just builds locally.
Each test then scales each deployment to zero replicas to effectively stop all services, clears the system’s underlying database, and scales the service deployments back to a small number of replicas sufficient for testing.
The whole thing runs fine until one day the replicas randomly fail to start.
HTTP Proxy in Electron flatpaks
Some electron-based flatpaks (e.g. Mattermost, see https://github.com/flathub/com.mattermost.Desktop/issues/23) for some reason ignore Gnome’s HTTP proxy settings. In this case we can set the proxy directly inside the affected flatpak.
Discoverable GPT partitions
LWN recently covered a comprehensive guide about discoverable GPT disk images by Lennart Poettering.
Secure boot on Arch Linux with sbctl and dracut
I started playing around with secure boot, with the ultimately goal of setting it up on my laptop. I experimented in a libvirt/qemu VM and to my surprise a custom secure boot setup is rather easy (the Secure Boot page on the Arch Wiki suggests quite the contrary), thanks to dracut and a fairly recent tool named
sbctlwhich just recently had it’s first release.
Arch Linux with LUKS and (almost) no configuration
Installing Arch on a LUKS-encrypted dsik traditionally required a few careful configuration steps to configure the proper root device for booting; if any of these steps was omitted or done wrongly the system would fail to boot. With systemd and dracut however a LUKS-encrypted Arch system can boot safely and reliably without any configuration:
- Dracut builds a unified EFI kernel image including microcode and a generic initrd with systemd and cryptsetup.
- systemd-boot automatically discovers unified kernel images installed by dracut and automatically adds them to the boot menu without explicit boot loader configuration.
- At boot systemd automatically discovers and mounts the root file system following its DISCOVERABLE PARTITIONS specification.
The following commands demonstrate a fresh Arch installation from the Arch installation media into a libvirt VM. Installing to a pristine physical machine or a different virtual machine provider should require only minimal changes; adapting an existing system may be more difficult and require more work.
Observations from using systemd-homed for a couple of days: