Review: OpenBSD 3.4 SPARC64 Edition

OpenBSD is a name synonymous with security, having earned the respect and adoration of security-concious sysadmins everywhere. OpenBSD is used in data centers all over the world, is the basis for several security products (from OpenBSD’s site), and is even the basis for Microsoft’s Services For Unix.

And like FreeBSD, it’s not known for running on UltraSPARC systems. Among its many platforms, OpenBSD does indeed have a port for both SPARC (sun4/4c/4m) and SPARC64 (sun4u/UltraSPARC), and the SPARC64 port supports my Ultra 5. So in continuing with my ongoing series on evaluating operating systems running on the Sun Ultra 5, I took a look at OpenBSD 3.4, SPARC64 edition.


OpenBSD, like FreeBSD and NetBSD, exists as a 64-bit only operating system on SPARC64. And like FreeBSD, OpenBSD has no mechanism for supporting 32-bit applications. This contrasts with Solaris and Linux, where 64-bit and 32-bit binaries, libraries, and kernels live together in harmony.

My test system is of course my Sun Ultra 5, of which the specs can be found in my intro article.


If you’ve used OpenBSD, you know the installation is about as no-frills as you can get. No fancy menus, no nice and neat CD ROM ISOs, and certainly no graphics. But while it’s lacking in refinements, it’s perfectly functional, and there is excellent documentation to back it up.

erase ^?, werase ^W, kill ^U, intr ^C, status ^T

(I)nstall, (U)pgrade or (S)hell? i

Welcome to the OpenBSD/sparc64 3.4 install program.

This program will help you install OpenBSD in a simple and rational way. At
any prompt except password prompts you can run a shell command by typing
'!foo', or escape to a shell by typing '!'. Default answers are shown in []'s
and are selected by pressing RETURN. At any time you can exit this program by
pressing Control-C and then RETURN, but quitting during an install can leave
your system in an inconsistent state.

Part of OpenBSD Install Screen

You can get the install files from OpenBSD’s FTP site or one of many mirror sites. You can also order install media from the OpenBSD site. With my cable modem on the ready, I chose the download route.

The SPARC64 install tree contains a bootable ISO image for installation, but the bootable CD does not contain the actual installation files, only the installation program itself. You can either burn the installations files to a separate (non-bootable) CD, or make them available via other means, such as FTP (either locally or from a main FTP server/mirror), HTTP, or NFS.

Because of its spartan design, installing OpenBSD may be a bit intimidating for more green users, but the documentation should be able to walk most through.

Probably the toughest part of this (or just about any other) install is drive partitioning. Every operating system seems to have their own unique way of doing the same task, even among the BSDs. Mentally switching between the various iterations can get tedious, although that’s more of a general complaint, not one directed at OpenBSD.

Fortunately for me, I already had my drive partitioned from NetBSD and FreeBSD, so I didn’t make any changes. I let OpenBSD re-format the already-existing partitions and continued on.

Installation is quick, taking only about 10 minutes to get a system up and running. I didn’t run into any problems.


Although I hadn’t it in my previous reviews, I thought it important to make special note of the documentation that accompanies OpenBSD. Having a reputation for putting security above all other matters, I was expecting somewhat weak documentation.

However the documentation for OpenBSD is in fact, excellent.

It’s concise, easy to follow, and comprehensive. As I found myself pondering a question, I quickly found the answer in the FAQ. What files do I need there to be available over HTTP, FTP, etc. for install? Does OpenBSD support soft-updates? Those questions were all covered simply and succinctly in the documentation. Kudos to the team that put that together and maintains it. They’ve done an exceptional job.


By default OpenBSD runs more minimalist than a living room spread in an Ikea catalog. Here’s a ps -auxww from my OpenBSD 3.4 system:

That’s only 16 running processes; 11 if you don’t count the processes started from my login and subsequent su. Definitely a plus for security. By contrast, my Fedora Core desktop system, while waiting for a GUI login, runs 56 processes while idle mode. Pretty much the only outside services turned on in OpenBSDby default are sendmail and sshd. Otherwise, the machine is deaf to the world.

Speaking of SSH, you can thank OpenBSD for the ubiquitous OpenSSH, used in just about every *nix system on the planet. Even Sun’s commercial SSH is based on OpenSSH. A detailed history of OpenSSH can be found here.


