Slashdot Mirror
Making OpenBSD Binary Patches With Chroot
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."
Linux patches are also distributed as source code. Indeed, isn't this the old skool *nix way, full stop?
The submitter is just pumping up clicks to his own site. You'll notice that he's also the author of TFA. I don't see that this is a particularly useful system, since you'd just be building binaries on another box anyway. If you're going to do that, you might as well just build an upgrade CD and upgrade through the normal process.
"Please describe the scientific nature of the 'whammy'" - Agent Scully
I still use version 2.3, I refuse to run an OS that has a blowfish as its mascot.
Most open source operating systems deliver their patches primarily as source code. I know Free and Net BSD and Linux provide source based patches. In fact, if you track the FreeBSD security announcements and errata information, you download a source code patch in the form of a diff file. To apply the patch, simply make certain you have downloaded the source code in the /usr/src directory and use the patch command. From there, the diffs are applied and you can run make to recompile the patched section. The commercial Linux vendors like Red Hat and SuSE provide binary patches for convenience purposes. The author of this article really should do more homework before making the statement that he did. Personally, I like the patch and compile method. I do know that this is a more secure way of supplying patches because you can read the source code and it makes delivering malware harder. I like to see what is going on behind the scenes.
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.
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.
How we know is more important than what we know.
Thats a questionable statement, that OpenBSD is primarily for firewalls.
I'm writing this on an OpenBSD 4.1-current laptop (IBM A31p ThinkPad) and
have used OpenBSD exclusively since 2001 for all my desktops. A lot of
people are discovering that OpenBSD does really well as a desktop. With
the introduction of 4.1, Open Office is supported, not to mention KDE,
media stuff, a really outstanding population of wireless cards, etc. I
think there are people who think of OpenBSD as a just a firewall; as
good (well, wonderful) as pf is, there is so much more there.
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.
I rarely criticize things I don't care about.
This is the beauty of peer review, especially from a group as vicious as Slashdot. I imagine the author of this process was so pleased with himself and excited to share his ingenuity with the world, only to submit it here and have his ideas stomped, blasted, toasted, dragged through mud, and rendered to pieces. Not that I would suggest we do anything different, but sometimes I cannot help but to admire the crucible that is public forum.
Why bother.
I consider OpenBSD my primary desktop OS. Now, having used systems like Debian, I must admit yours is a question that's difficult to answer. I probably can't come up with one that is compelling for all people. But I can take a stab at how I feel about the issue.
/etc/rc.conf. This is accomplished by developers hand tweaking the default config file and the shell scripts that take action upon it. The typical Linux solution is to have the package manager rather chaotically add to /etc/init.d and /etc/rc.* at the whim of potentially thousands of different package authors. There are pros and cons to both approaches, but, it all boils down to a philosophical difference. And between BSD and Linux, there are many philosophical differences. I think a lot of them boil down to the contrast between chaotic and very conservative development.
If I could use a few words to describe the interaction of base system packages on Linux with the equivalent on BSD, I could describe the BSD scheme with words like "small", "simple", "cohesive", "compact". Although many different software packages are in fact pulled from many different sources (gcc and Xorg are some important examples), there is a sense of it all belonging to a single unit. It is developed together, in the same source tree. If you look at header files, or config files for various daemons, or the source tree itself, or whatever, you get the feeling that it is all one big unit.
If BSD is all these things, then Linux package management can be described as somewhat more "chaotic". This is both good and bad. It is good in the sense that different packages can be developed, configured, and upgraded separately in the base system. This has some benefits, sure. But you also lose some of that cohesion. A simple example: on OpenBSD, you can configure all of the preinstalled daemons in the base system with one fell swoop, by editing the config file
So, I don't know if I have conclusively answered your question, but this is a small part of my view on the subject.
It might be nice for OpenBSD to provide binary patches. They do, after all, provide binaries for lots of packages in ports. It might also be worthwhile to remember that OpenBSD is relatively small, relatively developer-oriented, and not a rich project. It might not be worth the effort to put lots of different binaries online when they can focus their energies on improving -current.
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.
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.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant