Binary patches with BinpatchNG
Contributed by jj on Mon Jan 14 08:01:26 2013 (GMT)
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.
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
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:
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 <email@example.com>
Now we can also have a look at the actual code of the patch that was
$ 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
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 firstname.lastname@example.org, I just lost that info along the way while editing. Sorry for that
<< Debugging the OpenBSD kernel via QEMU | Reply | Flattened | Expanded | Hibernate on amd64 >>
Re: Binary patches with BinpatchNG (mod 8/30)
by Gerardo Santana (santana) (email@example.com) on Sun Jan 13 20:48:01 2013 (GMT)
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.
[ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]
Add Story |
Copyright © 2004-2008
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 April 2nd 2004 as well as images
and HTML templates were copied from the fabulous original
Jim's kind permission.
Some icons from slashdot.org
used with permission from Kathleen.
This journal runs as CGI with
on OpenBSD, the
source code is
Search engine is ht://Dig.
undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]