Previous | Home | Next - Centralized Installation Manager


Maintenance

Managing the environment with the centralized installation manager

WAS V7 introduced the centralized installation manager. Starting from WAS V8, the centralized installation manager evolved with new capabilities and is integrated with both the Installation Manager and the job manager.

The centralized installation manager (CIM) can reduce the number of steps required to install and maintain the WAS environment. Its features allow the centralized installation manager to work outside the WAS cell to schedule the installation and maintenance tasks.

The process for managing v7 and previous versions are different than the process for managing v8 and v8.5. Starting with CIM v8, the Installation Manager is used to install the product on remote machines, where Versions 6.1 and 7 use ISMP and Update Installer.


The centralized installation manager prerequisites

To avoid issues when using the centralized installation manager, ensure that your platform satisfies the requirements listed in this section.


Linux and UNIX target requirements

The centralized installation manager, through RXA, uses SSH v2 to access UNIX and Linux target workstations. This usage requires using either OpenSSH 3.6.1 (or, if accessing AIX targets, OpenSSH 4.7) or Sun SSH 1.1 on the target hosts.

Note that OpenSSH 3.7.1, or higher, contains security enhancements not available in earlier releases, and is recommended.

Using OpenSSH: OpenSSH Version 4.7.0.5302 for IBM AIX v5.3 is not compatible with Remote Execution and Access v2.3. If wer target systems are running AIX v5.3 with OpenSSH Version 4.7.0.5302 installed, the file transfer might stop in the middle of the transfer. To avoid this problem, revert the OpenSSH version from Version 4.7.0.5302 to Version 4.7.0.5301


Using the SSH protocol

RXA does not supply SSH code for UNIX operating systems. You must ensure that SSH is installed and enabled on any target to access using centralized installation manager.

In all UNIX environments, except Solaris, the Bourne shell (sh) is used as the target shell. On Solaris targets, the Korn shell (ksh) is used instead because of problems encountered with sh.

To communicate with Linux and other SSH targets using password authentication, edit the /etc/ssh/sshd_config file on the targets and set the following property:

The default value for the PasswordAuthentication property is no.

After changing this setting, stop and restart the SSH daemon using either of the following commands sequences:


Installing a secure shell public key to access remote targets

UNIX platforms generally support the use of SSH protocol. To use the SSH public/private key as an authentication method for accessing remote workstations, SSH must be installed and enabled on the installation target system. On AIX and Linux systems, issue the following command to ensure that SSH is enabled on the installation target:

We can generate an RSA private key and its corresponding public key using the ssh-keygen command.

Take the default location for storing the private key and make note of it. If we specify a non-empty string for the passphrase prompt, remember the string because you need it when to use the generated private key.

Additionally, know the location of the SSH public key file on the deployment manager and the administrative ID and password for the installation target. This information is the same administrative ID and password that you use later to install or uninstall software packages on the same installation target.


Windows target requirements

Many RXA operations require access to resources that are not generally accessible by standard user accounts. Therefore, the account names that you use to log in to remote Windows system targets must have administrative privileges.

To ensure that your Windows system targets cooperate with the centralized installation manager, configure the following components:


IBM i targets

Use of SSH public/private key authentication is not supported on IBM i platforms.


Additional requirements

Before using the centralized installation manager to install or uninstall maintenance on IBM AIX operating systems as a non-root user, install and configure sudo, an open-source tool, on the target AIX operating systems.

To install and configure sudo, download sudo from the IBM AIX Toolbox for Linux Applications official download website:

After sudo is downloaded, log on to the target system as root and install...

If wer AIX system does not already have rpm installed, we can download an AIX installp image for the rpm package manager for IBM POWER.

Authorize a non-root user ID specified to run the slibclean command as a root user without providing a password. Next, issue the visudo command to add the following entry to the /etc/sudoers configuration file (replace userID with the real user ID that you will be using):

Log in with the specified user ID and then issue the sudo -l command. If successful, a message similar to the following example displays:

User userid might run the following commands on this host:

If we do not have sudo installed or if sudo is installed but not configured correctly for the specified user ID, error messages are displayed.


Planning considerations

Ensure the environment meets the centralized installation manager prerequisites for the platform before you attempt to work with the centralized installation manager.


WAS V8 and V8.5

For WAS V8 and V8.5, you access the centralized installation manager functions through the job manager or deployment manager. Using the job manager or deployment manager, we can perform the following functions:

With the centralized installation manager for v8 and v8.5, we cannot install or update Installation Manager on a z/OS target. Prior to working with z/OS targets with the centralized installation manager, ensure the Installation Manager is already installed.

