HP Server Automation Release Notes

Software version: 9.11

Original Publication Date: January 2012

Server Automation release notes contain information for users who are familiar with the installation and maintenance of Server Automation, Storage Visibility and Automation, SE Connector, Application Deployment Manager, DMA integration, and SA-OO integration. The notes contain information that is not included in books or online Help.

In addition, these release notes contain a Known Issues table and a Fixed Issues table:

• Known Issues table includes known issues from SA versions 9.0, 9.01, 9.02, 9.03, 9.10, and 9.11.
• Fixed Issues table includes issues that:
  • Were found by customers during the SA 9.11 development cycle, and were fixed by the SA team during the same cycle.
  • Were in the Known Issues table for 9.10, but were fixed during SA 9.11.

Note: The latest information for 9.11 can be found in the latest version of these release notes, located at: http://support.openview.hp.com/selfsolve/manuals.

Table of Contents

This document contains the following information:

What's New In this Release

This section describes new features and items for this release.

For information about what was new in previous releases, please see the corresponding release notes at:
http://support.openview.hp.com/selfsolve/manuals.

Hotfix Patch Required for SA 9.11 with Pre-9.11 SA Agents

Snapshot and audit regression issues occur after upgrading to SA 9.11 if you are using an established datacenter and your SA Agent was not also upgraded to a 9.11 version.

In 9.11, upgraded SA Agents execute snapshots and audits using Python 2.4 code, but non-upgraded agents cannot use that version of Python and, therefore, cannot execute 9.11 snapshot and audit code correctly.

In the SA Client, the following error is displayed in the  /var/log/opsware/spoke/spoke-0.log:

2012-02-27 13:07:43,038 SEVERE Thread-179 [com.opsware.compliance.server.snapshot.ServerSnapshotGenerator] [handleFailedSnapshot] Failed to take snapshot for ruletype CMDOUTPUT :
java.io.IOException: Process failed:Executing command to Snapshot check on Server 2820002
Executing command failed
ERR: Failed while running: /var/opt/opsware/agent/snapshot/compliance_candr.py.dir.6645/__OPSWEXTRACT__/check-0/code.dir/getscript
ERR: Exception: RLIM_INFINITY

at com.opsware.compliance.handler.helper.BaseSnapshotHandler.generateSnapshot(BaseSnapshotHandler.java:300)
at com.opsware.compliance.handler.cmdoutput.CmdOutputSnapshotHandler.generateSnapshot(CmdOutputSnapshotHandler.java:102)
at com.opsware.compliance.server.snapshot.ServerSnapshotGenerator.doGenerateSnapshot(ServerSnapshotGenerator.java:226)
at com.opsware.compliance.server.snapshot.ServerSnapshotGenerator.generateSnapshot(ServerSnapshotGenerator.java:84)
at com.opsware.compliance.server.rmi.ISnapshotResultManagerImpl.createSnapshot(ISnapshotResultManagerImpl.java:222)
at com.opsware.rmi.wrapper.gen_server.comopswarecomplianceserverrmiISnapshotResultManagerImplTie.createSnapshot(comopswarecomplianceserverrmiISnapshotResultManagerImplTie.java:34)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

In the SA Web Client Job Status field, the following error is displayed:

Failed:
Error Details:
An internal exception of type com.loudcloud.opsware_common.errors.OpswareError with message OpswareError: Failed to take snapshot for policy type: CHECKPOLICY. Please check the log files for more information. [ module: java.lang, method: getWayError, line: 67, hostname: hubble.company.com, timestamp: 2012-03-02 18:36:29.346, messageKeyOrder:  msg, msg:   ] was caught.

Action required:

Contact HP Support to obtain a hotfix for this issue.

Qualified Managed Platforms

The SA 9.11 release provides qualified managed platform support for the following:

• All Platform Qualifications from 9.10.01 MPQ
• All Platform Qualifications from 9.10.02 MPQ
• ESX/ESXi 4.1 U2
• Red Hat Enterprise Linux 5.7 (IA 64, Power)
• Red Hat Enterprise Linux 6 (Power)
• Red Hat Enterprise Linux 6.1 zSeries
• Red Hat Enterprise Linux 6.2 (x86, x64)
• Windows Server 2008 R2 IA64
• XenServer 6

For more support and compatibility information, download the HP Server Automation Support and Compatibility Matrix for this release from the HP Software Support Online web site at: http://support.openview.hp.com/selfsolve/manuals.

For a list of supported operating systems and platforms for Storage Visibility and Automation Managed Servers, SE Connector, SAN Arrays, Fibre Channel Adapters, SAN Switches, File System Software, Database Support, and Storage Essentials Compatibility, see the Storage Visibility and Automation Support and Compatibility Matrix.

Agents

Agent Support

Agents were upgraded to Python 2.4.4.

Older Agents support a limited feature set. Pre-9.10 agent versions are supported only in upgraded cores.

For more information, see the HP Server Automation Support and Compatibility Matrix for this release from the HP Software Support Online web site at: http://support.openview.hp.com/selfsolve/manuals.

Faster Agent Installation

For more information on installing the agent and bringing servers under SA management, see the SA User Guide: Server Automation.

Application Deployment Manager

Code Component Base Directory Support

This capability enables you to create separate “sandboxes” for Code component deployment. This is useful if you want Code component files to only be installed in controlled file system locations.

Global and Release Parameters

There are two new types of variables that you can reference in parameter definitions:

Release parameters are available to all components within a release. They are created and managed by the application owner and can be modified by anyone who has permission to edit the application. The value of a release parameter does not change unless it is explicitly modified. A release parameter has the same value within a specific version of the release.

Global parameters are available to all applications. They are created and managed by the Application Deployment administrator. The value specification of a global parameter does not change unless it is explicitly modified by the administrator. The actual value of a global parameter can vary depending on the environment and target.

Automatically Created Directories

For a Configuration File component, the application designer can now instruct the Application Deployment Manager to create the destination directory if it does not yet exist on the target server.

Partial Import/Export

The admtool utility now supports importing and exporting one or more specific applications. You can specify the list of applications to be imported or exported on the command line, or you can specify a CSV file that contains the list of applications. In both cases, the names of the applications must be separated by semicolons (for example: app1;app2;app3).

Example 1: Export Three Specific Applications

/opt/opsware/da/bin/admtool.sh -e --exportAppList "app1;app2;app3" --exportFile ADM_export.xml
/opt/opsware/da/bin/admtool.sh -e --exportAppListFile app_list.csv --exportFile ADM_export.xml

Example 2: Import Three Specific Applications

/opt/opsware/da/bin/admtool.sh -i --importAppList "app1;app2;app3" --importFile ADM_import.xml
/opt/opsware/da/bin/admtool.sh -i --importAppListFile app_list.csv --importFile ADM_import.xml

Example 3: Preview the Import of Three Specific Applications
/opt/opsware/da/bin/admtool.sh -p --importAppList "app1;app2;app3" --importFile ADM_import.xml
/opt/opsware/da/bin/admtool.sh -p --importAppListFile app_list.csv --importFile ADM_import.xml

Sample contents of the app_list.csv file:

app1;app2;app3;

HP Operations Orchestration Integration

The Application Deployment Manager now supports enhanced logging for HP Operations Orchestration (HP OO) integration, allowing easier auditing of in-bound and out-bound HP OO interactions.

Database and Middleware Automation (DMA)

Single-Click Navigation for DMA Environments

To reduce confusion on the Environment > Dashboard page in the DMA web interface, single-click navigation is now used exclusively. When you click any item in the Environment hierarchy, that item is highlighted in blue, and the following information is displayed:

The hierarchy associated with the item clicked is highlighted in gray. For example, if you click an Instance, the Server and Organization to which that Instance belongs are highlighted in gray.

OO-SA Integration

Updates pertaining specifically to the OO-SA integration (Server Automation operations performed within Operations Orchestration) are delivered via the HP Live Network at https://www.www2.hp.com/.

Oracle RAC  Support

As of this release, SA supports Oracle 11.2.0.2. For more information, see Oracle RAC Support.

OS Provisioning

New Delivery Method for OS Provisioning Build Plan Content

As of SA 9.10, OS Provisioning Build Plan (OSBP) content is uploaded into the SA Core during installation and/or upgrade.

After installing or upgrading to SA 9.11, you must not download OSBP content from the HP Live Network (HPLN). Any automatic jobs you have created to download OSBP content from HPLN must be disabled. If you download OSBP content from HPLN after installing SA 9.11, you will overwrite the SA 9.10 OSBP content that was uploaded during install/upgrade with older SA 9.0 OSBP content, which will cause errors when you attempt to run OS Build Plan jobs under SA 9.11.

Enabling IBM POWER6 Provisioning with the DHCPD Tool

Due to hardware constraints, IBM POWER6 servers cannot be provisioned using the normal OS Provisioning procedures. However, you can enable provisioning for these servers using the dhcpdtool provided with SA.

