by Glenn Brunette
Note: The following information is applicable only to Oracle Solaris 10 and older versions of Oracle Solaris that use the SVR4 packaging model.
For over a decade, many Oracle Solaris administrators have deployed reduced or minimal Oracle Solaris configurations. While this has been done predominantly in the financial services and government/military sectors, this practice has become widespread in recent years with greater numbers of customers. These configurations are being used to promote heightened security under the premise that "software that is not installed cannot (easily) be re-enabled or exploited." In addition, some customers have indicated that their use of reduced or minimal Oracle Solaris configurations stems from their desire to also reduce the management burden and costs associated with instance provisioning, patching, migration, and audit compliance.
In order to satisfy these requirements, reduced or minimal Oracle Solaris configurations are created and deployed throughout a customer's environment. In most cases, customers who deployed such configurations have done so using supported, public, and documented interfaces that Sun previously delivered and Oracle now delivers in Oracle Solaris.
This document provides guidelines for building reduced or minimal configurations. It also outlines some of the risks and considerations that must be understood when using these types of configurations.
Note: The goal of this document is to describe what should be considered when creating a reduced or minimal Oracle Solaris configuration. Following the guidelines in this document does not guarantee that the resulting configuration will qualify as a supportable configuration. Before using any of these procedures, consult with your Oracle support representative.
Oracle Solaris must be installed using one of the Oracle provided (and supported) installation mechanisms (for example, Graphical Installer, JumpStart, and so on). The initial installation of the OS must be based upon one of the Oracle provided (and supported) software installation clusters (that is, metaclusters).
For Oracle Solaris 10, this would entail installing using one of the following metaclusters:
The stated purpose of the Reduced Networking metacluster was to help customers who want to deploy reduced or minimal Oracle Solaris configurations. The following statement was documented in the Sun Architectural Review case that introduced the Reduced Networking metacluster (PSARC/2002/254):
The Reduced Networking metacluster is intended to provide a supported foundation for the deployment and secure configuration of minimized systems.
This metacluster was introduced into Oracle Solaris 10 as a direct result of customer feedback in the area of minimization. Additional Oracle Solaris software packages can be added to or removed from the selected metacluster provided the conditions defined in items Oracle Solaris Package Addition (Installation) and Oracle Solaris Package Removal are satisfied.
Oracle Solaris must be upgraded using one of the Oracle provided (and supported) upgrade mechanisms (for example, JumpStart, Live Upgrade, and so on). Upgrading reduced and minimal Oracle Solaris configurations is supported using any of the Oracle supported upgrade mechanisms.
Oracle Solaris upgrade functionality will analyze the current set of packages installed on a system, the list of packages derived from the
clustertoc(4) file for the upgraded version of Oracle Solaris (for the appropriate metacluster), as well as the package history file. Using this information, the upgrade functionality will install and/or remove packages as necessary to ensure that the resulting system configuration is left in a consistent and supported state.
Note: It might be necessary to install the Live Upgrade software because it might not present in some of the Solaris OS metaclusters.
Any additional (that is, not installed in the previous steps) Oracle Solaris packages that a customer would like added to a system must be installed using one of the Oracle provided (and supported) installation mechanisms (for example, Graphical Installer, JumpStart,
pkgadd(1M), and so on). If any package dependencies exist on the software being installed, those dependencies must be satisfied prior to the installation of the package.
Example: Assume that package A depends on package B and neither package is installed on an Oracle Solaris system. If a customer wants to install package A, the customer must first install package B, because package A depends on package B. This same process must be completed for any other software packages upon which package A depends. Forcible addition of package A (without package B being previously installed) would result in an unsupportable configuration.
If there are any Oracle Solaris packages to be removed from an existing system configuration, they must be removed using an Oracle provided (and supported) mechanism (for example, JumpStart or
pkgrm(1M)). If any dependencies exist on the software package being removed, those dependencies must be addressed and satisfied prior to the removal of the package.
Example: Assume that package A depends on package B and both packages are installed on an Oracle Solaris system. If a customer wants to remove package B, the customer must first remove package A, because package A depends on package B. This same process must be completed for any software packages that depend on package B being installed. If the customer cannot remove a package that depends on package B, package B cannot be removed. Forcible removal of package B would result in an unsupportable configuration.
It is not permissible to remove any software packages that are found in the smallest Oracle provided installation cluster. For Oracle Solaris version 9 and later, this means any packages that are delivered by the
SUNWCmreq metacluster. For earlier releases of Oracle Solaris, this means any packages that are delivered in the
SUNWCreq metacluster. Removal of packages delivered in the smallest Oracle provided installation cluster will result in an unsupported configuration.
SUNWCmreq metacluster, available starting in Oracle Solaris 9, is special. It is not listed as a choice nor can it be selected when a system is installed. Its sole purpose is to contain those software packages that must be installed on every Oracle Solaris system regardless of the system's purpose or configuration.
It is prohibited to remove Oracle Solaris software packages using any means other than
pkgrm. Files and directories delivered by Oracle Solaris packages must not be removed individually using commands such as
rm(1). Further, the
pkgchk(1M) command must report no errors with respect to Oracle Solaris package accuracy and integrity after any installation or removal operation has completed.
Using a reduced or minimal Oracle Solaris configuration can have a beneficial impact on patching. According to research completed for Oracle Solaris 10, as of March 10th, 2006, there were 345 patches released for the SPARC platform version of the OS. Only 149 of those patches applied to the Reduced Networking metacluster. A savings of over 40% (in the best case) is extremely significant, especially for customers with large Oracle Solaris deployments. Even customers who take a reduced approach to Oracle Solaris OS configurations will benefit. Using the
SUNWCuser metacluster as the foundation for an Oracle Solaris installation will still yield patch savings of nearly 30% per system.
These benefits are not achieved without some measure of risk. A single Oracle Solaris patch can contain fixes for files that are delivered across multiple Oracle Solaris packages and metaclusters. When working with reduced or minimal Solaris OS configurations, this could mean that patches are partially applied since one or more of the packages to be patched might not be installed on the system.Note: As of the original writing of this document in 2009, the Oracle Solaris 10 kernel patch (118833 for SPARC) contains fixes for code delivered in five different packages, which themselves are delivered in three different metaclusters:
When working with reduced or minimal configurations, it is not easily apparent which patches might be partially installed. Furthermore, if a package (originally not installed) is added after the patches had been applied, it will not have been patched--even though the system will declare that the patch had been successfully installed. This kind of inconsistency is not only an annoyance; it can furthermore contribute to a security vulnerability inadvertently being exposed due to the use of unpatched code.
It is recommended that one of the following methods be used:
If neither of these options is acceptable, then a customer might want to use the Entire + OEM software installation cluster to avoid this problem.
Any new packages installed should come from the same Oracle Solaris revision that is currently installed on the system. For example, if the target system has Oracle Solaris 10 10/08 installed, any additional packages installed should be taken from the Oracle Solaris 10 10/08 release media. This is recommended because all available patches are pre-applied to the packages in each Solaris Update and the
pkginfo files are updated with the corresponding patch metadata. Adding a package from a different Solaris Update to a system will include the patch level of that release for that package, including the associated patch metadata, causing the overall patch metadata on the target system to be a mish-mash of different releases. Because
patchadd needs to find just one occurrence of a patch in the patch metadata of all packages in order to decide that a dependency is met, adding packages from different releases can cause
patchadd to incorrectly resolve patch dependencies for future patching operations, leading to potentially serious problems.
If a package needs to be added from a later Oracle Solaris Update (which should rarely, if ever, be necessary), you must reapply all patches listed in the
PATCHLIST field of the
pkginfo file of that package to ensure all the other packages on the target system are brought up to a consistent patch level. Conversely, if a package is added from an earlier Oracle Solaris Update or the same Oracle Solaris Update, you must reapply the most recent version of all patches that were previously applied to the target system in order to patch the added packages up to the same patch level as the rest of the system.
Be aware of the following recommendations, caveats, and warnings.
It is recommended that customers take an additive approach to building reduced or minimal configurations. That is, rather than start with the entire software distribution and attempt to remove packages that are not wanted, customers should strive to begin their installations using the smallest metacluster that most closely approximates their needs. Using this foundation, additional Oracle Solaris software packages can be added or removed, as appropriate.
It is prohibited to change the ownership, group, or permissions of files delivered by Oracle Solaris software packages. If a customer believes that an attribute is set in error or can be improved, the customer should file a bug or a request for enhancement (RFE) report so that Oracle can make an evaluation and take action accordingly. The
pkgchk(1M) command must report no errors with respect to Oracle Solaris package accuracy and integrity.
As with any complex system, it is not possible to evaluate every possibility. As a result, there might be software package dependencies that are not documented in Oracle Solaris. If a customer encounters such a problem and the configuration is deemed supportable, Oracle will work with the customer to determine which software package or packages might be required. To satisfy the dependency, the customer must install any required Oracle Solaris software packages. Further, Oracle will file a bug report so that this issue can be corrected in a future version of Oracle Solaris.
Some software packages might have dynamic or optional dependencies. This might be the case when a software package only requires another based on runtime settings defined by the user or those stored in a configuration file. In these cases, the software package might not list these dynamic dependencies. If a customer encounters this problem, section Undocumented Software Dependencies must be followed to determine which software packages are required. Any identified required packages must be installed.
The majority of software vendors (including Oracle) do the majority of their testing using systems that have been installed using the complete set of Oracle Solaris software (for example,
SUNWCXall). Testing is rarely completed using reduced or minimal configurations. As a result, there is a higher risk that software added post-installation will fail when using a reduced or minimal configuration.
Furthermore, the actual list of Oracle Solaris software packages required for a given reduced or minimal configuration will very much depend on the entire suite of hardware devices and software functions and services that will be used on the target platform. As a result, there could be an impact to the Oracle Solaris configuration if additional unbundled or third-party software packages are later added (or upgraded) to a system's configuration. Customers must always perform adequate testing to ensure that their reduced or minimal Oracle Solaris configurations perform as expected within their environment. This testing must be completed before placing such systems into production.
Customers are advised that "supported" is not the same as "qualified." Oracle Solaris Engineering designs, implements, and tests Oracle Solaris using the
SUNWCXall metacluster. The explicit package dependencies included with Oracle Solaris are, therefore, not certified to be correct. The exact interdependencies in the software are not formally known, evaluated, or documented in a reliable way. As a result, when building reduced or minimal configurations, it is possible that undocumented dependencies or unexpected behaviors may be discovered.
Oracle Solaris is a complex software product with many software packages, components, and settings. It is simply not possible to design or test for every permutation. In fact, the vast majority of Oracle and ISV products are tested only on the entire distribution of Oracle Solaris. As a result, customers who choose to deploy reduced or minimal Oracle Solaris configurations are advised that they are taking on additional risk and they are strongly encouraged to fully exercise and test their configurations before promoting them into production use. Customers who are uncomfortable with that risk are advised to install the complete Oracle Solaris distribution in a hardened configuration in order to reduce their exposure.
By default, Oracle Solaris minimization is not supported on any Sun SPARC Enterprise (formerly called Sun Enterprise) or Sun Fire platform System Controllers from Oracle that are capable of running Oracle Solaris.
The following people contributed to the creation and/or review of this document: Warren Belfer, Glenn Brunette, James Carlson, Joe Di Pol, Richard Elling, Harry Foxwell, Chris Gerhard, Jim Hall, Gerry Haskins, Vasya Igouchkine, Kathy Jenks, Robert Kriz, Jim Laurent, Peter Memishian, Dave Miner, Darren Moffat, Scott Rotondo, Isaac Rozenfeld, Jafar Shameem, Bart Smaalders, Mark Thacker, Anand Vaidun, Nicolas Williams, and Gary Winiger.
|Revision 1.3, 08/23/2011|