Introduction

I asked a psychiatric nurse practitioner about paranoia, and was told that “paranoiais the feeling that people are after you.” A medical dictionary would give you a slightly different definition, but this one is actually terribly useful for any system administrator. It’s not that everyone on the Internet is trying to attack you, but there’s always someone who wants to break into your system. Even if you think you have nothing of value, someone wants to own your computer. And you won’t realize the value of what you have until someone else has it. That’s just human nature.

If you’re not paranoid on the Internet, you’re in trouble.

That’s where OpenBSD comes in.

This book is an introduction to the OpenBSD operating system. OpenBSD is a member of the BSD family of operating systems. It is widely regarded as the most secure operating system available anywhere, under any licensing terms. It’s widely used by Internet service providers, embedded systems manufacturers, and anyone who needs security and stability. If you’re an experienced Unix system administrator who wants to add OpenBSD to your repertoire, this book is for you.

When you finish this book, you should be comfortable working with OpenBSD. You will understand how to configure, troubleshoot, and upgrade computers running OpenBSD and have a basic understanding of OpenBSD’s software, security, and network management features.

What Is Security?

We bandy the word security around a whole lot, so it’s worth taking a moment to talk about security itself. We all have a vague idea of what it means. “Security” means your stuff is safe, and other folks can’t get it. That’s fine, as far as it goes, but it doesn’t go far enough. In information technology, security has three parts:

Confidentiality

This means that secret data should remain secret. Your private information must not get into the public eye. That Eastern European kiddie porn syndicate should not get your credit card number.

Integrity

This means that data on the system should not be changed without authorization. Your records should remain intact. That intruder should not change the shipping address on an order, making your staff ship a crate of really expensive stuff to an abandoned warehouse in Detroit.

Availability

This means that the system keeps running. If your business depends on your website, losing the website means losing business. Someone who can take your website down can starve your company. And all kinds of people are willing to shut you down, either to compete or just for laughs.

Having been a system administrator for longer than some of you have been alive, I have a less formal idea of security. Security means eliminating bad days caused by computer problems. Spending a day getting a piece of software to compile is not a bad day. Is it an annoying day? Sure, but it’s not bad. A day when I need to get intruders out of my systems is bad. A day when I have a meeting due to computer intrusions is bad. A day when I realize that I cannot trust any computer on the network, and I must reinstall every blasted piece of gear I own, is really bad.[1]

While OpenBSD cannot change the fact that some of my servers are old enough to leave elementary school, it can fix the software aspects of security.

What Is BSD?

In the 1970s, AT&T needed a lot of specialized, custom-written computer software to run its business. The company was forbidden to compete in the computer industry, so it could not sell this software. Instead, AT&T licensed its software and the related source code to universities for nominal sums. Universities saved money by using this software instead of commercial equivalents with pricey licenses, and university students got access to this nifty technology and could learn how everything worked. In return, AT&T got exposure, some pocket change, and a generation of computer scientists who had cut their teeth on AT&T technology. Everyone got something out of the deal.

The best-known software distributed under this plan was UNIX.

Compared with modern operating systems, the original UNIX had a lot of problems. Thousands of students had access to its source code, however, and hundreds of teachers needed interesting projects for their students. If a program behaved oddly, or the operating system itself had a problem, the people who lived with the system had the tools and the motivation to fix it. Their efforts quickly improved UNIX and created many features we now take for granted. Students added the ability to control running processes, also known as job control. The UNIX S51K filesystem made system administrators wail and gnash their teeth, so they replaced it with the Fast File System (FFS), which introduced a whole host of features that have crept into every modern filesystem. Over the years, many small, useful programs were added to UNIX, and entire subsystems were replaced.