This involves using the dhcpdtool to set a parameter in the initial subnet declaration which enables Linux OS provisioning on the IBM POWER6 server's hardware. This workaround also requires that SA be in Full DHCP Management mode.

Note: Setting this parameter prevents Solaris SPARC OS provisioning. You will see a warning message to this effect when you change the parameter.

Perform the following tasks to enable Linux OS Provisioning on IBM POWER6 hardware:

1. Start the dhcpdtool.

   /opt/opsware/dhcpd/sbin/dhcpdtool

2. Select “Full DHCP Management”.

3. Select the network for which the workaround is to be applied. An editing menu is displayed:
   Opsware DHCP Network Configuration Tool
      Editing DHCP information for 192.168.208.160/27 (255.255.255.224)
      1) gateway    : 192.168.208.161
      2) DHCP range : 192.168.208.163 - 192.168.208.190
      3) DNS servers: 192.168.194.4
      4) DNS domain : dev.opsware.com
      5) Power6 provisioning override: No
        !!! WARNING: Option 5) breaks Solaris SPARC OS provisioning !!!
        !!! Make sure to deactivate this option before trying to provision a Solaris SPARC machine !!!
      1..5 to edit option.
      d)elete network and return to main menu.
      k)eep network and return to main menu.
      Choice [1..5, d, k]:

4. Select option 5 and press ENTER.

5. The message “Are you sure that you want to toggle POWER6 provisioning although it breaks Solaris SPARC provisioning (Enable/Disable)?” is displayed.

6. Press E to Enable POWER6 provisioning, D to Disable, then select K to keep the settings then S to save them.

7. Exit the DHCPD tool. Upon exiting, the DHCPD server is restarted and the new setting takes effect.

   Note: If you are not using the SA-provided DHCPD server, you must add the following line to the subnet in which POWER6 you will perform OS provisioning:
              filename "yaboot";

Patch Management for Windows

You can now import and install most Windows multi-binary patches, including those that have been traditionally blocked by SA or required fixit scripts. See Windows Server Post-Patch Upgrade or Install Task in the Installation section for additional details.

Tip: If you are installing Windows OS Service Packs (SP), hotfixes, and update rollups, it is best to remediate the server with the desired SP before installing the hotfixes and update rollups. Hotfixes are usually quickly released refinements that are eventually rolled up into the subsequent Service Pack. Isolating the SP into its own policy and completing that before running the remainder of the Vendor Recommended policy can prevent errors that may result from installing unnecessary hotfixes that are rolled up into the subsequent SPs.  

SA-UCMDB Integration

HP Server Automation now integrates with HP UCMDB. You can use the SA-UCMDB Connector to copy data from SA to the HP UCMDB. Whenever the data in SA changes, the SA-UCMDB Connector automatically sends the latest data to the UCMDB.

The HP Universal CMDB is a configuration management database (CMDB) for enterprise IT organizations to document, store, and manage business service definitions and associated infrastructure relationships. The UCMDB provides a shared single version of truth to support business service management, IT service management, change management, and asset management initiatives. These initiatives help align IT efforts with business requirements and run IT operations more efficiently and effectively.

HP Server Automation provides life cycle management for enterprise servers and applications from discovery to provisioning, patching to configuration management and script execution to compliance assurance. HP Server Automation automates operations and processes across disparate IT teams and systems. HP SA stores a large amount of information about your servers and software in the SA database. You can now leverage this data into the HP UCMDB.

For more information, see the HP SA-UCMDB Integration Guide available at: http://support.openview.hp.com/selfsolve/manuals

Support for Browsers

This table shows browser support information for this release.

Support for Windows Operating Systems

This section lists the operating-systems supported on the SA Client.

• Windows Server 2003  
• Windows Server 2008   
• Windows XP
• Windows Vista 
• Windows  7 

Note: Windows 2000 has been retired as a supported platform because it is no longer supported by the OS Vendor (Microsoft).

Remediation Scalability Enhancements

In 9.05, remediation performance and scalability have been significantly enhanced. There are two key areas of improvement:

• RPM Remediation Analysis – Fetching package headers during an RPM dependency analysis/preview is considerably faster than in previous SA releases.
• Remediation Package Staging – Downloading packages from the software repository to managed hosts is considerably faster than in previous SA releases and can now utilize 10GbE networking.

Two new components were introduced to the Slice Component bundle:

• tsunami – a download accelerator for the Software Repository
• memcached - an in-memory object caching system

To benefit from this enhancement, you must apply the 9.05 patch to each SA Agent on each SA Managed Server in the facility.

Note: This enhancement applies only to agents that communicate directly with a Linux-based SA core. You must upgrade your agents to the agent version shipped with the 9.05 patch to benefit from this enhancement. You can continue to use non-upgraded agents, but they will not benefit from this enhancement. See the SA 9.0 User’s Guide: Server Automation for information about the Agent Upgrade Tool.
The component services are integrated with the global Start script and are started with the other services. In particular, tsunami and memcached are started with the Slice component bundle components. A new log directory is also created for the tsunami logs:  /var/log/opsware/tsunami 

Note: For information about component log files or starting and stopping individual components, see the SA 9.0 Administration Guide.

Performance Considerations

For best results when deploying and using the remediation performance and scalability enhancements in this release, be aware of the following considerations.

Package Locality

When packages are uploaded to an SA core, the packages are associated with the core/facility (locality) in which they were uploaded. When you remediate a software policy against a specific managed host, it attempts to fetch the package from its local software repository or software repository cache.
If the package or packages in question do not reside in the local software repository, the local software repository attempts to fetch the package from the remote software repository where the package is. The package is then served to the managed host by proxy. Depending on the network speeds between cores, this operation can result in a performance penalty that would affect the remediation job.

Recommendation: To achieve the highest levels of performance, you should turn on Software Repository Replication for your mesh. Software Repository Replication was introduced in SA 9.0 and ensures that packages are replicated between cores in the same mesh automatically and frequently, which eliminates the performance overhead associated with proxying remote packages.

Satellite Performance

The initial release of this enhancement includes core-side improvements only. This means that machines reporting to a core via a satellite will not directly benefit from this enhancement. For Satellites that share a local LAN with a core machine (e.g. those used for HA or security boundaries), it is possible to disable the Software Repository Cache component via a customization of your satellite Agent Gateway configurations. 

Recommendation: Contact HP Software Professional Services for more information on customizing Agent Gateway configurations.

Installation

This section describes the SA 9.11 installation procedure.

While CORD/MPQ patches are customer installable, all Core installations and upgrades must be performed by HP Professional Services or HP-certified consultants. SA Satellite installations and upgrades performed by customers continue to be supported.

See the SA installation guides for more installation information.

Hotfix Patch Required for SA 9.11 with Pre-9.11 SA Agents

Snapshot and audit regression issues occur after upgrading to SA 9.11 if you are using an established datacenter and your SA Agent was not also upgraded to a 9.11 version.

In 9.11, upgraded SA Agents execute snapshots and audits using Python 2.4 code, but non-upgraded agents cannot use that version of Python and, therefore, cannot execute 9.11 snapshot and audit code correctly.

In the SA Client, the following error is displayed in the  /var/log/opsware/spoke/spoke-0.log:

2012-02-27 13:07:43,038 SEVERE Thread-179 [com.opsware.compliance.server.snapshot.ServerSnapshotGenerator] [handleFailedSnapshot] Failed to take snapshot for ruletype CMDOUTPUT :
java.io.IOException: Process failed:Executing command to Snapshot check on Server 2820002
Executing command failed
ERR: Failed while running: /var/opt/opsware/agent/snapshot/compliance_candr.py.dir.6645/__OPSWEXTRACT__/check-0/code.dir/getscript
ERR: Exception: RLIM_INFINITY

at com.opsware.compliance.handler.helper.BaseSnapshotHandler.generateSnapshot(BaseSnapshotHandler.java:300)
at com.opsware.compliance.handler.cmdoutput.CmdOutputSnapshotHandler.generateSnapshot(CmdOutputSnapshotHandler.java:102)
at com.opsware.compliance.server.snapshot.ServerSnapshotGenerator.doGenerateSnapshot(ServerSnapshotGenerator.java:226)
at com.opsware.compliance.server.snapshot.ServerSnapshotGenerator.generateSnapshot(ServerSnapshotGenerator.java:84)
at com.opsware.compliance.server.rmi.ISnapshotResultManagerImpl.createSnapshot(ISnapshotResultManagerImpl.java:222)
at com.opsware.rmi.wrapper.gen_server.comopswarecomplianceserverrmiISnapshotResultManagerImplTie.createSnapshot(comopswarecomplianceserverrmiISnapshotResultManagerImplTie.java:34)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

In the SA Web Client Job Status field, the following error is displayed:

