| Oracle® Access Manager Upgrade Guide 10g (10.1.4.3) Part Number E12495-01 |
|
|
View PDF |
| Oracle® Access Manager Upgrade Guide 10g (10.1.4.3) Part Number E12495-01 |
|
|
View PDF |
This appendix describes how you can upgrade an earlier Oracle Access Manager component installation that resides on a Solaris platform to Oracle Access Manager 10g (10.1.4.0.1) while migrating the component to a Linux platform. The topics in this chapter include:
Oracle has developed a methodology and a set of procedures that you can use when you want to switch from a Solaris platform to a Linux platform as you upgrade an earlier Oracle Access Manager component. For example, you can upgrade Oracle Access Manager release 6.1.1 components running on Solaris to release 10g (10.1.4.0.1) running on Linux. This methodology allows the upgraded component on the Linux platform to access the same LDAP directory server as the original component on the Solaris platform.
Your deployment most likely includes Oracle Access Manager components on other platforms in addition to Solaris (a heterogeneous deployment). For example, you might be running Oracle Access Manager Identity and Access Servers on Solaris with Oracle Access Manager Web components running on other platforms. The steps in this appendix apply only to the Solaris components that you will migrate to a Linux platform during the upgrade.
The discussion "About the Execution Stage for In-Place Upgrades" provides a high-level view of the upgrade tasks that you must perform, and the order in which these tasks must be completed for an in-place upgrade. The platform switch from Solaris to Linux while upgrading is similar to other in-place upgrades. You perform planning activities, schema and data preparation and upgrades, and component and customization preparation and upgrades. You upgrade and perform the switch as described in this appendix. Troubleshooting tips and techniques are the same for this type of upgrade as for other in-place upgrades. An upgrade with platform switch only involves making the Solaris source installation directory available on the Linux platform, running the obmigratenp tool two times for each component as described here, then performing a few reconfigurations due to platform switch. After the upgrade, component validation is the same for this type of upgrade as for other in-place upgrades.
Note:
You cannot use the zero downtime upgrade method when performing a switch from a Solaris platform to a Linux platform. Instead, upgrade while making the switch as described in this appendix and then apply the latest patch to installed components. For more information, see "Applying the Latest Patch Set".Task overview: Upgrading a component while switching from Solaris to Linux
Perform planning activities as usual:
Perform the schema and data upgrade as follows:
Prepare for the schema and data upgrade as described in Chapter 5 with the following exception: Do not install master 10g (10.1.4.0.1) Identity Server, WebPass, and Policy Manager components, which are not needed because the 10g (10.1.4.0.1) components you install on the Linux host will server the same purpose.
Upgrade the Identity System schema as described in Chapter 6.
Joint Identity and Access System: Upgrade the Access System schema and data as described in Chapter 7.
Prepare all remaining earlier Oracle Access Manager components as described in Chapter 8.
Prepare the intended Linux hosts as described in "Prerequisites and Preparation", which includes:
Upgrade Identity System components as described in "Upgrading Identity System Components while Switching to Linux" , which includes:
Joint Identity and Access System: Upgrade Access System components as described in "Upgrading Access System Components while Switching to Linux", which includes:
Perform remaining upgrade activities as described in:
Verify that the upgrade was successful using procedures for all upgrades in Chapter 14.
Refer to troubleshooting tips in Appendix G as needed.
When upgrading with a switch from Solaris to Linux, you perform tasks in the same order as you would for other in-place upgrades. However, during an upgrade with a switch from Solaris to Linux, you use the obmigratenp tool that is available with the Oracle Access Manager 10g (10.1.4.0.1) component that you install on the Linux host.
When you run obmigratenp without any parameters, the command prints the meaning of all input parameters. For specific information about obmigratenp and other utilities, see Appendix C. The obmigratenp tool is located in the following directory:
Component_install_dir\identity|access\oblix\tools\migration_tools\obmigratenp
When upgrading with a switch from Solaris to Linux, you specify Confirmed mode when asked so that you can skip certain steps. For instance, upgrades with a switch from Solaris to Linux you must skip Web server configuration updates for Oracle Access Manager Web component and schema and data upgrades. For more information about Confirmed mode, see "Confirmed Mode".
To upgrade with a switch to Linux from Solaris, you invoke the obmigratenp tool twice for each component, as follows:
The first invocation creates the orig folders and performs message catalog migration using a command.
obmigratenp -c <component> -f <from_version> -t <to_version> -s <old_version_Solaris_directory> -d <new_version_Linux_directory> -i <new_version_LINUX_directory> -u <user_name> -g <group_name> -l <comma_separated_list_of_languages_installed>
The user_name and group_name values should be the same as those specified while installing the component on the Linux platform. The -d parameter indicates the destination directory (the new version directory) and -i specifies the directory from which the obmigratenp tool is being invoked. Typically -d and -i have the same value. For example, the first invocation for an Identity Server upgrade might look like the following sample:
obmigratenp -c ois -f 611 -t 1014
-s /usr/temp/611/identity -d /usr/temp/1014/identity
-i /usr/temp/1014/identity -u <gtiberi> -g <admin>
-l en-us
The second invocation upgrades everything other than the orig folder and message catalog migration. This will involve parameter catalogs, schema, data, component-specific details, registry details (if applicable), and Web server configuration. The second invocation takes the form:
obmigratenp -c <component> -f <from_version> -t <to_version> -s <old_version_Solaris_directory> -d <new_version_Linux_directory> -i <new_version_Linux_directory> -u <user_name> -g <group_name>
An example of the second invocation for an Identity Server component might look like the following:
obmigratenp -c OIS -f 611 -t 1014 -s /usr/temp/611/identity
-d /usr/temp/1014/identity -i /usr/temp/1014/identity -u <gtiberi>
-g <admin>
Discussions in this section describe considerations you should take into account before performing an upgrade while switching from a Solaris platform to a Linux platform:
This topic provides considerations for Identity Server and Policy Manager components when preparing for and switching from Solaris to Linux.
The LDAP server contains the earlier release of the Oracle Access Manager schema, which must be upgraded. If you intend to switch to a Linux platform from Solaris during an Identity Server upgrade, do not upload the schema using the component installer. Instead, select No when asked "Is this the first Identity Server installation in the network for this LDAP directory server?"
For Policy Manager, answer No when asked if you want to update the schema automatically when installing on the Linux host.
To summarize these considerations:
When installing a 10g (10.1.4.0.1) Identity Server on Linux, select No when asked if this is "... the first Identity Server installation in the network for this LDAP directory server?".
When upgrading an Identity Server with a platform switch, accept the schema and data changes.
When installing a 10g (10.1.4.0.1) Policy Manager on Linux, select No when asked if you want to automatically update the schema now.
When upgrading a Policy Manager with a platform switch, accept the schema and data changes
For Oracle Access Manager Web components, the earlier Web server instance for Solaris will not be used. You must install a new Web server instance on the Linux platform before starting the upgrade. This new Web Server for Linux will replace the Web server for Solaris that currently operates with the earlier component.
When installing Oracle Access Manager Web components on a Linux computer, you must update the Web server configuration. However during the Web component upgrade, use Confirmed mode and skip the Web server configuration update when you are asked.
To summarize the considerations for Web components:
When installing 10g (10.1.4.0.1) Oracle Access Manager Web components on a Linux host, select the automatic Web server configuration update option.
During the upgrade, use Confirmed mode and skip the Web server configuration update.
Do not perform a manual Web server configuration update.
This section describes the activities that you must perform before you start upgrading with a switch from Solaris to Linux.
Task overview: Preparing your environment for the upgrade with a switch to Linux
Installing Oracle Access Manager 10g (10.1.4.0.1) Components on the Linux Host
Making Earlier Installation Directories on Solaris Available to the Linux Host
Before you start the upgrade, be sure to validate that your Linux platform is supported for Oracle Access Manager 10g (10.1.4.0.1) and that the system is operating properly.
You must download additional GCC run-time libraries (libgcc_s.so.1 and libstdc++.so.5) that are compatible with GCC 3.3.2 and specify the location of these on the local host while installing Oracle Access Manager components.
Finally, a Web server instance is required for use with Oracle Access Manager 10g (10.1.4.0.1) Web components only. After the upgrade and switch to Linux from Solaris, the Linux Web server instance will replace the Web server instance currently in use on the Solaris platform. Ensure that you have write permissions to the new Web server configuration files on Linux.
To prepare and validate your Linux system
Confirm that your Linux system and Web server instance are supported for Oracle Access Manager 10g (10.1.4.0.1) on the Oracle Access Manager platform support matrix, as follows:
Go to Oracle Technology Network:
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
Locate Oracle Identity and Access Management, and then click the link for the latest release. For example:
System Requirements and Supported Platforms for Oracle Access Manager 10gR3 (xls)
Install additional libraries (libgcc_s.so.1 and libstdc++.so.5) on each Linux host, as follows:
Obtain the zip file from the site shown here:
http://download.oracle.com/otn/linux/ias/1012/as_linux_x86_gcc_runtime_lib_704.cpio
Extract the following files to the local Linux computer on which you will install one or more Oracle Access Manager components:
libgcc_s.so.1
libstdc++.so.5
During Oracle Access Manager installation, specify the location of the libraries on the local computer and continue the installation.
Install a Web server instance on each Linux system that will host Oracle Access Manager Web components:
Using your Web server vendor documentation as a guide, add a supported Web server instance to your Linux system for use with Oracle Access Manager.
Verify that you have write permissions to Web server configuration files on your Linux system.
Note:
When installing Oracle Access Manager Web components with Oracle HTTP Server Web server (or Apache) you are prompted to install as the same user under which the Web server is running. This information is located in the httpd.conf file in the User and Group directive entries. For more information, see the Oracle Access Manager Installation Guide.Proceed to "Installing Oracle Access Manager 10g (10.1.4.0.1) Components on the Linux Host".
Before you begin upgrading, you must install Oracle Access Manager 10g (10.1.4.0.1) on the Linux host computer as outlined in the following task overview. When your earlier installation includes languages other than English, this additional instance should be installed with the same Language Packs as the original. This 10g (10.1.4.0.1) installation on Linux provides a foundation for the earlier installation that you will upgrade on Solaris.
The WebGate can be installed to use the same Web server instance as WebPass and Policy Manager to protect these components. If you install the WebGate to protect a Policy Manager and WebPass, the WebGate must be installed in the same directory as the Policy Manager. For example, if the Policy Manager is installed in \COREid\access\WebComponent, then the WebGate must also be installed there. Other than this, the new installation does not need to mirror the earlier one on Solaris with respect to path names and directory levels.
Note:
Oracle recommends that you automatically update your Web server configuration file for Oracle Access Manager using the automatic option to avoid errors.Setup and Validation Caveats: After installation, you can start the 10g (10.1.4.0.1) Identity Server service on the Linux host to ensure that it is operational. After WebPass installation you can establish communication between the Identity Server and WebPass as described in the Oracle Access Manager Installation Guide. However, do not set up the 10g (10.1.4.0.1) Identity System that you installed on the Linux host. This setup will be migrated from the Solaris host during upgrade. As a result, you will not be able to start the 10g (10.1.4.0.1) Identity System to verify that your Identity Server and WebPass are working together until after the upgrade and switch from Solaris.
There is a similar caveat after installing the 10g (10.1.4.0.1) Policy Manager on a Linux host. The upgraded Policy Manager setup will be migrated from the Solaris host. Do not set up the 10g (10.1.4.0.1) Policy Manager after installation. For complete installation prerequisites and other details, see the Oracle Access Manager Installation Guide.
Note:
The path names used here are for illustration only. Your path names will differ.Task overview: Installing Oracle Access Manager on the Linux host
Perform all prerequisites mentioned in this chapter.
Identity Server: Install the Oracle Access Manager 10g (10.1.4.0.1) Identity Server on the Linux host, as follows:
Specify a new installation directory. For example: /user/temp/1014/identity
Answer No when asked if this is the first Identity Server installation for this LDAP directory server.
After installation, ensure that the Identity Server service is running.
WebPass: Install the Oracle Access Manager 10g (10.1.4.0.1) WebPass in a new directory. For example: usr/temp/1014/webpass/identity.
Note:
Do not set up the Identity System.Policy Manager: After installing a new Web server instance on this computer, install the Oracle Access Manager 10g (10.1.4.0.1) Policy Manager in a new directory (usr/temp/1014/policymanager/access, for example), and specify the path to the same Web server instance that is used by the new WebPass.
Note:
Do not set up the Policy Manager.Access Server: Install the Oracle Access Manager 10g (10.1.4.0.1) Access Server in a new directory. For example: /user/temp/1014/access
WebGate: Install the Oracle Access Manager 10g (10.1.4.0.1) WebGate in a new directory (usr/temp/1014/webgate/access, for example) and specify the path to the same Web server instance used by the new WebPass.
Repeat as needed to provide an upgrade foundation for each earlier Oracle Access Manager component instance.
Validate that the 10g (10.1.4.0.1) Identity and Access System are operating properly, as described in the Oracle Access Manager Installation Guide.
You are ready to perform activities in "Making Earlier Installation Directories on Solaris Available to the Linux Host".
You must ensure that the directories for earlier components on Solaris are available to the Linux host for the upgrade process. There are two options to achieve this:
On the Solaris computer:
Tar the earlier component installation directory, then
FTP the earlier directory to the Linux computer where the latest version of the same component will be installed.
Cross mount the install folder from the Solaris computer on the Linux computer.
You are ready to finish preparation.
Table B-1 provides a list of prerequisite activities that should be performed on earlier components before you begin upgrading with a switch to Linux. After performing activities outlined in Table B-1, you can finish prerequisite activities in this chapter to prepare the Linux host that will be involved in the switch from Solaris.
Table B-1 Prerequisites for Upgrading Oracle Access Manager Components with a Switch from Solaris to Linux
| Perform the following Activities as Described in Chapter 8 |
|---|
|
Backing Up File System Directories, Web Server Configurations, and Registry Details Note: Perform this activity on both the earlier release running on Solaris and the latest release running on Linux. |
When all prerequisites are completed, you are ready to proceed with the upgrade task and platform switch.
Topics that follow should be performed in order:
Note:
The commands in this section use the sample installation path names from "Installing Oracle Access Manager 10g (10.1.4.0.1) Components on the Linux Host". Your path names will differ.For details about the obmigratenp tool, see Appendix C.
You perform the following steps to upgrade each earlier Identity Server on Solaris while switching to the Linux platform.
Note:
The exact commands must reflect your specific Identity Server deployments. Ensure that you have access to the earlier directory, as described in "Making Earlier Installation Directories on Solaris Available to the Linux Host".To upgrade the Identity Server while switching to Linux from Solaris
Locate the obmigratenp tool on the Linux host where you installed the Oracle Access Manager 10g (10.1.4.0.1) component.
usr/temp/1014//identity/oblix/tools/migration_tools/obmigratenp
Using appropriate path names for your Identity Servers, run the obmigratenp tool using a command that takes the following form:
obmigratenp -c ois -f 611 -t 1014
-s /usr/temp/611/identity -d /usr/temp/1014/identity
-i /usr/temp/1014/identity -u <user_name> -g <group_name>
-l en-us
The user_name and group_name values should be the same as those specified while installing the component on the Linux platform. For example:
Using appropriate path names for your Identity Servers, run the obmigratenp tool a second time as follows:
obmigratenp -c OIS -f 611 -t 1014 -s /usr/temp/611/identity
-d /usr/temp/1014/identity -i /usr/temp/1014/identity -u <user_name>
-g <group_name>
Auditing and Access Reporting: If your earlier installation included auditing and access reporting, go immediately to "Upgrading Auditing and Access Reporting for the Identity System" before performing step 5.
On the Linux host, verify that the Identity Server upgrade was successful.
Start the Identity Server service to confirm that it will start (notice that the name has not changed from the one originally assigned).
Identity Server Service Does Not Start: Confirm that you have performed all tasks and specified all information accurately. Check Identity Server migration log files for any errors reported during the upgrade and look for troubleshooting tips in Appendix G.
Upgrade Not Successful: See "Recovering From an Identity Component Upgrade Failure".
Upgrade Successful: Backup the instance as described in "Backing Up Upgraded Identity Component Information", then repeat these steps to upgrade every earlier Identity Server instance in your environment, before upgrading WebPass nastiness.
You perform the following steps to upgrade each earlier WebPass on Solaris while switching to the Linux platform.
Note:
The exact commands must reflect your specific WebPass deployments. Ensure that you have access to the earlier component as described in "Making Earlier Installation Directories on Solaris Available to the Linux Host".To upgrade WebPass while switching to Linux from Solaris
Locate the obmigratenp tool on the Linux host where you installed the Oracle Access Manager 10g (10.1.4.0.1) component.
Using appropriate path names for your WebPass instances, run the obmigratenp tool using a command that takes the following form:
obmigratenp -c wp -f 611 -t 1014 -s /usr/temp/611/webpass/identity
-d /usr/temp/1014/webpass/identity -i /usr/temp/1014/webpass/identity
-u <user_name> -g <group_name> -l en-us
The form is based on your specific WebPass example. However it uses a different directory structure.
Using appropriate path names for your WebPass instances, run the obmigratenp tool a second time as follows:
obmigratenp -c OIS -f 611 -t 1014 -s /usr/temp/611/webpass/identity
-d /usr/temp/1014/webpass/identity -i /usr/temp/1014/webpass/identity
-u <user_name> -g <group_name>
Verify that the WebPass upgrade was successful on the Linux host.
Stop, then restart the associated Identity Server service on the Linux host.
Start the WebPass Web server instance on the Linux host.
Web Server Does Not Start: Check the log files for any errors reported during the upgrade and look for troubleshooting tips in Appendix G.
Upgrade Not Successful: See "Recovering From an Identity Component Upgrade Failure".
Upgrade Successful: Back up this instance as described in "Backing Up Upgraded Identity Component Information",then upgrade every WebPass instance in your environment.
After upgrading all WebPass instances, proceed to "Finishing the Identity System Upgrade After Switching to Linux".
Using the procedures described in this chapter, your earlier Oracle Access Manager customizations are preserved. This implies that certain deployment-specific settings were carried over from the Solaris deployment to the Linux deployment. For example, the Identity Server host name and port. Following the upgrade, you must establish new deployment connections to ensure that the upgraded Oracle Access Manager Web components (WebPass) communicate with the Oracle Access Manager servers on Linux, not the earlier Web servers on Solaris.
Depending on the components you have upgraded, you must perform the following activities to finish your Identity System upgrade with a switch to Linux:
After upgrading the Identity Server with a switch to Linux, you must copy the ois_server_config.xml.bak from the original source directory on Solaris to the target directory on the Linux host. Also, you must modify the DNS host name of the Identity Server and the port to match the Linux server DNS host name and port. These changes are to be made in the configuration file. The following sample configuration file segment shows the parameters and values that you must change:
<? xml version="1.0" encoding="utf-8"?>
<ValNameList xmlns="http://www.oblix.com" ListName="ois_server_config.xml">
<NameValPair ParamName="OISServerID" Value="XXXX"></NameValPair>
<NameValPair ParamName="port" Value="YYYY"></NameValPair>
<NameValPair ParamName="security" Value="cert"></NameValPair>
<NameValPair ParamName="hostname" Value="<machine_name>"></NameValPair>
</ValNameList>
In the sample segment, you change the value of ParamName="OISServerID" to that of the Identity Server on the Linux host; the value of ParamName="port" is the port number on which the Identity Server listens; the value of ParamName="security" is either cert, simple or open; the value of ParamName="hostname" is the DNS host name of the Linux host.
To reconfigure an upgraded Identity Server for its Linux host
Locate the ois_server_config.xml.bak file in the following directory on the Solaris host:
oam1014/identity/oblix/config/ois_server_config.xml.bak
In the path, oam1014 refers to the Identity Server installation directory on the Solaris host (also known as IdentityServer_install_dir.
Copy the file as follows:
Rename the file on the Linux host to:
From: ois_server_config.xml.bak
To: ois_server_config.xml
On the Linux host: Open ois_server_config.xml and modify the values of parameters to reflect the Identity Server name, listening port, security, and Linux host in the configuration file:
<? xml version="1.0" encoding="utf-8"?>
<ValNameList xmlns="http://www.oblix.com" ListName="ois_server_config.xml">
<NameValPair ParamName="OISServerID" Value="XXXX"></NameValPair>
<NameValPair ParamName="port" Value="YYYY"></NameValPair>
<NameValPair ParamName="security" Value="cert"></NameValPair>
<NameValPair ParamName="hostname" Value="<machine_name>"></NameValPair>
</ValNameList>
Start the Identity Server service on the Linux host.
Validate that the Identity Server service on Linux is communicating with the WebPass on Linux as follows:
Restart the Web server on Linux and access the URL to your Identity System Console. For example, http://hostname:port/identity/oblix
Login and verify that the Identity Server on Linux is communicating with the WebPass on Linux.
After finishing the steps here on each Linux host involved in the switch, proceed to "Reconfiguring WebPass To Communicate with the Identity Server on Linux".
This topic includes the procedure that you use to reconfigure the upgraded WebPass instances to communicate with the upgraded Identity Servers after switching to Linux. As described here, you change the refresh parameter in the webpass.xml file to false. You then restart WebPass and enter the Identity System Console where you update the host name and port of Identity Servers as needed that were upgraded and switched to Linux. You finish by restoring the refresh parameter in the webpass.xml file to true and restarting the Web server.
To reconfigure WebPass to communicate with an upgraded Identity Server on Linux
Locate the webpass.xml file in the WebPass Web component installation directory on the Linux host. For example:
oam1014\webcomp\nsapi\identity\oblix\apps\webpass\bin\webpass.xml
In the path name, oam1014\webcomp\nsapi refers to the directory where the Oracle Access Manager WebPass for a Sun (formerly Netscape/iPlanet) Web server resides. This portion of the path name is also known as WebPass_install_dir.
Open the webpass.xml file in an editor and change the value of the refresh parameter to False, then save the file:
<SimpleList>
<NameValPair ParamName="refresh" Value="false" />
</SimpleList>
Restart the WebPass Web server.
Go to the Identity System Console by specifying the appropriate URL for your deployment in your browser. For example:
http://hostname:port/identity/oblix
In the sample URL, hostname refers to computer that hosts the WebPass Web server; port refers to the HTTP port number of the WebPass Web server instance; /identity/oblix connects to the Identity System Console. The main product page should appear with links to Identity System applications.
Proceed as follows:
Landing Page Appears—Proceed with step 6.
Landing Page Does Not Appear—See troubleshooting tips in Appendix G and "Recovering From an Identity Component Upgrade Failure".
Select Identity System Console, then login as a user with administrator privileges:
Login Successful—Proceed with step 7.
Login Not Successful—Ensure that you have logged in as a user with the proper credentials (Master Administrator or Master Identity Administrator).
Update Identity Server details as follows:
In the Identity System Console, click System Configuration, then select Identity Servers.
Click the name of an Identity Server to modify its parameters.
Click the Modify button at the bottom of the page.
Edit the following parameters on the Modify Identity Server page as needed:
Hostname: Enter the name of the computer on which the Identity Server is running.
Port: Enter the port number on which the Identity Server is listening.
Click the Save button at the bottom of the Modify Identity Server page.
Restart the Identity Server.
Repeat as needed for each Identity Server whose host has changed.
Open the webpass.xml file in an editor and change the value of the refresh parameter to False, then save the file:
<SimpleList>
<NameValPair ParamName="refresh" Value="true" />
</SimpleList>
Restart the WebPass Web server.
Proceed to "Validating and Backing up the Upgraded Identity System".
Oracle recommends that you first validate your Identity System upgrade and then back up the upgraded component details. For details, see the following topics:
Note:
These are the same procedures that appear in Chapter 9 and are intended to be used after upgrading all Identity System components.It is a good idea to quickly validate the following items to ensure that the overall Identity System upgrade was successful. You can perform a more extensive tests to validate your Identity System upgrade as described in Chapter 14.
To confirm your Identity System upgrade
Make sure your Identity Server service and WebPass Web server instance are running.
Check that your message and parameter catalog customizations have been preserved. For example, if you have changed any message in a particular message catalog file, then it needs to be retained.
Proceed to "Backing Up Upgraded Identity Component Information".
As mentioned earlier, Oracle recommends that you finish each component upgrade by backing up the upgraded component directory. This will enable you to easily restore your environment to the newly upgraded state should that be needed.
To back up critical information after the upgrade
Back up the latest Identity Server and WebPass component directories on Linux and store these in a new location.
WebPass Web Server: Back up the upgraded Web server configuration file, if required, using instructions from your vendor.
Proceed as follows:
Identity System Only: Upgrade the software developer kit (SDK) as described in Chapter 11 and then upgrade your Identity System customizations as described in Chapter 12.
Joint Identity and Access System: Perform activities in "Upgrading Access System Components while Switching to Linux" before upgrading the software developer kit (SDK).
If you do not have a joint Identity and Access System deployment, you can skip this section and proceed instead to Chapter 11 to upgrade the software developer kit (SDK).
After upgrading the Identity System components, you are ready to proceed with the Access System upgrade and platform switch. Activities that follow should be performed in order:
Note:
The commands in this section use the sample installation path names from "Installing Oracle Access Manager 10g (10.1.4.0.1) Components on the Linux Host". Your path names will differ.For details about the obmigratenp tool, see Appendix C.
You perform the following steps to upgrade each earlier Policy Manager (formerly known as the Access Manager component) on Solaris while switching to the Linux platform.
Note:
The exact commands must reflect your specific Policy Manager deployments. Ensure that you have access to the earlier component directory, as described in "Making Earlier Installation Directories on Solaris Available to the Linux Host".To upgrade the Policy Manager while switching to Linux from Solaris
Locate the obmigratenp tool on the Linux host where you installed the Oracle Access Manager 10g (10.1.4.0.1) component.
Using appropriate path names for your Policy Managers, run the obmigratenp tool using a command that takes the following form:
obmigratenp -c am -f 611 -t 1014
-s /usr/temp/611/am/access -d /usr/temp/1014/policyManager/access
-i /usr/temp/1014/policyManager/access -u <user_name> -g <group_name>
-l en-us
Using appropriate path names for your Policy Managers, run the obmigratenp tool a second time as follows:
obmigratenp -c am -f 611 -t 1014 -s /usr/temp/611/am/access
-d /usr/temp/1014/policyManager/access -i /usr/temp/1014/policyManager
/access -u <user_name> -g <group_name>
Verify that the upgrade was successful, as follows:
Policy Manager Web Server Does Not Start: Check the Policy Manager migration log files for any errors reported during the upgrade and see troubleshooting tips in Appendix G.
Upgrade Successful: Perform activities in "Backing Up Upgraded Access System Component Directories" for this instance, then continue upgrading remaining Policy Managers.
Upgrade Not Successful: See Proceed to "Recovering From an Access System Upgrade Failure".
When all Policy Managers are upgraded, proceed with "Upgrading Access Servers while Switching to Linux".
You perform the following steps to upgrade each earlier Access Server on Solaris while switching to the Linux platform.
Note:
The exact commands must reflect your specific Access Server deployments. Ensure that you have access to the component installation directory on Solaris, as described in "Making Earlier Installation Directories on Solaris Available to the Linux Host".To upgrade the Access Server while switching to Linux from Solaris
Locate the obmigratenp tool on the Linux host where you installed the Oracle Access Manager 10g (10.1.4.0.1) component.
Using appropriate path names for your Access Servers, run the obmigratenp tool using a command that takes the following form:
obmigratenp -c aaa -f 611 -t 1014
-s /usr/temp/611/access -d /usr/temp/1014/access -i /usr/temp/1014/access
-u <user_name> -g <group_name> -l en-us
Using appropriate path names for your Access Servers, run the obmigratenp tool a second time as follows:
obmigratenp -c aaa -f 611 -t 1014 -s /usr/temp/611/access
-d /usr/temp/1014/access -i /usr/temp/1014/access -u <user_name>
-g <group_name>
Auditing and Access Reporting: If your earlier installation included auditing and access reporting, go immediately to "Upgrading Auditing and Reporting for the Access Server" before performing step 5.
Verify that the upgrade was successful as follows:
Start the Access Server service. For example, if you do not store the server password in the password.lst file, use the following command and provide the password at the prompt if needed:
start_access_server -P mypassword port -d -t 61
Certain command options might disable the hide option and cause a password to appear in the command line. On an IBM SecureWay directory server, the next time you start the Access Server it can take a few minutes for the dialog requesting the PEM pass phrase to appear.
Access Server Service Does Not Start: Check the Access Server migration log files for any errors reported during the upgrade and look for troubleshooting tips in Appendix G.
Upgrade Not Successful: Proceed to "Recovering From an Access System Upgrade Failure".
Upgrade Successful: Perform activities in "Backing Up Upgraded Access System Component Directories" for this instance, then repeat the procedure to upgrade all Access Servers in your environment.
After upgrading all Access Servers, you can continue with "Upgrading WebGates while Switching to Linux".
You perform the following steps to upgrade each earlier WebGate on Solaris while switching to the Linux platform.
Note:
The exact commands must reflect your specific WebGate deployments. Ensure that you have access to the earlier component directory, as described in "Making Earlier Installation Directories on Solaris Available to the Linux Host".To upgrade the WebGate while switching to Linux from Solaris
Locate the obmigratenp tool on the Linux host where you installed the Oracle Access Manager 10g (10.1.4.0.1) component.
Using appropriate path names for your WebGates, run the obmigratenp tool using a command that takes the following form:
obmigratenp -c wg -f 611 -t 1014
-s /usr/temp/611/wg/access -d /usr/temp/1014/wg/access
-i /usr/temp/1014/wg/access -u <user_name> -g <group_name> -l en-us
Using appropriate path names for your WebGates, run the obmigratenp tool a second time as follows:
obmigratenp -c wg -f 611 -t 1014 -s /usr/temp/611/wg/access
-d /usr/temp/1014/wg/access -i /usr/temp/1014/wg/access -u <user_name>
-g <group_name>
Verify that the upgrade was successful, as follows:
Start the WebGate Web server.
WebGate Web Server Does Not Start: Check the Access Server migration log files for any errors reported during the upgrade and see troubleshooting tips in Appendix G.
Upgrade Successful: Perform activities in "Backing Up Upgraded Access System Component Directories" for this instance, then continue upgrading earlier WebGates.
Upgrade Not Successful: Proceed to "Recovering From an Access System Upgrade Failure".
Continue upgrading WebGates, and then proceed to "Finishing the Access System Upgrade with a Solaris to Linux Switch".
Using the procedures described in this chapter, your earlier Oracle Access Manager customizations are preserved. This implies that certain deployment-specific settings were carried over from the Solaris deployment to the Linux deployment. For example, the Access Server host name and port. Following the upgrade, you must establish new deployment connections to ensure that the upgraded Oracle Access Manager Web components communicate with the Oracle Access Manager servers on Linux, not the earlier servers on Solaris.
Depending on the component you have upgraded, you must perform the following activities to finish your upgrade: with a switch to Linux
Note:
There are no Policy Manager reconfiguration steps needed.This topic describes how to reconfigure Access Servers after switching to Linux hosts. You must specify new hostname and port details in the Access System Console, then use the command-line tool named start_configureAAAServer to reconfigure the Access Server.
To reconfigure Access Servers on Linux
Go to the Access System Console by entering the appropriate URL for your deployment in a browser window. For example:
http://hostname:port/access/oblix
where hostname refers to computer that hosts the WebPass Web server; port refers to the HTTP (or HTTPS) port number of the WebPass Web server instance; /access/oblix connects to the Access System Console.
Proceed as follows:
Landing Page Appears—Proceed with step 3.
Landing Page Does Not Appear—See troubleshooting tips in Appendix G and "Recovering From an Access System Upgrade Failure".
Select the Access System Console link, then log in as a user with Master Administrator privileges.
The Access System Console should appear.
Proceed as follows:
Login Successful—Proceed with step 4.
Login Not Successful—Be certain that you are logging in as a user with the proper credentials (Master Administrator or Master Access Administrator).
Update Access Server details as follows:
Select the Access System Configuration tab, then click Access Server Configuration when it appears in the left column.
Click an Access Server name on the List all Access Servers page to view its parameters.
Click the Modify button at the bottom of the page to display the Modify Access Server page.
Edit the following parameters on the Modify Access Server page as needed:
Hostname: Enter the name of the computer on which the Access Server is running.
Port: Enter the port number on which the Access Server is listening.
Click the Save button at the bottom of the Modify Access Server page.
Restart the Access Server Service.
Repeat as needed for each Access Server whose host has changed.
Run the start_configureAAAServer tool, as follows:
Locate the configureAAAServer tool:
AccessServer_install_dir/access/oblix/tools/start_configureAAAServer
Use the following command with the configureAAAServer tool to set up the Access Server:
configureAAAServer reconfig AccessServer_install_dir
Specify the following information for the Access Server:
The transport security mode in which the directory server is running
The host computer on which the directory server resides
The port number on which the directory server listens
The bind DN of the directory server
The password of the directory server
The directory server to which you are connecting
The location where configuration data is stored
The configuration DN
The policy base
The Access Server ID
Restart the Access Server.
Repeat as needed for each Access Server that was switched to a Linux host.
Proceed to "Reconfiguring WebGate".
This topic describes how to reconfigure WebGate to communicate with an Access Server that was switched to a Linux computer. For this, you use only the command-line tool named configureWebGate, and specify the host name for the Linux computer running the upgraded Access Server.
When you run the configureWebGate, you will use the options listed in Table B-2. For more information, see the Oracle Access Manager Access Administration Guide.
Table B-2 configureWebGate Commands
| Command | Operation |
|---|---|
-i WebGate_install_dir
|
Specifies the installation directory for the WebGate. |
-t <WebGate> |
Specifies that this operation is for WebGate. |
-h Access Server Host Name
|
Specifies the computer name where the Access Server installed on the Linux host. |
-p Access Server Port
|
Specifies the port number on which the Access Server listens on the Linux host. |
To modify a WebGate through the command line
Locate the configureWebGate tool:
WebGate_install_dir\access\oblix\tools\configureWebGate
In the sample path, WebGate_install_dir is the directory where WebGate is installed on the Linux platform.
Run the following command using specific values for your deployment and parameters listed in Table B-2, "configureWebGate Commands". For example:
configureWebGate -i WebGate_install_dir -t WebGate -h Access_Server_Hostname -p Access_Server_Port
When you receive confirming messages that WebGate is configured properly, restart the Access Server.
Oracle recommends that you first validate your Access System upgrade and then back up the upgraded component details. For details, see the following topics:
This is the same as the steps provided in Chapter 14.
You can complete any of the next steps to validate that the Access System schema and data upgrade have been successful. For more information, see Oracle Access Manager Access Administration Guide.
To verify a successful Access System upgrade
Make sure your Policy Manager Web server and WebPass Web server instance are running.
Navigate to the Access System Console from your browser by specifying the appropriate URL. For example:
http://hostname:port/access/oblix
where hostname refers to computer that hosts the Web server; port refers to the HTTP port number of the WebPass Web server instance; /access/oblix connects to the Access System Console.
The Oracle Access Manager landing page should appear.
Landing Page Does Not Appear: Confirm that you have specified information correctly. Look for troubleshooting tips in Appendix G.
Log in to the Policy Manager/Access System Console as a Master Administrator.
Complete one or more of the following tasks, as described in the latest (10g (10.1.4.0.1)) Oracle Access Manager Access Administration Guide. For example:
Display configuration details for an authentication scheme by clicking the link that corresponds to the scheme.
Define or modify a policy domain.
Explore the Access System Console.
Access a protected resource to confirm that login is working.
Log out, as usual.
As mentioned earlier, Oracle recommends that you finish each component upgrade by backing up the 10g (10.1.4.0.1) component directory after verifying that it is working properly. This will enable you to easily restore your environment to the newly upgraded state should that be a requirement.
Note:
This is an exact repeat of the information in Chapter 10 because there is no difference in the steps whether you are upgrading with a platform switch to Linux or without a switch to Linux.To back up critical Access System information after the upgrade
Back up the latest component directory on Linux and store it in a new location.
Web Server: Back up the upgraded Web server configuration file, if needed, using your vendor documentation as a guide.
Proceed to Chapter 11 and upgrade the software developer kit (SDK).
After this upgrade, Oracle recommends that you apply the latest patch set, which is available on My Oracle Support (formerly Metalink). For more information, see:
The procedures in "Preparing Upgraded Environments for 10g (10.1.4.3) Language Packs"
Obtaining Packages for Upgrades in Chapter 4 for details about the sequential application of patch sets
The procedure in the Oracle Access Manager Patchset Notes Release 10.1.4 Patchset 1 (10.1.4.2.0) For All Supported Operating Systems that explains how to obtain prerequisite patch sets: 10g (10.1.4.2.0)
The procedure in the Oracle Access Manager Patchset Notes Release 10.1.4 Patchset 2 (10.1.4.3.0) For All Supported Operating Systems that explains how to obtain and apply the 10g (10.1.4.3) patch set: 10g (10.1.4.3) patch set.
To use NPTL after applying the 10g (10.1.4.3) patch set, see ""NPTL Requirements and Post-Installation Tasks".
If a component upgrade was not successful, you can perform the following steps to rollback this upgrade, then try again.
Note:
This is an exact repeat of the information in Chapter 9 because the steps are the same whether you are upgrading on the same platform or performing a switch from Solaris to Linux.To recover from an unsuccessful Identity component upgrade
Restore the earlier component installation directory that you backed up before the upgrade (to recover the earlier environment), then back it up again. You will retain one of the earlier directories as a backup copy and use one to restart the upgrade.
WebPass Web Server: Restore the upgraded Web server configuration file, if required.
Using a backup copy of your earlier component installation directory (and Web server configuration, if needed), restart the upgrade as described in this chapter.
This is an exact repeat of the information in Chapter 10 because the steps are the same whether you are upgrading on the same platform or performing a switch from Solaris to Linux.
If the component was not successful, you can perform the following steps to rollback this upgrade, then try again.
To recover from an unsuccessful Access System component upgrade
Restore the earlier component installation directory that you backed up before the upgrade (to recover the earlier environment), then back it up again. You will retain one of the earlier directories as a backup copy and use one to restart the upgrade.
Web Server: Restore the backed up Web server configuration file, if required for this component (Policy Manager or WebGate).
Using a backup copy of your earlier component installation directory (and Web server configuration, if needed), restart the component upgrade as described in this chapter.
|
 Copyright © 2000, 2009, Oracle. All rights reserved. Legal Notices |
|