Daenney's blog

For a few years now I’ve had my eyes on Pulumi. Every time I looked at it I came away with a sentiment of “hmm, that seems nice”. I never got around to using it though and nobody around me had either so it was hard to get a sense of whether it would live up to my hopes. I recently decided to redo some of my personal infrastructure and since Pulumi has Hetzner Cloud support I decided to give it a go and see what would happen.

The electricity spot prices in Sweden (i.e the base price when you don’t have “fast pris”) are available from Vattenfal. On top of that price then come the transport costs your network operator charges, any taxes and 25% VAT. Yes. 25%. Yes on top of the taxes. Electricity is a luxury good. Apparently. These prices vary per region and the further south you go (the further away you are from the hydro plants) the more expensive it gets.

Thinking about the Fediverse a question that popped into my head was just how centralised the Fediverse is? By centralised I don’t mean the fact that mastodon.social is a huge instance, but centralised in the sense of which ISPs are hosting instances across the Fediverse. Mapping the Fediverse to Autonomous Systems The way this is achieved is technically speaking very simple: Query instances.social API for all instances it knows about Lookup the IP address(es) of each instance through DNS Use the MaxMind ASN database to find the AS number for the associated IP One problem is that this results in over 14k instances and for each one we do an A and AAAA query.

Server-Side Request Forgery is a web security vulnerability in which we attempt to trick the server to access resources that we, the client who did the request, would normally not be able to access. In practice this usually means trying to access other resources within the network the server is running in or other services on the same host. This usually happens when there’s a way for an attacker to control the URL a server is going to access.

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 how ActivityPub models microblogging. We’re going to dive into the three main parts: Actors, Activities and Objects. We’ll also take a look at how we use these to achieve microblogging in practice. Actor An Actor in ActivityPub is meant to represent someone or something performing an activity.

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.