Failed:
Error Details:
An internal exception of type com.loudcloud.opsware_common.errors.OpswareError with message OpswareError: Failed to take snapshot for policy type: CHECKPOLICY. Please check the log files for more information. [ module: java.lang, method: getWayError, line: 67, hostname: hubble.company.com, timestamp: 2012-03-02 18:36:29.346, messageKeyOrder:  msg, msg:   ] was caught.

Action required:

Contact HP Support to obtain a hotfix for this issue.

General Information

• SA 9.11 can be rolled back, but only to the previous full release, SA 9.10.
• The patch_opsware.sh script is used both for installing and for uninstalling SA 9.11.
• There's no need to supply a response file with patch_opsware.sh .
• The patch_database.sh script is used both for installing and rolling back database schema changes required for SA 9.11.
• You must run the patch_database.sh script on the First Core and all Secondary Cores. Note that the Model Repository and Oracle database can exist on a different host than the SA host.
• The response file used to last install/upgrade of the SA Core must be supplied when invoking patch_database.sh.
• This patch includes updated SA Agents that will be uploaded to the Software Repository. However, no agents will be upgraded on core machines (that is, in
  the Model Repository) or on Managed Servers without manual intervention.
• SA 9.11 can only be installed on systems running the following:
  • SA version 9.10 GA build (Build ID of opsware_45.0.6790.0 )
  • SA patch versions 9.10.01 or 9.10.02.

  If any installed SA components (other than a previously installed patch) have a different build ID, you will not be allowed to install SA 9.11.

• To determine the build ID for a core machine, open the file:

/var/opt/opsware/install_opsware/inv/install.inv

and find the section beginning with %basics_ . Under this line, find the build_id .

For example:

%basics_linux

build_id: opsware_45.0.6790.0

When you install an SA patch, the patch installation updates the install.inv file to record the patch installation and the patch build ID.

For example:

%opsware_patch

build_id: opsware_45.0.17090.0

• Before a patch operation (such as install/upgrade/uninstall), all core/satellite services must be up and running. If any services are stopped or dysfunctional (as reported by the /etc/init.d/opsware-sas status command), the patch operation will terminate.
• Upon completion of a patch operation, all services on the core/satellite machine should  be up and running.
• If you are patching a multi-host core/satellite, you must patch each core and satellite host separately, one at a time.
• If you are patching a Multi-master mesh, HP recommends that you patch the primary core first, followed by secondary cores and satellites, thus ensuring that the primary core is at a higher version (such as SA 9.11 or higher) than the secondary cores.

  If you must roll back the SA 9.11 patch in a Multi-master Mesh, HP recommends that you roll back the secondary cores and satellites first, then the primary core.

• Mixed version core environments are not supported. However, during the patch upgrade, a transitory mixed core version environment is supported. For example, while the patch upgrade is in progress, cores at different patch levels can temporarily coexist in a Multimaster Mesh.
• In order to patch and/or roll back Wayscripts, the spog.pkcs8 certificate must exist under /var/opt/opsware/crypto (typically the certificate is installed with the Shell, SAS Web Client, or Build Manager). If the certificate does not exist, the patch operation will fail with the following error:

  Could not find spog.pkcs8 /var/opt/opsware/crypto/occ

  Copy the certificate from another core machine (for example, occ ) to
  
  /var/opt/opsware/crypto/occ
  
  and retry this operation.

  If this error is encountered, simply copy the certificate from another core machine to your core server and retry the operation.

• In order to patch and/or roll back Software Repository ( word ) updates, the spin.srv certificate must exist under /var/opt/opsware/crypto/spin (typically the certificate is installed with the Web Services Data Access Engine ( spin )). If the certificate does not exist, the patch operation will fail with the following error:

  Could not find spin.srv under /var/opt/opsware/crypto/spin.

  Copy the certificate from another core machine (such as occ) to

  /var/opt/opsware/crypto/spin

  and retry this operation.

• The following error may occur during upgrade on cores on which Solaris patching has not yet been set up:

  You don't have permission to update the patch meta database in HP SA.
Please re-run this command with a proper hpsa_user and hpsa_pass.
T he hpsa_user needs permission to write the folder
"/Opsware/Tools/Solaris Patching" and the Package Management
Client Feature, "Manage Package" permission set "Read & Write".
There was a problem with running update_supplements.
Please refer to section Patch Management for Solaris of the Users Guide:
Application Automation manual for details on how to set up Solaris
patching on your core.

  You can safely disregard this error.

Script Running Order

The pre-patch, database update and patch install scripts must be run in the following order:

SA Script Running Order - Upgrade

SA Script Running Order - Rollback

Adobe Flash Player and HP BSA Launcher Issues

Certain SA Client features (such as Run OS Build Plan or HP UX Provisioning) require the Adobe Flash Player. If you try to run these features, and you have not yet installed Adobe Flash Player, you will get an error. If you subsequently install the Player on a machine where you have already installed HP BSA Launcher, and try to run the same features, the error message will still be displayed, even though you have already installed the Player.

To make sure Adobe Flash Player functions correctly and to avoid the error message, you should:

