You Have Installed OpenBSD. Now For The Daily Tasks.

© 2024-2026 Peter N. M. Hansteen

Despite some persistent rumors, installing OpenBSD is both quick and easy on most not too exotic hardware. But once the thing is installed, what is daily life with the most secure free operating system like?

Welcome to OpenBSD! I assume you are reading this as a new user who has just completed installing the system. If you are more experienced with the system and reading because you want to see what they're teaching the young ones these days, you are welcome here, too. And at any rate, input such as corrections and comments are always welcome.

But first, for the really impatient, here are the main points we cover in this piece:

---

TL;DR: Supported Releases and Five Commands You Need To Know

• OpenBSD has two releases per year, May 1st and November 1st (roughly). Only the two most recent releases are supported.
• The first command to run after a new install is syspatch, which pulls in any security updates and installs them. If the output indicates a reboot or other action is needed, do as the program says.
• OpenBSD's sudo replacement doas is in base, is easy to set up and use and likely fills your needs for privilege elevation.
• Third party software comes in packages. Use pkg_add to install packages. For finding packages, openbsd.app might help.
• When you need to upgrade to a new release, sysupgrade does the job well in almost all cases.
• For managing services (if you need to), rcctl is there for you to get things done.
• Please keep yourself up to date on developments, and keep the length or limit of the support period for your release in mind. Also, we will offer some insight on running -current at the end.

---

Installing OpenBSD is quite straightforward on most hardware (possibly excluding some true antiques and, occasionally. the newest of the new). In the rest of this article we will assume that you have completed a basic install, following the OpenBSD Installation Guide in the OpenBSD FAQ, possibly supplemented by other sources.

In our experience, following the FAQ's instructions should get you there, and keep in mind that the defaults are sane, and it is not entirely unheard of that the interactions with the installer consist almost entirely of pressing the Enter key in response to the prompts with suggested default values. And if you have not read the afterboot(8) man page, now is likely a good time to give it at least a glance.

Note: This piece is also available without trackers but classic formatting only here.

Planning Ahead: One Release Every Six Months, The Two Most Recent Releases Are Supported

When you start poking around OpenBSD and learning how things are done, it is important to keep in mind that

• The OpenBSD project makes two releases a year, with release dates normally falling on or around May 1st and November 1st.
• The project offers security updates to the base system and packages for supported releases, currently the two most recent ones. See the FAQ item about OpenBSD flavors for further explanation.
• Support is available primarily through the project mailing lists. In addition, user groups and commercial (paid) support options are available in several locations.

This means that there is no such thing as an OpenBSD Long Term Support (LTS) release, you are actually expected to upgrade to a supported version at least once a year.

At the time of this writing (late May 2026), the supported releases are OpenBSD 7.8, which was released on October 22nd, 2025, and the most recent release OpenBSD 7.9, released May 19th, 2026. Once OpenBSD 8.0 becomes available (the link will start working some time before the event), OpenBSD 7.8 support stops, and you need to move on to a supported release.

So once you are past the initial experimental phase, please start planning for how to maintain your systems. You will not regret doing those preparations down the road.

---

Protip: Before starting anything that produces output that likely scrolls off the top of your screen or window, start a script session so all visible events are preserved in the file you specify. See man script for details.

---

Your First Move After Install: Run syspatch

There you are, with a fresh install of a still supported release of OpenBSD.

The first thing to do is to check whether any security updates (patches) are available. The easiest way to check is to choose the Patches link from the main OpenBSD website. If you installed your release close enough to the release date, there may be no patches available yet, but you can rest assured that over the lifetime of a release, there will be some. Towards the end of their lifetimes some releases have seen twenty or more updates.

If you are on one of the more common platforms (amd64, arm64 or i386), you could even skip the manual check and let syspatch do the job for you (for the other 11 platforms, the old fashioned patch and make process, managed and verified via signify still applies, see the contents of each patch file).

To run the initial syspatch on a new system, log on with the user you created during the install process, then su to root, and run syspatch with no arguments.

If you have Internet connectivity and there are installable patches available, the command lists them as they are fetched and applied.

If no patches are available, the command exits quietly.