When working with WAS V8 and V8.5 and the centralized installation manager, you need an additional 120 MB of disk space for the Installation Manager installation kit. If the environment includes different operating systems, additional disk space is required for other Installation Manager versions.


WAS V6.1 and V7

For WAS V6.1 and V7, you access the centralized installation manager functions using only the deployment manager. The centralized installation manager for v6.1 and v7 does not support z/OS operating system targets. Using the centralized installation manager for v7, we can perform the following functions:

  • Install, update, and uninstall WAS ND V7 on remote machines
  • Install and uninstall WAS V6.1 and V7 refresh packs, fix packs, and interim fixes on remote machines
  • Install and uninstall customized installation packages (CIPs)

    To use the centralized installation manager for v6.1 or v7, the disk space required increases significantly and varies depending on how many binaries there are in the repository.

    The centralized installation manager relies on current information regarding the versions of WAS that are installed on each node. This information is kept current on the deployment manager configuration by the node agent running on each node. The deployment manager is aware of the correct versions of WASs that are installed on each node, if the node agent of each node is started at least once after an update is applied. To ensure the deployment manager receives this information, the centralized installation manager starts the node agent automatically after each installation or uninstallation of maintenance.

    The centralized installation manager relies on the node agent to effectively stop the server processes on the target node. If the node agent is not running, it is up to the administrator to ensure that all the server processes are stopped on the target node before initiating any maintenance update operations on the node.


    Working with the centralized installation manager and


    WAS v8 and V8.5

    In WAS V8 and V8.5, the centralized installation manager uses the Installation Manager to manage targets. We can access the centralized installation manager using several methods, including the job manager console or the command line.


    Installation Manager

    WAS V8 and V8.5 use Installation Manager. Be sure to use an up-to-date version of Installation Manager when working with the centralized installation manager. Minimum required version of the Installation Manager is v1.5.2. Installation Manager is integrated with the centralized installation manager, deployment manager, and job manager to provide a single, central place of administration for the following tasks:

    • Installing and uninstalling products
    • Updating and rolling back fix packs and interim fixes
    • Installing and uninstalling feature packs

    Installation Manager provides a common installation technology, which makes it easier and faster to manage your software. Installation Manager can install a desired level of maintenance in single pass, based on GUI commands or response files. One instance of Installation Manager can manage WebSphere and other IBM products, such as Rational.

    Installation Manager also allows you to record response files when invoked with the -record and -skipInstall options. This method makes it easier to prepare a valid response file for the environment.

    The job manager or deployment manager stores the Installation Manager installation kit in their local directory. By default, the kit resides at the job manager or deployment manager PROFILE_HOME/IMKit directory. To change the location of the kit, in the job manager or deployment manager console, click Jobs | Installation Manager installation kits.

    We can add multiple Installation Manager installation kits for many platforms. Figure 29-1 illustrates an example of Installation Manager installation kits V1.5.2 for different platforms.

    To install software on your targets using the Installation Manager, add the proper version of the Installation Manager installation kit valid for the target operating systems.


    Accessing the centralized installation manager

    We can access the centralized installation manager in WAS V8.5 and V8 from the following interfaces:

    • The job manager console

    • The deployment manager console

    • The AdminTask object from wsadmin

    The console for the centralized installation manager tools is available under the Jobs menu and is accessible from the job manager or deployment manager for WAS V8 and V8.5.

    Menu options in the job manager or deployment manager console...

    • Submit: Prepares and submits jobs to one or more targets.
    • Status: Displays a current status of submitted jobs.
    • Targets: Lists defined targets and allows you to create new targets.
    • Target resources: Lists target resources, which is useful when working with target groups.
    • Target groups: Lists and defines target groups.

  • Installation Manager installation kits: Configures the Installation Manager installation kit repository.

    We can also work with the centralized installation manager using the command line. We can use AdminTask by invoking it from the wsadmin script from the job manager or the deployment manager host. Example 29-1 presents a Jython example of AdminTask usage. In this example, a testConnection job type invokes the target to verify the connection between job manager or deployment manager and yourhost.com is active.

      AdminTask.submitJob('-jobType testConnection -targetList [yourhost.com]' -username admin -password admin)


    Working with the centralized installation manager and

    WAS V6.1 and V7 WAS V8.5 and V8 do not require IBM Update Installer or IBM Installation Factory. However, it supports these products in case you plan to use v6.1 or v7 together with WAS v8 or v8.5.

    The following sections explain additional components used when managing Version