Appendix A Java ES and Solaris 10 Zones

This appendix describes the issues that arise when you install and configure Java ES components in Solaris 10 zones, and recommends some practices regarding for addressing those issues. This appendix contains the following sections:

• What Are Zones?

• Why Use Zones for Java ES?

• Zones Limitations of Java ES Components

• Zone Support in the Java ES Installer

• Recommended Use of Zones with Java ES

• Special Cases or Exceptions

• An Illustrative Example: Install Application Server in a Sparse Root Zone

What Are Zones?

Zones are an application and resource management feature of the Solaris 10 operating system. This feature allows the operating system to be represented to applications as virtual operating system environments (zones) that are isolated and secure. These zones provide the advantages of operating system independence with some level of centralized resource management. Hence applications can be isolated from one another by being installed and run in different zones, while at the same time certain operating system resources can be centrally allocated and administered.

From the point of view of an operating system supporting multiple zones, operating system resources include resources such as process management, memory, network configuration, file systems, package registries, user accounts, shared libraries, and, in some cases, installed applications.

Structure of a Multi-zone Environment

A multi-zone environment consists of a global zone (the default operating system) and one or more non-global zones. The global zone contains resources that can be allocated among non-global zones by a global (zone) administrator. Non-global zones provide the following features:

• Security. By running distributed services in non-global zones, you limit the damage possible in the event of a security violation. An intruder who successfully exploits a security flaw in software within one zone is confined to that zone. The privileges available within a non-global zone are a subset of those available in the global zone.

• Runtime isolation. Non-global zones allow for the deployment of multiple applications on the same computer even if those applications require different levels of security, require exclusive access to global resources, or require individualized configuration. For example, multiple applications running in different zones can bind to the same network port by using the distinct IP addresses associated with each non-global zone. The applications are prevented from monitoring or intercepting each others network traffic, file system data, or process activity.

• Administrative isolation. The virtualized operating system environment allows for separate administration of each non-global zone. Actions taken by a zone administrator (as opposed to the global administrator) in a non-global zone, such as creating user accounts, installing and configuring software, and managing processes, do not affect other zones.

There are two types of non-global zones: whole root zones and sparse root zones:

• Whole root zones. Contain a read/write copy of the file system existing on the global zone. When a whole root zone is created, all packages that are installed on the global zone are made available to the whole root zone: a package database is created and all files are copied onto the whole root zone for the dedicated and independent use of the zone.

• Sparse root zones. Contain a read/write copy of only a portion of the file system existing on the global zone (hence the name sparse root) while other file systems are mounted read-only from the global zone as loop-back virtual file systems. When a sparse root zone is created, the global administrator selects which file systems to share with the sparse root zone (by default, the /usr, /lib, /sbin, and /platform directories are shared as read-only file systems). All packages that are installed on the global zone are made available to the sparse root zone: a package database is created and all files in the mounted file system are shared with the zone.

Whole Root Zones vs. Sparse Root Zones

The choice between using whole root non-global zones versus sparse root non-global zones depends upon a trade-off between resource efficiencies and administrative control. Whole root zones allow you to maximize administrative control (independence and isolation) at the cost of memory and other resources, while sparse root zones optimize the efficient sharing of executables and shared libraries (while using a much smaller disk footprint) at the cost of administrative independence. There is currently no measure of the performance advantage of sparse root zones over whole root zones; it is very likely to be software-specific.

Package Propagation

Packages installed in a global zone are (by default) available to all non-global zones: a process called package propagation. (For propagation to take place, newly-created non-global zones must be fully booted, that is, be in a running state.) Propagation provides local (non-global) visibility and availability to packages that are installed in the global zone. Propagation allows for application package life-cycle management (installation, upgrade, un-installation) to be performed centrally by a global administrator, while application configuration and runtime management are performed by (non-global) zones administrators.

