Daenney's blog

One of the goals we have with GoToSocial is to make self-hosting your own fediverse instance really easy. In practice this means a few things: Providing a single static binary for easy deployment and without requiring containers Being very mindful of how much compute and memory we require No dependencies on external databases like Postgres, background job systems like Sidekiq which would require Redis, or an object store for media storage even though we do support using some of these things Though we don’t want to require an external database, we do need a database.

On my Linux desktop I have multiple sound devices. Typically it’s the built-in sound card, the graphics card audio output and my GoXLR outputs. I don’t ever want to use the built-in audio or have audio routed to my monitor. But the Linux desktop has this habit of sometimes switching to one of those outputs, especially when coming out of standby because the USB audio devices provided by the GoXLR disappear.

If you happen to have a GoXLR or a GoXLR Mini, the GoXLR-Utility project that’s supported across Windows, macOS and Linux allows you to configure the device without relying on TC-Helicon’s proprietary, Windows-only, tool. The GoXLR-Utility UI resembles the GoXLR App so you should be able to switch with ease. One of the many benefits of this is that GoXLR-Utility exposes an HTTP API that lets you control the mixer and be notified of mixer state changes.

A little annoyance I always run into when configuring a new laptop is getting Gnome Display Manager to use Colemak on the login screen. For some reason, it’s impossible to configure the GDM keyboard layout unless there’s at least 2 users on the system. Otherwise Gnome Settings refuses to show the UI for it. I’m not sure why this weirdly hostile feature towards folks with alternative keyboard layouts on a single-user system exists in Gnome, but here we are.

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.