[nolan@nprescott.com] $>  cat blog archive feed

OpenBSD, Up and Running

2018-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.

Why OpenBSD?

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

SSH Annoyances

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 website 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 capable enough. ssh allows jumping through a server as a way of leap-frogging these kinds of connection difficulties, all you need is the -J flag:

$ 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.

Nameserver Configuration

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: 173.199.124.14).

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, ssh 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 doas as compared to sudo under Linux. I've found that it's not been an issue that doas doesn't support the kind of fine-grained permissions configuration that 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.

Next Steps

The immediate next step after installing the operating system is to run 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 v4.

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.

Yak Shaving

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 self-described "scutil kludge". In the midst of all of that, I got side-tracked with the following:

IPv6 Certification Badge for nprescott

  1. To quote RFC 6147 on the subject
[nolan@nprescott.com] $> █