Dave's OpenBSD Blog 5. Tour conclusion

The two kernel chapters are given in order of the most likely needed kernel configuration changes to the least likely: sysctl, config, building a custom kernel.

First, I enjoyed running the recommended dmassage package for viewing the device tree from the startup boot messages from the kernel.

Then I explored making changes to (and viewing) the running configuration ("system controls") with sysctl. As always, this may be cryptic, but it’s well organized. The advice in this book seems very good and I have to assume it’s still relevant. Check manpages and /etc/examples/sysctl.conf for parameters to change (especially the manpages to find out why you would change these and what the valid parameters are.)

Secondly, I read along to understand how you would use config to edit the kernel binary to change parameters that cannot be altered while the system is running. I think it’s wild that you can do this, but it’s a very clear and simple system. I love that the kernels are just binary files at the root of the file system and that you can boot them specifically at the boot> prompt on startup (or even configure them at startup!)

Finally, building a custom kernel is clearly not something you’d want to actually do (as folks often do with Linux). Michael Lucas has some really funny writing in these kernel chapters. Especially this one.

Chapter 20 is an excellent summary of the OpenBSD release cycle, which I found very helpful. I’d read some of this online before, but the book presents it all in an especially cohesive manner (and includes actual advice, which is often absent from official documentation).

Thankfully, it’s taken me so long to get to this part of the book that my installation(s) of OpenBSD were for 7.1 and 7.2 has come out. So I was able to follow along for the upgrade process.

Here’s the 7.2 upgrade guide. Excellent documentation!

https://www.openbsd.org/faq/upgrade72.html

On the laptop, the unattended upgrade was wonderfully unexciting. It just worked. I love it.

Similar, but slightly more exciting was my "cloud" virtual server upgrade, which looked like this:

At that point, the web server and SSH connection went offline for a bit. What was really cool was that I was able to log into my Vultr account and watch OpenBSD complete the upgrade and reboot via a virtual console. Once it was done rebooting, everything came back and just worked.

I finished the upgrade with the recommended sysmerge and pkg_add -u commands.

You’d hardly know anything happened, but here’s the new kernel version proving it did:

So PF is yet another thing that has come from the OpenBSD and taken over the world.

People always tell you not to reinvent the wheel.

With MS and Apple, you have to use their wheels.

Linux runs whatever wheels it can find.

Over in OpenBSD land, they fix the broken wheels…​until they have time to make better wheels. And it works! The OpenBSD wheels are better!

As a wheel reinventor myself, I’m a huge fan of the OpenBSD model. OpenBSD is why we can have nice things!

Anyway, I’ve heard about PF for a long time. As always, Wikipedia has a nice summary of PF (wikipedia.org).

PF was written for OpenBSD and released in 2001. It has been ported to other OSs, but it lives in the OpenBSD kernel and that’s where you’ll find the most current version.

The two chapters in Absolute OpenBSD are an exellent introduction to the topic. I only played with the logging and state viewing tools, so I can’t say how current the configuration documentation is other than what I found on my (now) 7.2 system was all explained by these chapters, so it can’t have changed too much!

I’ve often considered putting a multi-homed BSD box (probably one of those fanless Celeron single-board computers) into my home network and trying my hand and filtering. But that’s a big task and I’ve slowly learned over the years that real system administration, especially networking, is just not my favorite way to spend my time. I like knowing how it works, but TCP/IP is deep and I’m well aware how surface-level my knowledge is.

The custom installations chapter and the afterward are both throwbacks to a time I can identify with: the early and mid 2000s. So many of us learned network administration by just barely learning enough to support our fledgeling Web applications. And hardware has come a long, long way…​while still remaining weird and horrible. :-)

Lucas’s tale in the afterward out-shocks any of mine. But I recognize it all the same.

You never forget the vendors that let you down when the going gets tough. And you never forget the FREE software that saves your butt when all else fails.

First of all, Absolute OpenBSD 2nd Edition by Michael W. Lucas is excellent. I wish this book existed for Slackware Linux. (The "Slackbook" exists, but it’s way more out of date than this.)

As for OpenBSD itself, I think it’s really important to understand what it’s for, for you.

For me, OpenBSD seems like a really, really great option for anything I intend to use with minimal interaction - in an appliance-like fashion. Especially using only the official packages.

Going forward, I would like to convert ratfactor.com over to an OpenBSD instance. I like the idea of using mostly static files and some FastCGI with the httpd that comes with OpenBSD and knowing that the box can just sit out on the Web safely for years and years without trouble. Performing an upgrade today on bare metal hardware and a virtual instance has given me a lot of confidence in that process.

(Slackware has also been very trouble-free, so I have absolutely no complaints about that. But in the back of my mind, I’ve always felt like it was a matter of time before my "hands-off" approach to security would haunt me.)

I would also like to try using PF on the local network. And a local DNS server. But that may or may not happen. I have other interests that are more appealing to me at this time.

For me, OpenBSD is not the work desktop or hobby desktop I need or want.

For work, I often have to run crappy software that is easier to get going on Linux. That’s out of my control.

For my home/hobby use, I like experimenting with weird software development and Linux makes that a first-class experience. Specifically, the Linux support of a stable ABI (syscalls that use specific registers and syscall numbers) means I can write experimental languages like Meow5 in assembly without having to link any system libraries or include any C headers. And, Linux lets me, gasp, write to and execute the same memory segments. Naughty fun!

OpenBSD specifically disallows these things for perfectly good security reasons. I don’t want to run weird experimental languages on my main Web server. OpenBSD is a good choice there, but not on my assembly language experiments laptop.

Like I said, I’d like to convert over to an OpenBSD web server. To properly do that, I want either a local hardware or virtual instance of OpenBSD that I can test the website and all upgrades on.

I have that Vultr virtual instance already. And I certainly have an old hardware machine sitting around here that isn’t doing anything useful at the moment. So my next adventures may be in converting my CGI applications to FastCGI (?) and trying to get my hardware to do WoL (Wake on LAN) so I don’t have to have that old hardware running 24/7 to test my website (though if I have to go in the basement and hit a power switch now and then, that’s not gonna kill me either).

Thanks for joining me on this journey in 2022 and I’ll post more to this blog in the future as I continue my OpenBSD adventures!