The Computer Science Research Group (CSRG) at the University of California, Berkeley, acted as a central clearinghouse for UNIX code improvements from 1979 to 1994. The group collected changes from other universities, evaluated them, packaged them, and distributed the compilation for free to anyone with a valid AT&T UNIX license. The CSRG also contracted with the Defense Advanced Research Projects Agency (DARPA) to implement various features in UNIX, such as TCP/IP. The resulting software collection came to be known as the Berkeley Software Distribution, or BSD. Users took the CSRG’s software, improved it further, and fed their improvements back into the CSRG. Today, we consider this a fairly standard way to run an open source project, but in 1979, it was revolutionary.

Fifteen years of work is a lifetime in software development. For comparison, Microsoft went from Windows 95 to Windows 7 in 15 years. The CSRG members collected so many enhancements and improvements to UNIX that they replaced almost all of the original UNIX with code created by the CSRG and its contributors. You had to look hard to find any original AT&T code.

Eventually, the CSRG’s funding ebbed, and it became clear that the BSD project would end. After some political wrangling within the University of California, in 1992, the BSD code was released to the general public under what became known as the BSD license.

BSD code is available for anyone to use under what is probably the most permissive license in the history of software development. The license can be summarized as follows:

Taken as a whole, this means that you can do almost anything you want with BSD code. (The original BSD license did require that users be notified if a software product included BSD-licensed code, but that requirement was later dropped.) You don’t even need to share any changes with the original authors! People could take BSD and include it in proprietary, open source, or free products.

Instead of a restrictive copyright, or the more permissive but still restricted copyleft, the BSD license is sometimes referred to as copycenter, as in “take this down to the copy center and run off a few for yourself.” Not surprisingly, companies such as Sun Microsystems jumped right on BSD. It was free, it worked, and plenty of new graduates had experience with the technology. One company, BSDi, was formed specifically to take advantage of BSD Unix.

Back in AT&T-land, UNIX development continued. AT&T took parts of the BSD Unix distribution and integrated them with official UNIX, and then relicensed the results back to the universities that provided those improvements. This worked well for everyone until the US government broke up AT&T, and the resulting companies were permitted to compete in the computer software business.

AT&T had one particularly valuable software property: a high-end operating system that had been extensively debugged by thousands of people and had powerful features, such as a variety of small but mighty commands, a modern filesystem, job control, and TCP/IP. AT&T started a subsidiary, Unix Systems Laboratories (USL), which happily started selling UNIX to enterprises and charging very high fees for it, all the while maintaining the university relationship that had given it such an advanced operating system in the first place.

The University of California, Berkeley’s public release of the BSD code met with great displeasure from USL. Almost immediately, USL sued the university and the software companies that had taken advantage of BSD. The University of California claimed that the CSRG had compiled BSD from thousands of third-party contributors unrelated to AT&T, and that it was the CSRG’s intellectual property to dispose of as it saw fit. Oddly enough, the lawsuit promoted BSD to thousands of people who never would have heard of it otherwise, spawning open source BSD variants such as 386BSD, FreeBSD, and NetBSD.

In 1994, after two years of legal wrangling, the University of California lawyers proved that the majority of AT&T UNIX was actually taken from BSD, rather than the other way around. To add insult to injury, AT&T had violated the BSD license by stripping the CSRG copyright from the files it had appropriated

Only about a half-dozen files remained as the source of contention. Bruised and broken in court, USL donated some of those files to BSD while retaining others as proprietary information. BSD 4.4-Lite was released, containing everything except the proprietary files. Due to those missing files, BSD 4.4-Lite was the only formal operating system release ever that was known to not be usable or even compilable as delivered. Everyone knew this, and bought it anyway—a historic feat that modern vendors probably wish they could replicate.

A subsequent update, BSD 4.4-Lite2, is the grandfather of OpenBSD, as well as all other BSD code in use today, such as that in FreeBSD, NetBSD, and Mac OS X.

The Birth of OpenBSD

