+

Search Tips   |   Advanced Search

Centralized Installation Manager


 


Introduction

The Centralized Installation Manager (CIM) is a new feature for WAS ND v7.0 for distributed platforms, Windows, and IBM i.

With CIM, after installing ND on a machine, creating a dmgr node, and starting the dmgr, you can use CIM to...

This document describes how to...

CIM does not replace the standard installer and update installer tool used to install and update WAS v7. Rather, the CIM pushes the product binary files or maintenance to the remote targets and invokes the standard installer or update installer tool to perform the installation or update on the targets.

Use the Installation Factory to add product components to the repository. The Installation Factory is included in the WAS ND v7.0.

Use the CIM to install selected product components from the repository, which is located on the dmgr, to the nodes.

As an administrator, you can remotely install or uninstall product components and maintenance to specific nodes directly from the administrative console without having to log in and repetitively perform these tasks.

The CIM does not replace the Installation wizard or the IBM Update Installer for WAS. Instead, the CIM starts the Installation wizard for the product component or the Update Installer to install or uninstall the components or maintenance.

The various product components and maintenance files that you can install or uninstall by using the CIM include...


Notes on starting the node agent

The CIM relies on current information regarding the versions of WAS installed on each node. This information is kept current on the dmgr configuration by the node agent that is running on each node. The dmgr contains the correct versions of WAS installed on each node if the node agent of each node is started at least once after each update is applied.

To ensure that the dmgr receives this information, the CIM automatically starts the node agent after each installation or uninstallation of maintenance.

To locally apply updates on the nodes without using the CIM, issue the startNode command after you complete the operation to manually start the node agent.

Secondly, the CIM relies on the node agent to effectively stop the server processes on the target node and if the node agent is not running, the administrator will have to ensure that all the server processes are stopped on the target node before initiating any maintenance update operations on the node.


Update Installer for WAS v7.0

The CIM installs an appropriate level of the Update Installer on the target systems that it uses to install fix packs and other maintenance. If you had previously installed the Update Installer tool on any of the target hosts in a directory location other than...

WAS_INSTALL_ROOT/UpdateInstaller

...then you may want to consider uninstalling the Update Installer by using its uninstallation process because that copy would not be used by the CIM. But it is not mandatory to uninstall that copy for CIM to work properly.

The CIM will automatically install the Update Installer tool, if it is not already installed, in...

WAS_INSTALL_ROOT/UpdateInstaller

...when you install fix packs or other maintenance on the target systems.

If the version of the Update Installer tool found in...

WAS_INSTALL_ROOT/UpdateInstaller

...does not meet the minimum version required by the interim fix or fix pack, the CIM automatically installs a newer version on the targets, if you have downloaded the newer version of the Update Installer tool to repository.

You cannot use CIM to install the Update Installer on nodes that are not federated to the dmgr cell.


Temporary installation locations

After the CIM successfully completes the installation process on a remote node, it then deletes the installation image files located in the temporary location that you specify during the installation process. If the installation is unsuccessful, the files remain in the temporary location for you to use to determine what caused the installation error. However, you can safely delete the files.


2.2 Add the installation package as part of the installation flow

You can add the installation package to the CIM repository as part of the installation flow. This function is only available in the Installation wizard of IBM WAS ND.

To populate the repository, ensure that you have write permission to the repository directory.


Procedure

  1. Launch the Installation wizard for WAS ND.

  2. The repository for CIM panel will be displayed after WAS Environments panel, only if the selected profile types are cell, dmgr or none.

  3. To create a repository, select the check box...

    Create a repository for Centralized Installation Managers

    • Click Browse to specify the directory path of the repository.

    • Select check box...

      Populate the repository with this installation package

      ...to populate the repository.

    • Click Next to continue.

    If you did not select the check box, use the WebSphere Installation Factory to create and populate a repository later.

  4. If the directory path of repository already contains the same installation package, the option dialog is displayed. Click Yes to overwrite the existing installation package. Click No otherwise.


Populate a CIM repository with silent installation

Use the following optional parameters to create and populate a CIM repository:

-OPT cimSelected="true"

Specify this option to create a repository for CIMs.

-OPT cimRepositoryLocation="installation_location/cimgr"

This option must be specified if cimSelected option is specified.

-OPT populateRepository="true"

Specify this option to populate the repository with the current installation package.

-OPT overwriteRepository="true"

Specify this option to overwrite the existing installation package.

Example 1:

Use these options to create and populate the repository with the installation package on...

/IBM/WAS/cimrepos

...and overwrite the existing installation package.

Example 2:

If the specified installation package already exists in the repository, then use these options to create the repository only on...

/IBM/WAS/cimrepos

Otherwise, these options create and populate the repository with the installation package.

Example 3:

Use these options to create the repository only on...

/IBM/WAS/cimrepos


Add installation packages to a repository

Use Installation Factory to add WAS v7.0 or WAS CIPs to the repository. From the administrative console, you can then use the CIM to install added components from the repository to the nodes.

  1. Ensure you have write permission to the repository directory.

  2. Ensure you have write permissions to the WAS installation you are associating with the repository...

    app_server_root/properties

  3. Launch Installation Factory...

    • installation_factory_root/bin/ifgui.bat
    • installation_factory_root/bin/ifgui.sh

    ...and click...

    Manage Repository for Centralized Installation Manager

  4. On the WAS installation directory page, optionally enter the directory path to a WAS installation to associate the repository with the installation.

  5. Enter the directory paths to the repository and the installation package on the page...

    Repository and Installation Package

    The specified installation package is populated to the repository when the procedure is complete. If you only want to configure the WAS installation to associate the repository, then enter the directory path to the WAS installation on the previous page and leave the directory path to installation package to empty.

    To change selections, click Back.

  6. Review the preview page, and click Finish to begin the procedure on the repository.


Command line

You can also launch Installation Factory command line...

You can specify the following options:

-wasPath wasInstallationPath directory path of the WAS installation.
-repositoryPath repositoryPath directory path of the repository.
-installationPackagePath installationPackagePath directory path of the installation package.
-overwrite Overwrites the existing installation package in the repository.

Use the following command to create the repository on...

D:\CIM\repository

If the repository does not already exist, populate the repository with the installation package on ...

E:\WAS70ND

...and configure the WAS installation on...

C:\IBM\WebSphere\AppServer

...with the repository.

ifcli.bat -wasPath C:\IBM\WebSphere\AppServer -repositoryPath D:\CIM\repository -installationPackagePath E:\WAS70ND

Use the following command to add the installation package in...

E:\WAS70ND

...to the repository, which is associated with the WAS installation in...

C:\IBM\WebSphere\AppServer
ifcli.bat -wasPath C:\IBM\WebSphere\AppServer -installationPackagePath E:\WAS70ND

Use the following command to add the installation package in...

E:\WAS70ND

...to the repository in...

D:\CIM\repository

Overwrite the installation package in the repository if it exists already.

ifcli.bat -repositoryPath D:\CIM\repository -installationPackagePath E:\WAS70ND -overwrite

Use the following command to configure the WAS installation in...

C:\IBM\WebSphere\AppServer

...with the repository at...

D:\CIM\repository

The repository is created if it does not exist.

ifcli.bat -wasPath C:\IBM\WebSphere\AppServer -repositoryPath D:\CIM\repository


Results

The CIM repository now contains one or more WAS installation packages.

Each WAS installation has only one associated repository. The repository is shared among all the dmgrs of the installation.

Alternatively, you can add the installation package to the repository as you install the installation package on the dmgr workstation.


2.4 Special procedures for IBM i operating systems

Special procedures are required if you choose to run Centralized Installation Manager on IBM i operating systems. Since Installation Factory is not supported on IBM i operating system, create the repository on a Windows operating system and then transfer the repository to the IBM i operating system.

There are two ways to add installation packages into a CIM repository on an IBM i operating system. For local installations, the install image can be added as an optional procedure during the silent install of WAS. For remote installations, the user can use Installation Factory to create a repository on a Windows system, and then transfer the packages to the repository that resides on the IBM i system.


Using the silent installer locally on IBM i operating systems

Edit the response file, and set options...

...to the appropriate values. See comments in the response file for more details. The repository is created and populated as part of the installation process.


Using Installation Factory on Windows

  1. Install WAS ND v7.0 onto the IBM i operating system.

  2. Install Installation Factory onto the Windows operating system.

  3. Insert the WAS ND v7.0 installation disk into the drive of the Windows system, or create a CIP with Installation Factory on the Windows system.

  4. Create a repository locally on the Windows operating system with Installation Factory.

  5. Change the directory to the repository path. Run: zip -r cimrepos.zip * to create a compressed file including all the directories in the repository.

    You can also selectively include only the directories you want. If you are including any CIP images, you need to also include the corresponding CIP descriptors in the descriptors directory. The CIP descriptor is an XML file whose name contains the CIP directory name. For example, if the CIP directory name is...

    com.ibm.torolab.ND70_AIX_PPC32_1.0.0.0

    ...then the descriptor name is something like...

    InstallPackageND70X_com.ibm.torolab.ND70_AIX_PPC32_1.0.0.0.xml

  6. Log onto the IBM i system. Open the property file...

    <app_server_root>/properties/cimgr.props

    ... and look at the value of...

    CENTRALIZED_INSTALL_REPOSITORY_ROOT

    This is the location of the repository on the IBM i system. You can change it to point to another location.

  7. Create the repository directory if it is not already created.

  8. Transfer the file, cimrepos.zip, from the Windows system to the repository directory on the IBM i system.

    Extract the contents of the cimrepos.zip file onto the repository directory and optionally delete the file, cimrepos.zip. Now you have added the installation packages into the CIM repository on the IBM i system.

Instead of creating the repository on the disk drive of the Windows system and transferring the file, alternatively, you can map the IBM i file system of the repository onto the Windows system and use it for populating the installation packages. Using this alternative method eliminates transferring the files to the IBM i system.


Use the CIM to install components

Use the CIM to install the components to the nodes and begin managing environments. In the administrative console, click...

System administration | Centralized Installation Manager


Considerations when using customized installation packages


WAS v7.0 customized installation packages

For new installs of WAS v7.0 CIPs using CIM, on the Available Installation page, the following buttons are available...

For slip installation of a CIP, use a response file and therefore click the button...

Install with response file

To uninstall WAS v7.0 that was installed using a customized installation image, you can select either the WAS ND v7.0 package or the WAS customized installation package as the installation package. Clear all features under Select optional features. Click the button...