1. Make sure that Adobe Flash Player is installed correctly (access the following site: http://www.adobe.com/software/flash/about/).
2. Stop any instances of the SA Client.
3. Uninstall HP BSA Launcher.
4. Reinstall HP BSA Launcher (1.5.0 or later).
5. Restart the SA Client and run the features normally.
   

The error message should not be displayed.

Database Schema Update Procedure

Required only if you have not previously applied the SA 9.11 patch. The script run during this procedure makes required changes to the Model Repository including adding required tables and objects.

1. Mount the SA 9.11 distribution. Invoke patch_database.sh on the Model Repository host:
   
   

   <distro>/opsware_installer/patch_database.sh --verbose -r <response file>

   Where <response file> is the response file last used to install/upgrade the system.

   Usage: patch_database.sh [--verbose] -r <response file>

   patch_database.sh automatically detects if a database update is already installed and presents a corresponding menu:

   1. If the database update has not been previously applied, you see the following:
      Welcome to the Opsware Installer.
It appears that you do not have a database update
installed on this system.
Press 'i' to proceed with patch installation.
Press 's' to show patch contents.
Press 'q' to quit.
Selection: i
   2. Enter i at the prompt to begin the database update.
   3. If the database update has previously been applied, you see the following:
      

      Welcome to the Opsware Installer.
It appears that you have installed or attempted
to install a previous version of the database
update on this system.
Press 'u' to upgrade the patch to the current version.
Press 'r' to remove this patch.
Press 's' to show patch contents.
Press 'q' to quit.
Selection: u
You chose to upgrade the patch. Continue? [y/n]: y

      Enter u at the prompt then Y to begin the database update.

2. After you make your selection, the installer completes the new (or interrupted) installation.
   On completion, you see a screen similar to the following:

   [timestamp] Done with component Opsware SQL patches.

   [timestamp] ########################################################

   [timestamp] Opsware Installer ran successfully.

   [timestamp] ########################################################

Note: After running the patch_database.sh script, you may see the following error when running the System Diagnostic test on your core:

Test Name: Model Repository Schema
Description: Verifies that the Data Access Engine's version of the schema matches
the Model Repository's version.
Component device: Data Access Engine (spin)
Test Results: The following tables differ between the Data Access Engine and the
Model Repository: local_data_centers, role_class_bridge.

This error is invalid and you can disregard it.

Dual Layer DVD Requirements

All SA installation DVDs require a DVD drive that supports dual layer.

Patch Installation Procedure

Note: Before performing the tasks in this section ensure that you have completed the tasks listed in Database Schema Update Procedure.

Perform the following tasks to install SA 9.11:

1. Mount the SA 9.11 distribution. Invoke patch_opsware.sh on every host in the core/satellite facility:
   
   

   <distro>/opsware_installer/patch_opsware.sh --verbose

   Usage : patch_opsware.sh [--verbose]

   patch_opsware.sh automatically detects whether or not there is a patch already installed and presents a corresponding menu:

   1. Non-upgraded System : If your system has not been previously patched with a 9.1x patch, you see the following menu:
      Welcome to the Opsware Installer. It appears that
you do not have any patches installed on this system.
Press 'i' to proceed with patch installation.
Press 's' to show patch contents.
Press 'q' to quit.
Selection: i

      Enter i at the prompt to begin the installation.

   2. Previously Upgraded System : If an SA patch has already been installed successfully, when patch_opsware.sh is invoked from a newer patch
      release, you see the following menu:
      Welcome to the Opsware Installer. It appears that you have
installed or attempted to install a previous version of
the patch on this system.
Press 'u' to upgrade the patch to the current version.
Press 'r' to remove this patch.
Press 's' to show patch contents.
Press 'q' to quit.
Selection: u

      Enter u at the prompt to begin the upgrade.

2. After you make your selection, the installer completes the new (or interrupted) installation.

   The installer displays the following upon completion:

   [<timestamp>] Done with component Opsware Patch.

   [<timestamp>]

   ########################################################

   [<timestamp>] Opsware Installer ran successfully.

   [<timestamp>]

   ########################################################

Software Repository Content Upgrade

This section details upgrades to the software repository content on the upload distribution (such as agent packages to be reconciled to managed servers).

General Information

• Upgrading software repository content data is similar to using patch_opsware.sh from the upload distribution, but will only update those packages that have changed since the last major version.
• If you are upgrading a core hosted on multiple servers, the Software Repository content patch must be applied to the server hosting the Software Repository
  Store ( word store ).
• If you are upgrading a Multimaster Mesh, the Software Repository content upgrade should only be applied to the First Core (the upgraded content will automatically be propagated to other cores in the mesh).

Note: Unlike core patches, Software Repository content upgrades cannot be rolled back.

Upgrading the First Core Content

1. On the First Core Software Repository store ( word store ) host, invoke the upgrade script::
   
   

   <distro>/opsware_installer/patch_contents.sh --verbose -r <response file>

   where <response file> is the response file last used to install/upgrade the SA Core.

   The following menu is displayed:

   Welcome to the Opsware Installer. Please select the components
to install.
1 ( ) Software Repository - Content (install once per mesh)
Enter a component number to toggle ('a' for all, 'n' for none).
When ready, press 'c' to continue, or 'q' to quit.
   
   Enter either 1 or a and press c to begin the installation.
   

2. If the Software Repository content image is not installed on the server, the following message will be displayed:

   [<timestamp>] There are no components to upgrade.
[<timestamp>] Exiting Opsware Installer.

Rolling Back the Patch

To roll back SA 9.11 to SA 9.10, invoke the script:

<distro>/opsware_installer/patch_opsware.sh --verbose

If this is a patched system, the following will be displayed:

Welcome to the Opsware Installer. It appears that you have previously
completed installation of this patch on this system.
Press 'r' to remove this patch.
Press 's' to show patch contents.
Press 'q' to quit.
Selection:

Enter r at the prompt to remove the patch.

Notes:

• Rolling back SA 9.11 does not remove the Windows Server 2008 data that was created when the core was upgraded. For example, any Windows Server 2008 patches or policies created will remain. If you try to install these patches or attach the policies, an error will occur.
• Rolling back SA 9.11 does not delete any patches and policies that you have imported or created after the upgrade and these may fail with an error if you attempt to run them.

Rolling Back the Database Schema Update

To roll back the database schema update, enter this command:

<distro>/opsware_installer/patch_database.sh --verbose -r <response file>

Where <response file> is the response file last used to install/upgrade the system.

If the database has been updated, you see the following:

Welcome to the Opsware Installer. It appears that you have previously
completed the installation of this database update on this system.
Press 'r' to remove this patch.
Press 's' to show patch contents.
Press 'q' to quit.
Selection: r

Enter r at the prompt to begin the database schema update rollback.

Post-Installation Tasks

This section lists the tasks that should be performed after you install SA 9.11. Some tasks might not be appropriate for your situation.

Windows Server 2008 R2 x64

Required only if you have not set up SA support for Windows Server 2008 R2 x64 when you applied the SA 9.01 patch. SA 9.01 and later provide improved support for Windows Server 2008 R2 x64. Windows Server 2008 R2 x64 now appears with its own entries in the SA Client rather than as a subset of Windows Server 2008.

However, there are some tasks you must perform in order to migrate any Software Policies, Application Configurations, packages (units), Patch Policies and/or OS Provisioning objects you may already have set up for your server(s).

This section describes how to set up SA support for Windows Server 2008 R2 x64.

Migrating Software Policies, Application Configurations and/or Patch Policies is handled by running a script, windows_2008_R2_fix_script.pyc , provided with SA 9.11 and later in the directory:

<distro>/opsware_installer/tools

The script is called windows_2008_R2_fix_script.pyc and is invoked as follows:

/opt/opsware/bin/python2 windows_2008_R2_fix_script.pyc [--mrl=<MRL_ID>|--listmrls|--help

Note: It is very important that you ensure that the MRL(s) specified when you invoke this migration script are correct. Once the script is invoked, migration begins immediately. Providing the incorrect information when invoking this script can cause irreversible data integrity errors.

The script has the following options:

Script Options

Note: Migrated objects other than Patch Policies are not copied, they are attached to the new Windows Server 2008 R2 x64 configuration.

For Patch Policies, Windows Server 2008 R2 x64 copies are created of Windows Server 2008 x64 Patch Policies containing R2 patches (x64 patch library).

The Windows Server 2008 x64 Patch Policies are then detached from the Windows Server 2008 R2 x64 servers and the equivalent Windows Server 2008 R2 x64 Patch Policy copies are attached to the Windows Server 2008 R2 x64 servers.

Note: You can run windows_2008_R2_fix_script.pyc multiple times without issue. The changes made by the script cannot be rolled back.

Requirements

• You must run the script:
  • On the Core's Software Repository ( word ) host.
  • On a machine that has OPSWpytwist installed.
  • On an active core, all SA Core Components must be running.
  • As root. 
• You must log in to the SA Client and navigate to Administration -> Patch Settings-> Windows Patch Downloads -> Patch Products. Use the Edit button and add the Windows Server 2008 R2 x64 option.
• You must re-import the latest MBSA patch database by selecting Patch Database, then the Import from Vendor button.
• If your Hyper-V servers are installed with Windows Server 2008 R2 x64, you must either run hardware registration manually or wait for the scheduled hardware
  registration to complete before you run:
  • Data Reload on the Hyper-V server
  • Create VM, Modify VM, Delete VM, or any control operation on a
    Hyper-V VM

Software Policies

After migration completes, the Software Policy appears in the SA Client Navigation pane under Library/By Type/Software Policies/Windows/Windows Server 2008 R2 x64 and Windows Server 2008 x64.

During migration, Software Policies are modified only if:

• The software policy is attached to a Windows Server 2008 R2 x64 server and the software policy platform list contains Windows Server 2008 x64, or
• The Software Policy is attached to a device group, the device group contains a Windows Server 2008 R2 x64 server and the software policy platform list contains Windows Server 2008 x64.

When processing policy items, the script looks for the following types of objects:

• Nested Software Policies
• Units (Packages)
• Application Configurations

If the script finds a policy item that has Windows Server 2008 x64 in the platform list it will migrate that policy item to Windows Server 2008 R2 x64.

The order of items in the Software Policy is retained and remediation status remains unchanged.

If the script identifies an existing Software Policy as a Windows Server 2008 R2 x64 policy, it does not modify it during processing.

Packages

The script migrates only the packages that have Windows Server 2008 x64 in the platform list and are included as policy item inside a Software Policy that is migrated by the script.

After migration, the package will appear in the SA Client under both the Windows Server 2008 x64 and Windows Server 2008 R2 x64 folders in
Library/By Type/Packages/Windows.

The script does not take into account the package type. It looks for packages included in migrated Software Policies that are attached to Windows Server 2008 x64. Server Module Result objects, Windows Registry objects and Windows Services objects cannot be migrated by the script because their platform associations cannot be changed.

Properties settings (including general, archived scripts, install parameters, install scripts, uninstall parameters, uninstall scripts) are preserved.

Application Configurations

The migration script migrates an application configuration if:

• It is attached to a Windows Server 2008 R2 x64 server and has Windows Server 2008 x64 in the platform list, or
• It is attached to a device group that contains a Windows Server 2008 R2 x64 server and has Windows Server 2008 x64 in the platform list, or
• It has Windows Server 2008 x64 in the platform list and is a policy item of a Software Policy that is migrated.

During migration the script adds Windows Server 2008 R2 x64 to the application configuration's platform list. The script also inspects all application configurations' associated templates (CML templates) and if a template has Windows Server 2008 x64 in the platform list it is also migrated.

There is no undo option.

Patch Policies

During migration, the script appends R2 to the Patch Policy name. For example, for a patch policy named 2008 XYZ Policy, the migration script creates a new Windows Server 2008 R2 x64 policy named 2008 XYZ Policy R2 if:

• There are Windows Server 2008 R2 x64 patches in 2008 XYZ Policy .
• There does not exist any patch policy named 2 008 XYZ Policy R2 that contains patches applicable to platforms other than Windows Server 2008 R2 x64.

Note: If a Windows Server 2008 R2 x64 policy named 2008 XYZ Policy R2 already exists, the applicable patches will be added to it.

If Windows Server 2008 R2 x64 servers, or device groups containing Windows Server 2008 R2 x64 servers, are attached to Windows Server 2008 x64 patch
policies, the migration script will detach these policies and attach the newly created or updated equivalent Windows Server 2008 R2 x64 policies. Applicable Patch Policy exceptions are also migrated.

If metadata associated with Windows Server 2008 R2 x64 patches has been modified (for example: install/uninstall flags, pre/post install/uninstall scripts), that metadata will be migrated.

WindowsImageName Custom Attribute

The specification of the WindowsImageName custom attribute with Windows Server 2008 R2 x64 is somewhat different from other platforms.

For Windows Server 2008 R2 x64, the expected values are:

Windows Server 2008 R2 SERVERDATACENTER
Windows Server 2008 R2 SERVERDATACENTERCORE
Windows Server 2008 R2 SERVERENTERPRISE
Windows Server 2008 R2 SERVERENTERPRISECORE
Windows Server 2008 R2 SERVERSTANDARD
Windows Server 2008 R2 SERVERSTANDARDCORE
Windows Server 2008 R2 SERVERWEB
Windows Server 2008 R2 SERVERWEBCORE

The populate-opsware-update-library Script

A new option, --no_w2k8r2, is provided for the populate-opsware-update-library script and is used to specify that Windows Server 2008 R2 x64 patch binaries should not be uploaded. For more information about the populate-opsware-update-library script, see the SA User's Guide: Application Automation .

Windows Server CLI Installation

If you plan to install the SA Command-line Interface (OCLI) on a Windows Server after upgrade to SA 9.11, you must update the Agent on that server to the latest version. Errors occur during OCLI installation on Windows servers with earlier Agent versions.

Windows Server Post-Patch Upgrade or Install Task

These instructions are for customers who would like to import Windows multi-binary patches that have been traditionally blocked by SA or fixit scripts (such as MS11-078.pyc).

To allow import of previously blocked patches, run these commands on the SA core server with the Software Repository (Word) component after installing or upgrading to SA 9.11:

# cd /opt/opsware/mm_wordbot/util
# export PYTHONPATH=/opt/opsware/pylibs2
# python clear_winpatch_prereq_override.pyc -c -d

The clear_winpatch_prereq_override.pyc script has the following options:

After running this script, you should be able to import the Windows multi-binary patches into to the Windows Patch database in SA.

Note: This is for SA 9.11 upgrades and fresh installs.

Back to the Table of Contents

Installing Slices

If you install additional Slice Component bundle instances after patching the SA Core to version 9.1X, wayscript versions are set to version 9.10 rather than to the patch version. Use the following procedure to remedy the situation:

In the SA Web Client:

1. Log in as administrator (opsware admin user) and navigate to Environment -> Customer -> Opsware -> Custom Attributes -> CORD_OPSWwayscripts.
2. Identify the SA core server by checking the value field of the custom attribute CORD_OPSWwayscripts.
3. Log in to the SA Core server you identified in step 1 and execute the following two commands:
   
   Command #1:
cd /var/opt/opsware/OPSWpatch/OPSWwayscripts/scripts

Command #2:
./post_after_startup.sh
4. Apply any required hotfixes to the wayscripts.

Updating SA Agents

After you upgrade to SA 9.11, you should upgrade the SA Agent on each Managed Server in the facility. The latest version of the SA Agent enables you to use new SA features. You can continue to use non-upgraded Agents, you will not be able to take advantage of all SA 9.11 functionality. On any server on which you must run the SA Command Line Interface (OCLI), you must upgrade the SA Agent to SA 9.11 in order to continue using OCLI. See the SA User’s Guide: Server Automation for information about the Agent Upgrade Tool.

Note: If you choose not to upgrade your SA Agent to 9.11, see known issue QCCR1D143613 for information on a hotfix related to snapshots and audits.

Upgrades

Customized Settings

If you have customized such settings as Java heap settings, you must reapply your customizations after you install 9.11, as the settings are set to the SA default during installation or upgrade.

Windows Server Post-Patch Upgrade or Install Task

If you plan to import Windows multi-binary patches that have been traditionally blocked by SA or fixit scripts (such as MS11-078.pyc), see Windows Server Post-Patch Upgrade or Install Task in the Install section.

Back to the Table of Contents

Known Issues

This section describes cumulative known issues for 9.0 through 9.11. The table lists issues first alphabetically by Subsystem, then numerically within each subsystem.

Back to the Table of Contents

Fixed In This Release

The following fixed Issues table includes issues that:

• Were found by customers during SA 9.11 and were fixed during SA 9.11.
• Were in the Known Issues table for 9.10, but were fixed during SA 9.11.

The table lists issues first by subsystem, then numerically within each subsystem.

Fixed Issues for This Release

Back to the table of contents

Deprecated Features

When a feature or platform is identified as deprecated for a release, it means that you (the SA customer) are notified of its future removal.

Deprecated features are still fully supported in the release they are deprecated in, unless specified otherwise. The intent is that deprecated features or platforms will have support removed in the next major or minor SA release; however, eventual removal is at the discretion of HP.

The following sections list features that were deprecated in the SA 7.80 release. Current and future availability of these features is also described here.

Deprecated API Methods

In SA 9.0, moving application configurations and configuration templates into folders changed the behavior of the associated classes and services.

Attributes folder and lifecycle of the VO-s are required for the following API calls:

com.opsware.acm.ConfigurationService#create
com.opsware.acm.ConfigurationService#update
com.opsware.acm.CMLService#create
com.opsware.acm.CMLService#update
The following methods have been deprecated, but they still perform as expected. Method
com.opsware.folder.FolderVO#getCustomers should be used instead.
com.opsware.acm.ConfigurationVO#getCustomers
com.opsware.acm.CMLVO#getCustomers
The following methods have been deprecated and they have a void implementation. Method
com.opsware.folder.FolderVO#setCustomers must be used instead.
com.opsware.acm.ConfigurationVO#setCustomers
com.opsware.acm.CMLVO#setCustomers

Code Deployment and Rollback (CDR) Not Supported

Code Deployment and Rollback (CDR) was deprecated in the SA 7.80 release.  If you upgrade to SA 9.11 and also upgrade to an SA 9.11 agent, you will no longer be able to use CDR because it is only supported if you are using SA 9.01 (or earlier) agents. However, you will be able to use CDR with SA 9.11 if you uninstall the SA 9.11 agent and reinstall an SA 9.01 (or earlier) agent.  

The Application Deployment tool (first available in SA 9.0) is intended to replace CDR when you upgrade the agent to a version 9.02, 9.10, or later.

See the SA Application Deployment User Guide and your HP Technical Support representative for more information.

Agent Deprecation

In SA 9.0, HP announced the deprecation of the Server Automation Agent for the following versions:

• Server Automation 7.01
• Server Automation 7.00
• Server Automation 6.xx
• Server Automation 5.xx

Although releases of HP Server Automation prior to 9.0 will continue to support these versions of the Agent, it is recommended that customers migrate to newer versions of the Agent on their managed platforms.

HP SA will stop supporting these versions of the Agent in an upcoming major or minor release. Agents from Server Automation 4.xx and earlier are not supported in this release.

DOS-Based OS Provisioning

DOS-based OS Provisioning was deprecated in the SA 7.80 release and is not supported in SA 9.0 or later. For more information, contact your HP Technical Support representative.

start_opsware.sh and stop_opsware.sh scripts

As of SA 7.80, the following scripts are no longer supported:

start_opsware.sh
stop_opsware.sh

In SA 9.0 and later you must use the unified start script:

/etc/init.d/opsware-sas

If you have any applications or scripts that depend on this script, you must rewrite them to use the unified start script.

Virtual Server Management Actions

The Open Console action (for VMware virtual machines of ESX agent-managed hypervisor) was removed in the SA 9.0 release.

The Open Web Access action (for ESX agent-managed hypervisors) was removed in the SA 9.0 release.

As of SA 9.0, virtualization actions for agent-managed ESX 3.0 hypervisors are no longer supported, unless the ESX 3.0 hypervisor is managed by a Virtualization Service. It cannot be directly added to the Virtual Servers view (through Add Hypervisor); it needs to be vCenter managed.

Documentation Information

This section discusses documentation information for this release.

New Guides

The following new guides were added for this release:

• SA-UCMDB Integration Guide

To check for updates to these documents, go to: http://support.openview.hp.com/selfsolve/manuals

The HP Software Product Manuals site requires that you register for an HP Passport and sign in. To register for an HP Passport, select the New users - please register link on the HP Passport login page.

Documentation Errata

This section describes documentation errata.

SA 9.10 Administration Guide

• Chapter 7: Notification Configuration, Setting Email Alert Addresses for an SA Core (page  229) add the following bullet to Step 4:
  • In the field, CronbotMailAlertsEnabled, specify the value 1 to enable cronbot email alerts. To disable cronbot email alerts, specify the value 0.
• Chapter 5: SA Maintenance (page 193):

  In the Details: Start Order for SA Components list, item 16,  opswgw-lb, should be removed. The opswgw-lb component was incorporated into the Core Gateway (opswgw-cgw) component.

Application Deployment Manager Context-Sensitive (F1) Help

In the Application Deployment Manager, context-sensitive online help is provided for numerous dialogs, including the Manage Applications and Manage Targets dialogs.

To view a context-sensitive help topic, click the question mark icon in the dialog. Note that the F1 key does not open online help for the Application Deployment Manager.

To view the portion of the SA online help that pertains to application deployment, select Help -> Help in the Application Deployment Manager.

Refer to the HP Server Automation Application Deployment Manager User Guide for additional information.

SA 9.10 Simple/Advanced Installation Guide

• Chapter 6: First Core Post-Installation Tasks, page 115, SA DHCP Network Configuration Tool (dhcpdtool) section, add the following procedure:

  Enabling IBM POWER6 Provisioning with the DHCPD Tool

  Due to hardware constraints, IBM POWER6 servers cannot be provisioned using the normal OS Provisioning procedures. However, you can enable provisioning for these servers using the dhcpdtool provided with SA.

  This involves using the dhcpdtool to set a parameter in the initial subnet declaration which enables Linux OS provisioning on the IBM POWER6 server's hardware. This workaround also requires that SA be in Full DHCP Management mode.

  Note: Setting this parameter prevents Solaris SPARC OS provisioning. You will see a warning message to this effect when you change the parameter.

  Perform the following tasks to enable Linux OS Provisioning on IBM POWER6 hardware:

1. Start dhcpdtool.

   /opt/opsware/dhcpd/sbin/dhcpdtool
  
2. Select Full DHCP Management.

3. Select the network for which the workaround is to be applied. An editing menu is displayed:

    Opsware DHCP Network Configuration


    Editing DHCP information for 192.168.208.160/27 (255.255.255.224)

   1) gateway    : 192.168.208.161
   2) DHCP range : 192.168.208.163 - 192.168.208.190
   3) DNS servers: 192.168.194.4
   4) DNS domain : dev.opsware.com
   5) Power6 provisioning override: No
     !!! WARNING: Option 5) breaks Solaris SPARC OS provisioning !!!
     !!! Make sure to deactivate this option before trying to provision a Solaris SPARC machine !!!

     1..5 to edit option.
     d)elete network and return to main menu.
     k)eep network and return to main menu.

     Choice [1..5, d, k]:

