Daenney's blog

In this series of posts we’re going to explore ActivityPub, the protocol that powers microblogging across the Fediverse. This post is going to focus on the technologies ActivityPub is built upon. It doesn’t dive into how ActivityPub itself is used to provide interoperable microblogging. That will be the topic of a future entry. ⚠️ Caveat lector: This post has an air of mild annoyance 😑. If you don’t enjoy reading this type of commentary, I suggest you stop here.

I’m renaming the series to “Replacing Avahi” because after a bit of reflection “getting rid of” sounds a lot harsher than I ever intended. In part 1 we took a quick look at what DNS-SD is and why we use Avahi for it on Linux. We then came up with a plan on how to replace it by re-implementing its D-Bus API ourselves by in turn leveraging systemd-resolved’s D-Bus API.

Avahi is a daemon you can run on your system for the purpose of discovering or announcing services using DNS-SD. DNS-SD defines how to perform service discovery using DNS SRV and TXT records. Though it can use unicast DNS, its most typical usage is using multicast DNS over zeroconf, i.e link local IPv4/6. If you’ve heard of Apple Bonjour, this is it. For end-user systems, being able to discover devices in a network using DNS-SD is incredibly helpful.

When running servers I want to encrypt the data stored on them. The problem you then pretty quickly run into is that it’s hard to actually boot with an encrypted root. I’ve solved this problem in the past by having a tinysshd in my initramfs which prompts me for a password to unlock the volumes. Though this works, it’s annoying in that the server isn’t able to boot at all, causing any additional monitoring I have to not work.

A lot has been written about working remotely. In light of the current COVID-19 pandemic, I decided to write down my own thoughts on this topic and the processes and tools I’ve developed to help me be effective at working remotely. I moved to being full-time remote in February of 2019. Before that every job I’ve had was office bound. Though I worked remotely every now and then, especially when things like the flu hit, I’d never worked from home more than a few consecutive days and never in any permanent capacity.

In a previous post I showed you how to setup Keycloak to provide you with OpenID Connect and SAML capabilities. The problem with Keycloak is is that’s it’s a pretty big beast, whereas most of the time we don’t need all the functionality. It’s also tricky to run in a highly available fashion and is annoyingly slow to start up. In this post we’ll drop Keycloak in favour of Dex, a small OpenID Connect Provider that supports a number of backends including LDAP.

In a previous post I showed you how to set up Gatekeeper as a proxy to enfroce authorization on requests. The problem with Gatekeeper is that it required a lot of additional configuration, an additional proxy hop and is a separate component. What this post will do instead is use the OpenResty build of nginx with the OIDC plugin to avoid all of that. This brings the complexity back down to just running nginx with it acting as a Relaying Party to do authenticaiton and provide authorization information to backends.

Update 2019-06-09: Performing BIOS updates I recently decided to get myself a new laptop. Though work provides me with one, I make a point out of never using it for personal use. It can get a bit complicated around intellectual property laws. I’m also perfectly fine with my employer enforcing certain policies on their device that I just don’t want for my personal devices. For the device itself I decided I wanted a 13" model, with an AMD Ryzen CPU and Radeon graphics.

As part of my home automation I wanted to emulate a Philips Hue bridge. The reason for that is that a lot of things provide out-of-the-box integration with Philips Hue. Aside from that, there’s a ton of apps and other cool things in the Hue ecosystem I wanted to unlock. However, we use the IKEA Trådfri system at home, even though we do have a first generation Philips Hue bridge. The reason for switching to the IKEA one was:

I’m addicted to home automation. There. Said it. But it’s just such a tremendous amount of fun to play with. I’m pretty sure it’s the SRE in me. Why do anything by hand when you can have computers do things for you? Why turn on the lights when you get home when it can happen automatically? Turn on the lights when you enter the bathroom? Barbaric! Turn them off? I’ve git better things to do!