Show Uninstallation Targets

Select one or more targets from the table, and click Uninstall to launch the wizard. Any CIP installation packages can be used to uninstall all platforms of WAS v7.0 from workstations that are part of the ND cell.


WAS v6.1 customized installation packages

Centralized installation manager does not support the installation of WAS v6.1 customized installation packages. Instead, use the fix packs to upgrade WAS.


2.6 Requirements for using Remote Execution and Access

WAS ND provides new management features, such as initiating installations of product packages and maintenance for distributed platforms from the administrative console. To provide this new functionality, the product uses the Tivoli® Remote Execution and Access (RXA) toolkit to access remote workstations. For this facility to work, complete target-specific requirements.


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 onto remote Windows targets must have administrative privileges.


Simple File Sharing

Windows XP system targets must have Simple File Sharing disabled for Remote Execution and Access to work. Simple Networking requires that you log in as guest. A guest login does not have the authorization necessary for Remote Execution and Access to function correctly.

To disable Simple File Sharing, open Windows Explorer and click...

Tools | Folder Options | View | Use Simple File Sharing

Clear the check box...

Use Simple File Sharing

Click Apply and OK.

On Windows Vista systems, file sharing must be enabled for the Guest or Everyone accounts, and password protected sharing must be disabled. To disable password protected sharing, perform the following steps:

  1. Click...

    Control Panel | Network and Sharing Center | Sharing and Discovery

  2. Expand Password protected sharing by clicking the down arrow on the far right.

  3. Select Turn off password protected sharing.

  4. Click Apply, and exit the control panel.


Firewalls

Windows XP systems include a built-in firewall that is called the Internet Connection Firewall (ICF), which is disabled by default. For Windows XP Service Pack 2 systems, the Windows firewall is enabled by default. If either firewall is enabled on a Windows target workstation, Remote Execution and Access cannot access the target workstation. On Windows XP Service Pack 2, you can select the check box...

File and Printer Sharing

...in the Exceptions tab of the Windows Firewall configuration to allow access. Do not block port 445.


Administrative sharing

Enable the remote registry administration, which is the default configuration, on the target workstation for Remote Execution and Access to run commands and scripts. To verify that the remote registry is enabled and started, click...

Start | Programs | Administrative Tools | Services

From Remote Registry, ensure the status of the service is started.

Enable administrative sharing to successfully use Remote Execution and Access to connect to Windows systems targets. Examples of the default administrative disk share are C$ and D$. If you disable sharing, Remote Execution and Access considers directories located within the drives as hidden. In this case, the following message is displayed:

XCIM0009E: Error connecting to remote target <host_name>. Exception: java.io.FileNotFoundException: CTGRI0003E The remote path name specified cannot be found: <file_or_directory_path>. Cause: com.starla.smb.SMBException: The network name is incorrect.

To enable administrative sharing:

  1. Click My Computer.

  2. Right click the disk drive that you are enabling for administrative sharing.

  3. Click Sharing and Security.

  4. Select Share this folder.

  5. Specify the Share name, such as C$ or D$, and click OK.


Connecting to Windows Vista targets

To connect to Windows Vista targets, use one of the following options. Before you begin, ensure that the Remote Registry in Windows Services is started, and port 445 is unblocked in the firewall.

  1. Configure both the dmgr machine and the Vista target as members of a Windows domain. Use a user account in that domain, or in a trusted domain, when you connect to the target.

  2. Enable and use the built-in administrator account to connect to the target workstation...

    • Select...'

      Control Panel | Administrative Tools | Local Security Policy | Security Settings | Local Policies | Security Options

    • Double-click...

      Accounts: Administrator account status

    • Select Enable, and click OK.

  3. Disable the User Account Control that is enabled by default if you are using a different user account to connect to the target workstation.

    To disable User Account Control:

    • Select...

      Control Panel | Administrative Tools | Local Security Policy | Security Settings | Local Policies | Security Options

    • Double-click...

      User Account Control: Run all administrators in Admin Approval Mode

    • Select Disable, and click OK.

For the configuration changes to take effect, restart the workstation.


Linux and UNIX target requirements

The CIM, through RXA, uses SSH v2 to access UNIX® and Linux® target workstations. This usage requires the use of 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 SSH protocol

Remote Execution and Access does not supply SSH code for UNIX operating systems. Ensure SSH is installed and enabled on any target you want to access using CIM.

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 due to 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:

PasswordAuthentication yes

The default value for the PasswordAuthentication property is no.

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

/etc/init.d/sshd stop /etc/init.d/sshd start


IBM i targets

Use of SSH public/private key authentication to IBM i targets is not supported.


2.7 Additional requirement for installing or uninstalling maintenance on AIX as non-root

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

Complete the installation and configuration operations locally as the root user of the AIX operating systems without using CIM. You are required to complete the operations only once.


Procedure

  1. Download sudo from the IBM AIX Toolbox Download Web site.

  2. Issue the following command to install sudo:

    rpm -i sudo-1.6.7p5-3.aix5.1.ppc.rpm

    You can download an AIX installp image for the rpm package manager for POWER from the previous download Web site if AIX machine does not already have rpm installed.

  3. Authorize a non-root user ID, which you specify, to run the slibclean command as a root user without providing a password. Issue the visudo command to add the following entry to the /etc/sudoers configuration file:

    userid ALL = NOPASSWD: /usr/sbin/slibclean

  4. Log in with the specified user ID, and issue the sudo -l command.

    If successful, a message that is similar to the following example is displayed:

    User userid may run the following commands on this host:

    (root) NOPASSWD: /usr/sbin/slibclean /blockquote>

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


3 Usage Scenarios

This section shows end-to-end use cases of how the CIM can be used to assist WebSphere administrators.


3.1 Creating and managing an ND cell using CIM

Use the CIM to create a WebSphere ND cell and manage it.

To create a multiplatform cell using the CIM, you need...

  1. The CDs of all the WAS node platforms within the cell.

    For example, if cell is running on Windows, Linux and AIX operating systems, then you need the CDs for those platforms in the WAS ND edition.

  2. The Installation Factory for WAS, which is available on the install tools CD.

    You need this CD for the platform on which dmgr is running.

  3. For the CIM repository, approximately 3 GB for each platform in the cell.

    If you plan to create CIPs for use with CIM, then factor in additional disk space required for CIPs. You can delete images that are no longer needed from the repository to make more space available.


About this task

The CIM is capable of creating nodes on remote hosts by installing WAS ND and federating them to the existing dmgr.

Prior to CIM, you had to log in to every machine in the potential cell, install the servers manually, create a profile for each node, and federate the nodes to the dmgr. Now, these steps are all done for you by the CIM. You only select the machine host name, and provide the login credentials.


Procedure

  1. On the dmgr machine, launch the WAS ND Installation Wizard.

  2. From the Welcome Panel.

  3. From the License Panel, read and agree to the terms of the license.

  4. From the System Prerequisite Check panel.

  5. From the Optional Feature Installation panel, select all features.

  6. From the Installation Directory panel, select a writeable folder as the WebSphere installation root.

  7. From the Environment Selection panel, select Management.

  8. From the Server Type Panel, select Deployment Manager.

  9. From the Administrative Security panel, specify a user name and password for logging to the administrative console.

    This need not be the same user name and password for logging into the dmgr host.

  10. From the Repository for CIM panel, select the option to create a repository and specify the repository location.

    Select to populate the repository with the installation package.

  11. From the Installation Summary panel, click Next.

  12. After the installation is done, click Next.

  13. Start the dmgr...

    cd INSTALL_ROOT/profiles/Dmgr01/bin
    startManager.sh|bat

  14. Log in to the administrative console.

  15. Add other platform images for WAS ND to the CIM repository.

  16. Launch installations of WAS ND on the remote machines.

  17. You can monitor the status of the installations using CIM.


Results

The installation requests are sent via the CIM to install WebSphere application servers on the remote machines to create the cell.

The cell is now ready for management. You can add servers, install applications, and so on.


3.2 Update a cell to a new maintenance level

A new fix pack has been released and you want to update cell to the new maintenance level.

Use the WebSphere Update Installer (UPDI) to install the fix pack locally on the dmgr machine first. After that have a cell with all the node agents started. If the node agents are not running then make sure all the server processes on the target host have been stopped.


About this task

Complete the following steps to update all the nodes within the cell to the new maintenance level. You do not need to access the managed nodes directly while using CIM. With the node agent running on the targets, CIM will be able to stop all the running servers on the target node, update the remote node, and then restart the node agent.


Procedure

  1. Update the dmgr node to the new maintenance level.

    • Stop the dmgr server.
    • Update the dmgr node to the maintenance level needed using the Update Installer tool.
    • Restart the dmgr server.

  2. Log in to the administrative console.

  3. Download the fix pack binary files and Update Installer tool for the platforms you need into the CIM repository. You need the fix packs and Update Installers for all the nodes in the cell.

  4. Using the administrative console, install the new fix pack on all the nodes. You do not need to install the Update Installer tool directly on each node. CIM installs UPDI automatically if needed.

  5. You can monitor the installation requests of the maintenance packages.


4 Install packages


Use the CIM to install one or more packages to the specified target workstations.

First define an installation target, which is the remote workstation on which selected software packages might be installed. Workstations containing nodes defined in the cell are displayed as installation targets.

The CIM does not install maintenance on the dmgr. Instead, use the IBM Update Installer for WebSphere Software to apply maintenance to the dmgr.

During the installation process, the wizard prompts you to select an authentication method which is either user name and password or SSH public/private key. If you choose to use the SSH public/private key method, first create a pair of public/private keys and install the public key on all installation targets.

Ensure that the CIM repository is populated with the installation image for the components that you want to install on the remote workstations.

First create the repository to use the features of the CIM. If you did not create the repository during the product installation, you can still set up the CIM repository and add the binary installation images to the repository.


About this task

The number of steps to complete this task can vary depending on the type of installation package that you choose to install.


