OpenBSD is one of the three major free Berkeley Software Design Unix derivatives, the other ones being FreeBSD and NetBSD. Unlike Linux, which is a kernel with a userland bolted on, the various free BSDs are complete operating systems, each with their own area of strength.
One of the goals for the OpenBSD project is to try being the most secure operating system. The OpenBSD developers say the open software development model allows them to take a “more uncompromising view towards security than other vendors are able to”. To this end the developers have been auditing OpenBSD components on a file-by-file basis since 1996, and continue the process to this day.
Not saying that this is a fail-safe process, but the results speak for themselves: apart from a single security hole in SSH, there have been no breaches in the default OpenBSD installation for eight years.
Another benefit from this paranoid approach is that the OpenBSD doesn’t assume that everyone using the OS is a security expert. OpenBSD ships in a “secure by default” mode, with no non-essential services running when it fires up. For some, it can be a bit annoying having to manually start up the services you need, but this approach has obvious security rewards and even Microsoft is now going down this track with Windows Server 2003.
I tried out versions 2.6 to 2.8 some years ago and wasn’t all that happy with them. I felt that compared to FreeBSD and, for that matter, Red Hat Linux, OpenBSD was too awkward to be usable.
With that in mind, I was surprised how slick version 3.5 is. The installation is text-based with the trickiest bit being the disk partitioning but it’s not hard as long as you take a few minutes to read the very good instructions for setting up OpenBSD. The defaults are sane, and there’s very little you need to do apart from saying “yes” to the majority of the prompts.
What’s nice about OpenBSD is that the default kernel covers just about every hardware set-up, at least on x86, so there’s usually no need to recompile. In fact, if you do recompile, the OpenBSD team explicitly states that you’re on your own, so don’t go crying for help if things break – you’re likely to be laughed off the mailing list.
For me, the main reason to deploy OpenBSD was the “pf” packet filter. This is a very flexible tool for filtering and managing IP traffic, and it also happens to be programmable by mere mortals. If you’ve ever had a go with Linux “iptables”, you’ll know what I mean here.
By and large, I was able to set up a firewall/router by simply reading the very complete OpenBSD manual pages. Well, OpenBSD specialist Nicholas Lee in Wellington helped clean up the rules a bit, but the whole process was refreshingly painless and quick.
As OpenBSD can be fed a meagre hardware diet, it’s popular as the OS for embedded applications. Nicholas works with these things, similar to the small low-powerSoekris Engineering devices where you load the OS onto CompactFlash storage.
This brings me to one part of OpenBSD that could in my opinion be better: patch management. Currently the OpenBSD team issues patches in source code format only, and you have to compile new binaries. It’s not difficult, but binary patches would be better for those situations when you don’t have development tools installed – a likely scenario when working with embedded devices like the Soekris ones. Binary patching is also faster; not an unimportant concern today.
However, as the case often is with open source, a quick Google turned up unofficial solutions for binary patching likebinpatch.
OpenBSD isn’t an operating system for the masses by any means, but if you want a fast and secure platform for network-oriented tasks you could do an awful lot worse. Buying OpenBSD CDs and T-shirts helps fund the project. Otherwise, the New Zealand mirror is at Citylink in Wellington (ftp.citylink.co.nz/openbsd ). Saarinen is a Computerworld reporter. Send letters for publication in Computerworld NZ to Computerworld Letters.