Theo de Raadt was a NetBSD developer. After many strong, broad, and long-running disagreements with other NetBSD team members on how the project should be run, he went out on his own and founded the OpenBSD Project, attracting like-minded developers. The OpenBSD team quickly established an identity as a security-focused group, and it is now one of the best-known BSD descendants.

The OpenBSD team developers have introduced several ideas into the open source operating system world that are now taken for granted, such as public read-only access to the CVS repository and commit logs. They’ve also created several pieces of software that have become industry standards across many operating systems, such as sudo and the ubiquitous OpenSSH.

Today, many major companies rely on OpenBSD as a reliable, secure operating system with fanatical attention to security, correctness, usability, and freedom. OpenBSD runs on many different sorts of hardware, including the standard 32-bit and 64-bit “Intel PC” (i386 and amd64), Apple’s PowerPC Macintoshes (macppc), Sparc (sparc and sparc64), and obscure platforms such as the Sharp Zaurus PDA, the Lemote Yeeloong, and antediluvian VAXes. OpenBSD puts almost all of its effort into security features, security debugging, and code correctness, and has demonstrated in the process that correct code has a much lower failure rate, and hence greater security. OpenBSD strives to be the ultimate secure operating system.

The OpenBSD team continually improves the operating system. New features are added only once they meet the team’s code and documentation standards. Even if new software is added before it is feature-complete, it is expected to have full documentation and correct code.

The OpenBSD Community

OpenBSD is more than just a collection of bits. It’s a community of users, developers, and contributors, with a single central dictator—er, coordinator. And this community can be a bit of a shock for anyone who doesn’t know what to expect.

How can individuals scattered all over the world create, maintain, and develop an operating system, let alone build a community? Almost all discussion occurs through email and online chat. The process is slower than talking face-to-face, but it’s the only cost-effective way for a large group of people in every time zone to communicate in a reasonable fashion. Email and chat also offer written records of discussions. If you want to participate in OpenBSD development, you must be comfortable with email. (There are OpenBSD-dedicated web forums, but they’re outside the main community.)

The OpenBSD community has four tiers: users, contributors, committers, and the coordinator.

Many open source operating systems put a lot of effort into growing their user base, evangelizing, and bringing new people into the Unix fold. OpenBSD does not.

Most open source Unix-like operating system groups do a lot of pro-Unix advocacy. Again, OpenBSD does not.

The communities surrounding other operating systems actively encourage new users and try to make newbies feel welcome. OpenBSD specifically and deliberately does not.

The OpenBSD community is not trying to be the most popular operating system—just the best at it what it does. The developers know exactly who their target market is: themselves. If you can use their work, that’s great. If not, go away until you can.

The OpenBSD community generally expects newcomers to be advanced computer users. The members have written extensive OpenBSD documentation, and expect newcomers to be willing to read it. They’re not interested in coddling new Unix users and, if pressed, will say so—often bluntly and forcefully. They will not hold your hand. They will not develop new features to please users. OpenBSD exists to meet the needs of the developers, and while others are welcome to ride along, the needs of the passengers do not steer the project.

Contributors are OpenBSD users who have the skills necessary to add features to the operating system, fix problems, write documentation, or accurately report problems. Problems range from typographical errors in the documentation to system crashes. Almost anyone can be a contributor. In fact, the community has even accepted problem reports from me, and resolved them within hours.

Every OpenBSD feature is present because some contributor took the time to write the code for it. Contributors who submit careful, correct fixes, or who provide useful problem reports, are welcome in the OpenBSD community. And if a contributor submits enough fixes of sufficient quality, he might be offered the role of committer.

Committers have write access to the main OpenBSD source code repository. They can make whatever changes they deem necessary for their OpenBSD projects, but are answerable to each other and to the project coordinator. Most committers are skilled programmers who work on OpenBSD during their own time.

While being a committer seems glamorous, the role carries a lot of responsibility. If a committer breaks the operating system or changes something so that it conflicts with OpenBSD’s driving “vision,” he must fix it. Committers try to avoid breaking things, and frequently make their work available on websites and mailing lists before it’s integrated into the main OpenBSD source code collection, allowing interested people to preview, test, and double-check their work.

Many committers have very specific coordination roles within OpenBSD. For example, quite a few hardware architectures have a point man for issues that affect that hardware, the compiler has a maintainer, and so on. These committers have earned that position of trust in the community.

Theo de Raadt started OpenBSD in 1995 and still coordinates the project. He is the final word on how the system should work, what is included in the system, and who gets direct access to the repository. He resolves all disputes that contributors and committers cannot resolve among themselves. Theo takes whatever actions necessary to keep the OpenBSD Project running smoothly. If something should ever happen to Theo, the project does have plans for replacing him.

Building the OpenBSD organization around a central benevolent dictator avoids a lot of the management problems other large open source projects have.

If you decide to work on OpenBSD, you must accept Theo’s decisions as final. A contributor who doesn’t accept the project’s leader won’t remain with the community for long. Theo might have a big stick, but as he is the acknowledged project leader, he doesn’t need to use it nearly as often as you might think.

OpenBSD’s Strengths

What makes OpenBSD OpenBSD? Why bother with yet another Unix-like operating system when there are so many out there, several closely related to OpenBSD? What makes this operating system worth a computer, let alone worthy of protecting your company’s assets?

OpenBSD is designed to run on a wide variety of popular processors and hardware platforms, including Intel-compatible (both 32-bit and 64-bit), Alpha, Macintosh (both PowerPC and Intel systems), and almost anything from Sun. It runs on tiny devices such as the Sharp Zaurus, hefty Hewlett-Packard HP 9000 systems, certain Silicon Graphics workstations, and whatever else grabs the developers’ attention. The OpenBSD team wants to support as many interesting hardware architectures as it has the hardware and skills to maintain, so more are added regularly, and chances are most computers you encounter can run OpenBSD.

That said, when a hardware platform becomes too obscure, OpenBSD stops supporting it. A few MIPS systems, 68K Macintosh hardware, and Amiga systems are examples of systems that run older versions of OpenBSD but are not supported by new releases.

As a matter of legacy, OpenBSD will run on hardware that has been obsolete for decades because the hardware was in popular use when OpenBSD started, and the developers try to maintain compatibility and performance when possible. This includes platforms such as the VAX and Alpha, which were considered powerful in the 1980s and 1990s. While someone running OpenBSD on a dual-core 64-bit system might not notice a programming change in OpenBSD that increases the amount of CPU time needed to process network packets, people running OpenBSD on VAX systems will quickly notice that same change.

Of course, some performance-impacting changes cannot be avoided. For example, systems must support IPv6 in the very near future, and I suspect that decades-old hardware will struggle to keep up. OpenBSD cannot turn back the clock, but it will leave every scrap of computing power possible for your applications. And after all, that’s what’s important—people use applications, not operating systems. This focus on performance means that a system running OpenBSD with a 1GB disk and a 486 CPU can still support real applications, such as a DNS or web server.

Many free software projects are satisfied when they release code. Some think that they go above and beyond by including a help function in the program itself, available by typing some command-line flag. Others really go wild and offer a grammatically incorrect and technically vague manual page.

The OpenBSD community expects the documentation to be both complete and accurate. The manual pages for system and library calls are extensive, even when compared to other BSDs, and include discussions on usage and security.

Documentation errors are considered serious bugs, and are treated as harshly as any other serious bug. This might sound extreme, but in its own internal audits, the OpenBSD team has found any number of instances where programmers used a library interface exactly as recommended in the manual page, but errors in the manual page made the usage dangerous or insecure. Documentation is important.

In the spirit of the original BSD license, OpenBSD is free for use in any way, by anyone, for any purpose. You can use it with any tool you like, on any computer.

Most of today’s free software is licensed under terms that require software distributors to return any changes to the project’s owner, but OpenBSD doesn’t even carry that requirement. You can use OpenBSD in your proprietary system, ship that system everywhere in the world, and not pay the developers a dime.