For whole root zones, propagation is achieved through the automatic copying of installed files from the global zone to the whole root zones and through automatic synchronization of registry information. For sparse root zones, propagation is achieved through read-only file systems that are shared between the global and sparse root zones and through automatic synchronization of registry information.

Propagation of packages to non-global zones is controlled at the package level using internal package attributes. For some values of these attributes (the default values, at least), propagation can be disabled at install time by using the pkgadd —G option, which overrides the attribute values. Once installed, the propagation behavior of a package cannot be modified, except by uninstalling and reinstalling the package. Patches, for example, cannot change the propagation behavior of a package; in fact, patches must be applied in accordance with the propagation behavior of the package they are upgrading.

Why Use Zones for Java ES?

The isolation provided to applications running in different zones is similar to the isolation provided by running applications in the operating systems of different computers. Hence, instead of installing, configuring, and running Java ES components on different computers in order to isolate and secure them, those components can be installed, configured, or run in different zones within the same computer.

This consolidation of Java ES components can also enable more efficient resource utilization. Java ES components running in dedicated, under-utilized computers, can be run instead in different non-global zones of a single computer. Global administrators can dynamically allocate resources among the different zones depending on the resource requirements of the components running in those zones. (Note this possibility requires more knowledge and understanding of the resource requirements of different components than is generally available at the present time.)

A multi-zone environment can help achieve other objectives as well:

• Version Separation. Parallel sets of Java ES components of different versions can be run in different zones. This allows for migration from one Java ES version to another over a period of time. For example, Java ES Release 4 components in one non-global zone can be run in parallel with Java ES Release 5 components in another non-global zone. To achieve this type of version separation, life-cycle management (as well as configuration and runtime management) is delegated to zone administrators.

• Centralized Life-cycle Management. While not fully supported due to Java ES limitations, zones make it possible to centralize life-cycle management of Java ES components: components can be installed, upgraded, and uninstalled in the global zone but configured and run in a number of non-global zones to provide for runtime isolation, security, scalability, and other needs. Centralization of life-cycle management is advantageous when there are a number of instances of a component running in different zones, or when you want to ensure that such instances are synchronized to the same release version.

  For example, you would be able to install Application Server once in the global zone and run multiple instances in different non-global zones. The various Application Server instances could support Access Manager, Portal Server, or other Java ES components (these can be the same or different components in different non-global zones). Or different Application Server instances could be used by different development teams in different zones.

  To achieve this objective, life-cycle management is performed by a global administrator, while configuration and runtime management is delegated to the respective zone administrators. This approach requires broad coordination when life-cycle management tasks (such as upgrade) are performed.

• Organizational Independence. Different organizations can maintain separate deployments of Java ES components, or separate runtime instances of Java ES components, all coexisting and running on the same computer. For example, different groups of developers can use their own distinct instances of Java ES components, or different organizations can use different deployments of Java ES for testing, pre-production staging, or production. Organizational independence can be achieved in various ways, depending on specific objectives: either by centralizing Java ES life-cycle management while delegating configuration and runtime management to zone administrators, or by delegating all management functions (life-cycle, configuration, and runtime) to zone administrators.

The different objectives you can achieve using Java ES in a multi-zone environment, and the usage scenarios they imply, require different strategies for deploying and administering Java ES components across a multi-zone environment. Some objectives make use of the isolation of different zones to independently manage different Java ES components and their runtime instances, while other objectives make use of the propagation capabilities of the global zone to simplify life-cycle management of Java ES components.

Installation and administration strategies for using Java ES in a multi-zone environment will be revisited after discussing some of the multi-zone environment limitations imposed by the nature of Java ES software.

Zones Limitations of Java ES Components

Java ES components are grouped into different types, as described in Sun Java Enterprise System 5 Technical Overview. Accordingly, system service components provide the main Java ES infrastructure services, while service quality components enhance those system services. These two types of Java ES components are together referred to here as product components, components that are selectable within the Java ES installer.

