Setting up a Home Server with Fedora

Published on December 27, 2022

For a while now I’ve had a home server made from the remains of an old gaming PC after I sold the GPU. It sits in the corner generating heat, and running some non-essential services like a Gitea server, backing up my Dropbox files somewhere else1, and serving some static video files that I watch on my Xbox with Kodi. I traditionally have run Debian, but I’ve started to branch out and have started experimented with the Fedora distributions. I’m going to talk about the switch to Fedora 37, some of the pros of that switch (Fedora has been better suited to my needs), but also about my setup in general.

Living within sight of the edge

Debian’s famous stability did not serve the needs of my home server, whose primary purpose was to learn some sysadmin skills. When I upgraded to Debian 11 the version was still in beta, but I strongly wanted to try out podman with non-root containers, and didn’t like the hoops I had to jump through.2

Debian’s place as the default choice is well-deserved, and has served me well when stability was a dominant requirement. My experience is an application running on a Debian LTS release will keep working indefinitely without any maintenance through apt upgrades. That’s too boring for my personal needs, and the lack of recent software is detrimental. The old software issue is also why I have Fedora on my Framework laptop with 12th gen Intel. As I type this the top of my screen flickers occasionally, even on the mainline 6.0 kernel, but this was even worse on the 5.10 series used by bullseye.3

I’ve spent at least some time riding the Linux distribution windmill. My previous laptop ran Arch, and that somewhat scared me off the idea of rolling releases. Using Fedora on my laptop I’ve become a fan of the six month release cycle. There’s always the chance of software breaking during major updates, and I think six months provides a good balance of being able to schedule time to upgrade so I’m ready to fix potential issues, while also not being tied to very old software releases. My opinions are subject to change as I learn.

Building a Moat

Having a home server is scary business. Usually your exposure to the internet is through a router preconfigured by people hopefully smarter than you (by default at least). I often run python -m http.server to send files, which gives anyone with port 8000 access read access to the current directory, including directory listings. This is fine behind a NAT4, but my home server is exposing services to the outside world bad things can happen.

My home server is comfortably hidden behind the NAT, which gives me the first line of defense. I do use Tailscale for remote access, but I’ll leave that as an article for another day.

Fedora has some security features that provides its own line of defense. Unfortunately I’ve found these more frustrating than helpful. First, is SELinux which was causing nginx to return unexpected 405 errors.5 I have turned this to permissive mode (for now). Next is firewalld which apparently replaces the iptables filters I hated setting up. I’m not proud to say I had to disable both of these as I’m not familiar with either and they were getting in the way. My plan is for the protective cover of my NAT (as well has per-application settings), to provide the protection I need until I can learn these systems.

One default-enabled feature I found a bit annoying is the Cockpit Web Console which is a web server that, among other things, lets you open a terminal into the system from your web browser. My general assumption setting up a server has been that by default there will only be one way to open a remote shell, OpenSSH (I do make a point of harden this system, such as disallowing password authentication). I trust the Fedora team that this is secure, but I did find it uncomfortable enough to disable for now.

Backing Up

I stated earlier that I partially use this server to backup my Dropbox files into a different service.I also make a point of backing up configuration and service data of the server itself.

On the previous iteration I used Tarsnap which I’ve, in part, carried over to the new server. But it’s tough to stand still sometimes, and I’ve recently started switching things over to restic backed by Backblaze. I think once I get more experience with the latter it will make a good article to compare. So far I’ve found them to be functionally be very similar, but it’s been a huge advantage on restic’s part that I’m not tied to Tarsnap’s backend. For reference the per GB-Month cost is $0.25 at Tarsnap, $0.005 at Backblaze and $0.023 for Amazon S3 US East. It’s completely unfair to compare Tarsnap directly to Backblaze and S3, since Tarsnap automatically replicates across many regions, but the flexibility to use a cheaper option is tantalizing. For instance, automatically replicating my Dropbox onto a local disk and a single region bucket should be sufficient, if not overkill.

  1. I’m more concerned Dropbox will arbitrarily close my account, perhaps due to a faulty copyright detection system, than unintentionally lose my data. ↩︎

  2. Starting containers without root requires slirp4netns among other things, which wasn’t too difficult all-in-all to get working but I didn’t like having so many non-distribution-supported packages lying around. I tend to find anything manually installed from source has a tendency to get out of date without me realizing it. ↩︎

  3. There are no solutions, there are only trade-offs. - Thomas Sowell ↩︎

  4. In reality I rely on the belief there’s no untrusted devices on my network to a greater extend than I should. ↩︎

  5. This was a case of reading lots of documentation before getting up for a break, whereupon stepping back the answer immediately came to me. ↩︎