If the messages from syspatch or the patch description indicate that one or more services have been updated, make sure to restart those services to ensure that only the updated binary is loaded and running.

If the messages from syspatch or the patch description indicates that a reboot is required, please do reboot your system before proceeding. In that case, a shutdown -r now is likely appropriate before you go to the next steps.

For Administrative Tasks, doas Likely Fills Your Needs

With all available security in place for your OpenBSD base system, you more likely than not have a few more system administration tasks queued up, such as installing packages.

Performing those tasks require elevated privileges, so logging on as root may seem tempting. Please resist that temptation. It is much better if you only run with higher privileges when the situation actually requires it, and the OpenBSD base system has doas available for that purpose.

OpenBSD, like most of the Unixlikes around, used to rely on sudo for going to higher privileges, but feature creep happened over the years, and by the time OpenBSD 5.8 was released, we had doas available for "about 95% of the things people actually use".

Out of the box, doas comes almost ready to use.

As the man page hints, the command will only work with a valid /etc/doas.conf in place.

Fortunately, the configuration file man page offers an example that is a reasonable starting point. If you do cut and paste that one, please replace the user names aja and tedu with something appropriate for your local environment.

Simpler and more specific configurations are available, but even with those minimal edits, you will no longer need to log in as root or su to root to get things done.

Remove the Tedium From Services Management With rcctl

If your only OpenBSD system is your laptop, you probably do not need to worry about managing services at all. By default, a clean install runs no services.

The installer offered the option of enabling sshd for you, but accepting the offer is not actually a requirement. If you want to enable or otherwise manage services after install, you can get a lot done with rcctl, including enable, disable, start, stop, restart services and even set a service's parameters.

In short, you can get most of the operations you would need on your rc.conf.local file that you would imagine would require a text editor and perhaps a variety of kill commands done by targeted use of rcctl instead. Take a peek at the rcctl man page -- it's short, but useful and friendly.

For Anything Not In Base, Look to Packages with pkg_add and Other pkg_* Tools

A fresh OpenBSD install is a surprisingly full featured operating system. If you specified during install that you would be running the X windowing system, the system will offer a graphical login screen and present you with the fvwm window manager.

However, the default window manager may be perceived as too basic for some tastes, and in a typical end user scenario, you would typically want at least

• A desktop environment
• A web browser
• A suite of office software