Procedure

  1. Click...

    System administration | Centralized Installation Manager | Available installations

  2. Select a package type, which is the type of installation you want to perform.

    For example, you can choose to complete a product installation, or an installation that applies various types of maintenance files.

  3. Select an installation package.

    If you choose a package that includes available features, select each feature from the feature list. This list is not displayed if you choose an installation package that does not include available features.

  4. To populate the table with a list of applicable target workstations on which to install the selected software package, click...

    Show installation targets

  5. Select one or more installation targets from the list, and click Install or Install Using Response File to start the Installation wizard.

    Not all installation packages support response files. The button...

    Install Using Response File

    ...is disabled if that installation package does not support response files.

  6. Accept the license agreement.

  7. Select an authentication method to access the installation target.

    You can choose to use either the SSH public/private key method, or the user name and password method to authenticate.

  8. Provide the authentication settings.

    Depending on the authentication method that you choose in step 3, provide the appropriate user name and password for one or more installation targets, or provide the location of the SSH private key file and password on the dmgr.

    If you choose to authenticate using the user name and password method, you can provide a common user name and password to access all installation targets, or you can configure unique user names and passwords for each target.

    Do not use the browser to save the user name and password. The browser might offer the same user name and password on different target names.

  9. If you choose to install using a response file, you can click Browse to locate the response file in the dmgr. For security reason, the browse function is restricted to browse response files in...

    DMGR_PROFILE_ROOT/cim/responsefiles

    ...and any subdirectories below it.


    Password encoding utility program for response files

    Passwords specified in the response file may optionally be encoded...

    ResponseFilePasswordEncoder.sh file_name password_keys_list [-Backup | -noBackup]

    ...where password_keys_list is a list of password keys, delimited by comma, for which the password values are to be encoded.

    The -Backup option is an optional argument for making a back-up copy of the response file to be encoded. The default option is -noBackup.


    Examples:

    To encode the password values in the response file, responsefile.nd.txt, identified by the keys...

    • importSigningCertKSPass
    • importPersonalCertKSPass

    ...enter...

    cd INSTALL_ROOT/bin
    ./ResponseFilePasswordEncoder.sh responsefile.nd.txt importSigningCertKSPass,importPersonalCertKSPass

    To encode the password values in the response file, and to keep a back-up copy of the original response file...

    cd INSTALL_ROOT/bin
    ./ResponseFilePasswordEncoder.bat responsefile.nd.txt importSigningCertKSPass,importPersonalCertKSPass -Backup

    Invalid arguments in the command line cause the utility to display the command usage information.

  10. Specify the installation location and the working location of each installation target.

    The installation location is the remote location of the installation target where the package will be installed.

    The working location specifies the directory on the remote target where the CIM will transfer the binary installation files from its repository to the target for subsequent installation on the target.

    Make sure you have enough disk space on both the installation location and the working location. The space required in the installation and working location varies by installation packages. Centralized installation manager transfers the binary files for the selected installation package from the repository and extracts the content of the binary files into the working location.

  11. Specify other command parameters.

    The Installation wizard is a generic wizard for all installation packages that the CIM supports. In addition to the standard installation location parameter, a particular installation package might have zero or more command parameters that require user input. Specify values for these parameters as needed or take the default values.

  12. Read the installation summary, and click Finish to submit the installation request to the CIM for processing.


Results

You completed the steps to install one or more packages to the specified target workstations. The CIM receives installation request, processes the information that you provided, and then installs the package to the workstations.


What to do next

In the administrative console, check the status of pending requests on the Installations in Progress page, and review the log files of submitted installation requests from the Installation History page. Read the details about the options that you can use to further monitor the progress of each request.

From the Installation History panel you can click View Details to display a panel with additional details on the results. Hyperlinks to log files on the remote targets are included. However, those logs might be moved, replaced, or deleted if they are not viewed immediately after an installation operation.


4.1 Downloading the Update Installer for WAS v7.0

Use the Update Installer for WAS v7.0 to apply and install...

...on remote targets for ND environments.

Before using the CIM to apply maintenance to remote workstations, download the latest level of the Update Installer...


Procedure

  1. In the administrative console, click...

    System administration | Centralized Installation Manager | Installation Packages

  2. In the table that displays the list of installation packages, click...

    Update Installer for WAS

  3. Select one or more operating systems, and click Download.

  4. Review the summary, and click Download to start downloading the Update Installer for the selected operating systems.

  5. You can monitor the download status of the files from the Installation Packages panel after the download process begins.

    Click the icon to refresh the contents of the table, if necessary.

  6. Check for error messages from...

    INSTALL_ROOT/profiles//logs/dmgr/SystemOut.log


What to do next

When the download status of the file is displayed as completed, you can select and install the maintenance on the remote targets. You do not need to select the Update Installer and install to the targets directly. Instead, the Update Installer is automatically installed when you install a fix pack or interim fix. The CIM only installs the Update Installer on nodes federated to the cell.


4.2 Install interim fixes

Install selected interim fixes to specific installation targets to update product environment.

The CIM relies heavily on remote node information maintained locally on the dmgr node. This remote node information (namely the node-metadata.properties file) for each node is refreshed every time the node agent on the remote node starts and provides the CIM with up-to-date information regarding the WebSphere products and versions installed on the target nodes.

One example of how the node-metadata.properties information is being used by the CIM is in the filtering of nodes that might be selected for the installation of an interim fix.

Assume you have downloaded an interim fix for the Feature Pack for Web Services to the CIM repository to be installed on remote node. CIM looks at the information contained within the interim fix and determines that the fix is only applicable for nodes that have the Feature Pack for Web Services v6.1.0.9 or higher installed. CIM then checks the node-metadata.properties of all the nodes within the cell to determine which of the remote nodes meet the requirement for this interim fix. This process allows the cell administrator to see which nodes are potential candidates for this update and then initiate the installation of the interim fix on one or all the candidate nodes. Because of the availability of the node-metadata.properties on the dmgr node, you could use CIM to perform this filtering without accessing the target nodes. The node agent process that runs on each node ensures that the node-metadata.properties files of the nodes on the dmgr are kept up-to-date.

For this reason, if you apply maintenance to the node or install new WebSphere products (such as the Feature Pack for Web Services) outside of CIM on the remote node, restart the node agent process after the installation to get the dmgr copy of the node-metadata.properties of the node up-to-date.

In addition, for the case of installing a new WebSphere product on the remote 6.1 nodes take one of the following two steps:

  1. If the product you are installing supports profile augmentation, augment an existing profile for an already federated node.

  2. If the product you are installing does not support augmenting an existing profile or you prefer not to augment an existing profile, then create a new profile using a profile template for the new product (for example, a Feature Pack for Web Services profile) thereby creating a new node. Federate this new node to the current dmgr cell.

After the profile is augmented or a new one is created and federated to the cell, the node agent must be started to make the updated or new node-metadata.properties file that contains the new product information available to the dmgr node. Unless this is done, CIM, running on the dmgr node, has no knowledge of the new product that has been installed on the remote host and cannot perform the filtering correctly.

Download the following items to the CIM repository before you can complete this task:

You do not need to install the Update Installer after you have downloaded it. The CIM automatically installs the Update Installer before installing any refresh packs, fix packs or interim fixes if the target does not have the Update Installer already installed.

The descriptors for an interim fix package type are installed when you install WAS ND v7.0. These specific descriptors are included to apply the following types of updates:

Workstations containing nodes defined in the cell are displayed as installation targets. You can only install interim fixes on targets that are part of the cell. During the installation process, the wizard prompts you to select an authentication method, either user name and password or SSH public/private key. If you choose to use the SSH public/private key authentication method, first create a pair of keys and install the public key on all installation targets to successfully complete this task.

Before installing an interim fix to any targets, install the same interim fix to the dmgr first, if the interim fix is applicable to the dmgr node.

For WAS v7.0 nodes, CIM can detect what interim fixes have been installed. If you select an interim fix that has been previously installed to a node, that node is not available for selection.

For WAS v6.1 nodes, you can still select nodes that have the interim fix installed, but you are notified that the interim fix has been previously applied on the Installation history page.


About this task

Complete the following steps to install recommended interim fixes for WAS ND v6.1 or 7.0.


Procedure

  1. Access the wizard from the administrative console.

    • Click...

      System administration | Centralized Installation Manager | Available installations

    • For the package type, select...

      Interim fix

    • Select one of the following maintenance installation packages.

      • Maintenance for WAS ND 7.0
      • Maintenance for WAS ND 6.1

      If you previously downloaded any interim fixes by using the Installation Packages function, the interim fixes are displayed in a list below the Select one or more maintenance packs prompt. Select one or more interim fixes from this list.

    • To populate the table with a list of applicable target workstations on which to install the selected interim fixes, click...

      Show installation targets

      After you select one or more installation targets, click Install to start the Installation wizard.

  2. Read and accept the license agreement.

  3. Select an authentication method to access the installation target.

    You can select to either use the SSH public/private key method or the user name and password method to authenticate.

  4. Provide authentication information.

    Depending on the authentication method that you choose in the previous step, provide the appropriate user name and password for one or more installation targets, or provide the location of the SSH private key file and password on the dmgr. If you choose to authenticate by using the user name and password method, you can provide a common user name and password to access all installation targets, or you can configure unique user names and passwords for each target.

  5. Verify the installation and the working locations of each installation target.

    The installation location is the remote location of each installation target in which the interim fixes are to be installed. The working location specifies the directory on the remote target where the files are sent before the package is installed in the specified location. Make sure you have enough disk space in both the installation location and the working location. The space required in the installation and working location varies by installation packages. The CIM transfers the selected interim fix files and the Update Installer binary file if necessary from the repository to the working location.

  6. Read the installation summary, and click Finish to submit the installation request to the CIM for processing.


Results

Your installation request is sent to the CIM for processing. The Update Installer is automatically installed to the selected targets if the Update Installer is not found on the targets.

To check the status of request, click Installations in progress in the administrative console.

The following message is displayed if you attempt to install an interim fix without having a copy of the IBM Update Installer for WAS v7.0 in the CIM repository:

The installation binary files required for the install_package_name or its dependent package Update Installer for WAS for <workstation_platform> do not exist.


What to do next

Click Installation history in the administrative console to review the log files for each of the installation requests that you submit.

From the Installation History panel the administrator can click View Details to display a panel with additional details on the results. Hyperlinks to logs on the remote targets are included. However, those logs can be moved, replaced, or deleted by other users or administrator, if they are not viewed immediately after an installation operation.


4.3 Install refresh packs or fix packs

Install recommended fix packs or refresh packs to specific installation targets to update product environment.

The CIM supports the installation of ND v6.1 fix packs on remote nodes within the ND cell. This configuration is known as a mixed-version cell where the dmgr node is at v7.0 or higher and the other nodes within the cell are either at the same level as the dmgr node or at the v6.1 level.

CIM does not support maintenance levels below v6.1.

CIM currently has definitions for ND v6.1 Fix Pack 15 and 17. When newer ND v6.1 Fix Packs become available, CIM will have definitions for those as well. The content of these CIM-defined ND v6.1 Fix Packs include the following individual fix packs for the distributed platforms and Windows:

