Introducing the Homelab

My homelab is not a miniature enterprise. It is a compact Cisco switch, a couple of small boards, an OpenBSD machine that stages this website, and a partly-assembled video scaler sitting next to a soldering iron I have not learned to use yet. Anyone walking past it would see a shelf.

What makes it a lab is what I can do to it. I can misconfigure it, take it apart, and put it back together, and nobody files a ticket. That turns out to be the difference between reading about a thing and knowing it.

The boundary I use

Everything on the Homelab page is physically in my home and runs separately from the computer I use every day. That rule does most of the work. I operate public servers elsewhere, and some of them talk to projects that start here, but they are not part of this inventory and I do not want them to be. A lab is a place where breaking things is cheap.

The switch is the point

The Cisco Catalyst 3560CX-8PC-S is the piece that makes the rest of this a network instead of a pile of boards. It runs current firmware and it is where the Orange Pi and the InnoMedia adapter connect.

The plan is unglamorous: separate VLANs for voice, for the staging host, and for a NAS that does not exist yet, with QoS applied where the voice path gives it an actual reason to exist rather than a checkbox. None of that is deployed.

I want to be precise about why it interests me, because "learn networking" is not a goal. What I want is to understand where the boundaries belong, what specifically breaks when the policy is wrong, and how traffic behaves when several services with incompatible needs share the same wire. Configuration commands are the easy part. Knowing which configuration to reach for is not.

The machine that already earns its keep

The LattePanda 3 Delta runs OpenBSD and stages The Bug Report. Every change to this site is built and tested there before it goes anywhere a reader can see, which has already saved me more than once. OpenBSD is particular about things Linux forgives, and I would rather discover that on a small board in my house than in production.

It is still on Wi-Fi, which is the most honest thing on the shelf. It works, and it is not the network I actually want, and moving it onto a wired staging VLAN is one of the first real jobs waiting for the switch.

The bench

The Orange Pi RV2 is a RISC-V board on its stock image, waiting on Armbian and then Asterisk. The InnoMedia MTA is cabled up and waiting on the Orange Pi. The GBS-Control scaler is a board, a clock generator, an ESP8266, and a bag of parts, waiting on me to learn to solder. When it works it goes on the Wii.

None of that is running. That is fine — it is a bench, and things on a bench are supposed to be half-finished.

Why start the notes now

Because the alternative is writing them afterwards, and afterwards is a lie.

Retrospectives are tidy in a way the work never is. They skip the two weeks where something did not work for a reason that turned out to be embarrassing, and they present a straight line that nobody actually walked. Starting now means the record includes the parts I would rather leave out, which is the only version worth keeping.

So: one switch doing real work, one machine staging a website over Wi-Fi it should not be using, three projects on a bench, and a soldering iron still in its box. That is the baseline. Everything after this is change.