BTRFS, Subvolumes, Snapshots, and Snapper

Most Linux installations still treat the filesystem as an afterthought.

You make one root partition, maybe one home partition, format everything as ext4, and move on. That works. But once you start doing frequent package upgrades, distro experiments, workstation tuning, or homelab maintenance, the lack of cheap snapshots becomes very noticeable.

This is where BTRFS becomes practical.

Why Docker Buildx Bake Is More Interesting Than It Looks

If you only ever build one image with one Dockerfile, Docker Bake can look a bit underwhelming.

You move a docker build command into a docker-bake.hcl file, type docker buildx bake, and at first glance it feels like you just created one more file for no obvious reason.

That is the wrong way to evaluate it.

Your .env File Does Not Belong in Plaintext

In an earlier article, AES‑256 Is Enough. Your Secrets Workflow Isn’t, I argued that the cipher is usually not the weak point.

The weak point is the workflow around it.

One of the most common examples is the humble .env file.

Running a Tor Exit Node on CentOS Stream 9 with Ansible

If you want to operate a Tor exit node properly, you should avoid doing it by hand.

You need a repeatable bootstrap, a hardened SSH configuration, a firewall that only exposes what you actually need, a local resolver, and a maintenance path that does not turn into improvisation after the first update cycle.

I still like CentOS Stream 9 for this kind of infrastructure work. I explained why in an earlier article here: Why I Continue To Advocate For CentOS Stream In Production Environments.

In this article, I will show a small Ansible setup that bootstraps a CentOS Stream 9 host, configures it as a Tor exit relay, adds a local Unbound resolver, hardens SSH, enables fail2ban, and gives you a minimal maintenance workflow.

All hostnames, IP addresses, nicknames, usernames and contact details below are sanitized examples, but the structure mirrors a real setup.

You Probably Want a Monorepo for Your Base Images

Most engineering teams do not start with an image governance problem.

They start with something humble: one Dockerfile for Python, one for Node.js, one for kubectl, maybe one for Maven or a Java runtime. Every repository looks small enough to be harmless. Then the small things start multiplying: slightly different labels, slightly different CI jobs, slightly different versioning schemes, slightly different ways to import internal certificate authorities, slightly different smoke tests, slightly different signing steps.