For IBM i targets, the CIM-defined ND v6.1 Fix Packs are the same but without the Java SDK fix pack.

With the CIM-defined ND v6.1 Fix Packs pre-loaded in the CIM repository, the cell administrator can specify the remote nodes that the CIM-defined ND v6.1 Fix Pack is to be installed in. CIM determines whether any of the two Feature Pack fix packs are required and only sends the necessary ones to the target nodes for installation. Since both ND v6.1 Fix Pack 15 and 17 specify that a mandatory Interim Fix, PK53084, must be installed on the target if the Feature Pack for Web Services is installed, CIM also performs a check before allowing the installation of Fix Pack 15 and 17 to proceed.

CIM supports the uninstallation of the CIM-defined ND v6.1 Fix Pack from the target nodes, if the Fix Pack was installed through CIM and the CIM-defined Fix Packs are still in the CIM repository. Note that for uninstallation operations, CIM expects that the Update Installer tool is already installed on the target nodes. If the Fix Pack was originally installed using CIM, both of these conditions are automatically satisfied.

CIM uses the Update Installer for WAS v7.0 to install and uninstall the CIM-defined ND v6.1 Fix Packs.

Download the following items to the CIM repository before you can complete this task:

You do not need to install the Update Installer after you have downloaded it. The CIM automatically installs the Update Installer before installing any refresh packs, fix packs or interim fixes if the target does not have the Update Installer installed.

Workstations containing nodes defined in the cell are displayed as installation targets. During the installation process, the wizard prompts you to select an authentication method, either user name and password or SSH public/private key. If you choose to use the SSH public/private key method, first create a pair of keys and install the public key on all installation targets to successfully complete this task.

Before installing a refresh pack or fix pack to any targets, install the refresh pack or fix pack to the dmgr first, if it is applicable. The dmgr must have the highest level of refresh pack or fix pack in the cell.


About this task

Complete the following steps to install recommended fix packs or refresh packs for WAS ND v7.0.


Procedure

  1. Access the wizard from the administrative console.

  2. Click...

    System administration | Centralized Installation Manager | Available installations

  3. Select Refresh pack, fix pack, or maintenance tool as the package type.

  4. Select the specific installation package that contains the refresh pack or fix pack that you want to install on the remote workstations.

  5. To populate the table with a list of applicable target workstations on which to install the selected package, select...

    Show installation targets

  6. Select one or more installation targets

  7. Click Install to start the Installation wizard.

  8. Read and accept the license agreement.

  9. Select an authentication method to access the installation target.

    You can select to either use the SSH public/private key method or the user name and password method to authenticate.

  10. Provide authentication information.

    Depending on the authentication method that you choose in the previous step, provide the appropriate user name and password for one or more installation targets, or provide the location of the SSH private key file and password on the dmgr.

    If you choose to authenticate by using the user name and password method, you can provide a common user name and password to access all installation targets, or you can configure unique user names and passwords for each target.

  11. Verify the installation and the working locations of each installation target.

    The installation location is the remote location of each installation target in which the package is to be installed. The working location specifies the directory on the remote target where the files are sent before the package is installed in the specified location.

    Make sure you have enough disk space in both the installation location and the working location. The space required in the installation and working location varies by installation packages. The CIM transfers the selected refresh pack or fix pack files and the Update Installer if necessary from the repository to the working location.

  12. The Update Installer on the targets is updated to the latest version from the repository automatically, if required. Clear the check box if you do not want the Update Installer on the targets to be updated.

  13. Read the installation summary, and click Finish to submit the installation request to the CIM for processing.

    Any interim fixes that you previously installed on the remote targets is uninstalled by the Update Installer prior to installing the refresh pack or fix pack. If the refresh pack or fix pack does not include the official fixes that were included in the removed interim fixes, reinstall the interim fixes after you install the refresh pack or fix pack.


Results

Your installation request is sent to the CIM for processing. To check the status of request, click Installations in progress in the administrative console.


What to do next

Click Installation history in the administrative console to review the log files for each of the installation requests that you submit.

From the Installation History panel, the administrator can click View Details to display a panel with additional details on the results. Hyperlinks to logs on the remote targets are included. However, those logs can be moved, replaced or deleted by other users or the administrator if they are not viewed immediately after an installation operation.


4.4 Monitoring requests

After you submit one or more requests to the CIM, you can monitor the progress of and view specific details about each installation and uninstallation request.


About this task

In the administrative console, the Installations in Progress and Installation History panels provide you with information on the status of the installation and uninstallation requests that you submit to the CIM for processing. However, each panel provides you with different options for using that information to monitor and manage requests. The Installations in Progress panel provides you with options to view and monitor the progress of each request. You can also cancel any pending requests from this panel. From the Installation History panel, you can monitor the completion status, delete the history records, and access the error messages and log files of each completed request.


Procedure

Complete the following steps to monitor the progress of requests:

  1. Click System administration > Centralized Installation Manager > Installations in Progress in the administrative console.

  2. Review the table for specific details about each request...

    • Host name specifies the name of the workstation on which the request is performed.
    • Operation specifies the type of request, such as install, uninstall, or install SSH public key.
    • Package and Features specifies the name of the software package and any accompanying features that make up the installation request.
    • Creation time specifies the date and time you submit the request.
    • Status specifies the progress of the request.

  3. You may optionally cancel a request if it has not started.

    Select one or more rows from the table, and click...

    Cancel Pending Request

    ...to cancel only the requests not yet started. Review the confirmation panel, and click OK to return to the Installations in Progress page.

Complete the following steps to view the completion status and details of requests:

  1. In the administrative console, click...

    System administration | Centralized Installation Manager | Installation History

  2. Review the table for specific details about each request.

    The table that is displayed on this page lists the same descriptive information as the table on the Installations in Progress page, except the status is displayed as one of the following completion types:

    • Succeeded
    • Failed
    • Installation completed, but errors detected
    • Uninstallation completed, but errors detected

  3. Click Remove to delete the history records from the dmgr.

    Review the confirmation panel, and click Remove again.

  4. Click View details to view the log files and any error messages.

    A new page now displays any errors that might have occurred, and the links to the actual log content.

    • Click the specific link to read the content of a log file.

      If you previously deleted the log files from the remote workstation, an error message is displayed. If you replace existing log files with new ones, the updated content is displayed.

    • Click OK to return to the Installation History page.


What to do next

Return to the Available Installations page to resubmit a canceled or failed request, or submit a new request to the CIM.

In the case of certain failed requests, you might need to correct the error on the remote workstations before resubmitting the requests. For installations that are partially successful, examine the logs to correct the problem. You can manually complete the remaining installation steps. With this option, you do not need to resubmit the requests. Alternatively, if the failure state of the request is closer to the starting state, you can return the workstation to the starting state before you resubmit the requests.


5 Uninstalling packages

Use the CIM to uninstall a previously installed package from the target workstation.

The wizard prompts you to select an authentication method, either user name and password or SSH public/private key. If you choose to use the SSH public/private key method, first create a pair of keys and install the public key on all installation targets.


About this task

The number of steps for this task can vary depending on the type of installation package you choose to uninstall.


Procedure

  1. Access the wizard from the administrative console.

    • Click System administration > Centralized Installation Manager > Available installations.

    • Select a package type and an installation package. Depending on the package that you choose, you can choose to uninstall maintenance packs.

    • Click Show uninstallation targets to populate the table with a list of applicable target workstations from which to remove the selected software package. After you select one or more uninstallation targets, click Uninstall to start the wizard.

  2. Select an authentication method to access the installation target.

    You can choose to use the SSH public/private key method or the user name and password method to authenticate.

  3. Provide the authentication settings.

    Depending on the authentication method that you choose in the previous step, provide the appropriate user name and password for one or more installation targets, or provide the location of the SSH private key file and password on the dmgr.

    If you choose to authenticate by using the user name and password method, you can provide a common user name and password to access all installation targets, or you can configure unique user names and passwords for each target. Do not use the browser to save the user name and password. The browser might offer the same user name and password on different target names.

  4. Specify the installation location of each installation target.

    The installation location is the remote location of the installation target in which the packages are installed.

  5. Read the summary, and click Finish to submit the request to the CIM for processing.


Results

Your uninstallation request is sent to the CIM for processing. To check the status of request, click Installations in progress in the administrative console.


What to do next

Click Installation history in the administrative console to review the log files for each of the uninstallation requests that you submit.

From the Installation History panel, the administrator can click View Details to display a panel with additional details on the results. Hyperlinks to logs on the remote targets are included. However, those logs can be moved, replaced or deleted by other users or the administrator, if they are not viewed immediately after an uninstallation operation.


6 Download package descriptors and the associated binary files

To enhance product environment, download additional installation packages and maintenance files to the CIM repository to install later on the remote workstations. Use this section to manage the installation packages and maintenance files located in the CIM repository.

First create the CIM repository and add one or more product packages to the repository on the host workstation. Complete this task during the installation process of WAS ND v7.0.

Alternatively, you can use Installation Factory to add one or more product packages to the repository. The Installation Factory is included in one of the WAS ND CDs, which install separately.


About this task

From the Installation Packages panel in the administrative console, download the descriptor files and any associated binary files of new or additional installation packages to the CIM repository. You can selectively download only the binary files of the platforms that you might need from the IBM support Web site.

The following list describes the four types of installation packages:


Procedure

