On Thu, Jan 8, 2009 at 6:43 PM, Kory Wheatley <[email protected]> wrote: > I would like to know other system admins patch strategy for > installing Solaris 10 Patches. Typically, we install the Sun Alert > Security Patches on our test systems then try to roll them out > within 30 days of the patch coming out. We only do recommended > patches when needed by software on the system or if required as a > dependency patch
Another mechanism to consider is requesting that Sun run an SRAS audit against a representative system. While security is an important aspect of system availability, the recommendations that come from an SRAS audit (in particular EIS analysis) can be useful. This has the most value on systems that fall out of the range covered by the Recommended cluster. For example, for years neither the Sun Alert bundle nor the Recommended bundle had patches for ge or ce network drivers. However, when network performance problems were detected patching the network drivers was almost always the first step toward resolution. Throw in some high end (e.g. E25K, M8000) servers or SAN drivers and you will get even further from the ground covered by the Sun Alert and/or Recommended bundle. > Also do you break your mirror to install the patches on one disk and > test than sync back up (either using Solaris Volume Manager or a > hardware mirror)? Do you only do this for Kernel patches and > Solaris 10 Update patches? It would seem time consuming breaking > the mirror to install all security patches, but I don't know what > others are doing. We recently don't use this method. Live upgrade. The EIS boot disk layout[1] is the mechanism that I have used for years - even before it was Sun's recommendation. It works well. If you are doing a split mirror, be sure that you make the split mirror bootable before you need it. That is, split, mount at /mnt, metaroot -R /mnt, umount /mnt, THEN patch. 1. http://wikis.sun.com/display/BigAdmin/BootDiskLayout With ZFS root, Live Upgrade becomes much cooler. Creating a new fully functional boot environment takes seconds (if you include the time required to type "lucreate" with a couple options) and takes up a trivial amount of space. Of course, if you put a gig of patches in it, it will grow. However, it makes it feasible to have many boot environments in the space previously required to store only two. > I would just like to get a feel if other System Admins are > aggressive in installing the security patches as soon as they come > out? Versus why break it if it runs. My preferred approach is to harden the system such that it is only the very occasional network-based attack on ssh or other must-have services that will have a high likelihood of being exploited. Establish good identity management practices so that only those that should have access to the system have it and they are all done through named (not shared) accounts. Lock out people that shouldn't have access as soon as their need for access ends. With that, the need to apply the latest patches (for e.g. Java applet vulnerabilities, again) tend to not look very important. Secure by Default and JASS can be your friends here. Since you are coming from a .edu, the case where you have hundreds or thousands of students accessing as system needs to be covered as well. In that case, patching the locally exploitable bugs becomes much more important but will never be a complete solution. Without policies in place that give you a way to get rid of authorized users that misbehave, you have little chance of having a long-term secure system. Get to know the relevant computer use and misconduct policies and work with those that can help you enforce them. One interesting approach suggested by Bob Netherton is to have three boot environments at all times. - The previous "good" boot environment - The current running boot environment - The next boot environment Whenever a patch has passed your QA process, apply it to the "next boot environment". That is not to say that you activate it at that time. This prepares you for always being ready to activate it when the outage window comes, or when threat level associated with the patches you have already applied (but not activated) suddenly increases. At such a time as you activate your next boot environment and you are happy with it, destroy the oldest boot environment and create your new next boot environment. -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ sysadmin-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss
