OpenBSD 4.5 Notes

25 November 2009
For quite a while I had been thinking of giving OpenBSD a try, and following a chance acquisition of a Sun Ultra 10 it seemed like a good opportunity to do so. The notes below are a bit disjoint (and in 1 or 2 places possibly outright wrong) as it was written as I was trying stuff out, and it concentrates on things either specific to the Sparc64 port or not mentioned in OpenBSD 101. A strong background in Linux and completion of initial installation using instructions at OpenBSD 101 is also assumed. My opinions of OpenBSD are given as conclusions at the end.

Booting from CD on an Ultra 10

Sparc systems use OpenBoot. In short you get to the OpenBoot prompt by pressing Stop-A, and boot from the CD by using the boot cdrom command .

Installing Bash

You will want to install Bash and make it your shell ASAP:

pkg_add -v chsh -s bash

.bashrc not being executed

At least on BSD (and some Linux distributions) ~/.bashrc is not run for login sessions (non-login sessions is when you type 'bash' again, or bring up an xterm). Instead, .bash_profile is run. I took the lazy option:

ln -s .bashrc .bash_profile

Installing other useful utils

The pkg_add command happily takes both filenames and URLs for package files. If the filename is not in the current directory, it searches PKG_PATH. Easiest thing is to set PKG_PATH to a local OpenBSD package mirror then forget about it. The uname backticks fill in the version number (4.5) and architecture (sparc64) for you.

export PKG_PATH=`uname -r`/packages/`uname -m`/ pkg_add -v pico wget lsof fileutils

As can be seen I also install pico, wget, lsof, and fileutils:


I've never liked Vi, so installing Pico is usually an early call. May also want to make it the default editor:

export EDITOR=/usr/local/bin/pico


Useful for downloading stuff like source tarballs. When setting up boxes over SSH (particularly ones at a different physical location), I prefer to cut'n'paste URLs and download direct, rather than downloading to my local machine then uploading via SCP.


Unlike Linux (which has netstat -pa --tcp), the OpenBSD netstat command does not have a parameter to list the process that is bound to a socket. Instead you have to use the lsof command that lists open files (for some reason this gets installed into /usr/local/sbin which might not be in the default $PATH):

lsof -i

GNU fileutils

This includes what under FreeBSD is known as gnuls. It is the GNU (i.e. Linux) version of various file utilities (rm, ls, chmod, etc), each appended with a 'g' to distinguish them from the BSD versions. The GNU version of these tends to be nicer, such as ls allowing parameters in places other than as the first entry:

ls -l ~ ls ~ -l

With the standard BSD ls, the second line treats "-l" as a file. If you want to use the GNU utilities, you can alias the commands (e.g. for ls):

alias ls=gls

Updating packages

pkg_add -u

OpenBSD packages & ports

With BSD, packages refers to pre-compiled binaries, whereas the ports system in a way of installing programs from source; the latter works by having an entire directory tree, and to install a specific program you go into the relevant directory, and the makefile downloads/builds/installs the program for you:

cd /usr/ports/misc/fileutils make fetch make build make install

In OpenBSD packages & ports seem to be a single seamless system: the ports system is used to build packages, which in turn are then installed using the package system. In particular dependencies are handled correctly, regardless of whether the package is downloaded or built from ports. This is on contrast to the disaster I faced with the FreeBSD package system, which I ended up shunning in favour of only using ports. Admittedly that experience was 2 and a half years ago..

Setting up OpenBSD ports

Although it is possible to grab the entire ports tree from CVS, it is better to start off with a snapshot; CVS is a bit sluggish even when there is only a relatively few files to update. Took a bit of digging to find a list of OpenBSD CVS repositories, and annoyingly none are UK-based:

cd /usr`uname -r`/ports.tar.gz tar -xzf ports.tar.gz cd ports cvs -q -d up -r OPENBSD_4_5 -Pd