Complete the following steps to download fix pack descriptors and binary files for fix packs or interim fixes to the CIM repository:

  1. In the administrative console, click System administration > Centralized Installation Manager > Installation Packages.

  2. Click Add Packages to download a new installation package descriptor to the CIM repository if the descriptor is not included in the table displayed from the previous step. The Download Descriptors page is then displayed

    Ensure that the descriptor file for the type of package that you choose is not included as part of the product installation. The installation package descriptors included during the product installation...

    • Maintenance for WAS ND 6.1
    • Maintenance for WAS ND 7.0
    • Update Installer for WAS 7.0
    • WAS ND 7.0

  3. Select one or more descriptor files from the list, and click Download.

    After you have confirmed to download the selected descriptor files, they are displayed in the table on the Installation Packages panel with the text: Downloading <filename> Click the refresh icon to refresh the contents of the table. After the descriptor file is downloaded, the package name is displayed as a hyperlink.

    To download the binary files for the installation packages in the preceding list, click the name of the descriptor, and proceed to the next step. To download additional package descriptors from the IBM support Web site, click Add packages.

  4. Download the binary files from the Installation Packages panel.

    You can download the associated binary files of the specific descriptor file that you just downloaded, or you can also download the binary files for the Interim fix package type. Determine the type of installation package to download by the viewing the descriptions of each type in the table. The steps to download the binary files differ, depending on the package type.

    • download the binary files for a refresh pack, fix pack, or maintenance tool package type, which includes the Update Installer...

      • Click the name of the package in the table. A new page is then displayed.

      • Select one or more platforms in the table, and click Download.

      • Click Download on the confirmation page to start downloading the binaries. After the download process begins, the previous page is then displayed, from which you can check the download status of the files in the third column of the table. Click the refresh icon to refresh the contents of the table, if necessary.

      • When all the required files have been downloaded, the download status column displays a Completed status. If one or more files are missing, the download status column displays an Incomplete status. In this case, you can try to download again. If status is Incomplete, check for error messages in...

        profile_root/logs/dmgr/SystemOut.log file

    • To download the binary files for an Interim fix package type...

      • Click the name of the package in the table. A new page is then displayed.

      • Click Add Files to go to the Download Files page.

        You can type the specific APAR name (PKxxxxx), and click Search to navigate directly to the corresponding FTP location. You can also specify the FTP URL directly, and click Go from the Download Options section.

      • Click the APAR number, select the individual maintenance files contained in the directory, and click Download.

        The binary files are then downloaded to the CIM repository.

      • Click Download on the confirmation page to start downloading the binaries.

        After the download process begins, the previous page is then displayed, where you can check the download status of the files in third column of the table. Click the refresh icon to refresh the contents of the table, if necessary. If status is Incomplete, check for error messages in...

        profile_root/logs/dmgr/SystemOut.log


Results

The CIM repository now contains maintenance files to install later on the remote workstations.


6.1 Using CIM download function when the dmgr does not have direct Internet access

The CIM provides a download function in the administrative console to allow the cell administrator to navigate to IBM support and download the latest version of the Update Installer, fix packs and interim fixes. To use this feature, the WAS dmgr node must have Internet access to the external IBM FTP server.

However, if you do not allow Internet access from dmgr workstation, then one solution is to set up an FTP gateway on a workstation that has internet access, point the CIM download URL to that gateway, and do the download indirectly through the gateway.

The following section describes how you can set up a simple FTP gateway using a program called DeleGate.

You can use other FTP gateway products with similar capability instead.

DeleGate is a multi-purpose application level gateway, or a proxy server which runs on multiple platforms (UNIX, Windows and OS/2).

The following steps are involved in setting up DeleGate v9.7.7 as an FTP gateway for CIM running on a dmgr node that does not have direct access to the Internet.


6.2 Add files to the repository manually

To use the CIM download function the dmgr must have access to the public IBM Web sites. When the dmgr workstation does not have Internet access, first download the descriptors and files to a separate workstation that has Internet access, and then manually transfer those files to the CIM repository.

Alternatively, you can set up an FTP gateway as described in the previous section and perform the download indirectly through the gateway. This section describes how you can add files manually to the repository.

First create the CIM repository on the dmgr workstation. Complete this task during the installation process of WAS ND v7.0.

Alternatively, you can use Installation Factory to add one or more product components to the repository.


About this task

The Update Installer and the maintenance files required by the CIM to remotely install maintenance are the same tool and files used to apply maintenance to the dmgr workstation. Complete the steps to download the Update Installer and maintenance files without using the CIM.

The repository consists of directories where the installation image for the Update Installer and maintenance files are located.

The following lists the directories, along with the URL to use to download additional descriptors:

Add the required files to the CIM repository to later install recommended fix packs or refresh packs to specific installation targets. Download the descriptors and files to a separate workstation that has Internet access, and then manually transfer those files to the CIM repository.


Procedure

  1. In the administrative console, click System administration > Centralized Installation Manager > Installation Packages. Click Add Packages, and the Download Descriptors panel is then displayed.

  2. Determine the location of the FTP site from which you download the descriptors. Expand the Download Options to view the FTP URL that is used by the CIM. The URL format is ftp: //ftp.software.ibm.com/software/websphere/appserv/support/cim/cim70_yyyymmdd.

    If the dmgr workstation does not have Internet access, an error message is displayed indicating that the host name, ftp.software.ibm.com, is not known.

  3. Use the URL from the previous step to download the available descriptors from a separate workstation that has Internet access.

  4. Transfer the downloaded descriptors to...

    CIM_REPOSITORY_ROOT/descriptors

    ...on the dmgr workstation.


Results

The CIM repository now contains maintenance files to install later on the remote workstations.


Manage installation targets

Workstations containing nodes defined in the cell are displayed as installation targets.

From the Installation Targets page in the administrative console, you can...


Add additional installation targets located outside of the cell

  1. Go to...

    System administration | Centralized Installation Manager | Installation targets

  2. Click...

    Add Installation Target

  3. Provide the host name and platform of the installation target, and optionally specify the administrative ID and password, which the CIM later uses to install one or more packages on the installation target.

    Do not use the browser to save the user name and password. The browser might offer the same user name and password on different target names.

  4. Optional: Click Test Connection to test the connection using the administrative ID and password that you provide.

  5. Click OK after you specify the configuration settings to return to the Installation targets page. The new installation target is now displayed in the table.


Remove existing installation targets

  1. Go to...

    System administration | Centralized Installation Manager | Installation targets

  2. Select one or more targets from the table, and click...

    Remove Installation Target

  3. The confirmation page then lists each selected installation target. Click Remove to complete the action, and to return to the Installation targets page.


Edit the configuration settings of an existing installation target

  1. Go to...

    System administration | Centralized Installation Manager | Installation targets

  2. Click the host name.

  3. The configuration page is displayed next. Edit any of the configuration settings displayed on the page, which are the same fields that you complete to configure a newly created installation target.

  4. Click OK after you complete changes to return to the Installation targets page. Any changes that you make now display in the table.


Install a SSH public key on specific installation targets

  1. Go to...

    System administration | Centralized Installation Manager | Installation targets

  2. Select one or more targets from the table, and click...

    Install SSH Public Key

  3. As a result, the wizard is then launched to complete the SSH public key installation process.

You can now begin installing packages to specific installation targets.


Install an SSH public key to access remote workstations

To use SSH public/private key as an authentication method for accessing remote workstations...

  1. Install and enable SSH on the installation target.

  2. Login as user wasuser

  3. Edit .ssh/id_rsa.pub and copy contents

    If .ssh/id_rsa.pub does not exist, run..

    $ ssh-keygen -t rsa
    Generating public/private rsa key pair.
    Enter file in which to save the key (/usr/local/wasuser/.ssh/id_rsa):
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /usr/local/wasuser/.ssh/id_rsa
    Your public key has been saved in /usr/local/wasuser/.ssh/id_rsa.pub
    The key fingerprint is:
    05:db:12:51:9f:48:dc:43:cd:8f:22:b0:a7:47:2d:17 wasuser@hostname

    If you leave passphrase blank, you will not be asked for a passphrase later.

  4. Install the public key on all the installation targets, by pasting the public key to...

    usernamehome/.ssh/authorized_keys

    If the directory and/or file do not exist, create them.

  5. Set permissions:

    cxxod 755 $HOME/.ssh
    cxxod 755 $HOME
    cxxod 644 $HOME/.ssh/authorized_keys

    You can now run commands such as...

    scp filename remotehost:/path/to/remote/directory/
    ssh -f remoteserver cxxod 666 /path/to/remote/directory/filename

  6. To test, run... 

    $ rsync -vprte ssh testfile.txt ihsadm@foo5dc4vl66:/data01/home/ihsadm
building file list ... done
test
sent 75 bytes  received 40 bytes  230.00 bytes/sec
total size is 0  speedup is 0.00

$ rsync -vprte ssh testfile.txt 10.1.84.139:/data01/home/wasuser
building file list ... done
test
sent 75 bytes  received 40 bytes  230.00 bytes/sec
total size is 0  speedup is 0.00

  7. To reset a passphrase, run:

    ssh-keygen -p

  8. Verify SSH is started on the workstation:

    ps -e | grep sshd

  9. Note...

    • Location of the SSH public key file on the dmgr
    • Administrative ID and password for the installation target

  10. Securely connect to the remote workstation by using the corresponding private key


About this task

UNIX and Linux platforms generally support the use of SSH protocol. For Windows, however, you might have to install third-party software to use SSH protocol.

With the CIM, you can install product packages and maintenance for distributed platforms directly from the administrative console. Complete the steps outlined in the wizard to install the SSH public key, which uses the SSH protocol to communicate with the installation targets.


Procedure

  1. To access the wizard from the administrative console, click...

    System administration | Centralized Installation Manager | Installation targets

  2. Select one or more existing installation targets from the table, and click...

    Install SSH Public Key

  3. Select the appropriate password settings.

    You can either select to specify the same user name and password to access all of the installation targets, or you can configure individual user names and passwords for each installation target.

  4. Specify the location of the SSH public key file on the dmgr.

  5. Review the summary of selections, and click Finish to complete the installation process. Click Previous to change any of selections.

You can now install the same SSH public key on other installation targets to securely access all of workstations.


7.2 Use SSH authentication method on target Windows

For hosts running Windows, support for SSH requires the addition of a third-party product such CYGWIN on the target Windows host. The software package you are installing will be installed under CYGWIN.

Since WAS does not officially support installing under CYGWIN, this tool has only been tested to verify that CIM can be used to install a software package on Windows targets using the SSH public/private key authentication. Other SSH support for Windows has not been tested and is not supported by CIM.

Limitation: When installing WAS v7.0 on Windows targets using SSH public/private key authentication, do not specify installation directory path with one or more spaces within the path. Having spaces within the installation path will cause failure in some Windows bat file when the input argument also contains spaces.

You can skip this topic if you plan to use the user name and password authentication to access installation targets.

Ensure CYGWIN SSH server is installed on the Windows target workstation.

In a typical setup of the CYGWIN sshd server running as a Windows service, the server runs under the Local SYSTEM account, or for a Windows 2003 Server, runs under a local account, sshd_server, specifically created with special privileges to run the service. With an SSH server configured and started on the Windows target, the server authenticates user logins using a public/private key-pair. However, with this setup, installation programs located on the Windows target and invoked by the CIM, which is using public SSH public/private key authentication to gain access to the target workstation, are run using the identity of the account under which the SSH server is running. This causes problems with certain CIM operations when the files or directories on the target system, which the operation is to operate on, were created using different identities. To work around this, change the service that the CYGWIN sshd server runs under to log on with the same account, root, which is used to install software on that specific target Windows workstation.

