Going Online

This morning it occurred to me that it’s time to take the site online, as in expose it to the internet. I’m comfortable enough with my security, the main reason being that I don’t expect many, if any, visitors to this site. While the domain will be publically accessable, it’s not going to be widely promoted. If that day ever comes, it’ll be easy enough to move this WordPress installation to another machine.

So while I won’t do a complete how-to or anything like that, I do think it’s worth noting how the system works. It’s an experiment, after all, I think it demands a bit of notation.

dumbleigh.com in all of it’s glory

There are two Raspberry Pis running the show. An 8gb runs Docker, and features the following programs:

  • Pi Hole
  • Grafana
  • Vault Warden
  • Caddy
  • Nextcloud
  • Owncast
  • Wireguard

Since all of these applications are “on-demand” as in don’t do much in the background and generally don’t run at the same time. All of the Docker containers are managed from Portainer.

The second Pi runs only WordPress, again in Docker/Portainer. There is no reason that WordPress couldn’t run on the 8gb Pi with the other junk, but something told me that it might offer some safety benefits to hosting WordPress from a different server. Also, if the site ever gets any traffic, I’ll truly know the Pi’s limit if WordPress is the only thing running.

Speaking of security, I’ll just provide some basic details as I feel like exposing my internal network is, if nothing else, a new risk to me. Basically, I have the router locked down as much as possible. I have my DDNS through Google, also where my domain is hosted. I have all of the publicly accessible pages reverse-proxied with Caddy. Caddy also handles the SSL. Fail2ban is also working in there, somewhere. There are also a few countermeasures installed on WordPress, mostly focusing on limiting login attempts.

There is one final computer in the mix, it runs only Jellyfin. Again, I think that the original 8gb Pi could run everything, but I have solely bluray rips, about 30% of which are 4k. I had some issues initially setting up the server using Ubuntu; I couldn’t get Jellyfin to recognize the drives no matter what I did. I found others on the internet who also had the same issue and I was never able to find a fix. I’m not completely happy with the situation as I didn’t exactly pay for Windows, and so I am forever watermarked. So here are the stats of the Windows server:

  • Intel I5 10400 (6-core @ 4.3ghz)
  • 32gb RAM
  • 256gb SSD
  • 2 x 12TB HDD
  • Nvidia 1060 3gb

There are a range of opinions on what sort of hardware is really necessary to run Jellyfin. One camp says Jellyfin can run smoothly on basic hardware, so let your client direct play the media. Unfortunately, none of my clients seem to want to play anything that way, at least not using the Jellyfin app (Android, GCCWATV, browsers). I’ve had limited success with Kodi, but I find Kodi cumbersome and we’ve never bonded. Another idea is to have powerful enough hardware to transcode on the fly. That’s the path I’ve taken, mostly because it makes the most since time-wise. 4k videos take forever to transcode. For instance, one video had my desktop I9-12900 with RTX3080 at 100% and it was transcoding at about 15fps. I have a feeling that part of the issue is Handbrake as I have had better luck with Tdarr. For what I’m doing, 4k transcoding on the fly make much more sense.

There’s the basic run down. I started this project about two years ago and it’s been up and down, with some portions (Nginx/Caddy) taking much longer than they should have to figure out. The current goal is to get to know the current setup, and making sure that WordPress is functioning as intended. In the future, it would be nice to selfhost my professional website. Security education is also a priority; I don’t think that I’m going to be a target anytime soon, but I’d like the system as locked down as possible. This project has been super challenging, but it’s so fulfilling to see all of the hard work come together.