Log aggregation systems are fantastic. As are time-series metrics databases. But that’s not what this post is about. These methods aren’t a replacement for those systems at all, but a basic way to implement the core basics of monitoring and alerting. You see, the strength of a SIEM or log aggregation system is its numbers. It correlates data from hundreds or thousands of sources, giving very important insights about overall system usage patterns, login activity, audit trails, and more.

I recently installed Debian Bullseye on an old Intel NUCCAY6H mini PC I had lying around. It’s a great little device for a home server, as it’s very cheap, fits 16G of memory, and with 4 mini-cores it’s no slouch. The first install attempt didn’t go well, with missing firmware for the NIC causing hanging for a couple minutes during boot. This happens quite a bit with Debian’s hard-line stance on binary blobs, so I re-installed with the non-free install media.

There are lots of “very correct” ways to make your server “very secure.” Most of them rely on paid services, complicated agent-manager topologies, and cool buzzwords like “zero trust”. However, as they say, perfection is the enemy of progress. Many are discouraged by this absolutist approach to server safety, and forget the very basics. Obviously, the expensive and complex solutions exist for a reason, but at the same time a little goes a long way.

The latest announcements for Windows 11 have revealed that the next version of the Windows operating system will have very stringent hardware requirements. Some of them are, in my opinion, quite reasonable. For example, they’re finally dropping support for 32 bit X86 and legacy BIOS boot. These make sense, because almost every PC manufactured since 2011 has supported X64 and UEFI. It also sheds a substantial amount of technical debt and cruft, and simplifies the system slightly.

I have wanted to run Kubernetes at home for some time, but the main obstacle has been a reliable solution for providing load balancing for ingress or services, and the lack of a reasonable way to manage NAT transparently. While publicly routable IPv4 addresses are seemingly limitless* in the cloud, typically we only get one at home. Similarly, there isn’t a straightforward way to build cloud-ey load balancers at home. While Google and Amazon can conjure up magic TCP load balancers on their complex overlay network platform, we don’t really have that luxury outside of the cloud.