My history with OpenBSD

I received an e-mail asking me how I got started with OpenBSD, so I thought I'd write the answer here in case anyone else wanted to read it.

I started using OpenBSD in 1998 (version 2.3 or 2.4) to host a BBS that I was running. I chose OpenBSD because of its security record and because I was getting fed up with Linux (Slackware) at the time. I think the machine was a Pentium 75 or something, and OpenBSD worked quite well on it. During the course of building the BBS, I had to install some 3rd party software, so I got interested in OpenBSD's ports system to make installation of that software cleaner. I submitted some ports to the ports@ mailing list and got them committed by other developers. I tested others' ports and supplied feedback where I could. I hadn't done much unix development back then, so writing simple makefiles for ports was an easy way to get involved.

In early 2000 I also started running the rt.fm OpenBSD mirror and donated some hardware I had available to some developers. I was working at an ISP at the time so I had free bandwidth available. I also started pushing to run OpenBSD on our servers at the ISP to replace Linux and eventually most of the OpenVMS servers we had in production. Many Linux distributions at the time had awful security and installed tons of crap that was never used, so OpenBSD's minimal installation was very appealing as a server platform.

Aaron Campbell (aaron@) had sent out some patches for testing that fixed some things on my Sony Vaio, so I was in contact with him quite a bit. At the time I was spending time in the #OpenBSD IRC channel which made it easy to interact with Aaron and some other developers. I think that IRC channel has since moved to a silc server somewhere, but I haven't been in it in a long time.

In 2001 I answered a request for someone to start writing the portsplus web pages on the OpenBSD website. It was a boring and tedious job, but I wanted to help out so I maintained these pages until 2005. For the first few months of this, I was sending my updates to naddy@ who committed them for me because I had not yet been given commit access.

I got commit access in August 2001 by recommendation of Aaron who mentioned my previous ports work, driver testing, and portsplus maintainership. Shortly after getting commit access, I started looking at the source code of various things in the tree. I hadn't much C development experience, but the OpenBSD source code is pretty easy to follow. My first work was in the kernel making wscons auto-attach USB keyboards to the console (a one-line change if I remember correctly), then adding a powerhook to the yds audio driver to support suspend on my Sony Vaio.

My various contributions to follow were mostly based on things I ran into while using OpenBSD for myself. I have been using it as my primary operating system on my laptops and desktops since 2000. Being immersed in it all day means you get fed up with and inspired to change things that don't work, and when you're responsible for maintaining production servers that run on it, you can't just throw your hands up and assume someone else will fix things.

For example, in 2004, the login_radius BSD authentication module that we used on our servers at the ISP didn't properly failover when our primary radius server went down. I looked at the code and figured out that it was not using the backup server properly, so I committed a fix for it.

We had also installed an OpenBSD server to sniff our upstream connections to analyze DoS attacks. Having a bunch of similar, unnumbered interfaces on the same machine was confusing, so I started writing the code that allowed ifconfig to set and display interface descriptions like our Cisco equipment. This way interfaces could be labeled with a human-readable description according to what they were connected to instead of having to refer to some external document. This is now the ifconfig em0 descr "blah" code that I'm sure a lot of people don't realize is in there.

This type of change was somewhat extensive and a bit intimidating for me, but once I sent it to the developers mailing list, I received a lot of encouragement and help from Theo and others to make it correct and get it in the tree.

The nvram driver I also wrote in 2004 was just so the tpb userland application could hook into the various hardware buttons on my ThinkPad X40. I don't think there's much use for the driver aside from that, but lots of developers had X40s and so no one objected.

In 2005 we were selling a firewall product to support our PBX server product. Because the VoIP phones we used primarily booted over crusty-old TFTP, we needed a way for TFTP to be securely pushed through our pf-based firewalls. I wrote the tftp-proxy daemon to solve this, and committed it in December 2005.

Other various changes and ports I've maintained have just been in response to my needs as a developer and user of OpenBSD. I help out others where I can, but unfortunately I don't have as much time to contribute anymore. Once in a while i'll come across a bug or buy some new piece of hardware that doesn't work with OpenBSD and I'll try to fix it. I test new snapshots whenever I can, and usually try to do at least one platform test of the release candidate snapshots every 6 months.

At least for me, I can't really force myself to learn some new development language or platform if I'm not using it all the time. I've read some C programming books but I could never get proficient in it because I never had to write anything real in C. Everything I've been writing for the past few years has been in high level languages like Ruby or Perl.

So my suggestion for starting OpenBSD development is to run it as your primary operating system on your primary machine. If something is broken, fix it, or at least dig into the code and understand how it is supposed to work. If you can't understand it, at least you'll be able to bring what you've learned to the mailing lists to ask someone else for help. If features are missing that you need, try to implement them. Documentation fixes are very easy and very helpful, so if something is confusing that you can't or don't know how to change, at least document it properly so others can understand it. Many times bringing up a documentation fix for something confusing will prompt a more knowledgeable developer to ask why it's so confusing and fix the code themselves.