I had assumed that like FreeBSD and NetBSD, that desktop/graphics would not be supported. That assumption turned out to be incorrect. OpenBSD does support the Ultra 5’s ATI graphics, and I was able to use this configuration file to run X windows.

As you can see, the default desktop environment is very bare-bones. It runs fvwm as the default windows manager, and Gnome and KDE aren’t installed as part of the X11 distribution.

OpenBSD 3.4 SPARC64 Screenshot running default X11 configuration with fvwm

As you can see in the screenshot, top reports only 70 MB used in memory and no swap activity. It’s easy to forget how small X11 by itself is when it’s not running KDE or Gnome or some other fancy window manager. Compare this to when the system is running Solaris with Gnome, where the disk trashs from hitting swap when I so much as move the mouse.

Setting up the desktop environment wasn’t trouble-free, however. After I installed from the serial console, I tried running startx from the serial console. I figured it’d die, but not only did it die, it actually crashed the system:

XFree86 Version 4data fault: pc=f0008fd0 addr=ffffffffffffe000
panic: kernel fault
kdb breakpoint at 129fec8
Stopped at.      Debugger+0x4:   nop

I switched from serial console to screen/keyboard and I didn’t have that problem anymore.

OpenBSD comes with xf86cfg (an X-based X configuration utility) and xf86config (text-based X configuration utility). xf86cfg wouldn’t run, and xf86config doesn’t seem to have SPARC in mind, with its lack of a Sun keyboard or mouse option, among others. So I was left without a working XFree86 configuration file. However, Google provided an answer and I yoinked a config, and X started up fine.

There are pre-built packages of the various components of KDE/Gnome but I didn’t install or configure any of them. I imagine that it would take some work to get it all working together. There are also various X11 apps available that are precompiled.

I was able to run 16-bit color (about 32,000 colors) at 1280×1024 with no problem. I also used SSH to tunnel a few remote X11 sessions, and ran apps such as Mozilla FireBird from my x86 Linux workstation.


As with NetBSD and FreeBSD, OpenBSD supports soft updates, which can greatly speed up disk operations. While FreeBSD lets you use tunefs, OpenBSD (like NetBSD) requires an edit to /etc/fstab and a reboot to enable soft updates. It isn’t enabled by default, but I would highly recommend doing so. While not all disk operations may benefit significantly, simple operations like untarring a file can be dramatically sped up by soft updates.

/dev/wd0f /usr ffs rw,nodev,softdep 1 2

For instance, untarring the ports.tar file without soft updates took about 17 minutes. With soft updates enabled on that file system, it only took 3 minutes. That’s a significant savings in time.

System performance-wise, OpenBSD (on x86 at least) didn’t fare well in a widely publicized and much embattled benchmarking article. Unfortunately I was not able to get those benchmarks running on OpenBSD SPARC64, and generally those benchmarks don’t seem to be 64-bit friendly (having compiled but died with a bus error for both FreeBSD and NetBSD on this same system). I spoke with the author, and unfortunately he doesn’t have access to a 64-bit system to do trouble shooting.

MySQL Problem

I was all ready to rave about OpenBSD, when I hit a little snag with MySQL. While MySQL compiled from source without any complaints and initially ran fine (idle, at least), I ran into a strange problem when running sql-bench, the excellent SQL benchmarking tool I’ve been using thus far.

When sql-bench came to the create benchmark, it died with the following error:

Accessing tables
Can't find file: './test/bench_60.frm' (errno: 9) at ./test-create line 137

The subsequent benchmarks after create died with similar errors. Initially I thought it may be some sort of permissions problem. The file it’s referring to does exist, but when I checked the permissions, they were all correct. I even (in a very un-OpenBSD-esque manner) chmod’d MySQL’s data directory to 777 just to make sure. Same problem, so permissions wasn’t the problem.

I initially ran sql-bench against 4.0.17, so I upgraded to 4.0.18, which is the current release. Same issue. OpenBSD comes with GCC 2.95.3 by default, so I installed the pre-made GCC 3.2.3 package. Still the same issue.

I was only able to find a single case of someone having a similar issue with a Google search.