Each product component depends on one or more locally shared libraries known as Java ES shared components. Shared components are installed automatically by the Java ES installer during product component installation, depending on the product components that are being installed. They are not individually selected, installed, or configured during deployment of Java ES product components.

Java ES Shared Components and Zones

The discussion in Why Use Zones for Java ES? focused on the use of zones by Java ES product components: those that can be explicitly selected in the Java ES installer and installed and configured in various zones to achieve a desired deployment architecture and functional capability. However, the shared components upon which product components depend set a number of limitations on how Java ES is deployed in a multi-zone environment. There are two issues regarding Java ES shared components and zones:

Synchronization of Shared Components

The difficulty of testing and supporting the large number (around 30) and complex interactions between Java ES shared components and Java ES product components mandates that all shared components within a single operating system instance be synchronized to the same Java ES version. In other words, all Java ES shared components installed in a non-zone environment, or in any single zone within a Solaris 10 environment, must be of the same version. This requirement sets certain restrictions on how Java ES can be used in a multi-zone environment.

This synchronization requirement has the following implications:

• Different versions of Java ES shared components can only reside in different zones. For example, you can install Java ES Release 4 shared components in one zone and Java ES Release 5 shared components in another zone, but you cannot combine them in the same zone.

• If any shared component in a zone is upgraded or any new shared component of higher version is introduced, then all shared components in that zone must also be upgraded at the same time. (Shared components are required to be backwardly compatible, so there is no problem for Release 4 product components to work with Release 5 shared components.) For example, suppose a Release 5 product component is installed in a zone in which one or more Release 4 product components reside. Because the Release 5 product component requires some number of Release 5 shared components, the synchronization requirement means that all Release 4 shared components residing in that zone must be upgraded to Release 5 at the same time the Release 5 product component is installed. This is the case even if the Release 5 product component being installed requires different shared components from those that are already installed in the zone.

• When shared components are installed in and propagate from the global zone (see Java ES Propagation Policies), then special care must be taken to maintain synchronization of shared components in all zones. Otherwise it would be possible for shared components of an earlier version in a non-global zone to be mixed with Release 5 shared components that have been propagated from the global zone. (Special care normally means that shared component life-cycle management takes place only in the global zone. For more information see Table A–2, and Shared Component Special Cases.)

The shared component synchronization requirement imposes restrictions on what the Java ES installer is constrained to do in a multi-zone environment (for more information, see Zone Support in the Java ES Installer) and also impacts procedures for installing and upgrading Java ES product components in a multi-zone environment.

Shared Components and Sparse Root Zones

Another issue impacting the use of Java ES in a multi-zone environment is that a large number of shared components cannot be installed in sparse root zones because of the read-only file systems in sparse root zones. Hence, those shared components whose base directory is /usr (a directory that by default is shared by the global zone) must be installed in the global zone to be available in a sparse root zone.

The inability to install a number of Java ES shared components in sparse root zones means that to successfully install product components which have dependencies on such shared components into sparse root zones, the shared components must first be installed in the global zone and propagated to non-global zones.

Java ES Product Components and Zones

Some of the objectives discussed in Why Use Zones for Java ES? for using Java ES in a multi-zone environment, and the usage scenarios they imply, make use of the propagation capabilities of the global zone to simplify life-cycle management of Java ES product components. Such usage scenarios, for example, call for life-cycle management of Java ES product components to be performed in the global zone by the global administrator, while the configuration and runtime management of those components is performed in non-global zones by zone administrators.

In other words, product components would be installed and upgraded in the global zone, but instances would be configured and run in non-global zones. This usage scenario would combine the benefits of centralized life-cycle management with the isolation and security afforded by non-global zones.

This scenario, however, depends upon the ability of each product component to be installed in the global zone, but be configured and run in a non-global zone. This separation depends upon how configuration of each product component is achieved, where configuration and dynamic application data is stored, how configuration data is located by executing binaries, and how upgrades are performed. For example separation might depend upon what pre or post install or upgrade scripts do: whether they start or stop component instances, set up links to configuration data, or perform other tasks that blur the distinction between life-cycle and configuration management.

