Good Morning from my Robotics Lab! This is Shadow_8472, and today I am reviewing the important parts of my homelab, going over the servers and software, and improving the inner workings. Let’s get started!
Hardware
The Internet comes in and connects to my ISP’s box. It’s set up in some kind of bridge mode. I have an Opnsense hardware firewall named Cerberus serving as the network hardware firewall and router. Wi-Fi is handled by an older router with stock firmware.
I have a server closet with my old RedLaptop, a NAS (Network Attached Storage) called GoldenOakLibry, and a pair of Dell Optiplex towers named ButtonMash and Joystick.
Golden Oak Libry
When we first got a NAS, we went with Synology. Since then, I’ve learned and the Linux kernel has developed, and one day I heard from tech support that they won’t be supporting a mission critical feature given my software stack (more on that later). I’ve been taking it slowly, but I’m transitioning into a newer QNAP device and adjusting to its quirks.
The driving force behind this month’s efforts has been completing this migration. I’d previously moved all the data onto other drives and back while only missing a few small files – mainly thanks to a terminal program called rsync. I grabbed all the metadata along with it – including UID/GID (User ID/Group ID) of all the files. And since I’d set up the previous NAS to not care about users, it was all Synology’s default “everybody” identifiers.
My goal for this time around is to distinguish between users. How-hard-can-that-be? Very.
Researching for Network Login
NFS (Network File System), the protocol I’m using to talk with Golden Oak, by default just trusts the incoming UID of any clients connecting to it. That means that if I upload a file from DerpyChips with a UID of 1000 and I access the NAS from my new laptop with a UID of 1000, everything will just work. But nothing is keeping my father’s computer from reporting the same UID, as 1000 seems to be the default value for all initial users. Now, I have an account on my father’s computer, and since it was created after his, my UID on there isn’t 1000. Too much work, too fragile. Approach rejected.
A more robust approach to solving this problem is Kerberos. I have some recollection from my initial days setting up the Synology NAS. In short: a client talks to a trusted server to get at a service. I spent a while researching implementation –including using Buildah to make a container to run with Podman– but found it expects way more network infrastructure than I already have, so I pivoted toward learning about this technology I keep hearing about in relation to homelabs: LDAP.
LDAP (Lightweight Directory Access Protocol) is roughly equivalent to Active Directory in Microsoft Land. And in true Linux fashion, LDAP is a specification, not a single piece of software. Opinions differ as to which is best for a use case like mine, but LLDAP (Lightweight LDAP) seems to be right for me.
Joystick
Podman is the underlying technology I use for my homelab. It is often compared to Docker, but it works without root access in case of container breakout. I have a non-admin account on my server, Joystick, where I use Quadlet files for permanent Podman containers so they’re always running when I expect them to be.
But the heart of my homelab (software wise) is Caddy. Caddy is more or less a do-it-all networking suite. It’s a reverse proxy with built-in HTTPS – both real and by self-signed SSL certificates. And everything Caddy does is controlled by a Caddyfile written in as simple a format as possible. Once everything is in motion, the most annoying part is telling your computers and browsers to trust your self-signed certificate authorities.
Taking inventory, I found I didn’t have much in fully functional order. Vaultwarden (3rd party Bitwarden server written in Rust) and Crafty Controller (Minecraft server management software). Beyond that, I have an incomplete Nextcloud setup waiting on Golden Oak and dreams of many more projects – many of which also are waiting on Golden Oak Libry. The home directory was getting full, so I sorted them between Services that provide target functionality and Network that support the Services.
One of Caddy’s features is a static web server. After reviewing all my containers, I wrote a landing page for it to display. Debugging it ate a bunch of time, but I found I had goofed a mount configuration. From there, I linked my different services as a way to test them.
During this process, I discovered a poor Caddyfile entry for Crafty. Someone on GitLab had suggested essentially bypassing HTTPS security in a way that otherwise looked legit. This would have been fine for my setup, but out of concern for the community, I updated an earlier solution that relied on a deprecated Caddy term a different Caddy /path/to/certificate. In this way, I learned one way to “establish trust.”
Cerberus
Hardware Firewall. It’s basically a fancy router – a REALLY fancy router. If Caddy is the heart, Cerberus is the head. It handles the DNS blocklist using the OPNsense plugin Unbound. But Unbound also handles domain name resolution. I was several major versions out of date. Oops. Fixed.
Ironing out Unbound was another place that ate up diagnostic time like crazy. I eventually happened across a bug report where DNS server crashes if Unbound tries forwarding a wildcard subdomain (as in *.myDomain.lan) if the router thought itself on that same domain (under System>Settings>General>Domain). It wouldn’t stop completely, but it would get really slow. Switching to myDomain.arpa is a small price to pay for not having to manually forward each subdomain I configure for Caddy.
Takeaway
Life’s been hectic as of late, so I haven’t had the time or usable attention span to finish all my goals. Instead, I found several smaller goals and am in the process of whittling away toward the larger ones. My homelab was a bit of a mess after the techno-wizzarding I’ve been pulling off, and on this later pass, I’ve improved my understanding of what it was I was doing and how to engineer it better.
I have plenty of smaller goals I left out because I want this to be a log of what I’ve managed to finish – not a dream log of what I still have to do, but I still have one thing I wish to share.
One of the links on my homelab landing page is back to the router: https://cerberus.myDomain.lan. Firefox won’t load it. I looked up how to establish trust between Caddy and OPNsense, and my search results were flooded with a Caddy plugin for OPNsense. I’m sure it’s a fine project, but I don’t want to invest in that toy right now. Long story short, I pivoted approaches to use an ACME (Automatic Certificate Management Environment) client I found for OPNsense. I left an entry in my Caddyfile to hopefully expose the ACME server and did everything to make my first attempt. It failed, but at least I got to that attempt in the first place. I do however need to call it quits on the research.
Prayer
One YouTuber I occasionally pay attention to is Network Chuck (Shoutout if you’re reading this). I may disagree with his claim that “everything in IT requires coffee,” but I do like how he’s made a space in his videos for Jesus, and I’d like to do the same (the prayer, not the coffee).
Father in Heaven,
I thank you for the progress I’ve had this month, and I praise you for whomever is sticking around. Please bless him or her according to your will. May you inspire my readers in their personal projects, be it with Caddy, OPNsense, or more. Guide them towards whatever documentation or bug report they need, and help them avoid focusing on premature feature creep.
In Jesus’ name I pray, Amen.
And if you are curious about the Bible, God, or Jesus, I’d be more than happy to talk. These days, I primarily use Discord. There’s a link to my server in my Socials tab at the top of this page. So far, He’s been welcome there, but from now on, I’d say He’s properly invited.
Final Question
Do you have an opinion on which LDAP server reigns supreme for homelabs? I look forward to hearing about it in the comments below or in my Socials!