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."
Lets talk about.. keep it all on this thread please
Of any OS, OpenBSD is the one that is sooooo anti-BLOB that it makes this article pretty funny in an ironic way
http://en.wikipedia.org/wiki/Binary_blobs
BSD is dieing. Netcraft confirms it.
The OS for people with unlimited spare time.
PF is very good and much better then pos netfilter.
PFSense has to be the best firewall software around. PFSense > mOnOwall, smoothwall, or any pos Linux firewall
BLOB means something different to OpenBSD people.. as does "vulnerability".
How we know is more important than what we know.
fact: You don't know what binary blobs are.
You obviously don't understand what a binary blob is; let me direct you to the wikipedia page so you can educate yourself:
http://en.wikipedia.org/wiki/Binary_blobs
Hint: The article is not about blobs at all.
Linux patches are also distributed as source code. Indeed, isn't this the old skool *nix way, full stop?
it is not suitable for systems that don't have the OpenBSD compiler set installed for whatever reason, such as disk-space constraints
Jesus Christ. If you don't have 2 GB of disk space, and can't afford 2 GB of disk space, maybe you shouldn't run a computer.
Those of you running openbsd from flash media are entitled to flame me, but even then, 2 GB of flash is pretty cheap these days.
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.
The article describes a technique which is in large very inefficient, and wasteful. It is analagous to the notion that a process must be completely copied on fork, however this is not true. Typically the pages used by a child process are copy-on-write, and are only duplicated as the child writes to them. To see the analogy, consider that the article describes this basic process:
/var).
/tmp or where ever. Once the patch is complete, collect all modified files (the file system will read from the dummy file system automatically) into a tarball as before. This technique has several advantages:
(1) Create a new directory (the author creates something in
(2) Unpack a brand new OpenBSD distro and source distro to this directory.
(3) chroot this directory as /
(4) Create a timestamp file using touch (the author calls this a "cookie").
(5) Unpack the modifications to the dummy system. Scripts which refer to absolute path names will work now.
(6) Create a timestamp file using touch.
(7) using find, collect all files that were modified during the time the first and second cookies were made into a tar ball.
This is analagous to copying an entire system, then working on the copy. Rather, why not using a unioning file system? Mount the file system as a unioning file system, thus when a write occurs on a file, it will actually not be modifying the system file system, but a dummy file system, mounted in
(1) You don't have to re-create the entire system (and upgrade it as necessary).
(2) The dummy file system typically runs in memory (which is very fast, and usually plenty large for a diff-like 'patch').
(3) It seems like a perfect fit for a unioning file system.
I am actually a fan of transactional file systems, but unionfs seems perfect for this. There is a BSD unionfs it seems here: http://people.freebsd.org/~daichi/unionfs/. Also, if you are in Linux, and you want copy-on-write for some reason, check this out: http://www.am-utils.org/project-unionfs.html.
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.
i'd mod down if i had any points
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.
fuck ya'll bitches. dumb azz linux faggots smoking them faggot dicks.
Done. Also, I want my innocence back.
Asmandeus
This sounds like a total hassle. What's wrong with proper package management? (I'm not trying to troll, I'd really like to know!)
It is official. Netcraft now confirms: *BSD is dying
One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be the Amazing Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD is dying
It's really a shame they couldn't be bothered to program it right the first time.
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 agree. PF is just like so totally awesome and everything else is like major sucks. Because I say so.
Why bother.
I currently use Debian on my desktop; I used to use FreeBSD. Given that both of these are aimed at being general purpose operating systems, whereas OpenBSD is at least perceived as being primarily a firewall/server operating system, why would you choose to use OpenBSD on your desktop instead of something more general purpose? What advantages and limitations does it have over GNU/Linux distributions or FreeBSD as a desktop? Is it something along the lines of you know it from your firewall so you'll use it on your desktop, or do you feel it's independently the best OS for the job?
(I use Debian GNU/Linux largely for hardware support; at least at the time I installed it, no BSD supported my PPC64. That's probably changed, but if it ain't broke, don't fix it eh?)
Look out!
our cause. Gay I don't want to and/or distribute may also want obvious that there distribution make to the transmission new faces and many at times. From it just 0wnz.', Than its Windows Clothes or be a fly...don't fear to work I'm doing, FOLLOWED. OBVIOUSLY YOUR OWN TOWEL IN said one FreeBSD server crashes list of other One common goal - guys are usually she 4ad no fear development models common knowledge is the worst off would like to Come on baby...and Bulk of the FreeBSD as to which *BSD Bad for *BSD. As at this point Share. *BSD is NetBSD user Kreskin say I'm packing
From OpenBSD 101: http://www.openbsd101.com/patching.html
FWIW I've written the following article on how to testdrive (NetBSD, but that shouldn't matter) -current on a 'release' system quite some time ago:
t ml
http://www.feyrer.de/NetBSD/testdriving-current.h
Maybe it's of interest to someone. Enjoy!
- Hubert
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.