This separation can also depend upon whether configuration is performed in a whole root or sparse root zone. For example, if a product component's configuration script writes to a read-only file system in a sparse root zone (for example /usr) or if non-default file systems (such as /opt) are shared with a sparse root zone, then the configuration of a component can fail.

---

Note –

Nearly all Java ES product components are installed under /opt, which by default, is writable in sparse root zones. For more information, see Sun Java Enterprise System 5 Installation Reference for UNIX

---

At the current time, the ability of each of the roughly 20 Java ES product components to support the separation of life-cycle management and configuration/runtime management between global and non-global zones has not been established. The various product components have adopted different approaches to configuration and upgrade. Given this situation, propagation of Java ES product components (except for Message Queue) is not currently supported. For more information, see Java ES Propagation Policies.

Zone Support in the Java ES Installer

Based on the usage scenarios discussed in Why Use Zones for Java ES?, and the Java ES component requirements and limitations discussed in Zones Limitations of Java ES Components, the Java ES installer provides qualified zones support for installation (and upgrade) of Java ES product components and for synchronization of shared components. Policies have been implemented in the installer to help prevent problematic installation and upgrade scenarios.

Java ES Propagation Policies

Based on the limitations discussed in Section 3, the Java ES installer implements two Java ES propagation policies:

• When product components are installed in the global zone, they are set by default to not propagate into non-global zones (Message Queue is an exception). Hence the non-global zones do not see them in their registries nor have access to the installed components.

• When shared components are installed in the global zone (for example, as part of the installation of product components), they are set to propagate into non-global zones. Hence non-global zones see them in their registries and have access to the installed shared components. This policy helps enforce the requirement that shared component versions be synchronized within any zone as described in Java ES Shared Components and Zones.

Installation of Product Components

The Java ES installer can install product components as well as the shared components needed to support each product component. Before installing a selected product component, the installer checks for the existence of current and previous versions of shared components. If the installer detects that a shared component required by the selected component is of a previous version or is missing, the installer will upgrade all shared components currently installed and install any missing shared components required by the selected component. This behavior, which meets the requirements of Synchronization of Shared Components, applies to non-zone operating systems, global zones, and all non-global zones.

However, there are two exceptions to this behavior:

• In sparse root zones, some shared components cannot be installed or upgraded (see Shared Components and Sparse Root Zones), and installation is halted until such time as such shared components have been installed or upgraded in the global zone. The installer provides the following message: “The following shared components, required by the components you have selected, cannot be installed or upgraded in a sparse root zone. Please install or upgrade these shared components in the global zone before proceeding. Use the All Shared Components option.” For more information see Synchronize All Shared Components.

• In a global zone, if non-global zones are present, instead of upgrading all shared components currently installed and installing any missing shared components required by a selected component, the installer synchronizes all Java ES shared components, whether or not they are needed by any specific product component. This allows all shared components to be propagated to non-global zones, thus assuring that there is no intermixing of shared component versions in non-global zones.

Upgrade of Product Components

A new capability has been implemented in the Java ES Release 5 to upgrade product components in a few special cases: Application Server, Message Queue, HADB, and Java DB. When the Java ES installer detects the previously installed release versions of these product components, it marks them as upgradable in the Component Selection page. If any of these four product components are selected, the installer will upgrade them using logic similar to that used for a fresh installation.

In particular, before upgrading a selected product component, the installer checks for the existence of current and previous versions of shared components. If the installer detects that a shared component required by the selected component is of a previous version or is missing, the installer will upgrade all shared components currently installed and install any missing shared components required by the selected component. This behavior, which meets the requirements described in Synchronize All Shared Components, applies to non-zone operating systems, global zones, and all non-global zones.

