Just a quick question, say if you got 3.9-stable can you binary upgrade it to 4.0-release using the CD? (Or, perhaps, FTP?)
2007/3/18, J.C. Roberts <[EMAIL PROTECTED]>:
On Sunday 18 March 2007 01:55, Darren Spruell wrote: > On 3/18/07, Maurice Janssen <[EMAIL PROTECTED]> wrote: > > On Friday, March 16, 2007 at 19:34:59 -0700, J.C. Roberts wrote: > > >Running "A.B-RELEASE+Patches" is very similar to "A.B-STABLE" > > > since the user applied patches (available on the errata.html > > > page) are included withing the -STABLE branch of cvs but the > > > differences is the -STABLE branch of cvs also includes > > > additional, less important bug fixes that were not note worthy > > > enough to have an errata entry. The reason why patches are made > > > available individually on the errata.html page is because some > > > people are required to follow a policy of making *only* the > > > minimal required changes to machines used in production > > > environments. (i.e. "If it's running properly, don't mess with > > > it"). > > > > One more question about this: is it supported to run a stable > > kernel on a system that is release or release+errate? > > Although there are only (typically) slight differences between > -stable and release+patches, they shouldn't be considered the same. > > > I have a test system tracking 4.0-stable (through anoncvs) and a > > few systems that are running 4.0-release with some of the errate > > applied (all kernel errata, but I skipped some others that I feel > > are not needed, like the httpd-patch on systems not running httpd). > > As an alternative to compiling the kernel on these systems, I could > > copy the 4.0-stable kernel. Is this supported? > > As for supported, I don't know. One is not the same as the other. > You'll be doing yourself a favor by not mismatching your kernel and > userland. Sooner or later, you will be bitten I agree with Darren on this. Mixing and matching is just asking for trouble. Yes, you can get away with it in a few limited situations but sooner or later it cause you a lot of headaches. In fact, the way your are doing things now, namely just applying the needed/relevant patches to each machine and compiling on each and testing on each is the hard and time consuming way to do things. Running A.B-RELEASE+patches is an *extremely* conservative approach to system administration of production systems. Personally, I think the approach is unnecessarily conservative and time consuming since you should be testing everything prior to putting it into production, and running A.B-STABLE is far easier to maintain. The only valid reason I can think of to run A.B-RELEASE+patches is if you are required by company policy to make the absolute fewest number of changes to production systems between upgrades. I personally do not know one single sysadmin that must live under such strict company rules but I'd guess they exist. If you are not forced by policy to make minimal changes to production, then you are much better off to be running -STABLE. The -STABLE branch of cvs is exactly as it's name implies, stable. You get all of the errata fixes as well as some minor bug fixes that were not note worthy enough to issue an errata (i.e. a small bug fix to a driver that you don't use will not affect your system behavior). When you take the time to learn the release(8) and keep your one single cvs -STABLE checkout up to date, your life becomes really easy and headache free. Rolling out your home made release(8) to multiple systems is damn easy and you can automate lots of it including your own personal customizations and/or configurations. You build once. You configure once. You roll your own release once. You test once. Then you deploy to all your machines and go sit on the white sand beach in a lounge chair to sip your blue exotic drink with a little paper umbrella. Easy. Well, it's easy unless you prefer drinking mai-tais or don't like little paper umbrellas but then again, of course you're free to alter the above the recipe to your tastes. You may want to note that *my* approach of running -STABLE is considered by many on this list to be "unnecessarily conservative" and I have to admit they are probably right. Unlike other projects, the -CURRENT branch of OpenBSD is extremely stable for production use. Over the years I've had a lot of people tell me that they just download the available snapshots of OpenBSD -CURRENT from FTP to run on their production servers. It works. And I've never seen a single horror story about problems endured by running OpenBSD -CURRENT in production. At times I wonder if the only acceptable excuse I have for running -STABLE rather than -CURRENT is the little paper umbrellas. ;-) Kind Regards, JCR
-- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
