first commit

content/posts/why-openbsd.md

@@ -0,0 +1,85 @@
+---
+title: "Why OpenBSD for a Homelab"
+date: 2025-01-15
+tags: [openbsd, homelab]
+slug: why-openbsd
+description: "The case for running OpenBSD as the foundation of a homelab — security model, pf, clean base system, and the value of good documentation."
+draft: false
+---
+
+A few people have asked why I chose OpenBSD for this homelab instead of the usual suspects —
+Proxmox, TrueNAS, some flavor of Linux. The short answer: I wanted to actually understand what
+my infrastructure is doing, and OpenBSD forces that in a way nothing else does.
+
+## The Security Model Is Different
+
+Most operating systems bolt security on. OpenBSD builds it in.
+
+`pledge(2)` and `unveil(2)` are the clearest expression of this. Programs declare up front exactly
+what syscalls they'll use and which filesystem paths they'll touch. The kernel enforces it. If a
+daemon gets compromised, the blast radius is bounded by what it pledged. This isn't theoretical —
+the base system uses these everywhere.
+
+Compare that to a typical Linux daemon running as root (or even a non-root user) with access to
+the full filesystem. The attack surface is enormous by default.
+
+## pf Is the Best Firewall I've Used
+
+I've spent time with iptables, nftables, and a few others. `pf(4)` is in a different category.
+
+The rule syntax reads like English. State tracking is intelligent by default. `relayd(8)` handles
+reverse proxying and TLS termination in a way that integrates naturally with pf. The whole
+networking stack hangs together coherently.
+
+Here's a minimal pf.conf to give a sense of the syntax:
+
+```
+set skip on lo
+
+block all
+
+pass in on egress proto tcp to port { 80 443 } keep state
+pass in on egress proto tcp to port 22 keep state
+pass out all keep state
+```
+
+That's readable. You can audit that in two minutes.
+
+## The Base System Is Clean
+
+OpenBSD ships a complete, minimal base system. No package manager drama, no systemd, no
+six-hundred-dependency init system. The base is coherent. Everything in `/usr/bin` and
+`/sbin` has been reviewed and fits together.
+
+When I install a service, I know exactly what I'm adding on top of a well-understood foundation.
+On a typical Linux distro, I'm never quite sure what's lurking in the base.
+
+## The Documentation Is Accurate
+
+This is underrated. OpenBSD man pages are written by the people who wrote the code. They are
+current. They are correct. When the man page says `pledge(2)` takes these promises in this
+order, that is exactly what happens.
+
+How many times have you followed a Linux man page only to find it describes behavior from four
+kernel versions ago? Or read documentation that's accurate for one distro but not another?
+
+With OpenBSD, the man page is the specification. This matters enormously when you're learning
+a new tool or debugging an obscure issue at 2am.
+
+## The Tradeoffs
+
+OpenBSD isn't the right choice for everything. ZFS isn't in the base (use FreeBSD for that).
+The package ecosystem is smaller than Linux. Some software just doesn't run on OpenBSD, or
+runs with limitations.
+
+For a homelab where the goal is to *understand* the infrastructure rather than just consume
+services, these tradeoffs are worth it. The constraint of a smaller, more deliberate ecosystem
+means you end up with a leaner, more auditable system.
+
+If you want to run Kubernetes on your homelab, OpenBSD is the wrong choice. If you want to
+actually know what your firewall is doing and why, it's worth the investment.
+
+## What's Next
+
+The next post covers the hardware — what's actually in the rack and why those particular
+machines. After that, I'll get into the pf configuration and VLAN setup.