OpenBSD is perhaps the freest of the free operating systems. Like every other free Unix-like operating system, the source code inherited from BSD originally contained a wide variety of programs that shipped under conditional licenses. Some were free for noncommercial use. Some were free if you changed the name once you changed the code. Others had a variety of obscure licensing terms, such as indemnifying a third party against lawsuits. These programs have either been relicensed (with the permission of the original author) or ripped out and replaced with free alternatives.

The word freedom has been given a lot of different twists by people in the programming community. Some believe that software is free if you can download it and use it. Some believe that software is only free if the end user gets the source code. The OpenBSD idea of freedom is that its code can be used for any purpose, by anyone.

Consider this: During a discussion on an OpenBSD mailing list regarding licensing terms,[2] Theo de Raadt said:

We know what a free license should say.

It should say

  • Copyright foo

  • I give up my rights and permit others to:

    • distribute

    • sell

    • give

    • modify

    • use

  • I retain the right to be known as the author/owner

When it says something else, ask this:

  • - is it 100% guaranteed fluff which cannot ever affect anyone?

  • - is it giving away even more rights (the author right)?

If not, then it must be giving someone more rights, or by the same token—taking more rights away from someone else!

Then it is _less_ free than our requirements state!

The OpenBSD team works hard to ensure that every line of code it supports is licensed in this manner.

Note

The source code tree does include code under different licenses, such as the GNU C compiler gcc, binutils, and so on. OpenBSD runs fine without them—you just can’t compile OpenBSD without them.

This is pretty straightforward. OpenBSD is a gift. You’re free to use it or not. As with any gift, you can do whatever you want with it. But you’re not free to bug the developers for features or support.

Every skilled programmer knows that programs written correctly are more reliable, predictable, and secure. However, many free software producers are satisfied if their code compiles and simply seems to work, and quite a few commercial software companies don’t give their programmers time to write their code correctly.

OpenBSD developers strive to implement solutions correctly. They make it a strict rule to write programs in a reliable and secure manner, following best current programming practices. And exposing the code to “weird” environments such as ancient VAXes is part of the discipline; OpenBSD developers insist that some subtle bugs (and a few less subtle ones) have been pinpointed only during testing on one of OpenBSD’s less mainstream architectures. Fixing those bugs benefits all users, of course.

OpenBSD implementations follow UNIX standards, such as the Portable Operating System Interface (POSIX) and the American National Standards Institute (ANSI), but they are less concerned about extensions to these standards created by third parties. For example, many Linux extensions do not appear in OpenBSD. When those extensions are added to standards, the OpenBSD team will add them.

OpenBSD code has been repeatedly audited for correctness through a lot of hard work. Anyone who tries to introduce incorrect code will be turned away—generally politely, and often with constructive criticism, but turned away nonetheless. And that brings us to OpenBSD’s most well-known claim to fame.

OpenBSD strives to be the most secure operating system in the world. While it can reasonably make that claim today, maintaining that position requires constant effort. Intruders constantly try new ways to penetrate computers, which means that today’s feature might be tomorrow’s security problem. As OpenBSD developers learn of new classes of programming errors and security holes, they scan the entire source tree for that type of problem and make fixes before anyone even knows how these issues might be exploited.

Additionally, OpenBSD takes advantage of any security features offered by hardware. For example, AMD’s 64-bit Intel-compatible CPUs can mark a page of memory as either executable or writable, but not both. (Intel later copied this feature.) This alleviates many buffer overflow attacks, but the operating system must use this facility. OpenBSD supported this feature in 2003, shortly after the hardware was released. In fact, OpenBSD generally supports all hardware security features offered on a platform.

The history of computing shows that users cannot be expected to patch or maintain their own systems. Systems must be secure against existing and future attacks out of the box. OpenBSD’s goal is to eliminate problems before they exist.

