Tutorials

Over the past few days, I’ve been messing around with moving some of my self-hosted services off of cloud providers, and onto my home infrastructure. While my home infrastructure may not be as reliable as the cloud providers, it’s nice to know my data is in my control. I’ve always been a uncomfortable just aiming DNS at my home IP, and poking holes in the firewall. This post details a couple of methods for hosting Seafile using Tunnels to better protect my home IP and the server.

1. Cloudflare Tunnels
2. VPS + Tailscale

I’ve recently started using the overlay network Tailscale to provide connectivity between my various machines, regardless of where I am. It’s extremely easy to configure and “just works”. Tailscale also includes a feature called MagicDNS that provides name resolution for machines on my tailnet (i.e. so that ping server123 magically just works). MagicDNS also allows you to override local DNS settings and force a custom DNS server for name resolution machines on your tailnet. This post documents the setup of Pi-hole (accessible only to machines on my tailnet) to provide some level of DNS privacy and Ad Blocking for machines on my tailnet.

Every six months or so, when the position of the moon is just right, I flip-flop on the privacy/self-hosted vs. just-let-Google-handle-it issue. Today, I’ve flopped toward privacy and self-hosting.

As part of my COVID friendly game project, werdz.ca, I’ve been working with GoLang, Create-React-App, WebSockets and NGINX (for production). Some of it has been “an adventure”.

This post is a set of quick notes about the problems I’ve encountered and how I worked by them.

I’m setting up a new Ubuntu 18.04 server and wanted the drives to be encrypted. Since the machine is headless in my basement, however, entering a password on boot is annoying.

We used to run a development blog for work. We wanted:

1. To use NGINX to host this content. It was all static pages.
2. To limit access to people within our network, or to employees while outside the network (phones, laptops, etc.).
3. We didn’t want to deal with user accounts, active directory, etc.
4. We wanted super low friction for users.