I tried playing around with some sysctl variables, thinking perhaps it was a limit on the number of open files (there’s about 10,000 tables in the create benchmark), but kicking kern.maxfiles to 15,000 didn’t help either. I made a post to the OpenBSD sparc port mailing list (they cover both SPARC and SPARC64) and the guy who had the issue wrote back, saying he still had the same problem.

Sean Brown responded to my post with some good suggestions, but they didn’t work out either. As he suggested, I kicked kern.maxfiles up to 32,000 but still no resolution. I also made sure --tmpdir was on a large file system, and that didn’t resolve the issue either.

Since the release of OpenBSD 3.5 is imminent (May 1st), I decided to try a snapshot of 3.5 to see if that would alleviate the issue. I pulled the 3.5 snapshot from the ftp site, and it was dated March 29th. Once it was loaded up, I ran MySQL and sql-bench and still had the same issue.

The sql-bench benchmarks has the ability to run against PostgreSQL as well, so I compiled PostgreSQL 7.4.2 from source (it compiled cleanly) and ran sql-bench against it. Unfortunately, most of the tests resulted in PostgreSQL dumping core:

Retrieving data

Bus error (core dumped) 

So there goes that. I tried using ports-compiled PostgreSQL but it also died with core dumps. Given the problems I had, and the problem at least one other had, it would seem OpenBSD SPARC64 isn’t really an option for database systems at this time, even on a development/staging basis.

PCI Devices

The Intel 10/100 card I have is also recognized by OpenBSD 3.4 as fxp0, as it was with NetBSD and FreeBSD. Which gives me an idea for possibly the best use of this Ultra 5: As a relatively fast, small, and self-contained firewall.

I found another PCI Ethernet card laying around, a 3com, so for shits and giggles I installed it in my Ultra 5 as well (there are a total of 3 PCI slots available, 2 are now full). OpenBSD also recognized that automatically and it came up as interface xl0. So for about 20 extra dollars, I’ve got a perfect firewall system with internal, external, and DMZ interfaces.


OpenBSD, like FreeBSD, sports a ports collection that makes compiling and installing software simpler. It’s not quite as complete as FreeBSD’s ports, or even NetBSD’s pkg_src. For instance, OpenBSD ports didn’t have mysql version 4, only 3.23.

OpenBSD also sports binary packages (which is where I got my beloved tcsh), which can be found on OpenBSD’s FTP site.

Tidy Little Firewall

All of the operating systems under evaluation (FreeBSD, NetBSD, OpenBSD, and coming soon Linux and Solaris) have one or more options available to make the system an effective and secure firewall. FreeBSD, NetBSD, and of course OpenBSD have the ability to run OpenBSD’s pf (packet filter). They, along with Solaris, also have the ability to run IPFilter, which is what powered OpenBSD’s firewall capabilities until a very public and very nasty spat between Darren Reed (author of IP Filter) and Theo De Raadt (infamous head of the OpenBSD) over licensing issues led to OpenBSD creating its own packet filter.

Linux (2.4 and 2.6) has netfilter, which is what I currently run on my home system for a firewall/router on a dual processor x86 system.

Yet while they all have this capability, I haven’t tested them as firewalls. However, since OpenBSD specializes in security, I decided to take a look at its ability to provide such functionality.

I used a fairly typical scenario for home and office users. The OpenBSD system sits with one interface (in my case, fxp0) sitting on the DSL/Cable modem connection, and another interface sitting on an internal network running an RFC 1918 network. The OpenBSD system performs one-to-many NAT, allowing several systems to share a single external IP address such as the one assigned to the Cable Modem/DSL line (Linux users often refer to this as IP masquerading).

Typical Home/Office Firewall Scenario

I’ve have extensive experience with Linux’s netfilter and IPFilter, but none with pf. However, since pf is very similar to IPFilter in configuration, acclimating myself was quite easy.

It took me half an hour to get it working, with much of that time spent trying to figure out that it wouldn’t work because (as the instructions stated) I needed to turn on IP forwarding. Doing so is a simple command with sysctl:

sysctl -w net.inet.ip.forwarding=1 

The rest of the instruction, as well as the example pf.conf file (which I used) is can be found in the pf FAQ.

