Solaris Patching Policy Overview
This documentation can be redistributed and/or modified under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version.
Unless required by applicable law, this documentation is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
This documentation should not be used as a replacement for a valid Oracle service contract and/or an Oracle service engagement. Failure to follow Oracle guidelines for installation and/or maintenance could result in service/warranty issues with Oracle.
Use of this documentation is at your own risk!
Patching Policy for Solaris (January 2011)
Solaris Patching overview
- Patches installed to correct a problem or issues within either the hardware, the OS, and/or OS related applications.
Corrective patching is driven by hardware and/or software problems or issues. The patch set installed for a corrective action should be limited to those patches related to the problem being worked on. By limiting the patches to a minimal patch set, there is a reduced chance of creating additional problems during the corrective action.
When reasonable, every effort will be made to schedule the downtime to install the corrective patches during the normal maintenance window or after hours, but, depending on the severity of the problem at hand, corrective patching can occur at any time, and sometimes with very little warning.
Preventive (Maintenance) patching
- Patches installed to help prevent known problems and issues from occurring within the hardware, the OS, and/or OS related applications, or to support new functions, hardware, and/or devices.
Oracle releases Critical Patch Updates and Security Alerts (CPU) 3 to 4 times a year. As new CPU are released, preventive (maintenance) patching should be scheduled for all of the Solaris servers and zones in order to prevent known bugs and security issues from occurring.
In addition to installing patches as new CPU are released, some additional patching may have to occur between CPU releases to support new hardware, functions and/or devices.
As opposed to corrective patching, which can occur at any time and with little warning (depending on the severity of the problem at hand), preventive patching should always be scheduled in advance to prevent conflicts with other work or maintenance. Production servers and zones should always be scheduled during the maintenance window. Test servers and zones can be patched after hours during the work week when it is agreed by all affected parties. Otherwise, test servers and zones should be scheduled during the maintenance window.
Solaris has a process called LiveUpgrade that creates and updates an Alternate Boot Environment (ABE) on a alternate set of boot disks. This allows patching of the ABE while the Current Boot Environment (CBE) remains running and unchanged. A reboot using the ABE is required to implement the patches, at which point the ABE becomes the new CBE, and the previous CBE becomes the Previous Boot Environment (PBE). As long as no changes occur in the new CBE that are incompatible with the PBE (for example no upgrades to Zpool, ZFS, Databases, Solaris Cluster, etc.), if a significant problem occurs with the new CBE, the PBE can be rebooted, and the running system is returned back to the point before the LiveUpgrade process occurred. To facilitate the ability to rollback to the PBE, no incompatible changes to the CBE should be made for at least 1 week after implementing the CBE.
Traditional patch process
While most patches can be implemented using LiveUpgrade, there are some patches that can not. For example, patches that change the behavior of the patching or LiveUpgrade process itself may not be able to be installed using LiveUpgrade. In these cases, the patches must be implemented using the traditional patching process, which frequently requires the system and zones to be down to install the patches. Because the LiveUpgrade process is not used to implement these types of patches, there is also no simple rollback ability in the event of a system error. For these reaons, whenever possible, a full backup should be run on the systems and zones before installing using the traditional patch process.
--Tom Stevenson 14:17, 3 February 2012 (EST)
Page name |
Piped link |
Interwiki link |