OpenBSD Journal

Tepatche - Automatic OpenBSD system patching

Contributed by jose on from the keeping-up-to-date dept.

Gunnar Wolf writes :
"I have been developing a script to automatically patch OpenBSD installations, aimed mainly at sites running large numbers of OpenBSD machines. Although this program will never replace a security-conscious system administrator (in fact, it acts quite like a brain-dead one ;-) ), it will surely help many people manage the patching system.
Read on ...

If you are interested, please visit

I quote a bit of information from the web site:

RATIONALE OpenBSD is a stable, robust and secure operating system. Systems administrators running OpenBSD tend to be also more security conscious than administrators running other operating systems. Nevertheless, patching an OpenBSD system can be a tedious process for many people. If a person manages multiple OpenBSD servers, patching each of them can be a long and repetitive task, ideal for automatization. Tepatche will periodically check the FTP site we indicate it to, and if there is a new patch to be applied, downloads, applies, builds and installs it. Tepatche mantains a small status database to know in what is the status of each of the system's patches.


  • Tepatche is released under a BSD license - read the COPYING file.
  • This is EXPERIMENTAL code. It works for me. However, it is code intended to be run as root and to modify vital system binaries, and a programming error can have nasty consequences.
  • Tepatche assumes that the patches published in the specified ftphost is trustable. If the ftphost (typically or one of its mirrors) were to be comprimised, anything can happen.
  • If applying a patch requires kernel compilation, the system administrator MUST DO SO MANUALLY. Tepatche will patch the sources, but building the kernel involves many steps that do require manual operator involvement.
  • "
I'm a bit gunshy about automatic updates, I tend to do this only after careful automatic review of the changes. This is even more so during hackathons and the like. Still, this can be useful if you have a farm to maintain, especially with the severity of recent security flaws.

(Comments are closed)

  1. By Anonymous Coward () on

    1. I, like many other people, don't keep my sources in /usr/src. Same with obj - it's usually located in /tmp/obj (/tmp is a mfs filesystem). Would be nice to make it configurable. Even better - just read /etc/mk.conf and fall back to the default paths if mk.conf does not contain BSDSRCDIR and BSDOBJDIR variables.

    2. I think it would be better to send the report to standard output and let cron deal with mailing the admin - why reinvent the wheel?

  2. By chris () on

    i thought about doing this myself a while back, not for public consumption but for my own sanity. Looks like once again, thing of anything and it's most likely already been done. Haven't tried this out but I will definately give it a go and I'll report back my findings. This would be excellent for a fresh install from a cd.. to get up to date, for those of us who don't use -stable or -current. What?! I haven't tamed the CVS beast yet.


    would be nice if this type of utility was more integrated into the project, possibly having a file on mirrors which lists patches, and versions that have been upgraded (ie the recent openssh business) This could be done via cvs. I mean I understand security really should be in the hands of the admin, but for the lonely home user, a util would be nice.

  3. By Anonymous Coward () on

    Would it be possible to chesk patches on local filesystem in specified directory ( without running my own ftp server )? I like the idea of automatics patching, however I want download/check patches manually.

  4. By Chris Lewis () on

    Nice idea. It's something I've wanted to write myself (as some others have said, too) for a while, but have never really got around to it. When I'm not at work I'll check out the source.

    I think OpenBSD's patching system was just asking for automation in this way for us lazy admins (or those with huge server clusters they want looking after :).

    Looking forward to poking at it.



  5. By WB () on

    I thought it might be nice to pre-seed the ports systems with patch names (openbsd-3.1-patch4) and have the patches match those names (would require coordination of the developers). Maybe assume 100 patches for pre-seeding. When a patch comes out, just go to the directory and run make. Ports magic does the work. I just don't know the ports system well enough.

  6. By JC () on

    I guess people might feel alot safer if there was a patch signing process...

    I guess it could be as simple as having the admin sign the patches before putting them in the ftp patch repository using gpg for example and having tepatche simply verify the signature before running the patch and verify against the public key(s) stored locally by tepatche.

    Heck, perhaps the OpenBSD team might even put out signed versions of the patches...

    I think it might represent an acceptable amount of coding considering the safety it would bring...


  7. By Matt Van mater () on

    I've been thinking about doing this for some time now, and just today as i upgrade my firewall from 3.0 to 3.1 (and the hell of upgrading and patching everything on a slow system) i saw this post!

    I was thinking to myself how I kinda want to go over to gentoo and play around with their feature which is like this. now i won't have to! For a while i was thinking about looking into porting freebsd's portupgrade over to openbsd. maybe we can combine these two tools to effectively get gentoo's 'emerge update' functionality on our openbsd boxen!

  8. By Thxix () on

    First and formost, i would like to thankyou for writeing this scrypt. i think alot of us have been wanting to do it, but never did. anywas its running on my laptop now and is working great. but i do have one problem/suggestion. tepatche seems to fail on systems that already have some patches applyed, maby a work-around for this would be a good idea, or even a command line option... just a thought. anywas thanks it works great... keep up the good work.

Latest Articles


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.]