|
Oracle® Application Server Upgrade and Compatibility Guide
10g Release 2 (10.1.2) for Microsoft Windows Part No. B14096-05 |
|
 Previous |
 Next |
|
Oracle® Application Server Upgrade and Compatibility Guide
10g Release 2 (10.1.2) for Microsoft Windows Part No. B14096-05 |
|
|
Previous |
Next |
This chapter describes additional upgrade procedures that may benefit specific OracleAS Identity Management users. This chapter contains the following sections:
Performing an Oracle Internet Directory Multi-Master Replication Upgrade
Using the Data Migration Method of Upgrading OracleAS Identity Management
This section describes how to upgrade Oracle Internet Directory in a replicated environment. You can upgrade one computer at a time, or all of the computers at one time. Instructions are provided for each method in the following sub-sections:
Preparing for an Oracle Internet Directory Multi-Master Replication Upgrade
Upgrading Oracle Internet Directory on Multiple Replicas Simultaneously
Oracle Corporation recommends that during upgrade, in order to prevent conflicts, the replication environment be a Single Master (that is, only one replica is read/write and all others are read only).
|
See Also: Oracle Internet Directory Administrator's Guide for information about managing and configuring Oracle Internet Directory replication configurations |
Before you begin upgrading Oracle Internet Directory 9.0.4.x.x in a replicated environment, you must perform the following steps for all replicas other than Master Definition Site (MDS) Replica or Primary supplier replica:
Locate the database registration entry of the database of replica to be upgraded.
SOURCE_ORACLE_HOME\bin\ldapsearch -h host -p port -D cn=orcladmin -w superuser_password -b "cn=oraclecontext" -s one "(objectclass=orcldbserver)" dn
This will return a list of Distinguished Names (DNs) corresponding to all the Databases registered in Oracle Internet Directory in the following form:
cn=database_name,cn=oraclecontext
Of these entries, locate the DN of the following entry, which will be used in Step 3 of this procedure:
cn=dbname_of_replica_to_be_upgraded,cn=oraclecontext
Identify the replica ID of the replica to be upgraded by issuing following command:
SOURCE_ORACLE_HOME\bin\ldapsearch -h hostname_of_replica_being_upgraded -p port -D cn=orcladmin -w superuser_password -b "" -s base "(objectclass=*)" orclreplicaid
Modify the seealso attribute of Replica Subentry of the replica to be upgraded as given below:
Create a file, for example mod.ldif, with following contents:
#File Name : mod.ldif dn: orclreplicaid=replicaid_from_step_2,cn=replication configuration changetype: modify replace: seeAlso #The DN used in seealso attribute is obtained in Step #1. seeAlso: cn=dbname_of_replica_being_upgraded,cn=oraclecontext
Modify replica subentry using ldapmodify command.
SOURCE_ORACLE_HOME\bin\ldapmodify -h hostname_of_replica_being_upgraded -p port -D superuser_DN -w superuser_password -v -f mod.ldif
Navigate to the following directory and locate ias.properties file:
SOURCE_ORACLE_HOME\config
Open the ias.properties file and modify properties as shown in Table 6-1.
Make sure the Oracle Internet Directory server is upgraded to 10g Release 2 (10.1.2) and that it is up and running.
To verify that Oracle Internet Directory is running, enter one of the following commands.
If you are running Oracle Internet Directory on a non-secure port:
SOURCE_ORACLE_HOME\bin\ldapbind -p Non-SSL_port
If you are running Oracle Internet Directory on a secure port:
SOURCE_ORACLE_HOME\bin\ldapbind -p SSL_port -U 1
These commands should return a "bind successful" message.
Verify that the tnsnames.ora file contains only one alias for the database.
For example, the tnsnames.ora file might contain two entries for a database called ORCL03, as in the following example:
ORCL03 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)
(HOST = stakb03.acme.com)
(PORT = 1521))) (CONNECT_DATA =
(SERVICE_NAME = orcl03.acme.com)))
ORCL03.US.ORACLE.COM =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)
(HOST = stakb03.acme.com)
(PORT = 1521)))
(CONNECT_DATA =
(SERVICE_NAME = orcl03.us.oracle.com)))
In this example, remove the second, fully-qualified entry before you begin the upgrade procedure. After upgrade is complete, you can add the fully qualified database name alias to the tnsnames.ora file.
Create an LDIF file, for example add.ldif, with the contents shown in Example 6-1.
Start a second instance of LDAP server with "change log generation disabled" as shown below.
Note that this example assumes that the second instance is not in use and port 4444 is not used by any process.
oidctl connect=connect_string_of_db server=oidldapd instance=2 flags="-p 4444 -l false" start
Add the entries defined in the ldif file you created in Step 8 by using ldapadd tool as shown below.
To add these entries, you must use the port used for the LDAP server you started in Step 9. This example assumes that the LDAP server you started in step 8 is listening at port 4444.
ldapadd -p 4444 -h hostname -D cn=orcladmin -w password -f ldif_filename -c
For example:
ldapadd -p 4444 -h mgmt42.acme.com -D cn=orcladmin -w m03kslj -f add.ldif -c
Stop the second LDAP server as shown below.
This example assumes that the instance number used for the second instance was 2.
oidctl connect=<connect_string_of_db> server=oidldapd instance=2 stop
Table 6-1 Properties to Modify in ias.properties Before Replication Upgrade
| Property Name | Original Value | Change to This Value |
|---|---|---|
|
False |
True |
|
|
Infrastructure |
Infrastructure |
|
|
host name of supplier |
host name of replica |
|
|
port of supplier |
port of replica |
|
|
SSL port for supplier |
SSL port for replica |
Example 6-1 Contents of LDIF File Used to Prepare for Replication Upgrade
#File Name : add.ldif
################################
# Event Type Configuration
################################
dn: cn=ProvisioningEventTypeConfig,cn=odi,cn=oracle internet directory
changetype: add
cn: ProvisioningEventTypeConfig
orclaci: access to entry by group="cn=Provisioning Admins,
cn=changelog subscriber,cn=oracle internet directory" (browse,add,delete)
orclaci: access to attr=(*) by group="cn=Provisioning Admins,
cn=changelog subscriber,cn=oracle internet directory"
(read,search,write,compare)
objectclass: orclContainer
dn: orclODIPProvEventObjectType=ENTRY,cn=ProvisioningEventTypeConfig,cn=odi,
cn=oracle internet directory
changetype: add
orclODIPProvEventObjectType: ENTRY
orclODIPProvEventLDAPChangeType: Add
orclODIPProvEventLDAPChangeType: Modify
orclODIPProvEventLDAPChangeType: Delete
orclODIPProvEventCriteria: objectclass=*
objectclass: orclODIPProvEventTypeConfig
dn: orclODIPProvEventObjectType=USER,cn=ProvisioningEventTypeConfig,cn=odi,
cn=oracle internet directory
changetype: add
orclODIPProvEventObjectType: USER
orclODIPProvEventLDAPChangeType: Add
orclODIPProvEventLDAPChangeType: Modify
orclODIPProvEventLDAPChangeType: Delete
orclODIPProvEventCriteria: objectclass=InetOrgPerson
orclODIPProvEventCriteria: objectclass=orclUserV2
objectclass: orclODIPProvEventTypeConfig
dn: orclODIPProvEventObjectType=IDENTITY,cn=ProvisioningEventTypeConfig,cn=odi,
cn=oracle internet directory
changetype: add
orclODIPProvEventObjectType: IDENTITY
orclODIPProvEventLDAPChangeType: Add
orclODIPProvEventLDAPChangeType: Modify
orclODIPProvEventLDAPChangeType: Delete
orclODIPProvEventCriteria: objectclass=InetOrgPerson
orclODIPProvEventCriteria: objectclass=orclUserV2
objectclass: orclODIPProvEventTypeConfig
dn: orclODIPProvEventObjectType=GROUP,cn=ProvisioningEventTypeConfig,cn=odi,
cn=oracle internet directorychangetype: add
orclODIPProvEventLDAPChangeType: Add
orclODIPProvEventLDAPChangeType: Modify
orclODIPProvEventLDAPChangeType: Delete
orclODIPProvEventCriteria: objectclass=orclGroup
orclODIPProvEventCriteria: objectclass=orclPrivilegeGroup
orclODIPProvEventCriteria: objectclass=groupOfUniqueNames
orclODIPProvEventCriteria: objectclass=groupofNames
objectclass: orclODIPProvEventTypeConfig
dn: orclODIPProvEventObjectType=SUBSCRIPTION,cn=ProvisioningEventTypeConfig,
cn=odi,cn=oracle internet directory
changetype: add
orclODIPProvEventObjectType: SUBSCRIPTION
orclODIPProvEventLDAPChangeType: Add
orclODIPProvEventLDAPChangeType: Modify
orclODIPProvEventLDAPChangeType: Delete
orclODIPProvEventCriteria: objectclass=orclServiceSubscriptionDetail
objectclass: orclODIPProvEventTypeConfig
dn: orclODIPProvEventObjectType=SUBSCRIBER,cn=ProvisioningEventTypeConfig,
cn=odi,cn=oracle internet directory
changetype: add
orclODIPProvEventObjectType: SUBSCRIBER
orclODIPProvEventLDAPChangeType: Add
orclODIPProvEventLDAPChangeType: Modify
orclODIPProvEventLDAPChangeType: Delete
orclODIPProvEventCriteria: objectclass=orclSubscriber
objectclass: orclODIPProvEventTypeConfig
######################################################################
# DIPADMIN Account
######################################################################
dn: cn=dipadmin,cn=odi,cn=oracle internet directory
changetype: add
cn: dipadmin
sn: dipadmin
description: DIP Administrator Idenitity in OID
objectclass: person
######################################################################
# DIPADMIN Group
######################################################################
dn: cn=dipadmingrp,cn=odi,cn=oracle internet directory
changetype: add
cn: dipadmin
owner: cn=dipadmin,cn=odi,cn=oracle internet directory
uniquemember: cn=orcladmin
uniquemember: cn=dipadmin,cn=odi,cn=oracle internet directory
description: DIP Administrator Group in OID
objectclass: groupOfUniqueNames
objectclass: orclprivilegegroup
######################################################################
# ODIPGROUP getting recreated here from 904 (Had been removed in 902*)
######################################################################
dn: cn=odipgroup,cn=odi,cn=oracle internet directory
changetype: add
cn: odipgroup
objectclass: top
objectclass: groupofUniquenames
objectclass: orclprivilegegroup
uniquemember: cn=orcladmin
orclaci: access to entry by group="cn=dipadmingrp,cn=odi,cn=oracle internet
directory" (browse) by * (none)
orclaci: access to attr=(uniquemember) by group="cn=dipadmingrp,cn=odi,
cn=oracle internet directory" (search,read,write,compare) by * (none)
dn: cn=odisgroup,cn=odi,cn=oracle internet directory
changetype: add
cn: odisgroup
objectclass: top
objectclass: groupofUniquenames
objectclass: orclprivilegegroup
uniquemember: cn=orcladmin
orclaci: access to entry by * (none)
orclaci: access to attr=(*) by * (none)
Upgrading one computer at a time in a replicated environment ensures that Oracle Internet Directory available during the upgrade for additions, modifications, and searching.
The following sections describe how to upgrade one replica at a time:
Follow these steps to upgrade one replica at a time:
If you are upgrading from Release 2 (9.0.2), make sure you have applied the latest Release 2 (9.0.2) patchsets.
The OracleAS Identity Management upgrade procedures have been tested using the latest patchsets available from OracleMetaLink. As a result, before you upgrade Release 2 (9.0.2) OracleAS Identity Management, apply the latest Oracle Application Server 9.0.2 patchsets.
The OracleMetaLink Web site is at the following URL:
http://metalink.oracle.com/
At the time this document was published the most recent Oracle9iAS patchset release was the Oracle9iAS 9.0.2.3 patchset (3038037). To locate this patchset, search for patch number 3038037 on OracleMetaLink.
|
Note: After applying Oracle9iAS 9.0.2.3 patchset (3038037), verify that the patchset was applied successfully before proceeding with the 10g Release 2 (10.1.2) upgrade. For example, verify that the Application Server Control, your deployed applications, and the components you use are functioning properly after you apply the patchset. |
Make sure you have completed the procedure in Section 6.1.1, "Preparing for an Oracle Internet Directory Multi-Master Replication Upgrade".
Identify the replica to be upgraded.
The replica can be an LDAP-based partial or fan-out replica, or it can be an Oracle Advanced Replication (ASR) based multimaster replica.
|
See Also: "Directory Replication Concepts" in the Oracle Internet Directory Administrator's Guide |
Stop the replication server on the replica to be upgraded.
Make sure that the LDAP server, the Oracle Internet Directory database, and the database listener are up and running.
If you are upgrading an ASR-based replica, then delete all ASR jobs on other replicas by issuing the following command:
SOURCE_ORACLE_HOME\ldap\admin\oidrdjob.sql
All ASR jobs on other master sites that transfer changes to this replica are deleted. This has the effect of taking the replica currently being upgraded out of the replication environment, so that no changes come to it, while other replicas continue to operate and replicate changes.
Upgrade the replica as described in Section 5.5.1, "Upgrading OracleAS Identity Management in a Colocated Infrastructure" or in Section 5.5.2, "Upgrading OracleAS Identity Management in a Non-Colocated 10g (9.0.4) Infrastructure".
Start the replication server database in the upgraded replica Oracle home.
Test the connectivity to the other replicas.
The Net Services Upgrade assistant might have modified listener.ora and tnsnames.ora, breaking connectivity. If connectivity is broken, identify the entries that were modified in the files, and restore the entries from the corresponding files in the source Oracle home.
For example, copy the original entries from the following files in the source Oracle home to the corresponding files in the destination Oracle home:
SOURCE_ORACLE_HOME\network\admin\listener.ora SOURCE_ORACLE_HOME\network\admin\sqlnet.ora SOURCE_ORACLE_HOME\network\admin\tnsnames.ora
If you are upgrading a Oracle Advanced Replication (ASR) based Replica, recreate jobs on each replica, after it is upgraded, by issuing the following command:
DESTINATION_ORACLE_HOME\bin\remtool –asrrectify
The jobs that were deleted in Step 5 are re-created. They will begin transferring the existing changes and new changes from other replicas to the upgraded replicas.
Perform the Oracle Internet Directory post-upgrade procedures.
After you upgrade a 10g (9.0.4) replica, change the replication distinguished name (DN) password stored in the wallet using the Replication Environment Management Tool (remtool), as follows:
DESTINATION_ORACLE_HOME\bin\remtool -pchgwalpwd -v -bind host:port/repl_dn_pwd
If you do not know replication DN password, reset the replication DN password using the following command:
DESTINATION_ORACLE_HOME\bin\remtool -presetpwd -v -bind host:port
|
See Also: Oracle Identity Management User Reference for details about the arguments you can use with theremtool command.
|
After you reset the password of the replication DN of partial replica, you must change the password of replication DN at its supplier. To do so, create an LDIF file (for examlple, modpwd.ldif), with following contents:
dn: cn=replication dn,orclreplicad=consumer_replicaid,cn=replication configuration changetype: modify replace: userpassword userpassword: new_password
Then, apply the change at supplier using ldapmodify tool as shown below:
ldapmodify -h supplier_hostname -p supplier_port_number> -D cn=orcladmin \ -w super_user_password_of_supplier -f modpwd.ldif
After you change or reset the password, you can then start oidmon, LDAP server, and replication server. The replica is upgraded to Oracle Application Server 10g Release 2 (10.1.2) and you can then proceed to upgrade the other replicas in the directory replication group.
After you upgrade a Release 2 (9.0.2) replica, you must perform the following steps before restarting and using the upgraded replica:
After upgrading the infrastructure to Oracle Application Server 10g Release, use a text editor to open the following configuration file in the destination Oracle home:
DESTINATION_ORACLE_HOME\opmn\conf\opmn.xml
Locate the entry that identifies the Oracle Internet Directory component entry in the opmn.xml file.
Add the ORACLE_SID environment variable within an environment element, as shown in Example 6-2.
Make sure that the value of the ORACLE_SID environment variable is set to the System Identifier (SID) of the Oracle Application Server 10g Release 2 (10.1.2) database.
Save and exit the opmn.xml file.
Start the LDAP server and oidmon for the replica you are upgrading.
Use the following command to change the password of the replication distinguished name (DN) of upgraded replica:
DESTINATION_ORACLE_HOME\bin\remtool -presetpwd -v -bind host:port
Start the replication server.
Proceed with upgrading the remaining master site replicas as described in Section 6.1.2.1, "Upgrading the Oracle Internet Directory Replica".
Upgrade the database replication table by performing the following steps:
Stop the replication server on all replicas.
Quiesce the replication environment by issuing this command on the MDS replica:
DESTINATION_ORACLE_HOME\bin\remtool –suspendasr
Connect as REPADMIN (the database replication administrator) on the MDS replica and issue the following command:
execute DBMS_REPCAT.ALTER_MASTER_REPOBJECT (sname=> 'ODS', oname=> 'ASR_CHG_LOG', type=> 'TABLE', ddl_text=> 'alter table ods.asr_chg_log modify target_dn varchar2 (1024)')
Execute the following SQL command repeatedly until the "no rows selected" message appears:
SELECT * from dba_repcatlog WHERE request = 'ALTER_MASTER_REPOBJECT';
Generate replication support for the ASR_CHG_LOG table by issuing the command:
execute DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT
(sname=> 'ODS', oname=> 'ASR_CHG_LOG', type=> 'TABLE');
Execute the following SQL command repeatedly until the "no rows selected message appears:
SELECT * from dba_repcatlog WHERE request = 'ALTER_MASTER_REPOBJECT';
Resume the database replication by issuing the following command:
DESTINATION_ORACLE_HOME\bin\remtool -resumeasr
Start the replication server on all replicas.
Example 6-2 Adding the ORACLE_SID Environment Variable to the opmn.xml file when Upgrading a Release 2 (9.0.2) Oracle Internet Directory Replica
<?xml version = '1.0' encoding = 'UTF-8'?> <opmn xmlns="http://www.acme.com/ias-instance"> ... <ias-component id="OID" status="enabled"> <process-type id="OID" module-id="OID"> <environment> <variable id="ORACLE_SID" value="value_of_oracle_sid"/> </environment> <stop timeout="1800"/> <process-set id="OID" numprocs="1"> <dependencies> ... </ias-component> ... </opmn>
Upgrading multiple replicas simultaneously ensures that the entire network is upgraded without a transient stage. The procedure is simpler than upgrading one replica at a time, but involves directory service downtime.
The following sections describe how to upgrade multiple replicas at the same time:
Use the following procedure to upgrade all the replicas simultaneously:
In all replicas other than MDS replica or primary supplier replica, make sure you have completed the pre-upgrade steps provided in Section 6.1.1, "Preparing for an Oracle Internet Directory Multi-Master Replication Upgrade".
Stop the replication server on all replicas in the Directory Replication Group (DRG).
Upgrade all replicas as described in Section 5.5.1, "Upgrading OracleAS Identity Management in a Colocated Infrastructure" or in Section 5.5.2, "Upgrading OracleAS Identity Management in a Non-Colocated 10g (9.0.4) Infrastructure".
Start the database on all the upgraded replicas.
Test the connectivity to the other replicas.
The Net Services Upgrade assistant might have modified listener.ora and tnsnames.ora, breaking connectivity. If connectivity is broken, identify the entries that were modified in the files, and restore the entries from the corresponding files in the source Oracle home.
For example, copy the original entries from the following files in the source Oracle home to the corresponding files in the destination Oracle home:
SOURCE_ORACLE_HOME\network\admin\listener.ora SOURCE_ORACLE_HOME\network\admin\sqlnet.ora SOURCE_ORACLE_HOME\network\admin\tnsnames.ora
Perform the Oracle Internet Directory post-upgrade procedures.
After you upgrade all the 10g (9.0.4) replicas, reset the replication DN password of the upgraded replica by issuing following command:
DESTINATION_ORACLE_HOME\bin\remtool -presetpwd -v -bind host:port
Then, you can then start the oidmon, LDAP server, and replication server for each replica. All replicas are then upgraded to Oracle Application Server 10g Release 2 (10.1.2).
After you upgrade a Release 2 (9.0.2) replica, you must perform the procedure described in Section 6.1.2.3, "Completing the Upgrade of a Release 2 (9.0.2) Replica". After you complete that procedure, all the replicas will then be upgraded to Oracle Application Server 10g Release 2 (10.1.2).
|
Important: This step should be performed only when all the nodes in the directory replication group are upgraded. Do not repeat this step after each replica upgrade. |
The following sections provide information about upgrading Oracle Internet Directory Version 9.2 to 10g Release 2 (10.1.2):
Overview of Upgrading Oracle Internet Directory Version 9.2.0.x
Performing the Oracle Internet Directory Version 9.2.0.x Upgrade
Updating the Oracle Contexts in the 9.2.0.x Oracle Internet Directory
Setting Access Control Policies After Upgrading From Oracle Internet Directory Version 9.2.0.x
Oracle Internet Directory Version 9.2.0.x was a standalone release that was distributed with the Oracle9i Release 2 (9.2.0.x) database.
The following list provides an overview of the steps required to upgrade your Version 9.2.0.x Oracle Internet Directory to 10g Release 2 (10.1.2). Complete details on how to perform the upgrade are provided in Section 6.2.2, "Performing the Oracle Internet Directory Version 9.2.0.x Upgrade".
Table 6-2 Overview of Upgrading Oracle Internet Directory Version 9.2.0.x to 10g Release 2 (10.1.2)
| Step Number | Action to Perform | Description |
|---|---|---|
|
1 |
Upgrade the Oracle9i database to a version supported by Oracle Application Server 10g Release 2 (10.1.2) |
For more information, see Section 7.1, "Task 1: Upgrade the Database That Hosts the OracleAS Metadata Repository". |
|
2 |
Use the OracleAS Metadata Repository Creation Assistant to install the 10g Release 2 (10.1.2) OracleAS Metadata Repository into the database. |
This step configures your database so it can serve as a host for the 10g Release 2 (10.1.2) OracleAS Identity Management schemas. For more information, see the Oracle Application Server Metadata Repository Creation Assistant User's Guide. |
|
3 |
Manually create the required Oracle Internet Directory tablespaces and tables in the upgraded database. |
The detailed steps for creating the tablespaces and tables are included in Section 6.2.2, "Performing the Oracle Internet Directory Version 9.2.0.x Upgrade" |
|
4 |
Update the Oracle contexts in the directory. |
For more information, see Section 6.2.3, "Updating the Oracle Contexts in the 9.2.0.x Oracle Internet Directory" |
|
5 |
Install 10g Release 2 (10.1.2) OracleAS Identity Management into a new Oracle home. |
This step installs a new Oracle Internet Directory 10g Release 2 (10.1.2) Oracle home. During the installation, Oracle Universal Installer automatically performs additional configuration steps in the newly created 10g Release 2 (10.1.2) OracleAS Metadata Repository. |
|
6 |
Set the appropriate access control policies in the directory. |
For more information, see Section 6.2.4, "Setting Access Control Policies After Upgrading From Oracle Internet Directory Version 9.2.0.x" |
|
7 |
Perform the required Oracle Internet Directory post-upgrade prodedures. |
These procedures are documented in Section 5.6.4, "Completing the Oracle Internet Directory Upgrade". |
Use the following procedure to upgrade Oracle Internet Directory Version 9.2.0.x to 10g Release 2 (10.1.2):
Stop all processes in the Oracle home.
|
See Also: ""Starting and Stopping" in the Oracle Application Server Administrator's Guide |
Back up the database.
If you created the Oracle Internet Directory database by installing the Oracle9i Management and Integration installation type, install the Oracle9i Database 9.2.0.1.0 Software Only installation type into the same Oracle home, over the database created with the Management and Integration installation type.
The Software Only installation type is necessary because it includes software required to use a Oracle9i Release 2 (9.2.0.x) database as an OracleAS Metadata Repository.
If necessary, upgrade the database to a version supported by Oracle Application Server 10g Release 2 (10.1.2).
Refer to Section 7.1, "Task 1: Upgrade the Database That Hosts the OracleAS Metadata Repository" for information on the supported database versions and for suggested database upgrade paths.
Start the database and use the OracleAS Metadata Repository Creation Assistant to install the OracleAS Metadata Repository into the Oracle9i Release 2 (9.2.0.x) database.
Refer to the Oracle Application Server Metadata Repository Creation Assistant User's Guide for complete instructions.
|
Note: While installing the OracleAS Metadata Repository, be sure to select Register Later when you are prompted to register with the Oracle Internet Directory. |
After you install the OracleAS Metadata Repository, the Oracle9i database contains the schemas for all the Oracle Application Server 10g Release 2 (10.1.2) components, except Oracle Internet Directory. The Oracle Internet Directory schema is still at Version 9.2.
Connect to the database as the SYS user with SYSDBA privileges and create the Oracle Internet Directory tablespaces olts_svrmgstore and olts_battrstore by executing the following SQL statements:
CREATE TABLESPACE olts_svrmgstore DATAFILE 'svrmg1_oid.dbf' SIZE 1M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL;
CREATE TABLESPACE olts_battrstore DATAFILE 'battrs1_oid.dbf' SIZE 500K REUSE AUTOEXTENT ON EXTENT MANAGEMENT LOCAL AUTOALLOCATE;
Create the imcfgregistry table in the database by running the following SQL statement as the ODS schema:
CREATE TABLE imcfgregistry (
Component VARCHAR2(255),
instMode VARCHAR2(255),
IASInstance VARCHAR2(255))
TABLESPACE OLTS_DEFAULT MONITORING;
Update the Oracle contexts in the directory, using the procedure in Section 6.2.3, "Updating the Oracle Contexts in the 9.2.0.x Oracle Internet Directory"
Perform a 10g Release 2 (10.1.2) Identity Management installation in a separate Oracle home or on a separate computer.
During the installation, select Identity Management as the installation type.
|
See Also: 'Installing Oracle Identity Management Components Only (Including Oracle Internet Directory)" in the"Oracle Application Server Installation Guide |
Later in the installation, Oracle Universal Installer prompts you for the OracleAS Metadata Repository login credentials.
At the end of the installation, Oracle Universal Installer invokes the Oracle Internet Directory Configuration Assistant, which uses these credentials to log in to the database. The configuration assistant checks the version of Oracle Internet Directory schema. If the version is 9.2.0.x, then it upgrades the schema to 10g Release 2 (10.1.2).
After the installation, the following conditions are in effect:
The Oracle Internet Directory server is running on the non-SSL and SSL ports, as determined by the 10g Release 2 (10.1.2) installation process. The Oracle Internet Directory ports are identified by the OIDport and OIDsslport properties of the following configuration file:
DESTINATION_ORACLE_HOME\config\ias.properties
The Oracle Internet Directory superuser and Oracle Internet Directory database schema (ODS) passwords are set to the same value as the ias_admin password specified during the Identity Management installation.
Set the appropriate access control policies as described in Section 6.2.4, "Setting Access Control Policies After Upgrading From Oracle Internet Directory Version 9.2.0.x".
Perform the tasks in Section 5.6.4, "Completing the Oracle Internet Directory Upgrade".
Use the following procedure to update the Oracle contexts in the Oracle Internet Directory before upgrading from Oracle Internet Directory Version 9.2.0.x:
|
Note: Theldapsearch and ldapmodify commands used in this procedure are located in the bin directory of the Oracle Internet Directory Oracle home.
|
Make sure the Oracle Internet Directory is up and running.
Look up the Oracle Context distinguished names (DNs) in the existing directory by running the following command:
ldapsearch -h host -p port -D cn=orcladmin -w superuser_password -b "" -s sub "cn=oraclecontext" dn
In this example, replace host, port, and supersuser_password with the host, port, and cn=orcladmin password for the Oracle Internet Directory.
Make note of the DNs located by the ldapsearch command. You will use this information later in this procedure.
Create an LDIF file with the content shown in Example 6-3.
|
Note: The first line of the LDIF record (the line that begins with "dn") should be on one line with no line breaks. The second line of the file starts with "changetype". |
Save the file with a recognizable name, such as oracle_contexts_update.ldif.
For each of the distingushed name entries (DNs) returned by the ldapsearch command you used in Step 2, perform the following steps:
Edit the LDIF file and replace the %s_OracleContextDN% string with the DN.
Use the following ldapmodify command to update the directory:
ldapmodify -h host -p port -D cn=orcladmin -w superuser_password -c -v -f oracle_contexts_update.ldif
For example, suppose the ldapsearch command in Step 2 returns the following DNs:
cn=oraclecontext cn=oraclecontext,dc=acme,dc=com
In this example, you would run the ldapmodify command twice. The first time, you would edit the LDIF file and replace %s_OracleContextDN% with cn=oraclecontext before running the ldapmodify command.
The second time, you would replace replace %s_OracleContextDN% with cn=oraclecontext,dc=acme,dc=com before running the command.
Example 6-3 Contents of LDIF File for Updating the Oracle Contexts in the Version 9.2 Oracle Internet Directory
dn: cn=preferredlanguage,cn=Attributes,cn=User Configuration,cn=Attribute
Configuration, cn=DAS,cn=Products,%s_OracleContextDN%
changetype: add
displayname: Language
objectclass: top
objectclass: orclContainer
objectclass: orclDASConfigAttr
orcldasadminmodifiable: 1
orcldasviewable: 1
orcldasselfmodifiable: 1
cn: preferredlanguage
orcldasuitype: lov
orcldaslov: en
orcldaslov: ar
orcldaslov: pt-BR
orcldaslov: fr-CA
orcldaslov: cs
orcldaslov: da
orcldaslov: nl
orcldaslov: fi
orcldaslov: fr
orcldaslov: de
orcldaslov: el
orcldaslov: iw
orcldaslov: hu
orcldaslov: it
orcldaslov: ja
orcldaslov: ko
orcldaslov: es-ES
orcldaslov: pl
orcldaslov: pt
orcldaslov: ro
orcldaslov: ru
orcldaslov: zh-CN
orcldaslov: sk
orcldaslov: es
orcldaslov: sv
orcldaslov: th
orcldaslov: zh-TW
orcldaslov: tr
orcldaslov: no
When you upgrade your Version 9.2 Oracle Internet Directory to 10g Release 2 (10.1.2), you must manually set up some required access control policies for the 10g Release 2 (10.1.2) Oracle Delegated Administration Services and for the middle tier installations so theycan operate with the upgraded Oracle Internet Directory.
|
Note: Theldapsearch and ldapmodify commands used in this procedure are located in the bin directory of the Oracle Internet Directory Oracle home.
|
To set up the required access control policies:
Create an LDIF file with the contents shown in Example 6-4.
Note that each value of the orclaci attribute (identified with bold text in the example) must be a single line, without any line breaks, or an error will occur.
Replace all occurrences of %rlmDN% in the upgrade_acp_92.ldif file with the default realm distinguished name (DN).
The occurrences of %rlmDN% are identified with bold italic text in the example.
You can determine the default realm DN with the following ldapsearch command:
ldapsearch -h <oid host> -p oid_port -D OID_superuser_DN -w OID_superuser_password -b "cn=common,cn=products,cn=oraclecontext" -s base "objectclass=*" orcldefaultsubscriber
Issue the ldapmodify command below:
ldapmodify -p <oid port> -h <oid host> -D <OID superuser name> -w <OID superuser password> -v -f upgrade_acp_92.ldif
Example 6-4 Contents of LDIF File that Sets Access Control Policies When Upgrading from Oracle Internet Directory Version 9.2.0.x
#--- BEGIN LDIF file contents--- dn: cn=Attribute Configuration, cn=DAS,cn=Products,cn=OracleContext changetype: modify add: orclaci orclaci: access to entry by group="cn=OracleDASConfiguration, cn=Groups,cn=OracleContext" (add,delete,browse) by * (noadd,nodelete) orclaci: access to attr=(*) by group="cn=OracleDASConfiguration, cn=Groups, cn=OracleContext" (read,write,search,compare) by * (nowrite,nocompare) dn: cn=Attribute Configuration, cn=DAS,cn=Products,cn=OracleContext,%rlmDN% changetype: modify add: orclaci orclaci: access to entry by group="cn=OracleDASConfiguration, cn=Groups,cn=OracleContext,%rlmDN%" (add,delete,browse) by * (noadd,nodelete) orclaci: access to attr=(*) by group="cn=OracleDASConfiguration, cn=Groups, cn=OracleContext,%rlmDN%" (read,write,search,compare) by * (nowrite,nocompare) #---END LDIF file contents------
Use the following sections to learn more about an alternative method of upgrading your OracleAS Identity Management environment.
Before you use the instructions in this chapter, review Table 6-3, which describes the differences between data migration and the more typical OracleAS Identity Management upgrade procedures described in Chapter 5, "Upgrading Identity Management Services".
Use this table to be sure you use the upgrade procedure best suited for your OracleAS Identity Management environment.
Table 6-3 Comparison of Data Migration and Typical OracleAS Identity Management Upgrade Procedure
| Typical OracleAS Identity Management Upgrade | Data Migration Upgrade |
|---|---|
|
Use Oracle Universal Installer to automatically:
|
|
|
All upgrade tasks are performed on one host on the same platform. |
You can migrate your OracleAS Identity Management data from one host to another, and you can migrate data from one platform to another (for example, from UNIX to Microsoft Windows). |
|
After the upgrade, you use the destination Oracle home and the original source Oracle home is decommissioned. |
After the data migration, you can continue using both the source and destination installations. The source installation is left untouched. |
|
This upgrade can be used only to upgrade from a previous version to a newer version. |
This procedure can be used to upgrade to a newer version of Oracle Application Server or to move data between installations of the same version. |
|
During the upgrade, the OracleAS Identity Management services are down. |
During this upgrade, there is no downtime required, although Oracle Internet Directory must be in read-only mode while the data in the directory is backed up. |
|
The upgrade is relatively quick and less time-consuming because many of the steps are automated. |
The upgrade procedure will usually take longer than a typical OracleAS Identity Management upgrade because many of the steps are manual. |
Use the following steps to upgrade OracleAS Identity Management using the data migration method.
Step 1 Install a new, complete 10g Release 2 (10.1.2.0.2) OracleAS Identity Management environment
You can install any of the supported OracleAS Identity Management topologies described in the Oracle Application Server Installation Guide. The new 10g Release 2 (10.1.2.0.2) OracleAS Identity Management environment must include its own OracleAS Metadata Repository and database.
Review the following requirements when installing and configuring the new OracleAS Identity Management environment:
The database name you select during the installation must not conflict with the database in the source environment.
Do not install any other iAS component against the new Identity management instance until data migration is complete
Do not load any user data before data migration is complete
Test and verify that all identity management components are working smoothly
Step 2 Back up the OracleAS Identity Management data in the source environment
Set the Oracle Internet Directory to read-only mode.
Create an LDIF file; for example, mod.ldif, with the following content:
dn: changetype : modify replace: orclservermode orclservermode: ro
Run the following command to execute the LDIF file:
SOURCE_ORACLE_HOME\bin\ldapmodify -h source_oid_host -p port -D cn=orcladmin -w orcladmin_password -v -f mod.ldif
Setting Oracle Internet Directory to read-only is not required, but if you do not set the directory to read-only, any changes made while you are backing up the directory will not be included in the backup.
Back up the Oracle Internet Directory by using the following commands:
ldifwrite -c db_connect_string -b "cn=oraclecontext" -f bkp1.ldif ldifwrite -c db_connect_string -b "dc=com" -f bkp2.ldif
In this example, replace db_connect_string with the Oracle Internet Directory database connect string. If you do not provide this string, it defaults to the value of the ORACLE_SID environment variable.
Also in this example, it is assumed that dc=com is the root of the subscriber. If you have additional subscribers, then execute an equivalent ldifwrite command for the root of each subscriber.
|
See Also: "ldifwrite" in the Oracle Identity Management User Reference |
Merge bkp1.ldif and bkp2.ldif into one file; for example, bkp.ldif and save the file in a known location so you can later load it into the new destination Oracle Internet Directory.
Set the Oracle Internet Directory back to read-write mode.
Create an LDIF file; for example, modrw.ldif, with the following content:
dn: changetype : modify replace: orclservermode orclservermode: rw
Run the following command to execute the LDIF file:
SOURCE_ORACLE_HOME\bin\ldapmodify -h source_oid_host -p port -D cn=orcladmin -w orcladmin_password -v -f modrw.ldif
Step 3 Back up the OracleAS Single Sign-On data in the source environment
Back up the OracleAS Single Sign-On data using the following command:
SOURCE_ORACLE_HOME\sso\bin\ssomig -export -s orasso -p source_database_orasso_schema_password -c source_SSO_database_connect_string -log_d full_log_directory_path
In this example:
Replace source_database_orasso_schema_password with the database schema password for OracleAS Single Sign-On.
This password is randomized during installation of the OracleAS infrastructure. To obtain the password, see Appendix B of the Oracle Application Server Single Sign-On Administrator's Guide.
Replace source_SSO_database_connect_string with the net service name for the OracleAS Single Sign-On database.
Replace full_log_directory_path with the name of the log directory.
This directory must be writable. The log file, the export configuration file, and the dump file are written here. Use the absolute path for the directory when running the script. The default is ORACLE_HOME/sso/log.
|
See Also: "Export and Import Script: Syntax and Parameters" in the Oracle Application Server Single Sign-On Administrator's Guide |
Step 4 Prepare the destination OracleAS Identity Management for Data Migration
Back up the local registration information from the destination OracleAS Identity Management so it can be restored after you migrate the data from the source OracleAS Identity Management instance:
DESTINATION_ORACLE_HOME\ldap\bin\remtool -backupmetadata -replica oidhost:oidport/repdnpwd -bkup ldiffilename
In this example:
Replace oidhost with the host name of the destination Oracle Internet Directory.
Replace oidport with the port at which the destination Oracle Internet Directory is listening.
Replace repdnpwd with the replication DN password of the destination Oracle Internet Directory, which by default is the same as the ODS/cn=orcladmin password after the installation.
Replace ldiffilename with the name of the ldif file that will contain the backed up registration data.
|
See Also: "remtool" in the Oracle Identity Management User Reference |
Merge the destination OracleAS Identity Management schema with the source OracleAS Identity Management schema:
ORACLE_HOME\bin\schemasync -srchost source_oid_hostname -srcport source_oid_port_number -srcdn source_oid_privileged_DN -srcpwd source_oid_privileged_DN_password -dsthost destination_oid_hostname -dstport destination_oid_port -dstdn destination_oid_privileged_dn -dstpwd destination_oid_privileged_DN_password -ldap
In this example, replace source_oid_privileged_DN and destination_oid_privileged_DN with the distinguished name of the user used to bind to the directory. This user must have permissions to modify the directory schema, for example the super user (cn=orcladmin).
The -ldap parameter is optional. If you include the -ldap parameter, then the schema changes are applied directly from the source Oracle Internet Directory to the destination Oracle Internet Directory. If you do not include the -ldap parameter, then the new attribute definitions are saved to the following LDIF file:
ORACLE_HOME\ldap\odi\data\attributetypes.ldif
And, the object class definitions are saved to the following LDIF file:
ORACLE_HOME\ldap\odi\data\objectclasses.ldif
Any errors that occur during the schema synchronization are logged in the following log files:
ORACLE_HOME/ldap\odi\log\attributetypes.log ORACLE_HOME/ldap\odi\log\objectclasses.log
|
See Also: "schemasync " in the Oracle Identity Management User Reference |
Stop the Oracle Internet Directory in the destination Oracle home using OPMN:
DESTINATION_ORACLE_HOME\opmn\bin\opmnctl stopall
Clean up any conflicting data from the destination Oracle Internet Directory by running the following commands, which correspond to the ldifwrite commands used in Step 2:
DESTINATION_ORACLE_HOME\ldap\bin\bulkdelete.sh -connect db_connect_string -base "cn=OracleContext" DESTINATION_ORACLE_HOME\ldap\bin\bulkdelete.sh -connect db_connect_string -base "dc=com"
This example assumes that dc=com is the root of the subscriber. If you have additional subscribers, then use an equivalent bulkdelete command for the root of each additional subscriber.
Step 5 Load the source Oracle Internet Directory data into the destination Oracle Internet Directory
Verify the backup data in the ldif file:
DESTINATION_ORACLE_HOME\ldap\bin\bulkload.sh -connect destination_oid_connect_string -check -restore path_to_bkp.ldif\bkp.ldif
In this example, replace path_to_bkp.ldif with the path to the location where you stored the backup LDIF files.
After running the bulkload -check command, check the contents of the following log files:
DESTINATION_ORACLE_HOME\ldap\log\bulkload.log DESTINATION_ORACLE_HOME\ldap\log\schemacheck.log DESTINATION_ORACLE_HOME\ldap\load\badentry.ldif
If necessary, perform the bulkload command repeatedly on the ldif file until no errors are reported in the log files.
For example, look for these common error messages:
Error Message: DN Error --- DN "<DN of the error entry>", rc=0
Action: An entry in the ldif file has an invalid DN and cannot be loaded into the destination Oracle Internet Directory. Remove this entry from the ldif file.
Error Message: ERROR * gslsbzCheckDupAttrValinEntry : Dupl Value {X- ORCLLMV}4F6500711D4185249B624840E0439040 found
Action: An entry in the ldif files has duplicate values for Password verifiers. Clean up the entries that have duplicate password verifiers.
Load the source Oracle Internet Directory data into the destination Oracle Internet Directory:
DESTINATION_ORACLE_HOME\ldap\bin\bulkload.sh -connect destination_oid_connect_string -generate -restore -load path_to_bkp.ldif\bkp.ldif
In this example, replace path_to_bkp.ldif with the path to the location where you stored the backup LDIF files.
Check the log files again to be sure no errors were generated while the data was loaded into the destination Oracle Internet Directory. Errors in this step (such as index creation errors) can cause serious problems later.
Step 6 Migrate the OracleAS Single Sign-On data
Copy the files created when you backed up the OracleAS Single Sign-On data in the source environment in Step 3 to the destination host.
Use an appropriate method for copying the files to the destination host, such as FTP. The files to copy are ssomig.dmp and ssoconf.log. By default, these files are created in the follwing directory:
DESTINATION_ORACLE_HOME\sso\log
Enter the following command to import the Single Sign-On data:
In the above example:
Replace full_log_directory_path with the directory location where you have copied SSO data files (soomig.dmp and ssoconf.log).
Replace destination_orasso_schemas_password with the ORASSO schema password of the destination Oracle database. This password is stored in the LDIF file you created in the first substep of Step 4, ""Prepare the destination OracleAS Identity Management for Data Migration".
In the backup LDIF file, the password is stored as the value of attribute orclpasswordattribute of the following entry in the LDIF file:
orclresourcename=ORASSO,
orclReferenceName=database_global_name,
cn= IAS Infrastructure Databases,
cn=IAS, cn=Products, cn=OracleContext
For example, in the following example, ORASSO schema password is welcome1.
dn: OrclResourceName=ORASSO,
orclReferenceName=orcl.myhostdb1.us.oracle.com,
cn=IAS Infrastructure Databases,
cn=IAS,
cn=Products,
cn=OracleContext
orclflexattribute1: true
orclpasswordattribute: welcome1
orclresourcename: ORASSO
objectclass: orclResourceDescriptor
objectclass: top
An example of the resulting ssomig command would appear as follows:
|
See Also: "Export and Import Script: Syntax and Parameters" in the Oracle Application Server Single Sign-On Administrator's Guide |
Step 7 Completing the OracleAS Identity Management Data Migration
Upgrade the oraclecontext and subscriber context for the destination OracleAS Identity Management installation, as follows:
|
Note: This step (upgrading theoraclecontext and subscriber context) is applicable only when the source OracleAS Identity Management and the destination OracleAS Identity Management are of different versions. For example, you must run this step when using data migration to upgrade from 10g (9.0.4) to 10g Release 2 (10.1.2.0.2).
|
Run the following command to upgrade the Oracle Internet Directory metadata as part of a migration from a previous version of OracleAS Identity Management to 10g Release 2 (10.1.2.0.2):
DESTINATION_ORACLE_HOME\bin\oidca mode=UPGRADE -silent dbuser=DBA_user dbpwd=DBA_user_password connstr=TNS_alias_db_connect_string sudn=oid_superuser_DN supwd=oid_superuser_password iaspwd=ias_admin_password iasinstance=app_server_instance_name nonsslport=nonsslport | sslport=sslport
Run the following command to upgrade the Oracle Directory Integration and Provisioning metadata:
DESTINATION_ORACLE_HOME\bin\oidca mode=DIP -silent oidhost=oid_host nonsslport=oid_nonssl_port | sslport=oid_ssl_port sudn=oid_user_dn supwd=oid_user_password iaspwd=ias_admin_password
Restore the local registration information for the destination OracleAS Identity Management that you saved in the first substep of Step 4, "Prepare the destination OracleAS Identity Management for Data Migration".
Note that this example assumes you saved the local registration information in a file called locreg.ldif.
DESTINATION_ORACLE_HOME\bin\ldapmodify -h destination_oid_hostname -p destination_oid_port -v -f locreg.ldif
Stop the Oracle Internet Directory using the oidmon utlity and then start it using OPMN.
Oracle recommends this step because the oidca utility, which was used when you upgraded the oraclecontext and subscriber earlier in this procedure, starts the Oracle Internet Directory using the oidmon utility.
For more information about using oidmon and opmctl to control the Oracle Internet Directory, refer to the Oracle Internet Directory Administrator's Guide.