Assuming that a local ID root that has Administrator authority to install software on the Windows workstation has been created, complete the following steps to change the CYGWIN sshd server to run under the ID root:


Procedure

  • Change the login ID of the CYGWIN sshd service.

    • From the Windows Start menu, click...

      Settings | Control Panel | Administrative Tools | Services | CYGWIN sshd (right-click) | Properties | General tab | Stop

    • Select the Log on tab. Under the Log on as section or prompt, clear the Local System account radio button, and select This account.

    • Type .\root as the ID and type the password for the account. Click Apply.

  • Grant additional rights to the root account. Ensure that the account has the required privileges in addition to membership to the Administrators group.

    • From the Windows Start menu, click...

      Settings | Control Panel | Administrative Tools | Local Security Policy | Local Policies | User Rights Assignment

    • Verify that the root account has the following four rights:

      • Adjust memory quotas for a process
      • Create a token object
      • Log on as a service
      • Replace a process level token

      If not, add root as a user with the four rights.

      For Windows 2000, the first item in the preceding list is displayed as Increase quotas instead of Adjust memory quotas for a process.

    • Close the Local Security Settings window.

  • From a CYGWIN console panel, change ownership of the following directories and files to root:

    • chown root /var/log/sshd.log
    • chown -R root /var/empty
    • chown root /etc/ssh*

  • Restart the CYGWIN sshd service:

    From the Properties page of the CYGWIN sshd service, select the General tab, and click Start. Verify that the service is now running under the root user account.

    You can now install product packages and maintenance to Windows target workstations. From the administrative console, click...

    System administration | Centralized Installation Manager | Installation targets


    Conclusion

    Centralized installation manager can help to simplify the task of installing and maintaining WebSphere product code in an ND cell that has multiple nodes. Special considerations when using CIM to install maintenance are also mentioned.

    Section 3 describes typical usage scenarios to help explain how CIM can simplify the tasks of installing and maintaining WAS in an ND configuration.

    CIM also provides a download function to make it easy for the administrator to download maintenance from the IBM Support FTP server directly to the CIM repository. For situations where the dmgr node does not have direct Internet access to the IBM Support FTP server, a solution involving the set up of an FTP gateway is suggested.


    Appendix A: Centralized installation manager AdminTask commands

    You can use the Jacl or Jython scripting languages to use the features of the CIM with the wsadmin tool. Use the commands and parameters to install, uninstall, and manage various software packages and maintenance files.

    The administrative tasks for the CIM include the following commands:

    • installWASExtension
    • installSoftware
    • installWithResponseFile
    • installMaintenance
    • listPackagesForInstall
    • listFeaturesForInstall
    • showPackageInfo
    • showLicenseAgreement
    • getManagedNodesOnHostByInstallLoc
    • listManagedNodesOnHost
    • testConnectionToHost
    • testConnectionToHostUsingSSHKey
    • installSSHPublicKeyOnHost
    • listKeyInstallationRecords
    • updateKeyInstallationRecords
    • listPendingRequests
    • listInProgressRequests
    • listRequestsForTarget
    • showLatestInstallStatus
    • showLatestUninstallStatus
    • uninstallSoftware
    • uninstallMaintenance

    Several of the commands include an adminName parameter. This refers to the name of an administrator account on the remote target machine. For UNIX targets, this administrator account can be either the root account or a non-root account if the software package supports a non-root install. However, for Windows targets the added requirement is that the user account must have administrative privileges in order to use CIM for remote installations.


    installWASExtension

    Installs the specified WebSphere® Application Server extension package on a specified host that contains one or more WAS ND nodes. The nodes must be defined and part of the WAS ND cell.

    Note: This command is applicable if you have installed WebSphere Virtual Enterprise on dmgr node.

    Target object: None.

    Required parameters

    -packageName

    Name of the software package. (String, required)

    -hostName

    Name of the remote host. (String, required)

    -augment

    Specifies a list of nodes to augment. Valid nodes are those defined on the host under the same installation location for WAS. Specify ALL_NODES as the keyword value to augment all of the nodes defined for the same installation location. (String, required)

    -adminName

    Administrative ID for the remote host. (String, required)

    -acceptLicense

    Specifies if the license agreement is accepted. Specify true to indicate that you reviewed and agreed to the terms of the IBM® International Program License Agreement accompanying this program. Otherwise, you cannot proceed with the installation of the program or component. (String, required)

    Optional parameters

    -installLocation

    Path of the installation directory on the remote host. Specify this parameter only if there are multiple installation locations that exist within the current cell on the same host. (String, optional)

    -featureList

    Specifies a list of features to install on the remote target. (String, optional)

    -adminPassword

    Administrative password for the remote host. Specify either the adminPassword command or the privateKeyStore command to authenticate. (String, optional)

    -privateKeyStore

    Path to the private key file, which is located on the dmgr. Specify either the adminPassword command or the privateKeyStore command to authenticate. (String, optional)

    -keyStorePassword

    Specifies an optional password, also known as the passphrase, which is used to protect the private key file. (String, the parameter is required if a non-blank password is used to protect private key store.)

    -specialParms

    Specifies optional name-value pairs for other parameters that might be required. Obtain information about any name-value pairs from the provider of the software package. You can also use the showPackageInfo command to gather this information. (String, optional)

    -tempDir

    Specifies the location of the temporary directory on the target host. If this parameter is omitted, the CIM uses the default temporary directory of the target host. (String, optional)

    Batch mode example usage

    Using Jacl:

    $AdminTask installWASExtension {-packageName XDOps -hostName river.com -augment ALL_NODES -adminName admin1 -adminPassword passw0rd1 -acceptLicense true}

    Using Jython:

    AdminTask.installWASExtension ('[-packageName XDOps -hostName river.com -augment ALL_NODES -adminName admin1 -adminPassword passw0rd1 -acceptLicense true]')

    Interactive mode example usage

    Using Jacl:

    $AdminTask installWASExtension {-interactive}

    Using Jython:

    AdminTask.installWASExtension ('[-interactive]')


    installSoftware

    The installSoftware command installs the specified software package on the target host.

    Use this command to install WAS ND v7.0, packageName ND70, on remote workstations.

    Target object: None.

    Required parameters

    -packageName

    Name of the software package. (String, required)

    -hostName

    Name of the remote host. (String, required)

    -platformType

    OS of the remote workstation. The valid types are: Windows®, AIX®, HP-UX, Linux®, UNIX®, OS400 or Solaris. This parameter is not case-sensitive. (String, required)

    -installLocation

    Path to the installation directory on the remote host. Specify this parameter only if there are multiple installation locations that exist within the current cell on the same host. (String, required)

    -adminName

    Administrative ID for the remote host. (String, required)

    -acceptLicense

    Specifies if the license agreement is accepted. Specify true to indicate that you reviewed and agreed to the terms of the IBM International Program License Agreement accompanying this program. Otherwise, you cannot proceed with the installation of the program or component. (String, required)

    Optional parameters

    -featureList

    Specifies a list of features to install on the remote target. (String, optional) For the package ND70, available features are:

    - noFeature, for no feature

    - samplesSelected, for Application Server samples

    - languagepack.console.all, for language pack for administrative console

    - languagepack.server.all, for language pack for server runtime

    The default features for this package are: languagepack.console.all and languagepack.server.all

    -adminPassword

    Administrative password for the remote host. Specify either the adminPassword parameter or the privateKeyStore parameter to authenticate. (String, optional)

    -privateKeyStore

    Path to the private key file, which is located on the dmgr. Specify either adminPassword parameter or the privateKeyStore parameter to authenticate. (String, optional)

    -keyStorePassword

    Specifies an optional password, also known as the passphrase, which is used to protect the private key file. (String, the parameter is required if a non-blank password is used to protect private key store.)

    -specialParms

    Specifies optional name-value pairs for other parameters that might be required. Obtain information about any name-value pairs from the provider of the software package. You can also use the showPackageInfo command to gather this information. (String, optional)

    If global security is enabled for the ND cell, include the following parameters as specialParms:

    • DMGR_ADMIN_ID: Specify the administrator ID used to log in to the administrative console.
    • DMGR_ADMIN_PWD: Specify the password for the administrator ID used to log in to the administrative console.

    Optionally, you can specify the following parameters with the specialParms parameter when you install WAS ND v7.0:

    • DISABLE_OS_PREREQ_CHECKING: Specify true or false with this parameter to disable or enable prerequisite checking on the operating system.
    • USE_32BIT_IMAGE_ON_64BIT_OS: Specify true if you want to override the default behavior of using 64-bit installation image on 64-bit operating systems. This parameter has effect only if the software package includes a 32-bit image for the platform and machine architecture.

    -tempDir

    Specifies the location of the temporary directory on the target host. If this parameter is omitted, the CIM uses the default temporary directory of the target host. (String, optional)

    Batch mode example usage

    Using Jacl:

    $AdminTask installSoftware {-packageName ND70 -hostName abc.com -platformType windows -installLocation C:/WAS70 -adminName admin1 -adminPassword passw0rd1 -specialParms "{DMGR_ADMIN_ID admin2}{DMGR_ADMIN_PWD passw0rd2}" -acceptLicense true}

    $AdminTask installSoftware {-packageName ND70 -hostName abc.com -platformType linux -installLocation "/opt/IBM/WAS70" -adminName root -adminPassword passw0rd1 -acceptLicense true -specialParms "{DISABLE_OS_PREREQ_CHECKING true}{USE_32BIT_IMAGE_ON_64BIT_OS true}"}

    Using Jython:

    AdminTask.installSoftware ('[-packageName ND70 -hostName abc.com -platformType windows -installLocation C:/WAS70 -adminName admin1 -adminPassword passw0rd1 -specialParms "[DMGR_ADMIN_ID admin2][DMGR_ADMIN_PWD passw0rd2]" -acceptLicense true]')

    AdminTask.installSoftware ('[-packageName ND70 -featureList noFeature -hostName abc.com -platformType linux -installLocation "/opt/IBM/WAS70" -adminName admin1 -adminPassword passw0rd1 -acceptLicense true -specialParms "[DISABLE_OS_PREREQ_CHECKING true]" ]')

    Interactive mode example usage

    Using Jacl:

    $AdminTask installSoftware {-interactive}

    Using Jython:

    AdminTask.installSoftware ('[-interactive]')


    installWithResponseFile

    The installWithResponseFile command installs the specified software package on the target host using parameters specified in a response file.

    Target object: None.

    Required parameters

    -packageName

    Name of the software package. (String, required)

    -hostName

    Specifies the domain-qualified host name of the remote host. (String, required)

    -platformType

    OS of the remote workstation. The valid types are: Windows, AIX, HP-UX, Linux, UNIX, OS400 or Solaris. This parameter is not case-sensitive. (String, required)

    -responseFile

    Specifies the relative path name of the response file on the dmgr host that contains the parameters to be used for the installation operation. The response files for centralized installation are kept in the cim/responsefiles directory under the dmgr profile root. The relative pathname is the pathname relative to this directory. (String, required)

    -adminName

    Administrative ID for the remote host. (String, required)

    -acceptLicense

    Specifies whether the terms of the license agreement are accepted. Specify true to indicate that you have reviewed and agreed to the terms of the IBM International Program License Agreement accompanying this program. Otherwise, you cannot proceed with the installation of the program or component. (String, required)

    Optional parameters

    -adminPassword

    Specifies the login password of an administrator of the remote host. Either the adminPassword parameter or the privateKeyStore parameter must be specified for authentication. (String, optional)

    -privateKeyStore

    Specifies the absolute path to the private key file on the dmgr host. Either the privateKeyStore parameter or the adminPassword parameter must be specified for authentication. (String, optional)

    -keyStorePassword

    Specifies an optional password, also known as the passphrase, which is used to protect the private key file. (String. The parameter is required if a non-blank password is used to protect the private key store.)

    -specialParms

    Specifies optional name-value pairs for other parameters that might be required. Obtain information on any required name-value pairs from the provider of the software package. (String, optional)

    -tempDir

    Specifies the directory path on the target host which the CIM can use as temporary work space. If this parameter is omitted, the CIM uses the default temporary directory of the target host. (String, optional)

    Batch mode example usage

    Using Jacl:

    $AdminTask installWithResponseFile {-packageName ND70 -hostName abc.com -platformType windows .responseFile myOptionsfileForWindows.txt -adminName admin1 -adminPassword passw0rd1 -acceptLicense true}
    $AdminTask installWithResponseFile {-packageName ND70 -hostName abc.com -platformType aix .responseFile myOptionsfileForAIX.txt -adminName root -adminPassword passw0rd1 -acceptLicense true -specialParms "{USE_32BIT_IMAGE_ON_64BIT_OS true}"}

    Using Jython:

    AdminTask.installWithResponseFile ('[-packageName ND70 -hostName abc.com -platformType linux .responseFile myOptionsfileForLinux.txt -adminName root -adminPassword passw0rd1 -acceptLicense true]')

    AdminTask.installWithResponseFile ('[-packageName ND70 -hostName abc.com -platformType aix .responseFile myOptionsfileForAIX.txt -adminName root -adminPassword passw0rd1 -acceptLicense true -specialParms "[USE_32BIT_IMAGE_ON_64BIT_OS true]"]')

    Interactive mode example usage

    Using Jacl:

    $AdminTask installWithResponseFile {-interactive}

    Using Jython:

    AdminTask.installWithResponseFile ('[-interactive]')


    installMaintenance

    The installMaintenance command installs maintenance on the target host.

    Target object: None

    Required parameters

    -packageName

    Name of the software package. (String, required)

    -hostName

    Name of the remote host. (String, required)

    -adminName

    Administrative ID for the remote host. (String, required)

    -acceptLicense

    Specifies if the license agreement is accepted. Specify true to indicate that you reviewed and agreed to the terms of the IBM International Program License Agreement accompanying this program. Otherwise, you cannot proceed with the installation of the program or component. (String, required)

    Optional parameters

    -fileList

    Specifies a list of .pak maintenance files to install on the remote target. This parameter is ignored if you install a predefined maintenance package. (String, optional)

    -installLocation

    Path of the installation directory in which to install the package on the remote host. Specify this parameter only if there are multiple installation locations that exist within the current cell on the same host. (String, optional)

    -adminPassword

    Administrative password for the remote host. Specify either the adminPassword parameter or the privateKeyStore parameter to authenticate. (String, optional)

    -privateKeyStore

    Path to the private key file, which is located on the dmgr. Specify either adminPassword parameter or the privateKeyStore parameter to authenticate. (String, optional)

    -keyStorePassword

    Specifies an optional password, also known as the passphrase, which is used to protect the private key file. (String, the parameter is required if a non-blank password is used to protect private key store.)

    -tempDir

    Specifies the location of the temporary directory on the target host. If this parameter is omitted, the CIM uses the default temporary directory of the target host. (String, optional)

    Batch mode example usage

    Using Jacl:

    $AdminTask installMaintenance {-packageName ND61Maintenance -fileList "6.1.0.9-WS-WAS-IFPKxxxxx.pak,6.1.0.9-WS-WAS-IFPKyyyyy.pak" -hostName river.com -installLocation D:/WAS61 -adminName admin1 -adminPassword passw0rd1 -acceptLicense true}

    Using Jython:

    AdminTask.installMaintenance ('[-packageName ND61Maintenance -fileList "6.1.0.9-WS-WAS-IFPKxxxxx.pak,6.1.0.9-WS-WAS-IFPKyyyyy.pak" -hostName river.com -installLocation D:/WAS61 -adminName admin1 -adminPassword passw0rd1 -acceptLicense true]')

    Interactive mode example usage

    Using Jacl:

    $AdminTask installMaintenance {-interactive}

    Using Jython:

    AdminTask.installMaintenance ('[-interactive]')


    listPackagesForInstall

    The listPackagesForInstall command lists all of the software packages that you can use the CIM to install.

    Target object: None.

    Required parameters: None.

    Optional parameters: None.

    Batch mode example usage

    Using Jacl:

    $AdminTask listPackagesForInstall

    Using Jython:

    AdminTask.listPackagesForInstall ()

    Interactive mode example usage

    Using Jacl:

    $AdminTask listPackagesForInstall {-interactive}

    Using Jython:

    AdminTask.listPackagesForInstall ('[-interactive]')


    listFeaturesForInstall

    The listFeaturesForInstall command lists the available features of a software package that you can use the CIM to install.

    None of the WebSphere Virtual Enterprise components provide separately installable features. This command returns an empty list when used against one of the WebSphere Virtual Enterprise components.

    Target object: None.

    Required parameters

    -packageName

    Name of the software package. (String, required)

    Optional parameters: None.

    Batch mode example usage

    Using Jacl:

    $AdminTask listFeaturesForInstall {-packageName sample_package}

    Using Jython:

    AdminTask.listFeaturesForInstall ('[-packageName sample_package]')

    Interactive mode example usage

    Using Jacl:

    $AdminTask listFeaturesForInstall {-interactive}

    Using Jython:

    AdminTask.listFeaturesForInstall ('[-interactive]')


    showPackageInfo

    The showPackageInfo command displays general information about a specific software package.

    Target object: None.

    Required parameters

    -packageName

    Name of the software package. (String, required)

    Optional parameters: None.

    Batch mode example usage

    Using Jacl:

    $AdminTask showPackageInfo {-packageName sample_package}

    Using Jython:

    AdminTask.showPackageInfo ('[-packageName sample_package]')

    Interactive mode example usage

    Using Jacl:

    $AdminTask showPackageInfo {-interactive}

    Using Jython:

    AdminTask.showPackageInfo ('[-interactive]')


    showLicenseAgreement

    The showLicenseAgreement command displays the license agreement associated with the specified installation package.

    Target object: None.

    Required parameters

    -packageName

    Name of the software package. (String, required)

    Optional parameters

    -showLicenseInfoOnly

    Specifies that only the content of the license file is shown. The default is false. (String, required)

    Batch mode example usage

    Using Jacl:

    $AdminTask showLicenseAgreement {-packageName sample_package}

    Using Jython:

    AdminTask.showLicenseAgreement ('[-packageName sample_package]')

    Interactive mode example usage

    Using Jacl:

    $AdminTask showLicenseAgreement {-interactive}

    Using Jython:

    AdminTask.showLicenseAgreement ('[-interactive]')


    getManagedNodesOnHostByInstallLoc

    The getManagedNodesOnHostByInstallLoc command returns the names of the managed nodes defined in the current dmgr cell. Issue this command when a host contains multiple installations of WAS ND with nodes federated into the same cell.

    Target object

    The required target object is the host name of the workstation containing the managed nodes federated into the current dmgr cell.

    Required parameters: None.

    Optional parameters: None.

    Batch mode example usage

    Using Jacl:

    $AdminTask getManagedNodesOnHostByInstallLoc host_name

    Using Jython:

    AdminTask.getManagedNodesOnHostByInstallLoc ('host_name')

    Interactive mode example usage

    Using Jacl:

    $AdminTask getManagedNodesOnHostByInstallLoc {-interactive}

    Using Jython:

    AdminTask.getManagedNodesOnHostByInstallLoc ('[-interactive]')


    listManagedNodesOnHost

    The listManagedNodesOnHost command lists the managed nodes located on the federated host in the current dmgr cell.

    Target object: The required target object specifies the host name of the workstation containing the managed nodes federated into the dmgr cell.

    Required parameters: None.

    Optional parameters: None.

    Batch mode example usage

    Using Jacl:

    $AdminTask listManagedNodesOnHost host_name

    Using Jython:

    AdminTask.listManagedNodesOnHost ('host_name')

    Interactive mode example usage

    Using Jacl:

    $AdminTask listManagedNodesOnHost {-interactive}

    Using Jython:

    AdminTask.listManagedNodesOnHost ('[-interactive]')


    testConnectionToHost

    The testConnectionToHost command verifies that a connection can be established from the dmgr to the remote host by using an administrator ID and password for the remote host.

    Target object: None.

    Required parameters:

    -hostName

    Name of the remote host. (String, required)

    -platformType

    Platform type of the remote host. The valid types are Windows, AIX, HP-UX, Linux, UNIX, OS400 or Solaris. This parameter is not case-sensitive. (String, required)

    -adminName

    Administrative ID for the remote host. (String, required)

    -adminPassword

    Administrative password for the remote host. (String, required)

    Optional parameters: None.

    Batch mode example usage

    Using Jacl:

    $AdminTask testConnectionToHost {-hostName big.mountain.com -platformType linux -adminName root -adminPassword passw0rd3}

    Using Jython:

    AdminTask.testConnectionToHost ('[-hostName big.mountain.com -platformType linux -adminName root -adminPassword passw0rd3]')

    Interactive mode example usage

    Using Jacl:

    $AdminTask testConnectionToHost {-interactive}

    Using Jython:

    AdminTask.testConnectionToHost ('[-interactive]')


    testConnectionToHostUsingSSHKey

    The testConnectionToHostUsingSSHKey command verifies that a connection can be established from the dmgr to the remote host by using the SSH private key for the remote host.

    Target object: None.

    Required parameters: -hostName

    Name of the remote host. (String, required): -adminName

    Administrative ID for the remote host. (String, required): -privateKeyStore

    Path to the private key file, which is located on the dmgr. (String, required)

    Optional parameters

    -keyStorePassword

    Optional password, also known as the passphrase, which is used to protect the private key file. (String, the parameter is required if a non-blank password is used to protect private key store.)

    Batch mode example usage

    Using Jacl:

    $AdminTask testConnectionToHostUsingSSHKey {-hostName abc.com -adminName root -privateKeyStore /root/.ssh/id_rsa}

    Using Jython:

    AdminTask.testConnectionToHostUsingSSHKey ('[-hostName abc.com -adminName root -privateKeyStore /root/.ssh/id_rsa]')

    Interactive mode example usage

    Using Jacl:

    $AdminTask testConnectionToHostUsingSSHKey {-interactive}

    Using Jython:

    AdminTask.testConnectionToHostUsingSSHKey ('[-interactive]')


    installSSHPublicKeyOnHost

    The installSSHPublicKeyOnHost command installs the administrative SSH public key on the remote host.

    Target object: None.

    Required parameters

    -hostName

    Name of the remote host. (String, required)

    -adminName

    Administrative ID for the remote host. (String, required)

    -adminPassword

    Administrative password for the remote host. (String, required)

    -publicKeyStore

    Path to the public key file, which is located on the dmgr, in either Internet Engineering Task Force (IETF) standard format or OpenSSH format.

    Optional parameters: None.

    Batch mode example usage

    Using Jacl:

    $AdminTask installSSHPublicKeyOnHost {-hostName abc.com -adminName root -adminPassword passw0rd3 -publicKeyStore /root/.ssh/id_rsa.pub}

    Using Jython:

    AdminTask.installSSHPublicKeyOnHost ('[-hostName abc.com -adminName root -adminPassword passw0rd3 -publicKeyStore /root/.ssh/id_rsa.pub]')

    Interactive mode example usage

    Using Jacl:

    $AdminTask installSSHPublicKeyOnHost {-interactive}

    Using Jython:

    AdminTask.installSSHPublicKeyOnHost ('[-interactive]')


    listKeyInstallationRecords

    The listKeyInstallationRecords command lists the SSH public key installation records that the CIM maintains.

    Target object: None.

    Required parameters: None.

    Optional parameters: None.

    Batch mode example usage

    Using Jacl:

    $AdminTask listKeyInstallationRecords

    Using Jython:

    AdminTask.listKeyInstallationRecords ()

    Interactive mode example usage

    Using Jacl:

    $AdminTask listKeyInstallationRecords {-interactive}

    Using Jython:

    AdminTask.listKeyInstallationRecords ('[-interactive]')


    updateKeyInstallationRecords

    The updateKeyInstallationRecords command updates the SSH public key installation records that the CIM maintains.

    Target object: None.

    Required parameters: None.

    Optional parameters:

    -add

    Adds a list of host names to the installation records. (String, optional)

    -remove Removes a list of host names from the installation records. (String, optional)

    Batch mode example usage

    Using Jacl:

    $AdminTask updateKeyInstallationRecords {-add "abc.com,river.com"}

    Using Jython:

    AdminTask.updateKeyInstallationRecords ('[-add "abc.com,river.com"]')

    Interactive mode example usage

    Using Jacl:

    $AdminTask updateKeyInstallationRecords {-interactive}

    Using Jython:

    AdminTask.updateKeyInstallationRecords ('[-interactive]')


    listPendingRequests

    The listPendingRequests command lists the submitted installation or uninstallation requests that are not started

    Target object None.

    Required parameters None.

    Optional parameters None.

    Batch mode example usage

    Using Jacl:

    $AdminTask listPendingRequests

    Using Jython:

    AdminTask.listPendingRequests ()

    Interactive mode example usage

    Using Jacl:

    $AdminTask listPendingRequests {-interactive}

    Using Jython:

    AdminTask.listPendingRequests ('[-interactive]')


    listInProgressRequests

    The listInProgressRequests command lists the installation or uninstallation requests that are in progress for completion.

    Target object None.

    Required parameters None.

    Optional parameters None.

    Batch mode example usage

    Using Jacl:

    $AdminTask listInProgressRequests

    Using Jython:

    AdminTask.listInProgressRequests ()

    Interactive mode example usage

    Using Jacl:

    $AdminTask listInProgressRequests {-interactive}

    Using Jython:

    AdminTask.listInProgressRequests ('[-interactive]')


    listRequestsForTarget

    The listRequestsForTarget command lists all of the submitted installation and uninstallation requests for a specific host.

    Target object

    The required target object the host name of the target workstation. Specify the same host name that you use for the installSoftware and uninstallSoftware commands.

    Required parameters None.

    Optional parameters None.

    Batch mode example usage

    Using Jacl:

    $AdminTask listRequestsForTarget host_name

    Using Jython:

    AdminTask.listRequestsForTarget ('host_name')

    Interactive mode example usage

    Using Jacl:

    $AdminTask listRequestsForTarget {-interactive}

    Using Jython:

    AdminTask.listRequestsForTarget ('[-interactive]')


    showLatestInstallStatus

    The showLatestInstallStatus command lists all of the submitted installation requests for a specific host.

    Target object The required target object is the host name of the target workstation. Specify the same host name that you use for the installSoftware command.

    Required parameters None.

    Optional parameters None.

    Batch mode example usage

    Using Jacl:

    $AdminTask showLatestInstallStatus host_name

    Using Jython:

    AdminTask.showLatestInstallStatus ('host_name')

    Interactive mode example usage

    Using Jacl:

    $AdminTask showLatestInstallStatus {-interactive}

    Using Jython:

    AdminTask.showLatestInstallStatus ('[-interactive]')


    showLatestUninstallStatus

    The showLatestUninstallStatus command displays the status of the most recently submitted uninstallation request.

    Target object The required target object is the host name of the target workstation. Specify the same host name that you use for the uninstallSoftware command.

    Required parameters None.

    Optional parameters None.

    Batch mode example usage

    Using Jacl:

    $AdminTask showLatestUninstallStatus host_name

    Using Jython:

    AdminTask.showLatestUninstallStatus ('host_name')

    Interactive mode example usage

    Using Jacl:

    $AdminTask showLatestUninstallStatus {-interactive}

    Using Jython:

    AdminTask.showLatestUninstallStatus ('[-interactive]')


    uninstallSoftware

    The uninstallSoftware command uninstalls the software package from the remote host.

    Target object None.

    Required parameters

    -packageName

    Name of the software package. (String, required)

    -hostName

    Name of the remote host. (String, required)

    -platformType

    OS of the remote workstation. The valid types are Windows, AIX, HP-UX, Linux, UNIX, OS400 or Solaris. This parameter is not case-sensitive. (String, required)

    -installLocation

    Path to the installation directory on the remote host. Specify this parameter only if there are multiple installation locations that exist within the current cell on the same host. (String, required)

    -adminName

    Administrative ID for the remote host. (String, required)

    Optional parameters

    -adminPassword

    Administrative password for the remote host. Specify either the adminPassword parameter or the privateKeyStore parameter to authenticate. (String, optional)

    -privateKeyStore

    Path to the private key file, which is located on the dmgr. Specify either the adminPassword parameter or the privateKeyStore parameter to authenticate. (String, optional)

    -keyStorePassword

    Optional password, also known as the passphrase, which is used to protect the private key file. (String, the parameter is required if a non-blank password is used to protect private key store.)

    Batch mode example usage

    Using Jacl:

    $AdminTask uninstallSoftware {-packageName ND70 -hostName abc.com -platformType windows -installLocation C:/WAS70 -adminName admin1 -adminPassword passw0rd1}

    Using Jython:

    AdminTask.uninstallSoftware ('[-packageName ND70 -hostName abc.com -platformType windows -installLocation C:/WAS70 -adminName admin1 -adminPassword passw0rd1]')

    Interactive mode example usage

    Using Jacl:

    $AdminTask uninstallSoftware {-interactive}

    Using Jython:

    AdminTask.uninstallSoftware ('[-interactive]')


    uninstallMaintenance

    Uninstall maintenance, such as fix packs and interim fixes, from the remote host.

    Target object None.

    Required parameters

    -packageName

    Name of the software package. (String, required)

    -hostName

    Name of the remote host. (String, required)

    -adminName

    Administrative ID for the remote host. (String, required)

    Optional parameters

    -fileList

    List of maintenance files to uninstall on the remote target. (String, optional)

    -installLocation

    Path to the installation directory on the remote host. Specify this parameter only if there are multiple installation locations that exist within the current cell on the same host. (String, optional)

    -adminPassword

    Administrative password for the remote host. Specify either the adminPassword parameter or the privateKeyStore parameter to authenticate. (String, optional)

    -privateKeyStore

    Path to the private key file, which is located on the dmgr. Specify either the adminPassword parameter or the privateKeyStore parameter to authenticate. (String, optional)

    -keyStorePassword

    Optional password, also known as the passphrase, which is used to protect the private key file. (String, the parameter is required if a non-blank password is used to protect private key store.)

    Batch mode example usage

    Using Jacl:

    $AdminTask uninstallMaintenance {-packageName ND61Maintenance -hostName river.com -adminName admin1 -adminPassword passw0rd1 -fileList "6.1.0.9-WS-WAS-IFPKxxxxx.pak,6.1.0.9-WS-WAS-IFPKyyyyy.pak"}

    Using Jython:

    AdminTask.uninstallMaintenance ('[-packageName ND61Maintenance -hostName river.com -adminName admin1 -adminPassword passw0rd1 -fileList "6.1.0.9-WS-WAS-IFPKxxxxx.pak, 6.1.0.9-WS-WAS-IFPKyyyyy.pak"]')

    Interactive mode example usage

    Using Jacl:

    $AdminTask uninstallMaintenance {-interactive}

    Using Jython:

    AdminTask.uninstallMaintenance ('[-interactive]')