Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java Enterprise System 2005Q1 Installation Guide 

Chapter 2
Developing Your Installation Sequence

This chapter provides information and guidelines for developing an installation sequence based on your Sun Java™ Enterprise System (Java ES) deployment plan. If you have not yet developed a deployment plan, refer to Java Enterprise System Deployment Planning Guide (http://docs.sun.com/doc/819-0058).

This chapter contains the following sections:


What Is an Installation Sequence?

The order in which you perform installation tasks for your particular deployment is called the installation sequence. It depends on three things:


What Does My Deployment Plan Call For?

This section discusses how to interpret your deployment planning documents in relation to the Java ES installation tasks you will need to perform. There are two deployment planning documents that form the basis of your installation plan: the deployment architecture and the implementation specification.

This section contains the following subsections:

Reviewing Your Deployment Architecture

A deployment architecture is high-level mapping of a logical architecture to a physical computing environment. The physical environment includes the computing nodes in an intranet or internet environment, the network links between them, and any other physical devices needed to support the software.

A sample deployment architecture might look like the following figure.

Figure 2-1  Example Deployment Architecture

This figure shows an example deployment architecture.[D]

Reviewing Your Implementation Specification

The implementation specification is a document that outlines what needs to be done to implement the Java ES deployment architecture. The implementation specification includes details on what software goes on what hardware, and what configuration details will enable users to access the services.

The implementation specification includes details on the following:

The implementation specification might also include a description of the pilot system and the prototypes you need to set up and test before applying your deployment in a production environment. Whatever installation plan you develop for your pilot system (also called a sandbox or staging system), you will repeat the plan for the final rollout to production.

Although your implementation specification gives you a detailed list of what should be done, the specification does not tell you how installation should proceed. You will need to examine this specification as it applies to your particular deployment layout, then identify the key issues that will impact your installation.

What Are the Key Installation Issues?

Each deployment presents a different set of issues and components. By examining your implementation specification, you should be able to identify the main issues that will impact the sequence of installation.

The following table lists some typical deployment requirements that might affect your installation sequence. The left column lists the functionality called for in your deployment plan, and the right column contains a pointer to some information on that requirement.

Table 2-1  Installation Issues to Consider 

Deployment Requirement

Guidelines or Instructions

High availability using Sun Cluster software

Installing Sun Cluster software for high availability is described in Sun Cluster Software Example.

Solaris 10 zones

If you will be installing into Solaris 10 zones, refer to Solaris 10 Zones.

Directory Server replication

Note: If Directory Server replication is a requirement, Administration Server should be installed when Directory Server is installed.

Directory Server encryption

Configuring LDAPS (SSL over LDAP) on the Directory Server instance

Note: If Directory Server encryption is a requirement, Administration Server should be installed when Directory Server is installed.

Third-party web container

Third-party web containers (BEA WebLogic Server or IBM WebSphere Application Server) can be used with Portal Server and Access Manager. These containers must be installed and configured before installation any Java ES components that depend on them.

Note: To use a third-party web container for Access Manager SDK, you must configure Access Manager SDK manually after installation. See Access Manager SDK With Container Configuration Example.

Note: Portal Server can only use third-party web containers on Solaris OS, not Linux.

Apache Web Server for load balancing plugin

The Apache Web Server can be used with the Application Server load balancing plugin. In this case, the Apache Web Server must be installed and configured before installing any Java ES components that depend on it. For additional information, refer to Installation Prerequisites.

Separation of Portal Server and Access Manager

If Portal Server and Access Manager must be installed on separate hosts, refer to Portal Server Using a Remote Access Manager Example.

Schema 1 LDAP

An installation example based on LDAP Schema 1 is described in Calendar-Messaging Schema 1 Example. For a Schema 1 deployment, you cannot use Access Manager.

Single user entry

Guidelines for setting up a single user entry, possibly for single sign-on, can be found in the Sun Java Enterprise System User Management Guide (http://docs.sun.com/doc/817-5761). Access Manager is required to set up single sign-on for Schema 2.

High availability using HADB

An example of setting up the HADB for high availability is contained in Web and Application Services Example.

Load balancing

An example that includes using the Application Server load balancing plugin is contained in Web and Application Services Example

Non-root ownership

If non-root ownership will be required for Application Server or Web Server, refer to one of the following examples:

Access Manager Configured to Run as a Non-root User Example

Portal Server on a Non-root Owned Web Server or Application Server Instance Example

32-bit Directory Server on 64-bit platform

If you will be using a 32-bit Directory Server on a 64-bit Solaris SPARC Platform, refer to Configuring Directory Server After a Configure Later Installation.


How Do Component Interdependencies Affect My Installation?

To determine the best sequence for installing Java ES, it is important to understand how the components depend on each other. This section presents the basic interdependencies and explains some of the implications of these dependencies.

From an installation point of view, the Java ES components are layered as follows, with the bottom layer generally providing a base for the layers above.

5

Portal Server, Portal Server Secure Remote Access

4

Calendar Server, Messaging Server, Instant Messaging, Communications Express

3

Directory Server, Directory Proxy Server, Access Manager

2

Web container (Application Server, Web Server)

1

Sun Cluster software

The layering does not necessarily indicate which components require other components. For example, if your deployment does not specify Sun Cluster software, then Layer 1 is not a factor for you. Or if your deployment does not require a web container, then the second layer is not a factor in your installation planning.

Table 2-2 shows the dependencies among the Java ES components (not including dependencies on shared components, such as J2SE). Using this table, you can list or diagram the chain of dependencies across the hosts in your deployment. The left column lists the components, the middle column lists what is required for each component, and the right column indicates whether or not the required components must be installed on the local host.

Table 2-2  Cross-Component Dependencies 

Component

Required Component(s)

Required Must Be Local?

Access Manager

Directory Server

No

Web container, one of:

  • Application Server
  • Web Server

Yes

Note: To use a third-party web container for Access Manager SDK, you must configure Access Manager manually after doing a Configure Later installation.

Access Manager SDK

Access Manager

No

Administration Server

Directory Server

No

Application Server

Message Queue

Yes

Web Server if using load balancing

No

Calendar Server

Directory Server

No

For Schema 2:

Access Manager

 

No

A web container. See Access Manager.

No

Communications Express

Directory Server

No

Administration Server

Yes

Calendar Server if using calendar service

No

Messaging Server with Administration Server if using messaging service

Yes

For Schema 2:

Access Manager SDK

Yes

Access Manager

No

Web container. See Access Manager.

Yes

Directory Preparation Script

None

Not applicable

Directory Proxy Server

Directory Server

No

Administration Server

Yes

Directory Server

None

Not applicable

HADB

None

Not applicable

Instant Messaging

 

For single sign-on or Access Manager managed policies:

Access Manager or
Access Manager SDK


No (IM Core)
Yes (IM Resources)

A web container. See Access Manager.

No

Message Queue

None

Not applicable

Messaging Server

Directory Server

No

Administration Server

Yes

For Schema 2:

Access Manager or
Access Manager SDK

 

No
Yes

A web container. See Access Manager.

No

Portal Server

Access Manager or
Access Manager SDK

No
Yes

Web container, one of:

  • Application Server
  • Web Server

For Solaris OS only:

  • BEA WebLogic Server
  • IBM WebSphere Application Server

Yes

Portal Server Secure Remote Access

Portal Server
Portal Server–if Gateway only

Yes
No

Access Manager or
Access Manager SDK

No
Yes

Sun Cluster

None

Not applicable

Sun Remote Services Net Connect

None

Not applicable

Web Server

None

Not applicable

Component dependencies affect installation in a number of ways. For example:

During installation, if you fail to select a component that fulfills a requirement, a message informs you that a requirement has not been met. The installation cannot proceed until the requirement is satisfied.

The order in which you install components on multiple hosts should be determined by the interdependencies of the components you are selecting. Some helpful examples can be found in Chapter 3, "Example Installation Sequences".


Can I Use an Existing Installation Example?

A good first step to developing an installation sequence is to examine the examples in Chapter 3, "Example Installation Sequences". If any of these examples resemble what is specified for your deployment, you can use the sequence in the example as a basis for developing your own installation sequence.

Even if one of the existing examples does apply, it is a good idea to also review all the material in this chapter so that you understand what the example sequences are recommending.

If you are able to use one of the examples as a model for developing your installation sequence, you can proceed to How Do I Survey Existing Hosts?. It is important that any existing hosts be brought to Java ES readiness before installing Java ES software.


Tip

If you are experienced in installing Java ES, you might be able to adjust an installation sequence to shorten the time required. The installation examples might give you some ideas on how to do this.



How Should I Plan Installation Sessions?

In additional to accommodating the interdependencies of the Java ES components, there are two additional issues that need to be considered in planning your sequence.

What Configuration Option Is Best?

The Java ES installer offers two options for doing the initial configuration of the Java ES components:

These configuration options are mutually exclusive. That is, you can only select a single option for an entire installation session. For example, you choose the Configure Later option, but a number of the selected components offer installation-time configuration. Because you have chosen the Configure Later option, all configuration must be done after installation is complete.

The configuration option you choose applies to the entire installation session. If you want to select different configuration options for some components, you must run multiple installation sessions.

Configure Later Option

When you select the Configure Later option during installation, the installer places the component package files in their respective directories. No parameter setting is done, and most components are not operational because runtime services are not available. No instances are configured After installation, you must then run the various configuration tools for the components.

Even if some of the components you have selected do offer installation-time configuration, these components are not configured. Postinstallation configuration is required for all components selected in a Configure Later installation.


Note

If you want to use a third-party web container for Access Manager, you must select the Configure Later option. During post-install configuration, you can specify the third-party container.


All components can be installed using the Configure Later option.

Configure Now Option

If you select the Configure Now option, configuration pages are presented in the installer for each of the components that can be configured during installation. You can accept the defaults that are presented, or you can enter alternate values. To gather configuration information before you begin installation, refer to Chapter 4, "Configuration Information".

If you have selected the Configure Now option and some of the components you have selected do not offer installation-time configuration, you receive a message telling you which selected components cannot be configured during installation. The installation proceeds, and configuration pages are displayed for those components that do offer installation-time configuration.

The following table lists the components that can be configured during installation.

Table 2-3  Components That Can Be Configured During Installation 

Component

Additional Configuration Required After Configure Now Installation

Access Manager

Directory Server provisioning is required. See Configuring Access Manager After a Configure Now Installation.

Administration Server

Must be configured after Directory Server is configured.

Application Server

None

Directory Server

None

Directory Proxy Server

None

Portal Server

Web container configuration is required. See Configuring Portal Server and Portal Server Secure Remote Access After a Configure Now Installation on a Sun Web Container

Configuring Portal Server and Portal Server Secure Remote Access After a Configure Now Installation on a Third-Party Web Container

Portal Server Secure Remote Access

None

Web Server

None

There will be little, if any, postinstallation configuration for the components that you configure during installation.

The following components cannot be configured by the Java ES installer: Calendar Server, Communications Express, HADB, Instant Messaging, Message Queue, Messaging Server, Sun Cluster software, and SunSM Remote Services Net Connect. If these components are included in a Configure Now installation, you will receive messages stating that these components cannot be configured. The installation will proceed and you will need to do postinstallation configuration for these components.

How Many Installation Sessions Are Needed?

Because of the interdependencies of the Java ES components, sometimes it is preferable, or even necessary, to perform multiple installation sessions on a host. At a minimum, one installation session is required for each host in your deployment.

Your installation sequence must take every deployment issue (such as load balancing) and every selected component (such as Sun Cluster) into consideration across all the hosts in the deployment. You cannot simply perform installation on one host, then another host, without having an overall installation sequence for the deployment. Some components must reside on the same host as other components, some must be installed and running before others, some must be configured in a particular way before a related component can be configured.

Single Installation Session

A single installation session is possible under the following circumstances:

Multiple Installation Sessions

Multiple installation sessions are required for most Java ES deployments. To install in multiple sessions, you run the installer once to install and configure some Java ES components, then run the installer again to install and configure other components.

When you use multiple installation sessions for components that are related (for example, Directory Server, Directory Proxy Server, and Administration Server), parameter settings must be the same through each session. Typical installation parameters include server root, user, and group.

Multiple installation sessions are used in circumstances such as the following:


How Do I Survey Existing Hosts?

Before installation, it is important to know what resides on the hosts where you plan to install the Java ES software. If you have ordered a new Solaris system that has Java ES software preloaded, you do not need to survey your host. However, if your existing hosts have versions of Java ES components already installed, you might need to upgrade or remove some software before running the Java ES installer.

This section contains the following subsections:

Is Java ES Software Preloaded on Solaris OS?

If you ordered a Sun Solaris hardware system with preloaded software, the installation image for the Java ES software has already been copied to your system.

If Java ES software is preloadeded on a host, the following directory exists:

/var/spool/stage/JES_05Q1_architecture/

The architecture variable indicates the system’s hardware architecture, such as, SPARC or x86.

You will need to expand the installation image and use the Java ES installer to install and configure the preloaded Java ES software as described in this manual. Although there are no preexisting Java ES components installed on the host, you will still need to plan your installation sequence.


Note

If your preloaded Java ES software is on a Solaris 10 system:

  • Before expanding the installation image, refer to Solaris 10 Zones so that you will understand how the Java ES software must be installed to operate with Solaris 10 zones.
  • Sun Cluster software does not work with Solaris 10 for this release.

Are Incompatible Components Installed?

During installation, the installer verifies that any Java ES components that are already installed on the host are compatible with the version of Java ES you are installing. If some components are not compatible, your installation is likely to be interrupted by incompatibility error messages. Therefore, it is important to survey installed software and do any upgrading before running the Java ES installer.

The Java ES installer does not upgrade components during installation, with one exception: when Application Server and Message Queue have already been installed with the Solaris OS, the installer asks if you want to upgrade during installation.

The Java ES installer does upgrade shared components during installation.

Component Versions Required for This Release

The Java ES software associated with the 2005Q1 release includes the following selectable components. (The abbreviated names used in this guide follow the name and version.)

To see the full list of services and subcomponents as displayed in the Java ES installer, refer to Appendix A, "Java Enterprise System Components". This appendix also lists the shared components that are provided with this release.

Using the Installer to Survey Installed Software

You can use Solaris commands such as prodreg and pkginfo or the Linux rpm command to examine installed software. You can also use the installer itself to examine package-based software installations as described in the procedures in this section.


Note

Do not rely only on the Java ES installer for information about installed software. You must also perform an independent survey of the host to determine what software is currently installed.


    To Provide Access to Your Local Display for the Graphical Installer

If you are logging in to a remote host, make sure your DISPLAY environment variable is properly set to the local display. If the DISPLAY variable is not set properly, the installer runs in text-based mode.

You might need to grant display authorization to run the installer on your local display. For example, you can use the following command to grant display authority from myhost to the root user on serverhost:

myhost> xauth extract - myhost:0.0 | rsh -l root serverhost xauth merge -


Note

For full instructions on granting such authorization safely, refer to the “Manipulating Access to the Server” chapter in the Solaris X Window System Developer’s Guide (http://docs.sun.com/doc/816-0279).


    To Use the Installer for Identifying Upgrade Issues
  1. On each host, start the installer using the -no option to indicate that this is not an active installation:
  2. For the graphical installer:

    ./installer -no

    For the text-based installer:

    ./installer -nodisplay -no

  3. Proceed to component selection.
  4. Select the components you are planning to install on this host. The Status column indicates products that are required for the components you have selected.
  5. If an incompatible version of a selectable component is detected by the installer, you are prompted to upgrade or remove the incompatible version. After resolving the problem, you can refresh the selection list, make your selection, and then ask the installer to proceed.
  6. If an incompatible version of a shared component is detected by the installer, the Shared Component Upgrades Required list is displayed.
  7. For each shared component listed, review the Installed Version against the Required Version to determine if any upgrading will need to be done. You must determine whether the newer Java ES versions of shared components are compatible with other installed applications on the host.

  8. Exit the installer and do any upgrading necessary.
    • For selectable components, refer to the Java Enterprise System Upgrade and Migration Guide (http://docs.sun.com/doc/819-0062).
    • For shared components, most upgrading can be done during installation.
  9. Repeat the procedure for each target host.

  10. Note

    The installer detects the Directory Server version that is distributed with the Solaris OS and warns you that the Directory Server script belonging to the Solaris distribution will be renamed by the installer. No action is required.


Are Your Hosts Ready?

Before you start the installer, review the issues in this section.

System Requirements

Before you install Java ES, ensure that the hosts in your system meet the minimum hardware and operating system requirements. For the latest information on the supported platforms and software and hardware requirements, refer to “Hardware and Software Requirements” in the Java Enterprise System Release Notes (http://docs.sun.com/doc/819-0057).

If the operating system found on the host does not satisfy Java ES recommendations, the installer cannot proceed. You must resolve this problem before installation.

Access Privileges

To install Java ES software, you must be logged in as root, or become superuser.

Memory and Disk Space Requirements

The installer runs a check to determine if your host has sufficient memory and disk space for the components you selected.

Korn Shell Required for Portal Server on Linux

To install and configure Portal Server on Linux, the installer requires that the Korn shell be accessible at /bin/ksh. If your host does not have the Korn shell installed, you can get the Korn shell software by issuing the following command:

up2date pdksh


Next Steps

If you have not yet surveyed your existing hosts and done any upgrading required, refer to:

If you have not yet examined the example scenarios, refer to the Chapter 3, "Example Installation Sequences".

If you are going to do a Configure Now installation, gather your configuration information in Chapter 4, "Configuration Information".

When your installation sequence is ready, proceed to one of the following installation chapters:



Previous      Contents      Index      Next     


Part No: 819-0056-11.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.