4. Select option 5 and press ENTER

5. The message “Are you sure that you want to toggle POWER6 provisioning although it breaks Solaris SPARC provisioning (Enable/Disable)?” is displayed.

6. Press E to Enable POWER6 provisioning, D to Disable, select K to keep the settings, then S to save them.

7. Exit the DHCPD tool. Upon exiting, the DHCPD server is restarted and the new setting takes effect.

Note: If you are not using the SA-provided DHCPD server, you must add the following line to the subnet in which POWER6 you will perform OS provisioning:

           filename "yaboot";

• Appendix A, "Oracle Setup for the Model Repository", page 191, the section titled "Oracle XDB Component Installation Requirements" should be removed or ignored. From SA 9.10 onwards SA uses the Oracle Data Pump utility rather than the Oracle Export utility.
• Appendix A: To reflect support for Oracle 11.2.0.2, replace the section in Appendix A on page 26, "Oracle RAC Support", with the following information:

   

  Oracle RAC Support

  SA 9.11 and later supports Oracle Real Application Clusters (RAC).

  Note: Oracle RAC support requires a new installation of both Oracle and SA. Therefore, in order to
  enable Oracle RAC support in SA, you must first install SA and Oracle 10.2.0.4, 11.1.0.7 or 11.2.0.2, configured as described in the following sections.

  Supported Oracle Versions

  SA support for Oracle RAC includes these Oracle Enterprise Edition versions:

  - 10.2.0.4
  - 11.1.0.7
  - 11.2.0.2

Supported Operating Systems

- Red Hat Enterprise Linux AS 4 x86_64
- Red Hat Enterprise Linux AS 5 x86_64

Set up the Oracle RAC Database/Instances

SA supports any valid Oracle RAC configuration, such as any number of nodes, ASM or
regular disks, and so on.

However, SA requires that the Oracle database be configured for use with SA. You will require
your Oracle DBA's help to configure the Oracle RAC/instances, the required initialization
parameters, the required tablespaces, the opsware_admin database user, and the
listener.ora and tnsnames.ora files.

Create the Database with the Required Initialization Parameters

Before installing Oracle, the following scripts must be run and init.ora must have certain
parameter values edited or added as shown in Required and Suggested Parameters for
init.ora in the SA 9.10 Simple/Advanced Installation Guide, Appendix A.

1. Create the database

Create a database with the UTF8 character set (as required by SA), the data and index
files, the default temporary tablespace, the undo tablespace, and the log files.

2. Create the Required Tablespaces

Create the following tablespaces that are required by SA:
LCREP_DATA
LCREP_INDX
TRUTH_DATA
TRUTH_INDX
AAA_DATA
AAA_INDX
AUDIT_DATA
AUDIT_INDX
STRG_DATA
STRG_INDX
See “Tablespace Sizes” in the SA Simple/Advanced Installation Guide for additional
tablespace sizing information.

3. Specify the Required and Suggested Parameters for init.ora.

The file init.ora must be edited as shown in Required and Suggested Parameters for
init.ora in the SA 9.10 Simple/Advanced Installation Guide, Appendix A.

4. Create the User opsware_admin

You can use the script, CreateUserOpsware_Admin.sql, to create the opsware_admin
database user and grant permissions (privileges) to the user (required by SA) or create the
user manually.

If you plan to create the opsware_admin user manually, follow the procedure below:

Manual Creation of the User Opsware_Admin

To create the opsware_admin user after a manual Oracle installation, log in to SQL*Plus, and enter the following:

# Su - oracle
# Sqlplus "/ as sysdba"
SQL>create user opsware_admin identified by opsware_admin
default tablespace truth_data
temporary tablespace temp
quota unlimited on truth_data;
grant alter session to opsware_admin with admin option;
grant create procedure to opsware_admin with admin option;
grant create public synonym to opsware_admin with admin option;
grant create sequence to opsware_admin with admin option;
grant create session to opsware_admin with admin option;
28 Appendix
grant create table to opsware_admin with admin option;
grant create trigger to opsware_admin with admin option;
grant create type to opsware_admin with admin option;
grant create view to opsware_admin with admin option;
grant delete any table to opsware_admin with admin option;
grant drop public synonym to opsware_admin with admin option;
grant select any table to opsware_admin with admin option;
grant select_catalog_role to opsware_admin with admin option;
grant query rewrite to opsware_admin with admin option;
grant restricted session to opsware_admin with admin option;
grant execute on dbms_utility to opsware_admin with grant option;
grant analyze any to opsware_admin;
grant insert, update, delete, select on sys.aux_stats$ to opsware_admin;
grant gather_system_statistics to opsware_admin;
grant create job to opsware_admin;
grant create any directory to opsware_admin;
grant drop any directory to opsware_admin;
grant alter system to opsware_admin;
grant create role to opsware_admin;
grant create user to opsware_admin;
grant alter user to opsware_admin;
grant drop user to opsware_admin;
grant create profile to opsware_admin;
grant alter profile to opsware_admin;
grant drop profile to opsware_admin;

Installing the Model Repository

In most production environments with Oracle RAC, the Model Repository installation can be done from any SA server. The database server or RAC nodes in this case are considered to be remote.

The examples used in the following sections assume this configuration:

Identity	Host Note	Name	Type	Address	Address static or dynamic	Resolved by
Node 1 Public	rac1pub	rac1pub	Public	192.168.173.210	Static	DNS
Node 1 virtual	Selected by Oracle clusterware	rac1-vip	Virtual	192.168.173.212	Static	DNS and/or host file
Node 1 private	rac1pub	rac1prv	Private	172.16.1.100	Static	DNS, hosts file, or none
Node 2 Public	rac2pub	rac2pub	Public	192-168-173-211	Static	DNS
Node 2 virtual	Selected by Oracle clusterware	rac2-vip	Virtual	192.168.173.213	Static	DNS and/or hosts file
Node 2 private	rac2pub	rac2prv	Private	172.16.1.101	Static	DNS, hosts file, or none
SCAN vip 1	Selected by Oracle clusterware	sa_cluster1-scan	Virtual	192.168.173.216	Static	DNS
SCAN vip 2	Selected by Oracle clusterware	sa_cluster1-scan	Virtual	192.168.173.217	Static	DNS
SCAN vip 3	Selected by Oracle clusterware	sa_cluster1-scan	Virtual	192.168.173.218	Static	DNS

 

Model Repository Installation on a Remote Database (truth) RAC Server

In an Oracle RAC environment, only one of the RAC nodes is used during the SA installation/upgrade process. The SA Installer connects to only one Oracle RAC instance to install/modify the Model Repository. During the regular SA operations, all RAC nodes are used.

