- Overview
- Enhancing Security
- Recommendations and Methodologies for Minimization
- Background
- Qualifying a Solaris Configuration
- Automating Domain Installations
- Using Scripts to Qualify a Solaris Configuration
- Minimization Methodology
- About the Authors
- Acknowledgements
- Related Resources
- Ordering Sun Documents
- Accessing Sun Documentation Online
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Recommendations and Methodologies for Minimization
Recommendations and methodologies for minimizing systems are in a variety of forums, including Sun BluePrint OnLine articles, most notably the article titled "Minimizing the Solaris Operating Environment for Security: Updated for Solaris 9 Operating Environment." That article focuses on how to minimize the Solaris Operating Environment (OE) for a single-purpose, appliance-like application; a web server. Many functions and tools are not installed because they are not required for an appliance-like installation on which:
Minimal debugging takes place
Additional software would never be installed without re-installing the entire system
The entire system is treated like a single field-replacable unit (FRU)
In this two-part article series for minimizing domains, we extend the recommendations made in the "Minimizing the Solaris Operating Environment for Security" article to address some of the fundamental challenges with minimized systems, including the following:
Difficulty in adding software packages to a system after it is deployed and in production.
Adding additional software or hardware, whether OE or third-party, is difficult for many reasons. The primary difficulty is determining which Solaris OE packages (such as packages containing libraries, drivers, or software) might be required to make additional software function properly. After identifying required additional components, other challenges are typically encountered. This article addresses those challenges by proposing mechanisms to determine package dependencies as well as provide a baseline configuration that includes commonly used system components.
Systems that cannot be treated as single FRUs require diagnostic tools for use by the customer as well as Sun's support organization to diagnose and root cause problems with the system. This article covers these issues by proposing system configurations that include software packages and commands typically used by Sun's support organization either directly or indirectly to address system problems.
Package dependencies for advanced features in the Sun Fire V1280, 6800, 12K, and 15K systems. To date, these have not been identified in Sun product documentation. This article provides a configuration where the package dependencies of these advanced features are identified, documented, and tested.
Required packages for Sun remote monitoring solutions.
Required packages for popular third party applications such as Oracle and Sun ONE Application Server products.
Validation that the defined packages incorporate all required components for proper function. This article addresses this issue by recommending rigorous quality assurance mechanisms and techniques to validate that the software load, as defined, is as correct and complete as possible.
As with all well-documented configurations, the implementation of these recommendations should be as automated as possible. We address automation in this article by defining JumpStart profiles that incorporate the recommendations and address the fundamental challenges listed previously. These profiles are available electronically and can serve as a starting point for developing profiles for your systems.