These are the steps I’ve followed so far to set up my local infra. Just in case I need to replicate what I’m doing.
The goal: to run some apps accessible in my local network. Maybe file storage, definitely some sort of media server solution, and very likely custom stuff I will code and am coding.
So first things first, I set up a laptop with the latest LTS release of Ubuntu Server, because I working with Ubuntu on and off for twenty years now. Hostname chord.
I went into my home router — ISP standard issue here in the DR — and customized the DHCP server settings: addresses are dynamic between 10.0.0.2 and 10.0.0.127; they didn’t much care for RFC 1918 and made the network a 24 bit netmask. I then setup chord to use the IP address 10.0.0.128/24 instead of relying on DHCP, and set up the nameservers; this info lives in /etc/netplan/50-cloud-init.yaml. After installing it there, sudo netplan apply applies the changes.
This might bite me in the future if I have over 120 clients running at home, mostly because I will likely adjust the router to run 10.0.0.0/8 and forget to change the chord accordingly.
Before setting up the IP statically, I tried configuring the router to do it via DHCP binding the MAC address to an IP address. And failed.
Talking about chord, I had some fun editing /etc/systemd/logind.conf to ignore closing the lid instead of going to sleep.
So far so good — this is standard stuff I wouldn’t take too long to figure out from scratch when I unavoidable forget it. But then I did something I’d not done before: I set up bind9, because I want things in my house to have names.
I had some fun reading RFC 8375 – I like the evidence that people are using .home as a TLD somewhere, and that such things affect how these decisions are made. Well, it also feels very engineery, reading RFCs, and I like to do it from time to time. Thing is, my home’s domain is .home.arpa, as it should be in homenets. So I had to set up the config file at /etc/bind/named.conf.options to make the thing a forwarder for Cloudflare’s DNS, and then went on to write /etc/bind/db.home.arpa — the mythical zone file itself!
The config broke at the start, because I followed a guide too closely. A quick comparison with the setup for the local zone file (db.local) showed me the error of my ways.
This is what it looks like:
$TTL 300
@ IN SOA ns.home.arpa. admin.home.arpa. (
2025091302
300
60
3600
60 )
@ IN NS ns.home.arpa.
ns IN A 10.0.0.128
chord IN A 10.0.0.128 This is what it means:
- time to live: 5 minutes (so I’ll have frequent queries, but that’s OK, I foresee this being not much trouble on the daily and an avoided headache when customizing stuff)
- “ns.home.arpa” is the authoritative server; admin@home.arpa is the administrator” (Will I “have” to setup a local email solution to appropriately manage my zone? Time will tell!)
In the parenthesis:
- serial number for the file; YYYYMMDD## where ## is the amount of changes I made in the day; this was my second attempt.
- secondary checks time to live in seconds*
- retry for failed requests in seconds*
- time to keep the zone if no updates are received*
- and time to live for the cache of unknown domains, set to 60; this is making me itch even now, I’m about to change it.
* The ones with asterisks — I don’t know what they do, but they seem to be relevant only in case another DNS server talks to this one, so I’m happy to let them be.
After that configurational incantation, we have them actual zone records. Which only refers to chord. This is what I’ll need to update to add other hosts that will have fixed IPs and will need names. AKA other servers.
After doing this, and applying the changes with rndc reload (which errored out once because the file was missing stuff, so I fixed it) I changed the router to have the primary name server doled out in the DHCP config to be 10.0.0.128. This is the first time I’ve done this, so I made the secondary name server the classic Cloudflare 1.1.1.1.
And that’s it so far — I am afraid I’ll forget some odd obscure specific detail at some point when I’ll need it, but now I remember. And you, too, can look up RFCs and look at bind9 and toy around with the admin interface of your router (for the local telcos, the original user and password are generally taped onto the router, or else are the serial numbers. Please update that and save it into your password manager).
Coming up: Trying to set up a solution to deploy containers easily. Probably TLS will break me (aka if these things require TLS then using the local domain is out of the question because I can’t go installing a CA’s root cert in my guest’s phones so that they can connect to a local instance of whatever I’m running). In that case, I’ll just use a regular random domain and configure the IPs over there, in the universe, and tear down bind9.
Oh, but if that’s not the case! One of the first few projects will be a web interface to edit the bind9 zone config for the local environment so I can add servers as they come!
footnote: I successfully installed casaos; to uninstall I’d run casaos-uninstall.