With Mastodon quickly becoming a refuge for former bird-site users fleeing the new regime, many are considering self-hosting their Fediverse instance. There’s many good reasons to do this, such as privacy, data ownership, or even maintaining consistent performance while larger communities struggle to on-board an influx of new users. But, as always, self-hosting means new responsibilities! In this case, to ensure that the data is safe and secure, operating correctly, and to ensure that the server is not disseminating malware.

Anybody who runs an internet-facing webserver has seen their fair share of spammy scanners in the logs. It varies server to server, but some of mine get up to 15,000 scans per day. Almost all of these are harmless network mappers, but they still annoy me. Many are compromised hosts or belong to hackers & organized crime rings. While it’s possible to create false positives, it’s probably safe to block all of these.

Several admins and developers like automatically updating their servers with new builds as they become available. Commonly known as “CI/CD”, this process allows teams to iterate much faster and speed up product development. Often, this is simply pulling from a repo and running a couple docker-compose commands, which is very easy to automate. A bad way to do this is using a cron job that runs every 10 minutes to pull from the repository and execute any commands.

This guide is for an advanced Debian GNU/Linux installation using the ZFS storage system with an encrypted root volume for security and privacy. It will also be upgraded from the current Stable release (Bullseye) to the rolling-release Unstable version (Sid). ZFS has long been considered the last word on advanced storage developments. With its advanced safety, efficiency, and performance mechanisms it’s easy to see why it’s popular in the storage world, DIY and enterprise alike.

If you’ve put Redis on the internet you’ve probably had your box hacked one way or another. Unfortunately, the service has very weak defaults with no authentication, encryption, or meaningful access control. While it’s true that redis is a back-end service that should only be used between servers, it’s often misused and abused. For example, there are about 40,000 redis instances indexed on shodan.io, about half of which are not in protected mode.