However, there are three exceptions to this behavior:

• In sparse root zones, some shared components cannot be installed or upgraded and the upgrade operation is halted until such time as such shared components have been installed or upgraded in the global zone. (For more information, see Shared Components and Sparse Root Zones) The installer provides the following message: “The following shared components, required by the components you have selected, cannot be installed or upgraded in a sparse root zone. Please install or upgrade these shared components in the global zone before proceeding. Use the All Shared Components option.” (For more information, see Synchronize All Shared Components.)

• Both Application Server and Message Queue are bundled with the Solaris operating system. Neither of these versions can be directly upgraded in a sparse-root zone. For the details regarding these two bundled components, see Product Component Special Cases.

• In a global zone, if non-global zones are present, instead of upgrading all shared components currently installed and installing any missing shared components required by a component selected for installation, the installer synchronizes all Java ES shared components, whether or not they are needed at that time for any of the components selected for installation. This allows all shared components to be propagated to non-global zones, thus assuring that there is no intermixing of shared component versions in the non-global zones.

---

Note –

There are a number of special cases or exceptions that might interfere with the installation or upgrade of product components in non-global zones. These cases are described in Special Cases or Exceptions.

---

Synchronize All Shared Components

A shared component synchronization option is provided to meet situations in which all shared components must be synchronized. When the All Shared Components option is selected, the installer will upgrade all shared components currently installed and install any missing shared components, whether or not they are needed by any specific product component. This option applies to global zones and whole root zones, but not to sparse root zones.

The All Shared Components option, is needed in the following two zone-based scenarios:

• Manually upgrading product components. The All Shared Components option is needed to perform the shared component installation and upgrade needed when upgrading product components that cannot be upgraded using the Java ES installer.

• Installations or Upgrades in a Sparse Root Zone. Some shared components cannot be installed in default sparse root zones. (For details, see Installation of Product Components and Upgrade of Product Components.) Hence when running the installer in sparse root zones, you might first be required to synchronize shared components in the global zone, depending on the shared components involved. You use the All Shared Components option in the global zone to perform the shared component installation and upgrade required in this case.

Summary of Java ES Installer Behavior Regarding Shared Components

The behaviors described above are summarized in the following table, which shows how the Java ES installer's treatment of shared components depends on the zone context as well as what has been selected in the component selection page.

Table A–1 Installer Behavior Regarding Shared Components

Zones Context	Product Component Selected	All Shared Components Selected
Non-zone operating System	Upgrade all shared components currently installed  Install any missing shared components required by the selected product component	Upgrade all shared components currently installed  Install any missing shared components, whether or not they are needed by any specific product component
Global zone: no non-global zones	Upgrade all shared components currently installed  Install any missing shared components required by the selected product component	Upgrade all shared components currently installed   Install any missing shared components, whether or not they are needed by any specific product component
Global zone: non-global zones exist	Upgrade all shared components currently installed   Install any missing shared components, whether or not they are needed by any specific product component	Upgrade all shared components currently installed Install any missing shared components, whether or not they are needed by any specific product component
Whole root zone	Upgrade all shared components currently installed  Install any missing shared components required by the selected product component	Upgrade all shared components currently installed  Install any missing shared components, whether or not they are needed by any specific product component
Sparse root zone	Cannot upgrade or install some shared components in read-only directories. If installer encounters such shared components, it blocks and instructs user to manage shared components in the global zone.	Cannot upgrade or install some shared components in read-only directories. Installer therefore blocks and instructs user to manage shared components in the global zone.

Recommended Use of Zones with Java ES

While the deployment of Java ES in a multi-zone environment has the general objective of providing for product component runtime isolation and efficient resource utilization, there area number of more specific objectives for which a multi-zone environment can be used. These are discussed in as discussed in Why Use Zones for Java ES?. Installation and administration strategies for Java ES in a multi-zone environment depend largely on which of these objectives you are trying to achieve.

