This section contains a brief description of Solaris 10 zones support for the current release of Java ES. Installation sequence examples are included. The following topics are addressed in this section:
The Solaris 10 zones feature (also known as Solaris containers) provides a means of creating virtualized operating system environments within an instance of Solaris OS. This allows one or more processes to run in isolation from other activities on the host. For example, a process running in a zone will only be able to send signals to other processes in the same zone, regardless of user ID and other credential information.
Every Solaris 10 host contains a single global zone. The global zone is both the default zone for the host and the zone used for system-wide administrative control. All processes run in the global zone if no non-global zones are created by the global administrator. Some Java ES product components, such as Sun Cluster software, can only be installed in the global zone. A non-global zone can be thought of as a box. One or more applications can run in this box without interacting with the rest of the host. Each non-global zone has what appears to be its own instance of an installed Solaris 10 operating system with configuration and other information unique to that non-global zone. When a package is installed in the global zone, it is, by default, propagated to all non-global zones. In other words, the package is installed in the non-global zones as well as in the global zone. This propagation provides non-global visibility and availability to packages that are installed in the global zone. This propagation behavior can optionally be suppressed when the package is added, thus restricting the package to the global zone only. The default configuration for a non-global zone is to share portions of the global zone's file system. Two types of non-global zones are supported: whole root zone and sparse root zone.
A whole root zone contains a read/write copy of the file system that exists in the global zone. When a whole root zone is created, all packages that are installed in the global zone are made available to the whole root zone. A package database is created and all packages are copied onto the whole root zone, creating a dedicated and independent copy of all files.
A sparse root zone contains a read/write copy of only a portion of the file system that exists in the global zone, while other file systems are mounted read-only from the global zone as loopback virtual file systems, for example, /usr. The global administrator selects which file systems to share with a sparse root zone at the time the sparse root zone is created.
For Java ES, it is assumed that for sparse root zones the /opt file system is not inherited from the global zone and is, therefore, writable.
For your zones deployment to succeed, it is crucial that you plan the tasks and sequence of those tasks very carefully. Java ES components can potentially be installed in any type of zone in an almost unlimited set of combinations, and in almost any order. In some cases, the order in which Java ES product components are installed, and the order in which non-global zones are created, can be very important. For a full description of planning for implementing Java ES in a Solaris zones environment, refer to the Appendix A, Java ES and Solaris 10 Zones, in Sun Java Enterprise System 5 Installation Planning Guide.
The following list describes the level of zones support for this release of Java ES:
Both whole root zones and sparse root zones are supported.
Java ES can be installed in the global zone when non-global zones already exist.
Non-global zones can be created after Java ES is installed in the global zone.
All shared components in a zone must be from the same release of Java ES.
Whole root and sparse root deployments of Java ES should not be mixed on a single computer.
The Java ES installer can install Java ES components in sparse root zones with the following exceptions:
Sun Cluster software, Sun Cluster Geographic Edition, and Sun Cluster Agents can only be installed in the global zone.
Message Queue can only be installed or upgraded in the global zone, or in a whole root zone.
Shared components can only be installed or upgraded in the global zone, or in a whole root zone.
Before Application Server can be installed into the sparse root zone, any version of Application Server that is bundled with the operating system must be manually removed from the global zone.
The Java ES installer controls propagation of the packages it installs in the global zone:
Shared components are always propagated.
Message Queue and Java DB are always propagated.
All other product components are never propagated.
If you have a previous version of Java ES installed in a whole root zone, you should not install Java ES in the global zone.
Installation of shared components in a whole root zone can be blocked if specific versions of Sun Java Web Console are already installed in the zone. This, in turn, can block installation of product components in the whole root zone.
This situation is addressed in Bug 6451030 in the Sun Java Enterprise System 5 Release Notes for UNIX.
Some earlier versions of the Sun Java Web Console packages contain an incorrect attribute setting that prevents Sun Java Web Console from being upgraded in whole root zones. The Sun Java Web Console packages that contain the incorrect attribute setting were shipped with Solaris 10, Solaris 10 Update 1 (1/06), Solaris 10 Update 2 (6/06), and Java ES 4 (2005Q4). The packages are correct in Solaris 10 Update 3 (11/06) and Java ES 5. To determine if your host contains the defective packages, run the following command in the global zone:
pkgparam -v SUNWmcon SUNW_PKG_ALLZONES
If you receive the following response, your host contains the defective packages:
SUNW_PKG_ALLZONES='true'
If you want to install Java ES 5 in a whole root zone, you will first need to upgrade the Sun Java Web Console packages in the global zone. You have the following options:
Option 1: Run the Java ES installer in the global zone and install only All Shared Components. This will upgrade the Sun Java Web Console packages and fix the zones attribute. This will also install all the other Java ES 5 shared components into the global zone and propagate them into all non-global zones. This might not be acceptable for your situation and is not recommended if you have a previous version of Java ES installed in a whole root zone.
Option 2: Upgrade only the Sun Java Web Console packages in the global zone. To do this, log into the global zone and navigate to the Java ES 5 installation directory for Solaris. As root, do the following:cd Product/sunwebconsole ./setup The setup script will upgrade Sun Java Web Console to version 3.0.2, which contains the repaired zones attributes.
The Product/sunwebconsole directory is only found in the full Java ES 5 installer, and is not available in Java ES suite installers. If you are using a suite installer, you must download and unzip the full Java ES 5 installer to access this directory.
After you apply one of these options, you can install Java ES 5 components in a whole root zone.
This example provides guidelines for installing Java ES software in a Solaris 10 whole root zone.
The following high-level tasks are required:
Verifying that Solaris 10 is installed on your host
The global zone is automatically created.
Verifying that all your whole root zones are in the running state
A zone is in the running state when it has been configured, installed, and booted. For information on whole root zones, refer to Chapter 18, Planning and Configuring Non-Global Zones (Tasks), in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.
Checking the installation sequence guidelines
Check to see what sequence guidelines apply. Refer to Table 2–1.
Checking the installation prerequisites
Check to see what installation prerequisites apply. Refer to Table 1–3.
Starting the Java ES installer in the desired whole root zone
At component selection, choosing the components you want
If a component cannot be installed in a whole root zone, then it will be unavailable for component selection.
Viewing the Installation Summary and Log
Completing postinstallation configuration as needed
Chapter 6, Completing Postinstallation Configuration provides postinstallation configuration instructions.
Starting product components
Chapter 7, Verifying Installed Product Components provides procedures for starting and stopping the Java ES product components.
Repeating this process in additional whole root zones as needed
This example provides guidelines for installing Java ES software in a Solaris 10 sparse root zone.
Verifying that Solaris 10 is installed on your host
The global zone is automatically created.
Verifying that all your sparse root zones are in the running state
A zone is in the running state when it has been configured, installed, and booted. For information on sparse root zones, refer to Chapter 18, Planning and Configuring Non-Global Zones (Tasks), in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.
Checking the installation sequence guidelines
Check to see what sequence guidelines apply. Refer to Table 2–1.
Checking the installation prerequisites
Check to see what installation prerequisites apply. Refer to Table 1–3.
Starting the Java ES installer in the global zone, and selecting only shared components
Select only All Shared Components at component selection; no other components should be selected. When shared component installation is complete, the shared component are in the global zone and are also propagated to all non-global zones.
For shared components that use multilingual packages, the Java ES multilingual packages must be present in the global zone.
If Message Queue or Application Server are being used, upgrading Message Queue in the global zone
Message Queue is often installed during Solaris 10 installation and does not support installation into a sparse root zone. Therefore, Message Queue must be installed in the global zone, after which it is propagated to all non-global zones.
If Application Server is being used, removing the bundled Application Server from the global zone
If Application Server is being used in the deployment, the Application Server that is bundled in Solaris 10 must be removed from the global zone. In the global zone on the host, list the Application Server packages as follows:
pkginfo -i | grep -i "application server" |
If Application Server packages are present, remove them from the global zone. Because these packages are automatically removed from all the non-global zones, you will need go to each sparse root zone and reinstall Application Server.
Starting the Java ES installer in the desired sparse root zone
At component selection, choosing the components you want
If a component cannot be installed in a sparse root zone, then it will be unavailable for component selection.
Viewing the Installation Summary and Log
Completing postinstallation configuration as needed
Chapter 6, Completing Postinstallation Configuration provides postinstallation configuration instructions.
Starting product components
Chapter 7, Verifying Installed Product Components provides procedures for starting and stopping the Java ES product components.
Repeating this process in additional sparse root zones as needed