86 lines
3.5 KiB
Markdown
86 lines
3.5 KiB
Markdown
---
|
|
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.
|