Table A–2 compares five scenarios, the installation and administration strategies to which they correspond, and the objectives that they are meant to achieve. While mixing of these scenarios might be possible in some cases, the results can be problematic and are likely to cause administrative mayhem. Hence, Java ES Release 5 generally does not support deployments that mix these scenarios.

Also, Scenario 1 and Scenario 5 are problematic, so Java ES Release 5 does not currently support them (though accommodation might be made for specific product components in the case of Scenario 5).

Table A–2 Zones Installation and Administration Strategies for Java ES

Scenario (Installation Strategy)	Administration Strategy	Objective (See Why Use Zones for Java ES?)	Comments
1: Install product components and shared components in the global zone with propagation enabled. No components installed in non-global zones.*	Component life-cycle management: Global administrator   Configuration and runtime management: Zones administrators	Centralized product component life-cycle management   Organizational independence for product component configuration and runtime management	Problematic: Not yet supported for Java ES product components, except for Message Queue. Requires that product components support installation in global zone but configuration and runtime management in non-global zones.
2: Install shared components in the global zone and product components in whole root zones	Shared component life-cycle management: Global administrator   Product component life-cycle management: Zones administrators   Configuration and runtime management: Zones administrators	Centralized shared component life-cycle management   Organizational independence for product component life-cycle, configuration, and runtime management	Mostly applicable when all components are of the same Java ES version, or when upgrading all product components in all whole root zones.
3: Install shared components in the global zone and product components in sparse root zones**	Same as Scenario #2	Centralized management of shared component life cycle.   Organizational independence for product component life-cycle, configuration, and runtime management   Increased resource efficiencies over Scenario #2 (See Whole Root Zones vs. Sparse Root Zones)	This scenario recommended when installing product components in sparse root zones. (Some shared components cant be installed in sparse root zones and must therefore be installed in global zone.)
4: Install product components and shared components in whole root zones	Component life-cycle management: Zones administrators Configuration and runtime management: Zones administrators	Version separation	No shared components or product components should be installed in the global zone. Recommended scenario for whole root zones.
5: Install product components and shared components in sparse root zones.	Same as Scenario #4	Organizational independence for product component life-cycle, configuration, and runtime management  Increased resource efficiencies over Scenario #4 (See Whole Root Zones vs. Sparse Root Zones)	Problematic. Cannot generally be implemented because a number of shared components cannot be installed in sparse root zones.

* Scenario 1 does not distinguish between whole root and sparse root zone environments; it assumes that no product components are installed in non-global zones. Installation of product components in non-global zones is covered in Scenarios 2-5.

** Scenario 3 assumes that /opt has not been made a read-only directory in the sparse root zone. If /opt were read-only, most Java ES product components could not be installed in sparse root zones and would have to be installed in the global zone, as in Scenario 1, as an alternative approach.

Recommended Practices

With Table A–2 in mind, here are a number of recommended practices:

• Plan your Java ES zones deployment strategy in advance depending on the objective in Why Use Zones for Java ES?that you are trying to achieve. Different objectives require different installation and administration strategies, as shown by the different scenarios of Table A–2.

• Avoid mixing scenarios. In particular:

  • Keep your Java ES zones deployment and administration strategy as simple as possible. Do not mix whole root and sparse root deployments of Java ES components on the same computer. (Procedures and practices needed to support sparse root zone deployments as in Scenario 3 can interfere with whole root zone deployments as in Scenario 4.)

  • Do not install the same Java ES product component in both the global zone and non-global zones, even if they are of different versions. (Procedures needed to upgrade a global zone installation as in Scenario 1 can break the non-global zone installations as in Scenario 4.)

  • When Release 4 (or earlier) Java ES components have been installed in a whole root zone, do not install Java ES Release 5 components (neither product components nor shared components) in the global zone, and do not upgrade Java ES components to Release 5 in the global zone. In other words, Scenario 2 is not supported when there are pre-existing Java ES installations in a whole root zone. (Installation or upgrade in the global zone could result in a mixing of Release 4 and Release 5 files in the whole root zone.)

