OpenBSD, Up and Running2018-12-16
After a very long week at work, I haven't had it in me to try and catch up on this year's Advent of Code. Instead, I spent the day reading my copy of Absolute OpenBSD and test driving things on a new server.
Having spent only a few days with it, one thing I am finding is that it feels more like a "coherent whole" of an operating system rather than kernel + everything else. This gives me some hope that I can figure out not just the "how" of my problems but the "why" as well. Administering a small-scale Linux machine for a while, I've sometimes felt like the OS is a big bag of potential solutions and I never know which is the right one. There seems to be less room for interpretation with OpenBSD.
While it is a little out-there in terms of mainstream operating systems, I don't doubt I could make a case for putting it on a resume (not so much the case for Haiku). The focus on correctness not just in the kernel but throughout the OS is refreshing in a field where "just ship it" is not always a joke.
Finally, I'm just charmed with the website aesthetic.
OpenBSD on Vultr
I've mentioned before that I moved to Vultr for VPS hosting, they offer an OpenBSD image for deployment which makes it easy enough for me to commit a day without overburdening me with things I care less about (like "how do I upload a custom OS to my hosting provider?"). Also interesting, at the $2.50 tier that I use, Vultr is out of IPv4 address space, so you can only get a VM with IPv6. This is something I've been meaning to look more into, having been bitten lightly by some of IPv6 at work in the past. The known/artificial limitation is just interesting enough to hold my attention without being insurmountable.
Generally speaking, the machine image has a sensible configuration. I put this down to OpenBSD moreso than Vultr, I don't know that I agree with the partitioning scheme as it seems to run contrary to much of the advice in Absolute OpenBSD.
iowa$ mount /dev/sd0a on / type ffs (local) /dev/sd0d on /usr/local type ffs (local, nodev, wxallowed) iowa$ df Filesystem 512-blocks Used Avail Capacity Mounted on /dev/sd0a 36320508 4103736 30400748 12% / /dev/sd0d 4334652 128200 3989720 3% /usr/local
The first hurdle that was not very exciting is finding that my home
internet (through Verizon), is not yet IPv6-ready. I'm pretty sure
Verizon has had IPv6 "in testing" for about a decade, so it should be
here real soon now — like their
say, "Check back for more information". Not for nothing though,
Vultr is pretty good about IPv6 and the server I host this site on it
ssh allows jumping through a server as a way of
leap-frogging these kinds of connection difficulties, all you need is
$ ssh -J nprescott.com -o "HostName 2001:19f0:5:2ab3:5400:1ff:fecd:b22f" some-name
To directly address the IPv6 address without a hostname I had to dig
into the options flag (
-o), weirdly, the "name" is required but
unused. The real fix here is to get a domain name for this server.
To do that is not so different from how I originally configured things with my domain name server:
Record Type: Name: Hostname: CNAME * nprescott.com.
I actually have a wildcard against the subdomains of nprescott.com, so that you can try navigating around to all sorts of fun addresses — perhaps: http://i.cant.believe.its.not.butter.nprescott.com, even if I haven't yet got my next big project setup there yet, the nameserver correctly directs to my webserver (currently at: 18.104.22.168).
For this particular case, I'd like the nameserver to carve out a subdomain and direct it to another server entirely. I accomplished this with a AAAA Record:
AAAA iowa. 2001:19f0:5:2ab3:5400:1ff:fecd:b22f
The AAAA record "wins" in specificity over wildcarded names in this
case. The name is
iowa because, well, I am terrible at naming
things. The intent was for your bog-standard nerd fandom oriented
scheme, fantastical people, sci-fi places but as soon as I'm under the
gun the only place-name I come up with is
iowa. But it's fine,
is much cleaner now:
$ ssh -J nprescott.com iowa.nprescott.com
The above ssh's to
iowa.nprescott.com "jumping" through
nprescott.com to get there.
A Security Mindset
One interesting difference in getting started was stumbling over
as compared to
sudo under Linux. I've found that it's not been an
doas doesn't support the kind of fine-grained permissions
sudo does and I like the idea of a smaller
"surface area" from which to escalate privileges. Things mostly just
work as expected without any real changes to how I do things. The idea
of frequent audits of the codebase for both security concerns and
correctness is deeply impressive to me. I recently watched Todd
Mortimer's talk on Removing ROP Gadgets from
OpenBSD and was
simultaneously struck by how pragmatic the solutions were, and
concerned that everyone isn't doing this sort of thing.
The immediate next step after installing the operating system is to
syspatch in order to apply
patches to the base system. One hiccup with this was that attempting
to do so resulted in failures, specifically, "cannot assign requested
address". Several of the default mirrors do not yet support IPv6, I
found https://cloudflare.cdn.openbsd.org/pub/OpenBSD/ to work for the
near term. Longer term, in order to support the wide world of IPv4 on
an IPv6-only machine I think I need to configure both DNS64 and NAT64,
to achieve address translation from v4 servers, "synthesizing AAAA
records from A records"1 and then translate v6 packets to
My current hiccup in this plan is that the only machine I have running a dual-stack network is the aforementioned linux machine that hosts this site. I'm still in the process of wrapping my head around how to properly configure both DNS64 and NAT64 on one server for use only by my new OpenBSD machine. I have a suspicion that the answer might be a VPN between the two. The real shame here is that this sort of thing is the bread and butter of OpenBSD and I'll instead have to do it all on my linux machine because it's the only one with IPv4 support.
I actually set about "fixing" my IPv6 woes on my home network via a
Hurricane Electric tunnel. This lead
to a few minor improvements and even more problems. I can now reach
IPv6 addresses directly, but hostnames don't resolve because mac os
doesn't set the appropriate flags to request AAAA records on userspace
network tunnels. The only promising suggestion I found has been is a
kludge". In the midst of
all of that, I got side-tracked with the following:
- To quote RFC 6147 on the subject