99 lines
4.1 KiB
Markdown
99 lines
4.1 KiB
Markdown
---
|
|
title: "The Hardware: What's in the Rack"
|
|
date: 2026-03-05
|
|
tags: [hardware, homelab]
|
|
slug: the-hardware
|
|
description: "A tour of the physical hardware — SuperMicro 1U firewall, Dell R720 primary server, Dell R710 secondary, and the desktop control node."
|
|
draft: false
|
|
---
|
|
|
|
Before getting into software configuration, it's worth documenting the physical layer. What's
|
|
actually in the rack, why those machines, and what each one does.
|
|
|
|
## The Firewall: SuperMicro 1U
|
|
|
|
The firewall is a SuperMicro 1U server with a Xeon E3-1230v2 and 16GB ECC RAM. This runs
|
|
OPNsense (FreeBSD-based) and handles everything at the network edge:
|
|
|
|
- **pf** — stateful packet filtering, VLAN routing
|
|
- **nginx** — reverse proxy, TLS termination for external services
|
|
- **WireGuard** — VPN for remote access
|
|
- **unbound** — recursive DNS resolver for internal clients
|
|
- **dhcpd** — DHCP for all VLANs
|
|
|
|
The E3-1230v2 is modest by current standards but easily handles firewall workloads. More
|
|
importantly, it supports AES-NI (important for VPN throughput) and runs cool and quiet.
|
|
|
|
Multiple NICs: one for WAN, one trunked to the main switch carrying tagged VLANs for each
|
|
network segment.
|
|
|
|
## The Primary Server: Dell R720
|
|
|
|
The R720 is the workhorse. Dual Xeon E5-2600 series processors, 64GB ECC RAM, a few SSDs
|
|
for the OS and data volumes.
|
|
|
|
This runs FreeBSD and hosts:
|
|
|
|
- **httpd** — web server for this site
|
|
- **Gitea** — self-hosted git
|
|
- **OpenSMTPD** — email (outbound, plus some inbound)
|
|
- **Prometheus + Grafana** — metrics collection and dashboards
|
|
- **Matrix** (Conduit) — self-hosted chat
|
|
- **Various smaller services** — RSS aggregator, bookmarks, etc.
|
|
|
|
The R720 is loud. Server-grade loud. It's in a separate room with the rack, so this is
|
|
tolerable. The fans throttle down after a few minutes under light load, but under any real
|
|
IO they spin up fast.
|
|
|
|
Power draw is significant — plan for 150-300W depending on load. Not a machine you run
|
|
on a home circuit without thinking about it.
|
|
|
|
## The Secondary Server: Dell R710
|
|
|
|
The R710 is older — Xeon 5500/5600 series — but has more RAM slots, currently at 48GB.
|
|
It runs FreeBSD with Linux VMs managed by `bhyve(8)`.
|
|
|
|
Primary roles:
|
|
|
|
- **nsd** — authoritative DNS for ridgwaysystems.org zones
|
|
- **Linux VMs** — game servers (Minecraft, Valheim, etc.), running in `bhyve(8)`
|
|
- **Jellyfin** — media server
|
|
- **Backup target** — receiving ZFS send/recv and rsync backups from srv01
|
|
|
|
The R710 is even louder than the R720 under load. Old server hardware wasn't designed with
|
|
home environments in mind. iDRAC makes remote management workable — I rarely need to touch
|
|
it physically.
|
|
|
|
## The Desktop: Daily Driver and Ansible Control Node
|
|
|
|
Standard desktop setup: Ryzen, 32GB RAM, NVMe storage, running Linux.
|
|
|
|
This is the Ansible control node. All infrastructure changes go through playbooks on this
|
|
machine and push to the servers. The goal is to get to a point where I could wipe any server
|
|
and bring it back up cleanly with `ansible-playbook`.
|
|
|
|
Not there yet — the playbooks are more "documentation that happens to be executable" than
|
|
a fully idempotent rebuild-from-scratch system. That's the project.
|
|
|
|
## Why Old Server Hardware?
|
|
|
|
Two reasons: price and ECC RAM.
|
|
|
|
A Dell R720 can be had for $200-400 on eBay depending on configuration. For that price you
|
|
get two server-grade CPUs, ECC RAM, hot-swap storage bays, iDRAC out-of-band management,
|
|
and hardware RAID if you want it. Nothing in the consumer space touches this value per
|
|
dollar for a home server.
|
|
|
|
The tradeoffs are power consumption and noise. For a rack in a utility room or basement,
|
|
those are manageable.
|
|
|
|
ECC RAM matters for a storage server. Silent corruption from a bit flip in a RAID controller
|
|
or filesystem is the worst kind of failure — the kind you don't notice until you need the
|
|
data. ECC doesn't eliminate all failure modes, but it eliminates the commonest one.
|
|
|
|
## What's Next
|
|
|
|
Next up: the pf configuration and VLAN setup. This is where most of the interesting work
|
|
happens — separating untrusted IoT devices from servers, routing WireGuard traffic, and
|
|
setting up the reverse proxy to forward external services.
|