Re: moving kernels between machines
Wow , that openbsdbinpatch looks pretty good! I 've just downloaded it and the idea of making binary patches in order to easily copy them to other similar machines is excellent. It would be great if openbsdbinpatch could be configured like TEPATCHE specifying the folder where to get the patches from, instead of specifiyng patch by patch in the Makefile, so it could be used to patch any OpenBSD version, not just the last one. Perhaps someone with some programming skills could do it. BTW , TEPATCHE is an Automatic Patcher for OpenBSD, it can be downloaded from http://www.gwolf.org/soft/tepatche/index.html Regards, Marcos Laufer - Original Message - From: Tasmanian Devil [EMAIL PROTECTED] To: OpenBSD misc@openbsd.org Sent: Friday, January 05, 2007 5:42 AM Subject: Re: moving kernels between machines - Machine A, a single i386 box without enough disk space to unpack the source tree http://openbsdbinpatch.sourceforge.net/ :-) Tas.
Re: moving kernels between machines
- Machine A, a single i386 box without enough disk space to unpack the source tree http://openbsdbinpatch.sourceforge.net/ :-) Tas.
Re: moving kernels between machines
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/5/07 12:42 AM, Tasmanian Devil wrote: - Machine A, a single i386 box without enough disk space to unpack the source tree http://openbsdbinpatch.sourceforge.net/ :-) Thanks much for this, and also for Nick Holland's excellent suggestion about keeping updated with -release. Paranoid question: How does a user know which binpatches to trust? dn iD8DBQFFnpCayPxGVjntI4IRAugUAJ4gN67UZGnyRgxfuvtk9BFvix2q5wCaA+gD 2Oe+vTwBToPP7J6IxDyf7vA= =LtR5 -END PGP SIGNATURE-
Re: moving kernels between machines
Paranoid question: How does a user know which binpatches to trust? I'd say you should at least trust the ones you've build yourself on your Machine B. ;-) Tas.
moving kernels between machines
I have two machines: - Machine A, a single i386 box without enough disk space to unpack the source tree - Machine B, a two-CPU i386 box running bsd.mp with plenty of disk My questions: 1. For purposes of applying kernel security patches, can I compile a patched kernel on Machine B and just transfer it over to Machine A and reboot? 2. If the answer to (1) is yes, what if anything do I need to do with userland on Machine A? For example, how would I apply patch 001 for 4.0, which is just for httpd? many thanks dn
Re: moving kernels between machines
David Newman wrote: I have two machines: - Machine A, a single i386 box without enough disk space to unpack the source tree - Machine B, a two-CPU i386 box running bsd.mp with plenty of disk My questions: 1. For purposes of applying kernel security patches, can I compile a patched kernel on Machine B and just transfer it over to Machine A and reboot? Of course... :) 2. If the answer to (1) is yes, what if anything do I need to do with userland on Machine A? For example, how would I apply patch 001 for 4.0, which is just for httpd? IF you really know exactly what files are altered, build 'em on your fast, big machine and copy them over to your small machine, making sure you get permissions and such correct. IF you do not know for sure which files are altered, I'd suggest just making your life simple, and follow stable, make a release, and install that on the small machine (and any others). When staying with stable, the process is trivial: unpack all .tgz files (don't forget the 'p' option!!), install the kernel, reboot. If your big, fast machine has some time when no one would notice, you might even want to set it up to periodically make a -stable release for you (yes, the official instructions say reboot between building the kernel and the userland, but since the API doesn't change in -stable, you can almost always get away without the reboot. In fact, on my -stable build machine (actually, a VMware session) at work, I only reboot the thing to make sure the build is good before installing it on a critical machine. AGAIN, if you know exactly what subset of things need to be patched, (for example, httpd), you could just stop and start that one service, but usually, by the time you have figured that all out, you could have just rebooted. See: http://www.openbsd.org/stable.html http://www.openbsd.org/faq/faq5.html , especially sections 5.1, 5.4 http://www.openbsd.org/faq/faq4.html#AddFileSet Nick. (who runs ONLY enough -release/-stable to verify the upgradeXX.html instructions are valid)