OpenBSD and Your Security

Even though OpenBSD is tightly secured, intruders still break into OpenBSD systems. This might seem contradictory, but in truth, it means that the person running the computer didn’t understand computer security.

OpenBSD has many integrated security features, but you cannot assume that these features secure everything running on the system. That’s just not possible. No operating system can defend itself against operator error. An operating system can protect itself from software problems to a limited extent, but ultimately, the responsibility for security is the administrator’s.

Consider a web server—even OpenBSD’s integrated Apache server—running on OpenBSD. OpenBSD provides the web server with a stable, reliable platform, and will provide services as the web server requests, within the limits assigned by the system administrator. If the system administrator has configured the web server correctly, a web server failure will not endanger the operating system. If the system administrator configures the web server to run with unlimited privileges, the web server can inflict almost unrestricted damage on the underlying system.

Or consider a less extreme case. The web server might be configured correctly, but suppose you install insecure forum software. An intruder can break into the forum and edit its data—maybe grab the username and password the forum software uses to access the local database. If that account information matches a system-level username and password, the intruder might be able to leverage them to gain access to the system. Or perhaps he can use that username and password to get administrator-level access to the database and penetrate other applications. What if those applications have elevated privileges?

Only careful, consistent, thoughtful work by a system administrator can prevent intrusions. Throughout this book, we’ll discuss some basic security precautions you should take when installing and running software. We’ll also discuss the advanced security features OpenBSD offers in order to protect itself.

OpenBSD’s Uses

Where does OpenBSD fit into your computing strategy? That ultimately depends on your strategy and your needs. OpenBSD can be used anywhere you need a solid, reliable, and secure system. I recommend OpenBSD for any of three different roles: a desktop, a server, or network management.

If you need a powerful desktop system with all the features you would expect from a complete Unix-like workstation, OpenBSD will do nicely. Graphic interfaces, office suites, web browsers, and other desktop software are available in the ports collection, OpenBSD also supports a variety of development tools, application environments, network servers, and other features that programmers and web developers need. If you’re a network administrator, you’ll find that OpenBSD supports packet sniffers, traffic analyzers, and all the other programs you rely on.

If you’re serving web pages, handling email, providing Lightweight Directory Access Protocol (LDAP) or database services, or offering any other sort of network service to clients, OpenBSD can help you. It’s a cheap and reliable platform. Once it’s set up, it just works. And, of course, it’s secure, which you cannot underestimate on the Internet.

OpenBSD makes an excellent firewall, bridge, or traffic shaper. You can use it to support intrusion detection software, web proxies, and traffic monitors. The integrated packet-filtering firewall and supporting software provides state-of-the-art network connection management and control, and can strip out many dangerous types of traffic before it reaches your servers. And its load-balancer features are competitive, with many commercial offerings that cost thousands of dollars more.

About This Book

This book is written for experienced Unix users or system administrators who want to add OpenBSD to their repertoire. I assume you’re familiar with basic commands, such as tail(1), chmod(1), ping(8), and so on, and that you know why each command in this list includes a number in parentheses after the name. We’ll discuss many programs that you might already be familiar with, but that might be slightly different in OpenBSD.

For maximum benefit, you should install OpenBSD on a dedicated machine. OpenBSD can coexist with other operating systems or run in a virtual machine, but if you’re going to use OpenBSD in a production environment, you should run it on its own.

Many people believe that OpenBSD is not the easiest Unix-like operating system, or the easiest version of BSD, or even the easiest open source BSD. OpenBSD doesn’t have handy wizards that walk you through each stage of the configuration process, although it does has a few menu-driven front ends. Once you’re familiar with how the system works, though, such wizards would only get in the way.

To truly understand OpenBSD, you must be willing to learn, experiment, and spend time accumulating understanding. Much of this knowledge can be directly applied to other versions of BSD, other Unix-like operating systems, and even completely foreign operating systems, such as Microsoft’s Windows.