• Recommended installation practices:

  • If you want to run different Java ES product components in different zones, install the product components in non-global zones (Scenario 2, 3, 4, 5).

  • If you want to run different Java ES product components in different zones but centrally manage shared component life cycles, synchronize shared components in the global zone, then install the product components in non-global zones (Scenario 2, 3). (This is a recommended practice whenever installing product components in sparse root zones.)

  • If you want to achieve version separation of Java ES product components or, for other reasons to isolate deployments of Java ES product components (Scenario 4), then install and configure all Java ES components in whole root zones. Do not install any Java ES components in the global zone.

• Recommended upgrade practices:

  • If you want to upgrade all installed Release 4 product components to Release 5, synchronize all Java ES shared components in the global zone, then perform the upgrade of the desired product components in the zones where they have been installed. (Release 5 shared components are backwardly compatible.)

  • If you have Release 4 or Release 5 product components installed in a non-zones environment, and you wish to add non-global zones to the environment and install product components in the new non-global zones, be sure to do so in accordance with the recommended practices above. This might mean uninstalling components in the global zone and reinstalling them in non-global zones.

Deployment Architectures

The scenario descriptions in Table A–2 and the recommended practices noted above do not include recommended Java ES deployment architectures for a multi-zone environment. Such architectures would be an adaptation of deployment architectures created for multi-computer network environments. In other words, the availability of multi-zone environments does not change the basic deployment design approaches for achieving high performance, high availability, scalability, security, and serviceability for Java ES deployment systems. What a multi-zone environment allows you to do is consolidate such deployment architectures into fewer computers.

Details of how to adapt a Java ES deployment architecture to a multi-zone environment, however, are highly dependent on the administrative strategies you desire, as discussed in previous sections. Deployment architectures also depend on your strategy for achieving high availability.

Note that Table A–2 and the recommended practices above do not include recommended procedures for implementing the scenarios that are described. In some cases the order in which Java ES components are installed and the order in which non-local zones are created can be important.

Special Cases or Exceptions

There are a number of special cases that arise mostly from the fact that some Java ES shared components and some Java ES product components are bundled with Solaris 10. By virtue of this bundling, these Java ES components exist in the global zone, and therefore in any non-global zone that is created from the global zone.

Product Component Special Cases

• Message Queue is bundled with Solaris 10, and, as a result, is automatically propagated when non-global zones are created (unless you have first removed Message Queue from the global zone). Message Queue cannot be installed in a sparse root zone. When installed or upgraded in a global zone by the Java ES installer, Message Queue, by default, is propagated to non-global zones, unlike other product components.

• Application Server is bundled with Solaris 10, and, as a result, is automatically propagated when non-global zones are created (unless you have first removed Application Server from the global zone). When propagated in this way, the bundled Application Server, which is installed in /usr, cannot be upgraded by the Java ES installer in a sparse root zone (by default /usr is read-only). To address this problem, the bundled Application Server must be manually removed from the global zone before installing the Release 5 Application Server in a sparse root zone.

• Sun Cluster can only be installed in a global zone. Sun Cluster is not supported in non-global zones.

Shared Component Special Cases

• SJWC packages that are bundled with Solaris 10 (Update 1 and Update 2) cannot be removed by the Java ES installer. These older SJWC packages have had the SUNW_PKG_ALLZONES set to True, which means the package must be identical in all zones and can only be managed by the global administrator. As a result these packages must be manually removed in the global zone to be replaced by the correct packages.

  If the Java ES installer is attempting to install a selected component in a non-global zone and detects that SJWC needs to be upgraded, the installer will block. This happens when installing on Solaris 10, Update 1 and 2.

  As a workaround, a special script has been developed that will remove the old packages of SJWC from the global zone and replace them with SJWC 2.2.6, which has the correct zones propagation attribute setting. As a result SJWC 2 2.6 is propagated to all non-global zones.