Perform the following tasks on the SA server on which you will run the SA Installer, for example rac1sa.dev.opsware.com.

Model Repository Hostname Resolution

On the server where you will run the SA Installer, ensure that the Model Repository hostname truth resolves to the remote database server, not to the server on which you will be running the SA Installer:

In /etc/hosts, enter the public IP address of one of the RAC nodes/instances. For example the /etc/hosts file on rac1sa.dev.opsware.com would have the following entry:

192.168.173.210 truth rac1pub rac1pub.dev.opsware.com

If you have set up Oracle Clusterware, you should use the Clusterware IP address rather than a single database node IP address. For example:

192.168.173.216 truth sa_cluster1-scan sa_cluster1-scan.dev.opsware.com

Install the Oracle 11g Full Client on the SA server

Note: For Oracle RDBMS 11.2.0.2, use the Oracle Full Client version 11.2.0.2.

1. The SA Installer will use the Oracle Full Client to connect to the database server and install the Model Repository. Below are sample commands for installing the Oracle full client.

Create user oracle for the Oracle Full Client installation:

root@rac1sa ~]# mkdir -p /u01/app/oracle
root@rac1sa ~]# mkdir -p /u01/app/oraInventory
root@rac1sa ~]# groupadd oinstall
root@rac1sa ~]# groupadd dba
root@rac1sa ~]# useradd -c "Oracle Client software owner" -g oinstall -G
dba -d /u01/app/oracle -s /bin/bash oracle
root@rac1sa ~]# chown -R oracle:oinstall /u01/app
root@rac1sa ~]# chmod -R 775 /u01/app
root@rac1sa ~]#passwd oracle (change oracle user password )

2. Create the .bash_profile file

In /u01/app/oracle create the .bash_profile file.

Temporarily comment out ORACLE_HOME and ORACLE_PATH. You will uncomment these entries after the Oracle client installation is complete.

Sample .bash_profile file

# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi

# User specific environment and startup programs
PATH=$PATH:$HOME/bin
export PATH

#SA-OracleRAC parameters begin
#unset USERNAME
export ORACLE_BASE=/u01/app/oracle
#export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/client_1
#PATH=$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$PATH
export PATH

if [ -t ]; then
stty intr ^C
fi

umask 022

#SA-OracleRAC parameters end

3. Install the Oracle Full Client

Install the Oracle Full Client as described in your Oracle documentation. You can create a share to access the Oracle Full Client binaries.

4. Set Up Terminals

You will need two X window terminals to install the Oracle Full Client:

Terminal 1: log in as root and enter the commands:

Terminal 1> xhost +
Terminal 2: ssh –X oracle@<new_oracle_full_client_host>

5. Start Oracle Full Client installation

From Terminal 2 run the Oracle Universal Installer (OUI) installer. The Oracle Full Client is installed in:

/u01/app/oracle/product/11.2.0/client_1

6. Run the Oracle Universal Installer to install Oracle Full Client. The directories in this example assume an Oracle 11g Full Client on Linux.

a. cd /location_of_oracle_full_client
b. /runInstaller
c. At the Welcome Screen, click Next.
d. Specify the Inventory Directory and Credentials (/u01/app/oraInventory and /u01/app/oinstall)
e. For Select Installation Type, choose Administrator, click Next.
f. For ORACLE_BASE select: /u01/app/oracle, click Next.
g. The Oracle Universal Installer performs some checks. If the checks are not successful, fix the issue and re-run this step. If the checks are successful the click on 'Next'
h. Oracle OUI will list of products that will be installed. Click on 'Install'
i. OUI will show the progress bar when installing
j. On the 'Welcome to Oracle Net Configuration Assistant' window click on 'Next'
k. Click on 'Finish' once the installation is complete.
l. The following two configuration scripts must be executed as "root" upon installation completion:
– /u01/app/oraInventory/orainstRoot.sh
– /u01/app/oracle/product/11.2.0/client_1/root.sh

7. Verify that the .bash_profile file for user oracle is correct.

8. Uncomment $ORACLE_HOME and $ORACLE_PATH.

Making changes to tnsnames.ora on an SA server

By default the tnsnames.ora file is located in /var/opt/oracle.

1. Login as root on the SA Server.
2. Enter the command:

   mkdir -p /var/opt/oracle

3. Copy tnsnames.ora from the remote database server to the directory you created above.

   For the RAC environment, copy tnsnames.ora from RAC Node 1 (for example, rac1pub.dev.opsware.com).

   To accommodate the remote Model Repository installation process, two sets of tnsnames.ora are required on the SA server.

   - tnsnames.ora-install_upgrade – this copy of tnsnames.ora is used during SA installation/upgrade. The file can be renamed.

   - tnsnames.ora-operational – this copy of tnames.ora is used during normal SA operation. The file can be renamed.

   You can use softlinks to point tnsnames.ora to either tnsnames.ora-install_upgrade or tnsnames.ora-operational. For example:

   ln –s tnsnames.ora-install_upgrade tnsnames.ora

tnsnames.ora-install_upgrade sample file

Make a note of the text that is in BOLD letters. These examples have RAC1SA_TRUTH as the truth.servicename. Ensure that the HOST references the same server as the truth entry in /etc/hosts file. truth.servicename is case sensitive.

# tnsnames.ora Network Configuration File: /u01/app/oracle/product/11.2.0/db_2/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.

RAC1SA_TRUTH =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1pub.dev.opsware.com)(PORT = 1521))
(CONNECT_DATA =
(UR=A)
(SERVER = DEDICATED)
(SERVICE_NAME = truth)
)
)

Use softlinks to link the file to tnsnames.ora.ora file. Do this before you start the SA Model Repository installation or upgrade:

ln –s tnsnames.ora-install_upgrade tnsnames.ora

During installation the SA Installer adds a SA Gateway entry into tnsnames.ora (linked to tnsnames.ora.install-upgrade) file on the First SA Core. When installation completes, copy this entry into the tnsname.ora.operational file. If this entry is not present in tnsname.ora.operational, Multimaster Mesh transactions will not flow. Below is a sample gateway entry from tnsnames.ora:

RAC2SA_TRUTH=(DESCRIPTION=(ADDRESS=(HOST=192.168.173.214)(PORT=20002)
(PROTOCOL=tcp))(CONNECT_DATA=(SERVICE_NAME=truth)))

Testing the connection from the SA host to the database

Before starting the Model Repository installation/upgrade, you can perform the following tests to verify that your tnsnames.ora file is configured correctly and if the SA Installer can connect to the database in restricted mode.

1 Verify that the SA server's /var/opt/oracle/tnsnames.ora file is configured correctly as described in Making changes to tnsnames.ora on an SA Server.

2 On the SA server:

a. Login as oracle or root or su – twist/spin – if these users exist
b. export ORACLE_HOME=/u01/app/oracle/product/11.2.0/client_1 (or where you installed the Oracle Full Client)
c. export LD_LIBRARY_PATH=$ORACLE_HOME/lib
d. export TNS_ADMIN=/var/opt/oracle
e. set $PATH $ORACLE_HOME/bin path
f. sqlplus sys/password@RAC1SA_TRUTH as sysdba;
where RAC1SA_TRUTH is the service_name or entry from the tnsnames.ora file
g connect opsware_admin/<password>@RAC1SA_TRUTH
If you are able to logon to the database then all files are configured correctly.

SA Installer Response File

You can now start the installation of the SA Model Repository. Ensure that you have the correct parameters values for the installation interview or that you have a previous response file.

Verify the paths to the client's tnsnames.ora file (%truth.tnsdir), oracle client home
(%db.orahome), database server name/IP (%db.host), listener port (%db.port), and so on.

- %db.sid: truth1 (Oracle SID of the instance where SA installer is going to connect to.)

- %db.orahome: /u01/app/oracle/product/11.2.0/client_1

- %db.port: 1521

- %db.host: 192.168.173.210 (server where Oracle RDBMS is installed)

- %truth.servicename: rac1sa_truth (value of service name from tnsnames.ora file)

You can now install the SA Core as described in the SA Simple/Advanced Installation Guide.

Post SA installation process

After you install the SA Core, perform the following tasks in order to use all the nodes in the Oracle RAC environment.

Making changes to tnsnames.ora on the SA server

After SA install is complete, the tnsnames.ora file should point/link to the tnsnames.ora-operational file.

In an Oracle RAC environment, only one of the RAC nodes or instances is used during the installation/upgrade process. The SA Installer connects to only one Oracle instance to modify the Model Repository. During the normal SA operations, all the RAC nodes are used. To accommodate the remote truth installation process, two sets of tnsnames.ora are required on
the SA server.

- tnsnames.ora-install_upgrade – this copy of tnsnames.ora is used during SA installation/upgrade. You can rename the file.

