There are a few Blueprints on patching you might consider reading.

I'll add another voice to the call for LiveUpgrade. It will save you.

I take a slightly different view for patching production systems. We strip the 
system down during install (no SUNWCxall for us, start with SUNWCrnet) and then 
apply all patches as of a given date, with a quarterly update to the latest 
patch set.

Patches run in dev and then once they're certified (give them a few weeks for 
people to discover bugs) then we roll out to production. Critical security 
patches that actually effect us are rolled as fast as possible, but still have 
to go through dev to ensure we're not going to end up bricking production. 
Obviously, change time scales to whatever your site is comfortable with.

Installing all the patches (using something like smpatch or patch check 
advanced (pca)) gives a couple of advantages:
* Calling for support is less likely to end in "install patch XXXXX-YY".
* Everything is patched, so if someone gets unprivileged login, they can't turn 
that into root (I'd not install rsh and similar SUID tools, but that's not an 
option if I want snoop).
* Similarly, for services that are otherwise disabled, if someone turns them on 
you're not immediately exposed.
* If all your machines are on the same baseline of a full set of patches, 
you're less likely to see inconsistent behavior between hosts.

The downside is that sometimes you will be the one to discover new bugs.

Using something like the full EIS baseline (which is usually released somewhere 
around the last Tuesday of the month) can also help reduce your chances of 
getting bitten as they're tested somewhat more within Sun.

You might also find the following enlightening: 
http://blogs.sun.com/barts/entry/rethinking_patching

Paul
-- 
This message posted from opensolaris.org
_______________________________________________
sysadmin-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss

Reply via email to