Please create an account to participate in the Slashdot moderation system


Forgot your password?
Upgrades BSD

Making OpenBSD Binary Patches With Chroot 66

Lawrence Teo writes "Unlike other operating systems, patches for the OpenBSD base system are distributed as source code patches. These patches are usually applied by compiling and installing them onto the target system. While that upgrade procedure is well documented, it is not suitable for systems that don't have the OpenBSD compiler set installed for whatever reason, such as disk-space constraints. To fill this gap, open source projects like binpatch were started to allow administrators to create binary patches using the BSD make system. This article proposes an alternative method to build binary patches using a chroot environment in an attempt to more closely mirror the instructions given in the OpenBSD patch files."
This discussion has been archived. No new comments can be posted.

Making OpenBSD Binary Patches With Chroot

Comments Filter:
  • by Anonymous Coward on Monday March 26, 2007 @07:23PM (#18494927)
    This is a lot like existing techniques, such as Gentoo's installation sandbox: first, a package is installed in a temporary file system, and changes made during the installation are then merged into the live filesystem (if installation was succesful, and none of the newly added files conflict with files already installed).

    Furthermore, the FreeBSD manual recommends a similar procedure for automated building of package lists (lists of files installed by a package): create a regular port, install it into a temporary copy of a base filesystem, and use mtree to figure out what files were modified during the installation process. In this case no chroot environment is used, since ports are expected to honour the installation prefix (given in PREFIX).

    So it's a pretty well-established technique; I'm not even sure using it to upgrade the base system is novel: as of late, FreeBSD provides binary updates to its operating system in addition to the traditional source upgrades (and binary releases), although I'm not sure how these packages are created.
  • Re:disk constraints? (Score:3, Informative)

    by QuantumG ( 50515 ) <> on Monday March 26, 2007 @07:33PM (#18495001) Homepage Journal
    OpenBSD is primarily used for firewalls. The purpose of a firewall is to do essentially nothing 'cept route and filter packets. As such, the cheapest least broken hardware is typically used. Some people (*cough* Steve Wozniak *cough*) even see embedded firewall devices that run OpenBSD. They run entirely off flash memory.
  • Re:disk constraints? (Score:4, Informative)

    by ArbitraryConstant ( 763964 ) on Monday March 26, 2007 @08:33PM (#18495599) Homepage
    Yup. We do this at work (no link because I'm not spamming). We sell OpenBSD firewalls on minimal hardware (about the size of a broadband router, low power enough to be fanless), and then sell various services on top of that. You can do a surprising amount.

    We use flash memory, and the space and rewrite cycle requirements for compiling on this are prohibitive.
  • by gwolf ( 26339 ) <gwolf.gwolf@org> on Tuesday March 27, 2007 @12:19PM (#18502567) Homepage
    Gerardo Santana worked on a project implementing binary patches for OpenBSD [] at least since 2001. His code is quite reliable, IIRC he basically lacked the needed machines to create the patches for all the OBSD officially supported architectures.
  • Re:Packages? (Score:3, Informative)

    by evilviper ( 135110 ) on Thursday March 29, 2007 @05:50AM (#18526145) Journal
    The *BSDs package management is better than any other I've seen, and far better than Slackware's pkgs, which don't manage dependencies at all... OpenBSD just doesn't use packages for the base system (dist sets instead), and doesn't provide updated binaries (for manpower reasons), only source.

    Maintenance actually gets easier, the more machines you have. If you need to build from ports for some reason, you only have to do it once, and can distribute the generated packages across as many systems as you want. Ditto for updating the base system, you just have to build it, then you can make dist sets to distribute.

    You're not even a good troll.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (9) Dammit, little-endian systems *are* more consistent!