OpenBSD Journal

Binary patches with BinpatchNG

Contributed by jj on from the can-I-upgrade-my-boss-with-this dept.

Binary patches with BinpatchNG

For many server administrators it may not be desirable to keep a full src tree around to update a system when an errata is published. While this may still be something that could work out just fine on large/fast servers, it's a dreadful task to do this on embedded systems or servers with little diskspace (like CF storage) or limited CPU power (Soekris, Alix, etc).
That's where binpatches (short for binary patches) come into play, they allow for patching a system by just installing the patch (and reboot if needed). The binpatches can be built on a fast machine and then deployed to a range of servers (running the same architecture).

This article will serve as a short introduction to binpatches, and m:tier's BinpatchNG in particular.

Introducing BinpatchNG

The original idea of implementing binary patches for OpenBSD was coded by Gerardo Santana, after which Felix Kronlage has added various new features such as the ability to sign packages as well as initial rollback support.
We at m:tier have been using Felix' version for several years for our customers. Gradually some extra features were implemented which we decided to release to the public last year. Among these new features were:

  • Fine grained rollback support. Since rollback packages can take up a lot of space (which may cause issues on smaller CF cards for example), it may be preferable to completely disable rollback support, or to only have it enabled for kernels, or enable it for every component.
  • A new naming scheme was adopted which allowed us to update and replace binpatches just like regular packages people install with pkg_add(1). Because binpatches are cumulative in nature, a new binpatch for a component, say the kernel, always includes all previous patches for this component. With this new scheme it's possible to just update the binpatch package to the latest available version; instead of having several binpatches "chained together" to finally result in the final desired state. This is acquired by adopting the usage of pkgpath's, just like packages built from ports.
  • Improved display of what's going on while fetching the distfiles, patches etc. This gives a better view of what's actually going on while bootstrapping the build environment and while building the binpatches.


In order to build a new binpatch, the build environment needs to be set up first, this is done with a simple
	make extract
This will fetch the sources and base sets and extract them. Now the patch which is to be used in the binpatch needs to be added to the Makefile after which it's simply a matter of executing the following command to build and create the binpatch:
	make package
What's great about binpatches as regular patches, is that you can query them like any other package:
      $ pkg_info binpatch52-amd64-bgpd-1.0
      Information for inst:binpatch52-amd64-bgpd-1.0
      Binary Patch for 001_bgpd.patch
      Patch(es) included in this package:
      Maintainer: m:tier <>
Now we can also have a look at the actual code of the patch that was installed:
	$ cat /var/db/binpatch/5.2-001/patches/001_bgpd.patch


Another advantage of using Binpatches becomes obvious when managing systems with Puppet. As now it's become just a matter of adding the new binpatch to the list of packages that need to be installed on a machine in order to deploy the binpatch. For example:


m:tier has been publishing pre-built binpatches for OpenBSD/amd64 and OpenBSD/i386 since 5.2, this allows for a quick 'pkg_add' when an errata has been issued.

While we do our best to ensure transparency (the patches used to build a binpatch are installed into /var/db/binpatch/) it's understandable policies may forbid installing packages from third parties. That's why in addition to providing the pre-built patches, we published the framework which is used to build this patches on.

Late edit: All this was submitted and written by, I just lost that info along the way while editing. Sorry for that

(Comments are closed)

  1. By Gerardo Santana (santana) on

    Nice work :)

    We can go even further, with the OpenBSD Team help, to periodically and automatically update the Makefile with the new patches.


    * a file or files with a *simple format* for specifying the new patch (number, name, architecture, OpenBSD version, description, patch location)


    * errata HTML pages
    * web feed (RSS, atom, etc.)


    * no more manual HTML editing for adding entries to errata.html. That means less human errors and more time for coding
    * provide a standard way to publish updates. OpenBSD users could stop web scraping errata.html and use a more robust way to update whatever tools they use

    Yes, I can write/document/maintain it.

  2. By Mattieu Baptiste (mattieu) on

    How BinpatchNG behaves in case of an upgrade? Should you remove BinpatchNG packages before upgrading the system?

    1. By Jasper (jasper) on

      > How BinpatchNG behaves in case of an upgrade? Should you remove BinpatchNG packages before upgrading the system?

      In case of an upgrade from OpenBSD X.Y to X.Y+1 ? Yes, they should be removed.
      This is actually a case I hadn't considered yet as in our setup this is not an issue. It's something inherited from the "previous" Binpatch-framework, though it could use some thought.


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]