• Common Agent Container. Version 1.1 is installed only when Sun Cluster, Sun Cluster GE, or Sun Cluster Agents are installed. It is not installed when the Synchronize All Shared Components option is selected. Only version 2.0 is installed in that case.

• Sun Explorer Data Collector. This shared component is installed only when Sun Cluster, Sun Cluster GE, or Sun Cluster Agents are installed. It is not installed when the All Shared Components option is selected.

An Illustrative Example: Install Application Server in a Sparse Root Zone

The following example is provided to draw out some of the complexities involved in Java ES zones support. In this example, the objective is to install Application Server in a Solaris 10 sparse root zone. This installation is complicated by the fact that Application Server (as well as Message Queue, upon which Application Server depends), is bundled with Solaris 10, and therefore the bundled version is installed in all non-global zones. For more information, see Product Component Special Cases.

To install Application Server in a sparse root zone, you must first remove the bundled version. (You cannot simply upgrade the bundled version in the sparse root zone because it is installed in a read-only directory). To remove the bundled version from the sparse root zone, you must remove it in the global zone.

In addition, Message Queue is installed in the global zone, representing a departure from Scenario 3 of Table A–2, in which only shared components (not product components) are installed in the global zone. However, Message Queue cannot be installed in a sparse root zone, because it installs in a read-only directory, so it must be installed and upgraded in the global zone.

The procedure is as follows:

1. Verify Solaris 10 is running on your system.

   This example assumes a clean version of Solaris 10 with no Java ES components having been explicitly installed in the global zone.

2. Create a sparse root zone (configure, install, and boot it).

   This zone will include any Java ES components that are already installed in the global zone, namely the versions of Message Queue and Application Server bundled with Solaris 10.

3. Remove the bundled version of Application Server from the global zone.

   This must be performed by manually removing Application Server packages:

   pkgrm SUNWascmnse SUNWaslb SUNWasut ...

   Where the full set of packages can be obtained using the following command:

   pkginfo -I|grep -I application server

   The results would include packages such as:

   SUNWascmnse, SUNWaslb, SUNWasut, SUNWasac, SUNWasdem, SUNWasman, SUNWaswbcr, SUNWasacee, SUNWashdm, SUNWasmanee, SUNWascml, SUNWasJdbcDrivers, SUNWasu, SUNWascmn, SUNWasjdoc, SUNWasuee

   And might include localization packages as well:

   SUNWLocaleasacee, SUNWLocaleascmnse, SUNWLocaleasu, SUNWLocaleasuee

   The removal of Application Server from the global zone is propagated to the sparse root zone that was created in Step 2. (This step and Step 2 can be performed in reverse order.)

4. Install Java ES 5 Shared Components in the global zone.

   1. Run the Java ES installer in the global zone.

   2. Select All Shared Components from the component selection panel. Do not select any other component.

   3. Complete the synchronization of shared components. All of the shared components are now synchronized in the global zone and propagated to all non-global zones.

5. Upgrade Message Queue in the global zone.

   The version of Message Queue bundled with Solaris 10 is already installed in the sparse root zone by virtue of Step 2. To upgrade Message Queue in the sparse root zone, simply upgrade it in the global zone; the upgrade will propagate to the sparse root zone. (Message Queue is the only product component which cannot be installed in a sparse root zone, but when installed in the global zone, will propagate to non-global zones.)

   1. Run the Java ES installer in the global zone.

   2. Select Message Queue in the component selection panel. Do not select any other component.

   3. Complete the upgrade of Message Queue.

6. Install Application Server in the sparse root zone.

   1. Run the Java ES installer in the sparse root zone.

   2. Select Application Server in the component selection panel. Do not select any other component for upgrade. De-select Message Queue if it is selected.

   3. Complete the installation of Application Server.