- 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
Minimization Methodology
The section defines a reusable methodology to produce a minimized domain configuration for an application by defining the packages needed to make up the minimized domain. This section describes common problems and solutions found when applying the minimization methodology to chosen applications.
The procedure requires the domain first to be installed with the Solaris OE meta-cluster SUNWCXall, to identify packages required, and to establish package dependencies.
The SUNWCXall meta-cluster of packages contains all Solaris OE and OEM software included in the Solaris OE distribution. This meta-cluster contains all the Solaris OE packages needed for an application to create the minimized profile. Other packages might need to be downloaded and installed, but these must be installed after the JumpStart installation has occurred.
Once the minimized profile is defined for the application, a JumpStart install operation is executed on the domain with the minimized profile to check that the install and main functionality of the application is error-free.
Having a second domain available, which is installed with SUNWCXall, can reduce the time needed to produce minimized configurations for multiple applications. Also, it can reduce time if references are made to the fully installed system during the minimization tasks.
NOTE
It is assumed that the locale settings for applications installed are in the default language, U.S. English. This setting requires setting all environmental variables LC_* to C in your shell before running pkg.ksh. The pkg.ksh has an option to do this when it is run. Localization is not supported for the applications in this article other than for the default language. Setting the locale environmental variables to other settings might include additional packages in the minimized configuration such as locale library packages, additional font packages, X packages, and locale packages.
To apply the minimization methodology, see the following topics:
"Review Application Documentation" on page 22
"Install the Application" on page 23
"Identify Packages Needed by an Application" on page 24
"Build Minimized Profile" on page 27
"Use JumpStart With Minimized Profile" on page 27
"Install Software" on page 27
"Resolve Application Install Errors" on page 28
"Run the Primary Application and Look for Errors" on page 38
Review Application Documentation
Often the install documentation accompanying an application provides information about where application files are installed.
Install documentation might also define if the software has any package prerequisites. These can be found during the install process but, with some large applications (such as ORACLE 9i), this can be a lengthy process, so reviewing documentation can be a time saver.
Identify any Solaris OE packages required by an application so you can add them to the minimized JumpStart profile.
Documentation provides important information for setting the location of dynamic libraries. Two methods are available for specifying the location of dynamic libraries to the system: crle(1) and the environmental variable pair LD_LIBRARY_PATH and LD_LIBRARY_PATH_64. The recommended method is to use crle(1) wherever possible, but the documentation might require using the environmental variable pair method.
The location of the dynamic libraries should be configured before running pkg.ksh. Note that pkg.ksh has the ability to try to determine the location of the dynamic libraries, but this method is not fool proof.
Install the Application
The installation operation is a multistep process. Installing an application on a full system and minimized system should be exactly the same. Any differences that occur might cause the installation to take a different path through the installation process, which could have unexpected side effects. It is important that the install should be a typical installation, causing as much of the application to be installed as possible. This approach allows the minimization process to be as effective as possible.
To Install an Application
Run pkginfo to capture the "before" installation snapshot, using the script command.
Log the install using the script command, so the process can be reviewed later.
Extract the application contents and examine the directory structure for packages that might be installed.
Install the application on the system.
Run pkginfo to capture the "after" installation snapshot, using the script command.
Run diff on the two snapshots to identify packages installed by the application.
After installing the application, make sure the location of application dynamic libraries is configured according to the documentation.
Identify where all the packages and files from the install are located in the file system.
If the application comes as a compressed tar file, then it might be possible to simply extract to a directory and perform subsequent steps in this methodology there, because no packages need to be installed.
NOTE
Set LC_* to C to prevent locale packages from being included.
Failure to set the application dynamic libraries location properly can cause the minimization call to pkg.ksh to yield unwanted packages. For example, installing Sun Explorer without configuring where its libraries are located (the default location is /opt/SUNWexplo/lib) causes pkg.ksh to require SUNWfruid. However, the dynamic libraries that Sun Explorer uses are a subset of SUNWfruid, with each library needed available. So, configuring dynamic libraries properly prevents SUNWfruid from being needed on a minimized system. The pkg.ksh can attempt to guess what the dynamic library directories are by searching for them. Specifying this option can cause a lengthy wait for pkg.ksh to complete.
For completeness of minimizing an application, identification is needed of where all the packages and files from an install are located in the file system. This task is often simple, but might be complex, depending on how the install works. It's completely application dependent.
For example, installing the Sun Management Center 3.5 agent software produces an install log that contains the names of all packages installed. An important distinction here is the difference between Solaris OE packages and application packages that are part of Sun Management Center 3.5. Application packages should not be added to the minimized profile.
Identify Packages Needed by an Application
Executables and dynamic libraries within an application make use of dynamic libraries and other files, such as configuration files, startup scripts for daemons, and so forth, within the Solaris OE.
These dynamic libraries and other files are contained within Solaris OE packages. Identify the dynamic libraries by running pkg.ksh against the installed application files or packages. Identify the other files from package dependencies.
The packages required must have their dependency relationships to other packages maintained by following the dependency lists for each of them.
These packages and their dependencies need to be added to the minimized profile so they are installed as part of the minimized package configuration.
Removing Unneeded Dependent Packages
A general rule for package dependencies is that they should be satisfied whenever they exist. This rule is mostly the case with our minimization methodology, however, there are times when extra packages required to satisfy dependencies are simply not needed and are redundant.
The situations where dependencies are not needed is a shortcoming of how packages are sometimes specified in Solaris OE. A trade-off needs to occur with respect to stringently adhering to the package dependencies and weighing this with the goal of achieving a secure system through minimization.
A good example of unwanted package dependencies is seen by reviewing the install log output by the script command when installing the Sun Management Center 3.0 agent software. This troubleshooting requires using commands like ldd and pkgchk to find what is causing unexpected package requirements and whether their inclusion is fully justified.
After running pkg.ksh against the install on a fully loaded system, reviewing the output log shows the following lengthy dependency list for the library libcalendarservice.so.1.0.
/opt/SUNWsymon/base/lib/sparc-sun-solaris2.8/libcalendarservice.so.1.0:ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically linked, not stripped Package: SUNWesaes truss: SUNWesaes ldd: SUNWcsl SUNWdtdst depend: SUNWcar SUNWkvm SUNWcsr SUNWcsu SUNWcsd SUNWdtbas SUNWcsl SUNWxwdv
Investigating this library further, we see it has truss and ldd dependencies on three packages directly. One of these packages is creating the unexpected dependency list. Running depend-tree.pl on SUNWesaes and SUNWcsl yields nothing substantial, but running against SUNWdtdst shows the cause.
Manual investigation of libcalendarservice.so.1.0 using the ldd command shows that the library /usr/dt/lib/libcsa.so.0 looks most interesting because its path name contains "dt."
# ldd /opt/SUNWsymon/base/lib/sparc-sun-solaris2.8/libcalendarservice.so.1.0
libcsa.so.0 => /usr/dt/lib/libcsa.so.0
libdl.so.1 => /usr/lib/libdl.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
/usr/platform/SUNW,Ultra-2/lib/libc_psr.so.1
The libcsa.so is a member of the package SUNWdtdst, as speculated, which is the CDE desktop applications package, as shown by the following.
# pkgchk -l -p /usr/dt/lib/libcsa.so.0
Pathname: /usr/dt/lib/libcsa.so.0
Type: regular file
Expected mode: 0755
Expected owner: root
Expected group: bin
Expected file size (bytes): 190800
Expected sum(1) of contents: 27313
Expected last modification: Mar 13 08:46:49 PM 2002
Referenced by the following packages:
SUNWdtdst
Current status: installed
If the dependencies for SUNWdtdst are followed to their logical conclusion, then the following additional packages are also required.
# depend-tree.pl -u SUNWdtdst Unique packages SUNWcar SUNWkvm SUNWcsr SUNWcsu SUNWcsd SUNWdtbas SUNWcsl SUNWxwdv
So, to satisfy the library requirement, the dependencies require Java™, X library, and CDE packages to be installed.
This requirement is not necessary because only a single-dynamic library from this package is needed, and this fact is the reason that dependency chains for shared libraries are not followed when pkg.ksh is run. We confirm this by searching the script output file for other dependencies on SUNWdtdst. There are none.
Without these shared library dependencies, only a few packages are needed to get Sun Management Center 3.0 running on a domain. With them, you have a potential security problem with redundant package inclusion.
Build Minimized Profile
A minimized profile comprises input from three areas:
Minimal bootable Solaris OE profile based on SUNWCreq, with required additional packages.
Installation package recommendations in documentation of the application, if applicable.
The package list produced by running pkg.ksh against application packages or directories.
To the minimal bootable Solaris OE profile, append the additional packages needed using the keyword add.
Use JumpStart With Minimized Profile
Add the minimized profile for the application to the JumpStart server and perform a domain install using it.
Only those packages specified will be installed and the system will be patched with the recommended cluster patch.
The installation logs for the JumpStart server will highlight any errors that occur during installation. These are located in /var/sadm/system/logs on the domain. If any errors occur, correct them and repeat the install procedure.
Install Software
Some software such as Solaris Secure Shell, which is now part of Solaris 9 OE, can be installed automatically during a JumpStart installation, by specifying it in the JumpStart profile.
Software such as Sun Validation Test Suite, Sun Explorer data collector, and so on, are added to a domain after JumpStart installations by using pkgadd. This process can be automated with an appropriate response file and finish script. The package to be installed should be stored on the JumpStart server.
Other software such as ORACLE 9i and Sun Management Center 3.5 have manual install requirements. The best you can do is use a JumpStart finish script to extract their contents to the /opt directory during the JumpStart installation, and manually run the install after JumpStart installation is completed.
The value of doing so needs to be evaluated in the context of how often domain installation is likely to occur and the storage space requirements of the application. ORACLE 9i comes on three CDs, which is almost 2 gigabytes of disk space and might be considered excessive if installation occurs only once.
NOTE
It is possible to make custom packages for an application using the command pkgmk command. This command allows the deployment of the applications with a minimum of effort after a JumpStart install has occurred.
Resolve Application Install Errors
Errors that occur during application install are presented in different ways. The exact nature of these is hard to define, but relatively obvious when they occur because they typically lead to an aborted install or display a message on the console.
Generally, there are two states that should be achieved and be free of error before testing any application:
Install the application successfully without error.
Run pkg.ksh on application directories, as done in Step 3 of the minimization methodology, without any missing dynamic libraries. If any are missing, then this should be consistent with installation on the full system.
The following sections highlight and describe some of the problems encountered when using the minimization methodology and how the issues are resolved.
Quick Method of Installing Needed Packages on a Minimized System
If the installation of an application fails on a minimized system, then the missing packages need to be identified on a fully installed system.
Once these have been found, by NFS mounting the directory containing the image of Solaris, it is possible to add the missing packages directly to the minimized system by changing to the package directory of the NFS mounted Solaris install image, and using the pkgadd -d . <missing packages> command.
This command installs missing packages to the minimized JumpStart installation. Next, reinstall the application and check for further errors. If successful, add the missing packages to the minimized JumpStart profile, perform a new minimized JumpStart install, and reinstall the application and check for errors. This process ensures that no unexpected errors or inconsistencies occur during JumpStart installation.
NOTE
By default, NFS is an unsecured service, but is a reasonable choice for this operation. For more information about securing the use of NFS, refer to the Sun BluePrints OnLine article titled "Solaris Operating Environment Security - Updated for Solaris 9 Operating Environment."
Dealing With Missing Packages
Installing an application on a minimized system can sometimes install more software than was added for installation on a full system. This happens because the application might install pre-requisite packages that are missing on the minimized system. These are already installed on the full system, so they do not need to be added.
When installing Patch Manager on a full system, the installer examines the system to see if packages are already installed. If so, then it does not install the Java Runtime Environment, as can be seen from the following Patch Manager install output.
Beginning installation ...
Now installing supporting packages...
SUNWjhrt
== installed version is newer
SUNWsdb
== installed successfully
SUNWapcy
== installed successfully
SUNWppmn
== installed successfully
SUNWcert
== installed successfully
SUNWpmgr
== installed version is newer
SUNWppro
== installed successfully
Installation is complete and verified. Be sure to:
[...]
However, if Patch Manager is installed on the minimized system, the Java™ Runtime Environment and its companion packages are installed, as the following shows:
Beginning installation ...
Now installing supporting packages...
SUNWj3rt
== installed successfully
SUNWlj3rt
== installed successfully
SUNWj3dev
== installed successfully
SUNWjhrt
== installed successfully
SUNWjsse
== installed successfully
SUNWsdb
== installed successfully
SUNWapcy
== installed successfully
SUNWppmn
== installed successfully
SUNWcert
== installed successfully
SUNWpmgr
== installed successfully
SUNWppro
== installed successfully
Installation is complete and verified. Be sure to:
[...]
NOTE
If packages are added in this manner that are part of the Solaris OE, then it is recommended practice to reapply the Solaris Recommended Patch Cluster. See "Install Patches" on page 15 for more information about patches.
Subsequently, running pkg.ksh on the minimized system shows many shared libraries are missing as, in the Patch Manager example, the X shared libraries were not installed to satisfy Java dependencies. Running pkg.ksh on the fully installed system did not highlight these, due to incorrect dependencies in Patch Manager.
The extracted tar file for installing Patch Manager should have been examined before starting the minimization process. That would have shown the packages this application is most likely interested in. The following directory listing shows the packages Patch Manager could potentially install.
# ls pproSunOSsparc5.9jre2.1 README SUNWcert SUNWj3rt SUNWjsse SUNWpmgr SUNWppro patchlist
If Patch Manager dependencies were specified correctly for SUNWppro then executing pkg.ksh would yield all the packages required by following the dependency chain in the Solaris OE package management system.
To address this short coming, examine the application's directory structure to give hints of what to expect. Next, compare the diff output of the before and after for pkginfo on both installs of the fully installed and minimized system to spot inconsistencies.
In the Patch Manager case, the directory structure shows 11 packages, but installing on the full system only highlighted 7 packages, so this is something that raises a flag for further investigation.
Dealing With Java Runtime Environment and X Dependencies
The Patch Manager case mentioned in the previous section raises an interesting dilemma for performing minimization. For many applications, the use of the Java Runtime Environment is to display graphical applications, and it needs the X libraries available to produce these displays. But there is a further point; not every Java application is graphical. They can be console-only applications built to use the rich API that Java offers.
In the Patch Manager example, this application is a console-only application for updating patches on the system. It does not display a GUI, so although package dependencies show it requires various X libraries, these are not used, based on our experience of finding the minimal package configuration for the Patch Manager 1.0 application.
NOTE
Exercise caution when faced with the decision of removing required packages, even if you believe that the contents of the packages might not be used by the application. The ability to support such a configuration can be adversely impacted.
For Solaris 9 OE, the fact that Patch Manager is run console-only allows Patch Manager to be installed free of X library requirements. Solaris 8 OE is more restrictive when it comes to leaving out X packages, due to mandatory packages included in metacluster SUNWCreq.
For other applications, it requires a judgement call by the user, who has experience with the application, to decide if it is graphical or not and if it needs X libraries packages installed, as indicated by pkg.ksh.
A side effect of having no X libraries is that the Java Runtime Environment does not install due to a dependency that the Motif RunTime Kit has on the SUNWmfrun package.
This package must be installed or the following message is displayed when Patch Manager installs SUNWj3rt.
WARNING: The <SUNWmfrun> package "Motif RunTime Kit" is a prerequisite package and should be installed. Installation of <SUNWj3rt> was suspended (interaction required). No changes were made to the system.
Finding Missing Packages After Minimized Install
A lot of applications do not specify their package dependencies properly. These missing dependencies are often exposed when a shell script executes as part of the install process. The script tries running a missing command and fails because the package containing the executable is not installed.
The application install script making the assumption that the executable will be installed is not realistic for a minimized system.
During the install of Sun Remote Services Net Connect 3.0 on a minimized system, this type of dependency problem became apparent because install complains that showrev is missing, as is shown in the following install output.
--- user/cron interaction test passed successfully. InstallNetConnect.003.000.000.sh: showrev: not found Processing package instance <SUNWsrspx> from
showrev is often needed for installations and should always be installed as part of any minimized profile. The following shows which packages are needed when it is executed on a full system.
# pkg.ksh -d 'which showrev' list is /usr/bin/showrev /usr/bin/showrev: ELF 32-bit MSB executable SPARC Version 1, dynamically
This problem was not highlighted on the fully installed system because it was masked by the fact that SUNWadmc and SUNWadmfw, which contain showrev, were already installed.
Most of the packages identified by pkg.ksh are mandatory for a Solaris OE install. Those that are not mandatory need to be added to the minimized profile to install showrev. Make sure that Sun Remote Services Net Connect 3.0 installs properly. The packages needed by Sun Remote Services Net Connect 3.0 are listed in the following table.
TABLE 1 Mandatory Packages
|
Package Type |
Description |
|
SUNWadmc |
System administration core libraries |
|
SUNWadmfw |
System and network administration framework |
|
SUNWlibC |
Sun Workshop compilers bundled libC |
|
SUNWlibms |
Forte Developer bundled shared libm |
Dealing With Unresolved Dependencies
The methodology presented in this article uses a systematic way of going through each file of an installed application and figuring out the dependencies, if it is an executable or dynamic library.
A problem can occur where an executable is compatible with a specific version of the Solaris OE only. There may be libraries that cannot be resolved on a different version of Solaris OE, because the shared library versions might be different.
An example similar to this occurred when installing Sun Management Center 3.0 agent software on Solaris 9 OE.
Running pkg.ksh on the full system after installing the application shows missing libraries that clearly are not right, because no packages were removed.
# pkg.ksh SUNWeswga SUNWessta SUNWesspa SUNWesmod SUNWesmcp SUNWescom
The same issue occurs running pkg.ksh on the minimized system. This is expected, because the minimized system is a subset of the fully installed system.
In the previous case, it turns out that snmp_edit is a little used, undocumented GUI wrapper program within Sun Management Center 3.0. Typically, this program is not required and, because it is the only executable that uses X libraries within Sun Management Center 3.0, is the reason that this application has no X package dependencies.
Items that are learned from the snmp_edit example are as follows:
Not every executable or dynamic library is needed by an application. Where an executable has unusual dependencies, for example, with the snmp_edit executable being the only one that depends on X packages, it is always worth investigating further to understand if it is a main program. This judgement call differs from application to application. It is worth noting that this is a deficiency of automating minimization; this is not something that can be easily programmed to take account of. What the script tools can do is attempt to highlight rarely needed packages by specific dynamic libraries or executables based on frequency of use.
Dynamic libraries might not be installed on a system by default. If an executable cannot resolve dynamic libraries on a fully installed system, then one of the following might be the cause:
The command is not compatible with the installed Solaris version.
A custom package requires a special software load, for example, SUNWlxml and SUNWlxmlx on Solaris 8 OE.
Dynamic libraries might be installed on the system yet not found. If an executable has unresolved dynamic libraries, then the cause might be one of the following:
An incorrectly configured application dynamic library directory, configured through crle(1) or LD_LIBRARY_PATH and LD_LIBRARY_PATH_64. An example of this is given in the next section.
A missing symbolic link for a library version. The likelihood of this cause is low, and its occurrence unusual, but the version discrepancy in snmp_edit could be this.
NOTE
By using Solaris Basic Security Module auditing, it is possible to log audit records for any executable that is launched. This is done when calls are made to the execve() kernel system call. By exercising the application functionality over a period of time, it is possible to analyze audit records to determine if a program is used. For more information, refer to the Solaris Security Auditing Web site at http://www.sun.com/software/security/audit.
Resolving Installed Shared Library Configuration Errors
Before executing an application for testing purposes, it is important to examine the environment and confirm that no problems occurred.
The most significant check is validating that all libraries the installed application might use are installed. This check can be performed by running pkg.ksh against the packages or directories, as done on the fully installed domain.
One important point is that libraries not found might indicate a library path problem with the crle(1) setting or LD_LIBRARY_PATH and LD_LIBRARY_PATH_64 environmental variable settings, rather than a package installation issue.
An example of this problem is found when applying the minimization methodology to Sun Validation Test Suite 5.1. After running pkg.ksh on the minimized system, a lot of shared libraries were installed, but their packages could not be identified.
# pkg.ksh SUNWvts SUNWvtsx [...] Unique packages needed: Couldn't find package for /usr/lib/64/libc.so.1 Couldn't find package for /usr/lib/64/libdevinfo.so.1 Couldn't find package for /usr/lib/64/libdl.so.1 Couldn't find package for /usr/lib/64/libCrun.so.1 Couldn't find package for /usr/lib/64/libX11.so.4 Couldn't find package for /usr/lib/64/libaio.so.1 Couldn't find package for /usr/lib/64/libc.so.1 Couldn't find package for /usr/lib/64/libdl.so.1 SUNWbip SUNWcar [...]
Examining the script log produced when installing Sun Validation Test Suite 5.1 shows an executable with the problem libraries to focus on.
/opt/SUNWvts/bin/sparcv9/afbtest: ELF 64-bit MSB executable SPARCV9
More clearly, running ldd shows the libraries are resolved, indicating they are installed. The directory of /usr/lib/64 is non-standard for 64-bit libraries in Solaris OE. The directory containing the libraries turns out to be a symbolic link to the traditional sparcv9 directory for 64-bit libraries.
# ldd /opt/SUNWvts/bin/sparcv9/afbtest
libX11.so.4 => /usr/openwin/lib/sparcv9/libX11.so.4
libnsl.so.1 => /usr/lib/64/libnsl.so.1
libdl.so.1 => /usr/lib/64/libdl.so.1
libsocket.so.1 => /usr/lib/64/libsocket.so.1
libdga.so.1 => /usr/openwin/lib/sparcv9/libdga.so.1
libvtstest.so.1 => /opt/SUNWvts/lib/sparcv9/libvtstest.so.1
libCrun.so.1 => /usr/lib/64/libCrun.so.1
libm.so.1 => /usr/lib/64/libm.so.1
[...]
# ls -lt /usr/lib/64
lrwxrwxrwx 1 root root 7 Feb 7 11:43 /usr/lib/64 -> sparcv9
Setting LD_LIBRARY_PATH_64 to the sparcv9 directory path resolves the problem and allows finding package dependencies to succeed.
# echo $LD_LIBRARY_PATH_64
/usr/lib/sparcv9
# ldd /opt/SUNWvts/bin/sparcv9/afbtest
libX11.so.4 => /usr/lib/sparcv9/libX11.so.4
libnsl.so.1 => /usr/lib/sparcv9/libnsl.so.1
libdl.so.1 => /usr/lib/sparcv9/libdl.so.1
libsocket.so.1 => /usr/lib/sparcv9/libsocket.so.1
libdga.so.1 => /usr/openwin/lib/sparcv9/libdga.so.1
libvtstest.so.1 => /opt/SUNWvts/lib/sparcv9/libvtstest.so.1
libCrun.so.1 => /usr/lib/sparcv9/libCrun.so.1
[...]
# pkg.ksh SUNWvts SUNWvtsx
[...]
Unique packages needed:
SUNWbip
SUNWcar
[...]
Run the Primary Application and Look for Errors
Run the application and test it to make sure basic functionality is operational. Error checking should be carried out continuously during this process. The output to the console, to /var/adm/messages, and to the application's own logs should be constantly monitored.