One of the big differences between how pf works compared to Linux’s netfilter is how it handles FTP sessions. FTP is a protocol notorious for being un-firewall and un-NAT-friendly, because of the two TCP ports it uses (21 for control and 20 for data).

In Linux, there are special kernel modules for handling FTP sessions through NAT, ip_conntrack_ftp.o and ip_nat_ftp.o. OpenBSD handles this by running an FTP proxy, which you can enable by uncommenting out its entry in /etc/inetd.conf (also detailed in the instructions). stream tcp       nowait  root    /usr/libexec/ftp-proxy ftp-proxy

Another difference between Netfilter and pf is the configuration syntax. I findthe IPFilter/pf-style syntax to be much more readable compared to Netfilter’s use of iptables and its rather convoluted syntax.

I’ve been running my LAN off my OpenBSD system for a few days now, and it’s been working great. Given the systems small size (less than 19 inches wide, about 2U, and more shallow than most rack-mount systems), relatively fast processor, easily expanded Etheret through the 3 PCI slots, it would make a great firewall/router. It may very well be that this system, once I’m done with my articles, ends up serving that purpose.


Speaking of hardware, I thought I’d respond to many comments, both in general and in reference to my articles, about the Ultra 5 being a shoddy piece of hardware. They liken it to PC construction, flimsy and plastic and generally undeserving of love and affection.

Actually, its engineering is superior to most PCs. While it’s not up the quality of say an old SPARC 5 or a NeXT workstation slab/cube (possibly the most elegant hardware ever produced, I used to own a color turbo slab), it stands heads and shoulders above the quality of your average Dell or Gateway PC. It even tops much of Sun’s current top-of-the line hardware, with their superfluous plastic adornments, GNDN (goes nowhere-does nothing) tabs, and razor sharp innards (seriously, the only thing modern Sun servers are missing are rotating knives inside).

The inside is well put together and the design well thought-out, the hard drives are your average IDE fair, holding up well under the rigors of time. The size fits great in a standard 19-inch rack as a 2U system on a shelf, and stacks well. The backend ports are easily accessible and their placement is well thought out.

However, a very ligitimate complaint about the Ultra 5s hardware-wise is its oft-maligned IDE controller, which is notoriously slow and buggy. Now that does indeed suck.


Despite the fact I couldn’t seem to make this system a viable database system (with either PostgreSQL or MySQL), OpenBSD turned out to be a very useful system, especially as a firewall.

The combination of excellent documentation, ample pre-compiled binaries, good ports system, and plenty of resources make OpenBSD worthy of serious consideration when exploring operating systems to install on an Ultra 5.

Appendix: dmesg.

If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.


  1. Panna 2004-04-29 7:38 pm EST
  2. Gabriel Ebner 2004-04-29 7:59 pm EST
  3. Jason 2004-04-29 8:31 pm EST
  4. mike frantzen 2004-04-29 9:06 pm EST
  5. bsdrocks 2004-04-29 9:20 pm EST
  6. Ray 2004-04-29 9:36 pm EST
  7. dpi 2004-04-29 10:37 pm EST
  8. richardtoohey 2004-04-30 1:23 am EST
  9. cybrjackle 2004-04-30 2:38 am EST
  10. cybrjackle 2004-04-30 2:43 am EST
  11. Christopher X 2004-04-30 3:49 am EST
  12. blah 2004-04-30 4:21 am EST
  13. BSDero 2004-04-30 4:44 am EST
  14. Brian P 2004-04-30 4:47 am EST
  15. Anonymous 2004-04-30 5:32 am EST
  16. dpi 2004-04-30 1:13 pm EST
  17. Anonymous 2004-04-30 1:16 pm EST
  18. cybrjackle 2004-04-30 1:45 pm EST
  19. SFN 2004-04-30 2:06 pm EST
  20. Anonymous 2004-04-30 4:05 pm EST
  21. Anonymous 2004-04-30 5:28 pm EST
  22. Panna 2004-04-30 7:52 pm EST
  23. thoren 2004-04-30 8:59 pm EST
  24. TonyB 2004-04-30 9:01 pm EST
  25. coolvibe 2004-04-30 10:58 pm EST
  26. TonyB 2004-05-01 8:34 am EST
  27. Wrawrat 2004-05-01 2:20 pm EST