- tnsnames.ora-operational – this copy of tnames.ora is used during normal SA operation. You can rename the file.

You can use softlinks to point tnsnames.ora to either tnsnames.ora-install_upgrade or
tnsnames.ora-operational:

ln –s tnsnames.ora-operational tnsnames.ora

tnsnames.ora-operational sample file

Note: If you have set up Oracle Clusterware, you should use the Clusterware IP address rather than a single database node IP address.

Make a note of the text that is in BOLD letters. This tnsnames.ora file is used during normal SA operation and contains the RAC parameters.

If you have set up Oracle Clusterware, use the following:

#This entry is for connecting to RAC virtual machines. This entry is used by SA during operation of SA.

RAC1SA_TRUTH =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = sa_cluster1-scan)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = truth)
(FAILOVER_MODE =
(TYPE = SELECT)
(METHOD = Preconnect)
(RETRIES = 180)
(DELAY = 5))
)
)

#This entry is for connecting to node2 via service_name. This is for DBA convenience. This is not used by SA.
TRUTH2 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2pub.dev.opsware.com)(PORT = 1521))
(CONNECT_DATA =
(UR=A)
(SERVER = DEDICATED)
(SERVICE_NAME = truth)
)
)

#This entry is for connecting to node1 via service_name. This is for DBA convenience. This is not used by SA.
TRUTH1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1pub.dev.opsware.com)(PORT = 1521))
(CONNECT_DATA =
(UR=A)
(SERVER = DEDICATED)
(SERVICE_NAME = truth)
)
)

#This entry is added by SA and is used by SA during regular operation.
RAC2SA_TRUTH=(DESCRIPTION=(ADDRESS=(HOST=192.168.173.214)
(PORT=20002)
(PROTOCOL=tcp))
(CONNECT_DATA=(SERVICE_NAME=truth)))

If you have not set up Oracle Clusterware, use the following:

#This entry is for connecting to RAC virtual machines.
TRUTH =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip.dev.opsware.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip.dev.opsware.com)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = truth)
(FAILOVER_MODE =)
(TYPE = SELECT)
(METHOD = Preconnect)
(RETRIES = 180)
(DELAY = 5))
)
)
LISTENERS_TRUTH =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip.dev.opsware.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip.dev.opsware.com)(PORT = 1521))
)
#This entry is for connecting to node2 via service_name. This entry is
optional
TRUTH2 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip.dev.opsware.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = truth)
(INSTANCE_NAME = truth2)
)
)
LISTENER_TRUTH2 =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip.dev.opsware.com)(PORT = 1521))

#This entry is for connecting to node1 via service_name. This entry is
optional
TRUTH1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip.dev.opsware.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = truth)
(INSTANCE_NAME = truth1)
)
)
LISTENER_TRUTH1 =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip.dev.opsware.com)(PORT = 1521))

Use softlinks to link the file to tnsnames.ora.ora file after SA installation is complete and you are ready to start SA in operational mode.

ln –s tnsnames.ora- operational tnsnames.ora

During installation, the SA Installer adds an SA Gateway entry into tnsnames.ora (linked to
tnsnames.ora.install-upgrade) file on the First SA Core. When installation is complete, copy that entry into tnsname.ora.operational. If this entry is not present in the tnsname.ora.operational, Multimaster Mesh transactions will not flow. The following is a sample gateway entry from tnsnames.ora:

Rac2sa_truth=(DESCRIPTION=(ADDRESS=(HOST=192.168.173.214)(PORT=20002)(PROTOCO
L=tcp))(CONNECT_DATA=(SERVICE_NAME=truth)))

Vault.conf File Changes

Note: If you have set up Oracle Clusterware, you should use the Clusterware IP address rather than a single database node IP address.

In an Oracle RAC environment, the vault.conf file must be modified after SA installation is complete. Modify /etc/opt/opsware/vault/vault.conf to specify the complete tnsname definition instead of the SID. For example:

If you have set up Oracle Clusterware, use the following:

Before:
truth.sid: truth1

After:
#truth.sid: truth1
truth.sid: (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = sa_cluster1-scan)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =(SERVER = DEDICATED)
(SERVICE_NAME = truth)
(FAILOVER_MODE = (TYPE = SELECT)
(METHOD = Preconnect)(RETRIES = 180)(DELAY = 5))))

If Oracle Clusterware is not setup, use the following:

db.sid:(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST =
rac1-vip.dev.opsware.com)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)
(HOST = rac2-vip.dev.opsware.com)(PORT = 1521)) (LOAD_BALANCE = yes)
(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = truth)
(FAILOVER_MODE = (TYPE = SELECT) (METHOD = Preconnect) (RETRIES = 180)
(DELAY = 5))))

db.port: 1521

Also, ensure that these values are correct:
truth.port: 1521
truth.host: 192.168.173.210 (database server IP)
truth.servicename: rac1sa_truth (tnsnames.ora enter)

- Restart the vaultdaemon:

/etc/init.d/opsware-sas restart vaultdaemon

Changing the da.conf Configuration File

In SA 9.10, the Application Deployment Manager reads database connection information from the tnsnames.ora file.

In SA 9.0 and 9.0x, the default was SID =Truth unless changed by the user, for example, in /etc/opt/opsware/da/da.conf:

truth.sid=truth1 (this is the Oracle SID of the instance on RAC node)

Changes to /opt/opsware/oi_util/startup/opsware_start.config

Note: If you have set up Oracle Clusterware, you should use the Clusterware IP address rather than a single database node IP address.

- #TRUTH_HOST="192.168.173.210"

- TRUTH_HOST="sa_cluster1-scan.dev.opsware.com" (use Oracle cluster IP, if changes to /etc/hosts )

Upgrading the Model Repository

To upgrade the Model Repository in an Oracle RAC environment, follow the same procedure as Installing the Model Repository. If you are doing a remote database installation, ensure that you modify your tnsnames.ora on the server where the SA Installer is run. It is recommended that you test the connection as suggested in section Testing the connection from the SA host to the database.

SA 9.10 User Guide: Server Patching

In chapter 4: Patch Management for Solaris, page 108, Fujitsu Clusters, SA Commands, replace the following statement:

Use the following command to display additional information about cluster commands:
/opt/opsware/solpatch_import -manual

With this statement:

Use the following command to display additional information about cluster commands:
/opt/opsware/solpatch_import/bin/solpatch_import --manual

Support Matrix

Please note the following documentation errors:

• AIX 5.2 was previously listed as a supported platform for the SSI feature. The SSI feature is not compatible with AIX 5.2.
• French locale support for the following platforms was not listed in the 9.10.01 and 9.10.02 matrices. French locales have been supported on these platforms since 9.10:
  
  Managed Servers:
  HP-UX 11iv3 (11.31) IA_64              
  SuSE Linux Enterprise Server 11 GA-SP1,  x86_32/x86_64      
  SuSE Linux Enterprise Server 10 GA-SP3,  x86_32/x86_64
  
  Core Servers and Satellites:
  SLES 10 SP2-SP3, x86_64

Back to the Table of Contents

HP Software Support

This web site provides contact information and details about the products, services, and support that HP Software offers. For more information, visit the HP Support web site at: HP Software Support Online.

HP Software support provides customer self-solve capabilities. It provides a fast and efficient way to access interactive technical support tools needed to manage your business. As a valued support customer, you can benefit by being able to:

• Search for knowledge documents of interest
• Submit and track progress on support cases
• Submit enhancement requests online
• Download software patches
• Manage a support contract
• Look up HP support contacts
• Review information about available services
• Enter discussions with other software customers
• Research and register for software training

To access the Self-Solve knowledge base, visit the Self-Solve knowledge search home page.

Note: Most of the support areas require that you register as an HP Passport user and sign in. Many also require an active support contract. To find more information about support access levels, go to: Access levels.

To register for an HP Passport ID, go to: HP Passport Registration.

Legal Notices

Warranty

The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

The information contained herein is subject to change without notice.

Restricted Rights Legend

Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license.

Copyright Notices

© Copyright 2000-2012 Hewlett-Packard Development Company, L.P.

Trademark Notices

Adobe® is a trademark of Adobe Systems Incorporated.
Intel® and Itanium® are trademarks of Intel Corporation in the U.S. and other countries.
Microsoft®, Windows®‚ Windows® XP are U.S. registered trademarks of Microsoft Corporation.
Oracle and Java are registered trademarks of Oracle and/or its affiliates.
UNIX® is a registered trademark of The Open Group.

Release-Notes Updates

To check for recent updates or to verify that you are using the most recent edition of a document, go to:
http://support.openview.hp.com/selfsolve/manuals

This site requires that you register for an HP Passport and sign in.
Or click the New users - please register link on the HP Passport login page. You will also receive updated or new editions if you subscribe to the appropriate product support service.

Contact your HP sales representative for details.

Back to the Table of Contents