This is where the OpenBSD ports and packages system comes into play. For installing packages, the tool you want to use is pkg_add (for some background and examples of how to use the ports and packages system, see my earlier piece You've Installed It. Now What? Packages!, also available prettified and tracked here).

The OpenBSD packages collection offers several options for all three categories, and a common combination is
xfce for desktop environment,
firefox for web browsing and
libreoffice for the office suite.

For package installs on OpenBSD, the general procedure is,

find the package name (your guess is likely right or quite close),
run pkg_add packagename,
read any message the command outputs at the end, and follow the steps indicated.

If the package install outputs instructions, you will likely also find the instructions in /usr/local/share/doc/pkg-readmes/packagename, but the earlier advice to run anything important in a script session applies here too.

So in our desktop scenario the sequence would be

$ doas pkg_add xfce
follow the instructions the package message prints. You may need to log out and back in after this step (and yes, you can have each user specify their own separate desktop environment).

$ doas pkg_add firefox
follow the instructions the package message prints.

$ doas pkg_add libreoffice
follow the instructions the package message prints.

At this point, the packages you installed are ready to use, and you can browse the web and read and produce office documents to your heart's content. If you want a mail client too, several of the well known ones are available as packages. A simple pkg_add thunderbird will add one of the more popular ones to your set of locally installed software.

If you want to find further packages, the You've Installed It. Now What? Packages! article offers some pointers. If you do not want to install a full ports tree for search purposes only, the openbsd.app website offers a nice clickable interface.

Keeping Up to Date: Keep Running syspatch and pkg_add -u

Keeping an OpenBSD system updated is not difficult. You have already seen syspatch in action for pulling in security or reliability updates.

Over the lifetime of a -stable version of the release (which is what your system turns into after your first syspatch), more updates will inevitably become available, and you (your system administrator) should periodically check for any updates and install them in due course.

One useful way to automate the process is to set a cron job that runs syspatch -c (see the syspatch and crontab man pages) at reasonable intervals and mails the output to somebody relevant.

If you run several systems or even more than one OpenBSD version, you would be well advised to appoint one machine per version to be the syspatch canary in order to keep the noise level in your mailboxes or other alerts channels down to reasonable levels.

For keeping installed packages up to date, the command to use is pkg_add with the -u (update) flag.

The pkg_add command offers several other flags that affect its behavior, but the only ones of any real use in a production (stable) environment are the -v (verbose) and -m (print progress bars) options.

If the messages from pkg_add indicate that one or more services have been updated, make sure to restart those services to ensure that only the updated binaries are loaded and running.

At this point, you should have all the pieces in place for keeping your OpenBSD-stable systems in trim with the latest available fixes. Keep up with updates, and you should be OK for the supported lifetime of the code.

Jumping to the Next Release with sysupgrade

All good things come to an end eventually, and when a new release is available, or at the latest, when your present operating system is coming close to end of its supported life, it becomes necessary to upgrade to the next, newer release.

Fortunately, recent OpenBSD versions (since OpenBSD 6.6, in fact - released November 17th 2019), offers a command that offer a smooth upgrade for the most likely scenarios, called sysupgrade.

The sysupgrade command is designed to handle the somewhat complex upgrade process (see the earlier article Keeping Your OpenBSD System In Trim: A Works For Me Guide for some background -- also available tracked and prettified) with minimal user interaction.

The command is designed on the premise that the system to be upgraded is very close to a default install -- if you keep yourself with custom kernels or left out any of the default install sets during install, you are not part of the target audience, and you will be better served by the article referenced in the previous paragraph.

Before proceeding to upgrading to a new release, it is advisable to read the release notes for the new release to identify any changes that may require extra attention. Fortunately, the occasions when manual intervention is strictly needed are rare between releases.

When a new release is available, you upgrade to the next release (numbered by increments of 0.1 per convention) by running

$ doas sysupgrade

The command fetches the install sets for the new release, reboots into the installer, runs sysmerge to perform any needed updates to configuration files and reboots into the upgraded system.

If the sysmerge pass detects any changes that are beyond its automated capability, it will issue a warning that a manual sysmerge is needed. In most cases this will not be needed, however.

When you have the base system upgraded, you will likely want to upgrade to newer versions of any installed packages as well. The command needed is the same as the one you used previously to pull in packages with updates for any identified issues:

$ doas pkg_add -u

When upgrading packages after a system upgrade it is worth paying attention to any package messages and to check for any updates to the package readmes in the /usr/local/share/doc/pkg-readmes/ directory.

Once you have started upgrading packages (if not earlier) you will want to explore other package tools. Try apropos pkg for pointers on where to start exploring.

If you run into any problems, the support channels mentioned earlier in this piece will offer help in response to any reasonably formulated problem reports.

Ready For -current? The Same Tools, Used Slightly Differently

When you have been running OpenBSD stable versions for a while, you may be tempted to explore a bit further, and perhaps even be involved in developing the systems or packages or testing any new features or changes that will become available in upcoming releases.

This is when you may want to explore OpenBSD-current. The way in is to install a snapshot (from the snapshots directory on your favorite mirror). Just how to proceed is really up to you, but if you jump to running -current, you will probably make your life easier in debugging and development contexts if you keep fresh cvs checkout of the src and xenocara source trees as well as the ports tree.

Once you are running a snapshot, the maintenance and upgrade procedure changes slightly. As mentioned, it is advisable to keep sources and ports up to date (start with reading the Building the System from Source part of the FAQ).

---

Note: Keep in mind that snapshots track -current, and generally switch to post-release code some time before the release becomes available. At that point, upgrading from a snapshot to the upcoming release is no longer a supported option -- if you see a commit messages similar to this one (which marked the transition to 7.7-current), it's already too late.

---

For -current or snapshots, syspatch is not really relevant anymore. Instead you run the sysupgrade command with the -s flag:

$ doas sysupgrade -s

The command runs much like it would for -stable versions, but with a slightly elevated risk of needing to run a manually supervised sysmerge after booting into the upgraded system.

New snapshots are generally accompanied (or followed soon after) by updated packages, and running pkg_add -u after a successful sysupgrade -s generally makes sense.

Some of the debugging related pkg_add flags make more sense in a snapshot environment.

It is worth noting that for the brief period when -current reports a release equivalent version string (one without -current or -beta suffix) it is necessary to add "-D snap" to the pkg_add arguments in order to update packages correctly.

If you intend to contribute in any way, including testing, it is essentially required that you read the tech@ and bugs@ mailing lists and familiarize yourself with how to interact on those forums before posting.

The Way Forward

Hopefully this piece will clear up any confusion caused by me reposting recently the two pieces Keeping Your OpenBSD System In Trim: A Works For Me Guide for some background -- also available tracked and prettified and You've Installed It. Now What? Packages!, also available prettified and tracked here, which by now are more than a decade old.

The pieces still contain mostly correct reference information, but informed readers will notice that they predate the introduction of syspatch and the availability of updated packages for -stable available via pkg_add -u.

Please keep in mind that our favorite operating system OpenBSD is in constant and rapid developement, and that anything written about that system could be quite out of date even a few years from now. I hope to revisit this and other pieces to keep them reasonably in line with evolving realities. I welcome your comments and corrections via email or other channels such as whatever social medium brought you the link to this article.

---

Note: Updated several times, last on 2025-10-22 to mark the OpenBSD 7.8 release.

---

Resources For Further Reading

The OpenBSD FAQ

Michael W Lucas: Absolute OpenBSD, 2nd edition

Ted Unangst: doas Mastery

OpenBSD Journal News items about OpenBSD, generally short with references to material elsewhere.

Peter Hansteen: What every IT person needs to know about OpenBSD Part 1: How it all started,
What every IT person needs to know about OpenBSD Part 2: Why use OpenBSD?,
What every IT person needs to know about OpenBSD Part 3: That packet filter
(or the whole shebang in the raw here or with trackers at bsdly.blogspot.com)

Network Management with the OpenBSD Packet Filter toolset, by Peter N. M. Hansteen, Massimiliano Stucchi and Tom Smyth (A PF tutorial, this is the BSDCan 2024 edition). An earlier, even more extensive set of slides can be found in the 2016-vintage PF tutorial.

That Grumpy BSD Guy Blog posts by Peter N. M. Hansteen (prettified, tracked). New entries as well as still-relevant pieces that started out over there and have warranted updating will also be findable, untracked other than my webserver log, at https://nxdomain.no/~peter/blogposts/. Please let me know if there are pieces you think would warrant liberation to that space.

---

You Have Installed OpenBSD. Now For The Daily Tasks. is © 2024 Peter N. M. Hansteen (published 2024-09-02, updated several times, last 2026-05-19)

---

You might also be interested in reading selected pieces via That Grumpy BSD Guy: A Short Reading List (also here).

Separately, The Book of PF, 4th edition is now available. For a little background, see the blog post Yes, The Book of PF, 4th Edition Is Coming Soon (also here).

---

You've Installed It. Now What? Packages!

Once you've installed your OpenBSD system, packages are there to make your life easier. A works for me/life is good guide for your weekend reading.

Installing OpenBSD is easy, and takes you maybe 20 minutes. Most articles and guides you find out there will urge you to take a look at the files in /etc/ and explore the man pages to make the system do what you want. With a modern BSD, the base system is full featured enough that you can in fact get a lot done right away just by editing the relevant files and perhaps starting or restarting one or more services. If all you want to do is set up something like a gateway for your network with basic-to-advanced packet filtering, everything you need is already there in the basic install.

Then again, all the world is not a firewall, and it is likely you will want to use, for example, a web browser (we used to have the venerable lynx in base, and ftp will retrieve web pages, but does not allow browsing) or editing tools that are not vi or mg. That's where packages and package systems come in. I'll skip a little ahead of myself and make a confession: The machine I'm writing this piece on reports that it has some 381 packages installed.

Before we move on to the guts of this article, some ceremonial words of advice: If you're new to OpenBSD or it's your first time in a while on a freshly installed system, you could do a lot worse than spending a few minutes reading man afterboot. That man page serves as a handy checklist of things you should at least take a peek at to ensure that your system is in good working order.

Some packages will write important information, such as strings or stanzas to put in your rc.conf.local, rc.local or sysctl.conf files, to your terminal. If you're not totally confident what to do after the package install finishes, it may be a good idea to run your ports and packages installs in a script(1) session. See man script for details.

When dinosaurs roamed the Earth ...
The story of the ports and packages goes back to the early days of free software when we finally found ourselves with complete operating systems that were free and hackers^H^H^H^H^H^H system administrators found that even with full featured operating systems such as the BSDs, there were sometimes things you would want to do that was not already in there.

The way to get that something else was usually to fetch the source code, see if it would compile, make some changes (or a lot) to make it compile, possibly introduce the odd #ifdef block and keep at it until the software would compile, install and run. In the process you most likely found out what, if any, other software (tools or libraries) needed to be installed to complete the process. At that point, you could claim to have ported the software to your platform. If you had been careful and saved a copy of the original source files somewhere, you could use the diff(1) utility to create a patch you could then send to the program maintainer and hope that he or she would then incorporate your changes in the next release.

But then, why wait for the next release? Why not share those diffs with others? How about putting it into a CVS repository that would be available to everyone? That idea was tossed around on relevant mailing lists for a while, and the first version of the ports system appeared in FreeBSD 1.0 in December 1993.

The other BSD systems adopted the basic idea and framework soon after, with small variations. On NetBSD, the term port was already in use for ports of the operating system itself to specific hardware platforms, so on that operating system, the ports tree is referred to as 'package source', or pkgsrc for short. The ports and packages tools are still actively maintained and developed on all BSDs, and most notably Marc Espie rewrote the pkg_* tools for OpenBSD's 3.5 release. Marc and other OpenBSD developers have been refining the package tools with every release since then.

Parallel development has lead to some differences in the package handling on the various BSDs, and some of the operations I describe here from an OpenBSD perspective may not be identical on other operating systems.

Around the same time the BSDs started including a ports tree and packages, people on the Linux side of the fence started developing package systems too. With distributed development taken to the point where the kernel, basic system tools and libraries are maintained separately, perhaps the need there was even greater than on the BSDs.

In fact, some Linux distributions such as the Debian based ones have taken the package management to the point where 'everything is a package' - every component on a running system is a package that is maintained via the package system, including basic system tools, libraries and the operating system kernel. In contrast, the BSDs tend to treat the base system as a whole, with the package management tools intended solely for managing software that does not come as a part of the default install.

The anatomy of ports and packages
The ports system consists of a set of 'recipes' to build third party software to run on your system. Each port supplies its own Makefile, whatever patches are needed in order to make the software build and optionally package message files with information that will be displayed when the software has been installed.

So to build and install a piece of software using the ports system, you follow a slightly different procedure than the classical fetch - patch - compile cycle. You will need to install the ports tree, either by unpacking ports.tar.gz from your CD set or by checking out an updated version via cvs.

With a populated ports tree in hand, you can go to the port's directory, say

$ cd /usr/ports/misc/screen

to see about installing screen, the popular GNU multi-screen window manager.

On a typical OpenBSD system, that directory contains the following files:

$ls -l

total 20
drwxr-xr-x  2 root  wheel   512 Mar 31 16:46 CVS
-rw-r--r--  1 root  wheel  1047 Mar 28 17:34 Makefile
-rw-r--r--  1 root  wheel   283 Apr  5  2007 distinfo
drwxr-xr-x  3 root  wheel   512 Jun 26  2012 patches
drwxr-xr-x  3 root  wheel   512 Mar 11  2012 pkg

here, the Makefile is the main player. If you open it now in a text editor or viewer such as less, you will see that the syntax is quite straightforward. What it does is mainly to define a number of variables such as the package name, where to fetch the necessary source files, which programs are required for the compile to succeed and which libraries the resulting program will need to have present in order to run correctly. The file defines a few other variables too, and you can look up the exact meaning of each in the man pages, starting with man ports and man bsd.port.mk. 

With all relevant variables set, at the very end the file uses the line

.include <bsd.port.mk>

to pull in the common infrastructure it shares with all other ports. This is what makes the common targets work, so for example, typing

$ doas make install 

(probably the most common port-related make command for end users and administrators) in the port directory will start the process to install the software.

But before you type that command and press Enter, you may want to consider this: This command will generate a lot of output, most likely more than will fit in the terminal's buffer. If the build fails, it is likely that the message about the first thing that went wrong will have scrolled off the top of your screen and out of the terminal buffer. For that reason, it is good sysadmin practice to create a record of lengthy operations such as building a port by using the script command. Typing script in a shell will give you a subshell where everything displayed on the screen will be saved in a file. Escape sequences, asterisk-style progress bars and 'twirling batons' will end up a bit garbled, but that essential message you are looking for will be there too. man script will give you the details, and unless you're an incurable packrat, do remember to delete the typescript file afterwards.

That process will start with checking dependencies, go on with downloading the source archive and checking that the fetched file matches the cryptographic signatures stored in the distinfo file. If the signatures match, the source code is extracted to a working directory, the patches from the patches/ directory are applied, and the compilation starts. If the dependency check finds that one or more pieces are missing, you will see that the process fetches, configures and installs the required package before continuing with the build process for the original package.

After a while, the package build most likely succeeds and the install completes. At this point you will have a new piece of software installed on your system. You should be able to run the program, and the installed package will turn up in the package listings output by pkg_info, such as

$ pkg_info | grep screen
screen-4.0.3p3      multi-screen window manager

This information is taken from the package's subdirectory in /var/db/pkg, where the information about currently installed packages is stored.

If you paid close attention during the make install process, you may have noticed that the install step was performed from a binary package. This is one of the distinctive features of the OpenBSD version of the package system. The package build always generates an installable package based on a 'fake' install to a private directory, and software is always installed on the target system from a package.

And now we should mention that on a typical modern OpenBSD system, you wouldn't want to install GNU Screen at all. Since the OpenBSD 4.6 release, equivalent (or better!) functionality has been included in the OpenBSD base system via tmux(1).

But you don't need to do that!

This means several things. If you have built and installed a package by typing make install in the relevant ports directory and later run the make deinstall or pkg_delete to remove the software, any subsequent install of the software will take place from the package file stored in a subdirectory of /usr/ports/packages.

But more importantly, in most cases you can keep your system's packages up to date without a ports tree on the machine. The main exceptions to the rule that precompiled packages are available from the mirrors are software with licenses that do not allow redistribution or require the end user to do specific things such as go to a web site and click a specific button to formally accept a set of conditions. In those cases it cant' be helped, and you will need to go via the ports system to create a package locally and install that.

For each release, a full set of packages is built and made available on the OpenBSD mirrors, and by the time you read this, there is reason to hope that running updates to -stable packages will be available for supported releases too.

The way to make good use of this is to set the PKG_PATH variable to include the packages directory for your release on one or more mirrors close to you and/or a local directory, and then run pkg_add with the -u flag.

My laptop runs -current and I'm based in Europe, so the PKG_PATH is set to

PKG_PATH=https://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/packages/`uname -m`/

On a more conservatively run system, you may want to set it to something like

PKG_PATH=https://ftp.eu.openbsd.org/pub/OpenBSD/`uname -r`/packages/`uname -m`/

If you want to find out what packages are available at your favorite mirror, you can get a listing of package names by fetching the file $PKG_PATH/index.txt. Another nice resource is openbsd.app, which offers a nice clickable interface.

Once your PKG_PATH is set to something sensible, you can use pkg_add and the package base name to install packages, so a simple

$ doas pkg_add screen

would achieve the same thing as the 'make install' command earlier (minus the lengthy compilations, and still assuming that you would want to install the package instead of getting to know tmux(1), which is included in the base system), and most likely a lot faster too.

Once you have a set of packages installed, and keeping in mind that you need a meaningful PKG_PATH, you can keep them up to date using pkg_add -u. If you want more detailed information about the package update process and want pkg_add to switch to interactive mode when necessary, you can use something like this command:

$ doas pkg_add -vui

I have at times tended to run my pkg_add -u with some of the -F flags in order to force resolution of certain types of conflict, but given the quality of the work that goes into the packages, most of the -F options are rarely needed. pkg_add and its siblings in the pkg_* tools collection has a number of options we have not covered here, all intended to make your package management on OpenBSD as comfortable and flexible as possible. The tools come with readable man pages, and may very well be the topic of future articles. You should also be aware that Michael W Lucas's Absolute OpenBSD, 2nd Edition is available from better bookstores with a more in-depth treatment of the package system than what I've presented here. Look at the end of the article for further links.

How do I make a package then?
That is a large question, and the first question you should ask if you think you want to port a particular piece of software is, "Has this already been ported?". There are several ways to check. If you are thinking of creating a port, you most likely already have the ports tree installed, so using the ports infrastructure's search infrastructure is the obvious first step. Simply go to the /usr/ports directory and run the command

$ make search key=mykeyword

where mykeyword is a program name or keyword related to the software you are looking for. One other option with even more flexible search possibilities is to install databases/sqlports. And of course, searching the ports mailing list archives (https://marc.info/?l=openbsd-ports) or asking the mailing list works too. When you have determined that the software you want to port is not already available as a package, you can go on to prepare for the porting effort. Porting and package making is the subject of much usenet folklore and rumor, but in addition you have several man pages with specific information on how to proceed. These are, ports(7), package(5), packages(7), packages-specs(7), library-specs(7) and bsd.port.mk(5).

Read those and use your familiarity with the code you are about to port to find your way. The OpenBSD web offers a quite a bit of information too. You could start with re-reading the main ports and packages page at https://www.openbsd.org/faq/faq15.html, and follow up with the pages about the porting process at https://www.openbsd.org/faq/ports/, testing the port at https://www.openbsd.org/faq/ports/testing.html and finally the checklist for a sound port at https://www.openbsd.org/faq/ports/guide.html#PortsChecklist.

All the while, try first to figure out the solution to any problems that pop up, read the supplied documentation, and only then ask port maintainers via the ports mailing list for help. Port maintainers are generally quite busy, but if you show signs of having done your homework first, there is no better resource available for helping you succeed in your porting or port maintenance efforts.

One fine resource for the aspiring porter is Bernd Ahlers' ports tutorial from OpenCon 2007 (hm. doesn't that need a refresh?), you can look up Bernd's slides at https://www.openbsd.org/papers/opencon07-portstutorial/index.html, and it is possible he can be persuaded to repeat the tutorial at a conference near you. And for some recent advances in the OpenBSD ports and packages system, see Marc Espie's EuroBSDCon 2012 presentation Advances in packages and ports in OpenBSD.

More information on the net
The main source of information about the OpenBSD ports and packages system is to be found on the OpenBSD project's web site. The FAQ's ports and packages section at https://www.openbsd.org/faq/faq15.html has more information about all the issues covered in this article, and goes into somewhat more detail than space allows here. If you encounter problems while installing or managing your packages, it is more than likely that you will find a solution or a good explanation there. And of course, if nothing else works or you can't figure it out, there is always the option of asking the good people at misc@openbsd.org or ports@openbsd.org (do read the OpenBSD Mailing Lists page before just butting in) or search the corresponding mailing list archives.

---

An earlier version of this article appeared in BSD Magazine 2/2008. You can now also find this updated version featured at OpenBSD Journal (aka undeadly.org), the primary OpenBSD news site.

If you're interested in OpenBSD in general, you have a real treat coming up in the form of Michael W. Lucas' Absolute OpenBSD, 2nd edition. If a firewall or other networking is closer to your heart, you could give my own The Book of PF and the PF tutorial (or here) it grew out of. You can even support the OpenBSD project by buying the books from them at the same time you buy your CD set, see the OpenBSD Orders page for more information.

Upcoming talks: I'll be speaking at BSDCan 2013, on The Hail Mary Cloud And The Lessons Learned, with a preview planned for the BLUG meeting a couple of weeks before the conference. There will be no PF tutorial at this year's BSDCan, fortunately my staple tutorial item was crowded out by new initiatives from some truly excellent people.