The ports tree can also be updated using cvsup (described below, but in the context of system updating), but there seems to be even fewer cvsup servers than anonymous cvs servers.

Updating OpenBSD (kernel, etc)

For this I (mostly) followed the instructions at OpenBSD-101. Only difference is that i used /usr/src/sys/arch/sparc64/conf/ instead of /usr/src/sys/arch/i386/conf/, and I installed csup (a cvsup drop-in replacement) instead of cvsup, as cvsup is available for i386 only. I also omitted the -g (seems to be silently ignored with csup) and -L 2 (default verbosity is enough for me) parameters. As with ports.tar.gz above there is also a src.tar.gz, but i suspect it is not worth the possible complications (an expanded /usr/src is about 610MB).

Mounting a CD (as root)

Both /dev/cd0a and /dev/cd0c seem to work fine. I suspect both are present to maintain consistency with BSD's partition naming scheme.

mount /dev/cd0a /mnt

I prefer to setup fstab so that I can (un-)mount a CD by only specifying the mount-point (in my case i have a preference for /mnt/cdrom):

mkdir /mnt/cdrom echo "/dev/cd0c /mnt/cdrom cd9660 ro,noauto,noexec 0 0" >> /etc/fstab

Mounting a CD as non-root

I never got this working properly. By default OpenBSD only allows root to mount anything, and it looks like it is designed to be very difficult to change. Various commands I used include:

sysctl kern.usermount=1 usermod -G operator remy chmod g=rw /dev/cd0?

I had successfully mounted a CD manually under ~remy/cdrom as non-root, but attempting to unmount it hard-locked the system. This is a major bug as far as I am concerned, so I did not bother reading up on (bad or otherwise) side-effects to adding users to the operator group. I also didn't bother looking into suid root scripts to to the mounting/unmounting.

Init scripts

The start-up scripts are somewhat minimalist, even by Slackware's standards: Services are started as individual cases in the monolithic /etc/rc, depending on whether the relevant flags in /etc/rc.conf are set to "NO" or to the command options for the service. This is nice as the last thing you want to do when setting up a server remotely is guessing where you are supposed to put the start-up call for custom-built daemons, which is my big complaint with SysV init scripts that most Linux distributions use. However it means there aren't any scripts under /etc/rc.d/ for manual startup/shutdown of specific daemons, although adding them would be fairly easy.

In contrast FreeBSD has a rather elaborate system that has individual start-up scripts (like Slackware), but also complicates things by having service start-up dependency resolution. This results in the individual start-up script templates being more complex than they need to, with the effort of learning the script layout exceeding the effort needed to sort out any daemon dependencies manually. This is particularly acute when installing daemons from tarball, and they come with their own startup/shutdown scripts.

The flamebait bit

When trying out OpenBSD it was with some (probably misremembered) irritations from my previous FreeBSD try-outs in mind, in particular the train-wreck that was mixing FreeBSD'd package & ports systems. In this respect, I took an early liking to OpenBSD.

FreeBSD's init scripts seemed a bit baroque for my liking; however OpenBSD's in contrast is a bit spartan. I think it is the intention of OpenBSD that anyone who wants anything sophisticated can add it themselves, and I would be tempted to transplant a cut-down /etc/rc.d/rc.inet2 from Slackware Linux.

The only automated way of doing a system update involves recompiling everything, and this takes a looong time (circa 12 hours on my Ultra 10). The alternative is to apply patches by hand, but I am not sure if this can be mixed with the automated approach, and I suspect there are cases where it still does not avoid a full recompile. This is a real killer, which is only mitigated by full-rebuild fixes being rare.

Since Theo has labelled securelevels "useless" I didn't bother trying them. Locking down root enough to stop rootkits being installed but providing an elaborate way for genuine admins to get unrestricted access would be difficult, so they are of borderline practicality for headless servers

On a related note only allowing root to mount CDs is a case where security actually impinges on usability, though in my case it is a minor annoyance.