Contents Overview

While this book is designed to be read from front to back, here’s a brief description of each chapter, in case you would rather skip around randomly.

  • Chapter 1. Discusses the OpenBSD documentation available both in the installed system and on the Web. You need to understand what you’re getting into before installing OpenBSD.

  • Chapter 2. Discusses installation on a standard amd64 (also known as the 64-bit Intel-compatible) system. Making some decisions before you install OpenBSD will ensure that you don’t need to reinstall it later.

  • Chapter 3. Carries you through every step of a real OpenBSD installation. The OpenBSD installer assumes a certain level of knowledge about computer hardware and OpenBSD that you might not yet possess. This walk-through will guide you through the rough spots.

  • Chapter 4. Discusses the basic steps you should take after installing OpenBSD to make your system secure, stable, and usable.

  • Chapter 5. Covers system startup. Different situations require different startup methods, and we’ll cover them all. We’ll also discuss how OpenBSD starts its component software.

  • Chapter 6. Discusses how to add, remove, and restrict OpenBSD user accounts.

  • Chapter 7. Discusses controlling user privileges and permissions. OpenBSD includes powerful tools such as classes and limits, as well as the privilege management tool sudo(8).

  • Chapter 8. Covers disk management with the standard OpenBSD filesystems.

  • Chapter 9. Covers advanced filesystem topics such as the Network File System (NFS), working with disk images, software RAID, and encrypted disks.

  • Chapter 10. Considers how to maintain security using tools such as file flags, securelevels, OpenBSD security announcements, and some basic cryptographic tools.

  • Chapter 11. Reviews the basics of TCP/IP versions 4 and 6, and covers some of OpenBSD’s tools for examining and troubleshooting the network.

  • Chapter 12. Takes you through configuring OpenBSD’s network stack for Ethernet, trunks, and virtual local area networks (VLANs).

  • Chapter 13. Describes OpenBSD’s add-on software tools. You’ll learn how to install precompiled software, compile your own software, and verify and remove software.

  • Chapter 14. Describes each major file in /etc that isn’t covered elsewhere, and discusses how you might want to use those files.

  • Chapter 15. Covers the various ways OpenBSD maintains itself and how you can make those processes fit your environment and workflow.

  • Chapter 16. Covers configuring software integrated with OpenBSD. You’ll learn about the system logger and log file management, the DHCP server, the web server, and more.

  • Chapter 17. Covers software useful to OpenBSD as a desktop, such as the window manager cwm(1) and Xenocara. This chapter includes coverage of important software that makes using OpenBSD with a desktop easier, such as SSH keys and tmux.

  • Chapter 18. Discusses the various tools available to configure a standard kernel. Unlike many other free Unix-like operating systems, OpenBSD does not expect or require the system administrator to compile a kernel. You can tune the standard kernels without recompiling.

  • Chapter 19. Discusses how to recompile a kernel in those rare instances when you must.

  • Chapter 20. Covers how to upgrade OpenBSD, either from a snapshot or from source.

  • Chapter 21. Documents OpenBSD’s integrated packet-filtering engine, PF. It includes discussions of real-world situations and how to handle them.

  • Chapter 22. Introduces things that the packet filter can do beyond just filtering packets.

  • Chapter 23. Includes tidbits that didn’t fit anywhere else but are not large enough topics to merit their own chapters. This includes diskless OpenBSD, building bootable USB installation media, and making custom OpenBSD installation sets.

This book won’t cover everything OpenBSD can do, but it will get your feet firmly under the table. To learn the rest, you’ll need to access OpenBSD’s information resources, which is the subject of the first chapter.


[1] I still have bad days due to people, mind you, but I largely solve them by other means. Don’t ask about the mounds of dirt in my backyard.

[2] This is from October 24, 2002, on the openbsd-misc mailing list. It’s more than a decade old, but still pretty much says it all.