Come for OpenBSD, Stay for Compilers

2024-04-18

---

After sharing the beginning of my journey with OpenBSD last night, I received some very helpful and encouraging e-mails, including excellent resources. Thank you, Gemini, for all your help!

I must confess that OpenBSD's installer intimidated me, at least initially. I've deployed a lot of Red Hat machines and am frankly used to a GUI. I was unsure how best to navigate configuring network settings over a command line alone. However, the installer is very easy to follow, and I quickly picked up on the flow.

OpenBSD is lauded for its efforts to make the base system secure, simple, efficient and easy to configure. I am happy to say that it's earned its reputation. I was stunned at how easy it was to update the base system, apply patches, install new packages, and even configure services. rc is much less of a pain to manage than systemd, and even configuring WiFi--a task that can turn into a nightmare on Linux--could almost be done in one line.

The amount and pertinence of OpenBSD's documentation is outstanding. Linux man pages can often be quite lacking, with little to no example usage and sometimes not even including all the options and configurations. I know GNU tools cover these things more thoroughly with info, but I don't use emacs, and I find info to be a little confusing. OpenBSD's man pages left me with almost no need to reference anything outside the system. Had I needed to configure everything with no Internet, I likely would have been able to do it.

But enough gushing about OpenBSD. The real adventure began when I decided to compile a few programs on the system.

I use yggdrasil to build a private IPv6 network to connect my devices to each other, and I use NNCP to send data and execute commands between them asynchronously. yggdrasil is available as an installable package in OpenBSD, but I decided to compile from source so I could have the latest version. The source, written in Go, compiled with no problems, and writing an daemon script for rc was almost trivial, taking far fewer lines than a systemd service file.

NNCP was a much tougher nut to crack. The first issue I ran into was with dependencies: the NNCP 8.10.0 tarball contains a version of gvisor from April 2023, which is not compatible with go 1.22--the version available in OpenBSD's repositories. I got around this by cross-compiling NNCP on my Fedora desktop, which has go 1.21, and moving the binaries to the OpenBSD laptop.

Simple utilities like nncp-cfgnew worked, but after setting up my config directory, nncp-exec failed to create a packet. The specific error message came from the OS as opposed to NNCP: "Unknown symbol 'syscall'". It turns out that in November 2023, OpenBSD removed indirect syscalls from libc and the kernel!

It seems I can get around the syscall limitation by compiling the NNCP binaries to be statically linked. go does this by default, but certain common modules cause the build process to switch to dynamic linking, and that's what NNCP does. I monkeyed around with the build script included with NNCP for most of the afternoon, trying to get the compiled binaries to use static linking, but I've had no success so far. I don't know go well enough to tell which module is the culprit, and it's possible that I can't compile NNCP without using dynamic linking.

I've had this OS on my ThinkPad for less than 24 hours, and I've already learned much more about compiling programs than I've learned in the last half-year on Linux. My journey with OpenBSD is shaping up to be an interesting one.

---

Up One Level

Home

[Last updated: 2024-04-19]