Posts

For a long time, I’ve had a setup with Keycloak as the IDM. But Keycloak is heavy. It’ll OOM with less than 2G of RAM and needs a database too. It also has features I don’t care for, like realms. As I’ve been slowly moving to self-host a few more things, including outside of my home, I want to have a way to centralise authentication for those services too. I want to keep the IDM for the home lab separate from my cloud things.

Every now and then I find myself needing to remember how HTTP request timeouts work in Go, and how to configure them. This has changed over time as http.Client gained the Timeout option, the various Timeout options you can set on the http.Transport and its underlying net.Dialer, and eventually the introduction of the context package in Go 1.7 that allows us to set a timeout/deadline on the request which in turn lead to the deprecation of http.

As part of setting up backups for my own GoToSocial instance, I’ve contributed some additions to the GoToSocial CLI and its backup documentation. This will hopefully make setting up backups easier for others too. This post goes through the why of setting up backups for this in the first place and looks at two pending changes to GoToSocial to make backups easier. So why backup your Fediverse instance? Because of the signing keys that are stored in your database.

This is a silly one, but I always forget about this until I need it and then stumble across it again. The scenario: you’ve just updated a piece of software and it comes with a new sample configuration. Being the good admin that you are of course you want to your config to reflect it, you’re not a monster. But you want to keep the settings you’ve tweaked. I always end up with a mess of patch files trying to do things, but all you really need is your favourite editor.

As I got into the ActivityPub side of the Fediverse I ended up hosting my own instance. Fediverse after all. But I wanted something I could easily operate and run which meant Mastodon was out and most Elixir-based solutions aren’t entirely simple to deploy and manage. Thankfully I stumbled across GoToSocial which is written in Go and has a fabulous community to boot. GoToSocial’s niche is small or single-user instances running on low-powered devices, like single-board computers or old laptops repurposed as home servers.

In Pulumi resources have inputs and outputs. Inputs are fairly obvious but Outputs have some interesting characteristics that are worth taking a closer look at. Outputs are effectively promises to resolve to a value once a resource is created. Outputs can in turn be used as inputs to a different resource which has the nice side-effect of establishing ordering/dependencies. When using Pulumi with Go you’ll see that resource structs have a $TypeOutput for most of their fields, like StringOutput.

A component resource is essentially a bundling of a number of resources. For example, when I want to provision a server I also need to assign it IPv4 and IPv6 addresses. I can do this independently, or I can create a custom Server component that does these things for me. This lets me encapsulate the way I work with infrastructure in my code and I can test the behaviour of a component.

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.