Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Internet Directory
11g Release 1 (11.1.1)

Part Number E10029-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

40 Setting Up Replication

Replication is the process of copying and maintaining the same naming contexts on multiple directory servers. It can improve performance by providing more servers to handle queries and by bringing the data closer to the client. It improves reliability by eliminating risks associated with a single point of failure.

Before reading this chapter, please see Chapter 6, "Understanding Oracle Internet Directory Replication" for an introduction to basic replication concepts.

This chapter presents some information that is common to both Advance Replication-based replication and LDAP-based replication. The procedural sections of the chapter describe how to set up LDAP-based replication and multimaster replication with fan-out. For information and procedures specific to Oracle Database Advanced Replication-based replication, please see Appendix C, "Setting Up Oracle Database Advanced Replication-Based Replication."

See Also:

Section 6.2.3, "Transport Mechanism: LDAP or Oracle Database Advanced Replication."

See Also:

Oracle Fusion Middleware High Availability Guide for information on setting up replication in high availability configurations.

This chapter contains the following topics:

Note:

All references to Oracle Single Sign-On or Oracle Delegated Administration Services in this chapter refer to Oracle Single Sign-On 10g (10.1.4.3.0) or later and Oracle Delegated Administration Services 10g (10.1.4.3.0) or later.

40.1 Introduction to Setting Up Replication

If you are unfamiliar with basic replication concepts, please see Chapter 6, "Understanding Oracle Internet Directory Replication" before reading this introduction.

This introduction contains the following topics:

40.1.1 Replication Transport Mechanisms

Oracle Internet Directory supports two replication transport mechanisms.

  • LDAP-based replication uses the industry-standard Lightweight Directory Access Protocol Version 3. You can set up LDAP-based replication in one-way, two-way, and multimaster configurations. This is the recommended protocol for most environments.

  • Oracle Database Advanced Replication-based replication uses the replication capability of Oracle Database. Only multimaster configurations are supported. (You can create a single master DRG by switching all nodes in a group but one to read-only mode.)

    If you must replicate Oracle Single Sign-On data, you must use Oracle Database Advanced Replication-based replication. For information and procedures specific to Advanced Replication-based replication, please see Appendix C, "Setting Up Oracle Database Advanced Replication-Based Replication."

You can convert an existing Oracle Database Advanced Replication-based multimaster agreement to an LDAP-based multimaster agreement. by using remtool -asr2ldap. See Section 40.2, "Converting an Advanced Replication-Based Agreement to an LDAP-Based Agreement."

See ALso:

The remtool command-line tool reference in Oracle Fusion Middleware Reference for Oracle Identity Management for more information about the Replication Environment Management Tool

40.1.2 Replication Setup Methods

The following methods are available for setting up Oracle Internet Directory replication.

40.1.2.1 Replication Wizard

The recommended method for setting up LDAP-based replication is to use the replication wizard in Oracle Enterprise Manager Fusion Middleware Control. The procedure is described in Section 40.3, "Setting Up an LDAP-Based Replication Agreement by Using the Replication Wizard." You can also use the wizard for modifying an existing replication agreement, as described in Section 43.2.4, "Viewing or Modifying a Replication Setup by Using the Replication Wizard" and Section 43.2.5, "Deleting an LDAP-Based Replication Agreement by Using the Replication Wizard."

40.1.2.2 Command Line Tools

You must use command line tools to set up Advanced Replication-based replication. You can also use command line tools to set up LDAP-based replication.

Command-line setup of LDAP-based replication is described in Section 40.5, "Setting Up an LDAP-Based Replication by Using the Command Line." Command-line setup of Advanced Replication-based replication is described in Appendix C, "Setting Up Oracle Database Advanced Replication-Based Replication."

When setting up replication from the command line, you use the oidctl command for stopping and starting the replication server. You use bulk tools for backing up data and loading it to other nodes. You use LDAP tools for a few operations.

Optionally, you can use the bootstrap capability of the replication server for the initial data migration.

You use the Replication Environment Management Tool, remtool, to perform various replication-related tasks, including:

  • Setting up a replication group

  • Converting an existing Oracle Database Advanced Replication-based agreement to an LDAP multimaster agreement.

  • Adding and deleting replicas

  • Managing the directory replication group

  • Modifying or resetting the replication Bind DN password

  • Modifying the database replication user REPADMIN password

  • Displaying various errors and status information for change log propagation

  • Tracking replication progress in a directory replication group.

See Also:

The remtool command-line tool reference in Oracle Fusion Middleware Reference for Oracle Identity Management for more information about the Replication Environment Management Tool

40.1.2.3 Database Copy Procedure

It is possible to set up replication on a new host by copying the Oracle Database from an existing host. This is a complex procedure that is not recommended for most environments. The procedure is described in Appendix L, "Adding a Directory Node by Using the Database Copy Procedure."

40.1.3 Bootstrap Rules

Whether you are using the replication wizard in Fusion Middleware Control or the command line, you can use the bootstrap capability of the replication server for the initial data migration.

You set the bootstrap flag by setting the attribute orclreplicastate to 0 under the replicadn.

When a replica is in bootstrap mode, the supplier node must be in on line mode (orclreplicastate=1). Do not set the supplier and consumer to bootstrap at same time.

Bootstrap cannot be used for initial data migration on a node that has more than one supplier. Therefore, bootstrap is limited to the following types of replica:

  • A leaf replica, that is, one that has no consumer replicas.

  • A primary replica in a two-node LDAP-based multi-master replication agreement, provided it has no two-way fanout replicas.

  • A non-primary replica in an LDAP-based multimaster replication agreement with two or more nodes, provided it has no two-way fanout replicas.

  • A fanout replica with only one supplier

If you set the bootstrap flag (orclreplicastate=0 under replicadn) of any other replica, the replication server throws one of these messages:

bootstrapping against non-leaf replica is not allowed
 bootstrap against master replica is not allowed

Notes:

  • Bootstrap is not allowed for Oracle Database Advanced Replication replicas.

  • Disable referential integrity during the replication bootstrapping process. If referential integrity is enabled, bootstrapping fails.

40.1.4 The Replication Agreement

When you set up replication, you create a container called a replication agreement in the DIT on each of the participating hosts. The attributes of the replication agreement entry are described in Section 42.1.3, "The Replication Agreement Entry."

If you use the replication wizard in Oracle Enterprise Manager Fusion Middleware Control, your selections on the Settings page of the wizard specify the replication agreement attributes that control connection and scheduling.

Your choices on that page include:

  • Whether the replication server should use same connection for performing multiple LDAP operations (Keep Alive) or open a new connection for each LDAP operation (Always Use New Connection).

  • The frequency at which replication should occur (Replication Frequency).

  • The interval at which the replication server should repeat the change application process (Human Intervention Queue Schedule). See Section D.5.1, "How the Multimaster Replication Process Adds a New Entry to a Consumer" for more information about the change application process and the human intervention queue.

The replication agreement also contains the replication contexts. These are discussed in more detail in Section 40.1.9, "LDAP Replication Filtering for Partial Replication." The attributes are described in Section 42.1.3, "The Replication Agreement Entry."

40.1.5 Other Replication Configuration Attributes

In addition to the replication agreement entry, the DIT includes several other entries that contain attributes that control replication. The entries and their attributes are described in Chapter 42, "Managing Replication Configuration Attributes." Once you have set up replication, you can manage these attributes.

Oracle Enterprise Manager Fusion Middleware Control has a Replication page, separate from the replication wizard, that enables you to configure replication attributes. You can also modify replication attributes by using LDAP tools. These methods are described in Chapter 43, "Managing and Monitoring Replication."

40.1.6 Replication Process and Architecture

See Appendix D, "How Replication Works" for detailed information about replication architecture and the replication process.

40.1.7 Rules for Configuring LDAP-Based Replication

The following rules apply to LDAP-based replication:

  1. If you have multiple Oracle Internet Directory instances that use the same Oracle Database, only one of the instances can be set up for replication.

  2. LDAP Multimaster replication is not backward compatible. It is only supported between replicas that are running 11g Release 1 (11.1.1).

  3. For either multimaster replication or two-way fan-out replication, all nodes must be running the same release of Oracle Internet Directory. Therefore, you must turn off replication while performing rolling upgrades.

  4. You can add a one-way fan-out replica that is running a newer release than its supplier. For example, in Figure 6-5, "Example of Fan-Out Replication", Node F can be running a newer release than the other nodes.

  5. In general, do not replicate changes generated on a newer version of Oracle Internet Directory to a node that has not yet upgraded to that version. If you do, the changes can contain information that the earlier version cannot properly interpret.

  6. More specifically, if you add a new Oracle Internet Directory 11g Release 1 (11.1.1.6) node to an existing DRG as a one-way fan-out replica, there is no need to upgrade other nodes of DRG. For all other types of replication, first upgrade the nodes in the DRG before adding the new node. This is true whether the existing nodes are running a 10g release or a previous 11g release. For example, in Figure 6-5, "Example of Fan-Out Replication", before adding an Oracle Internet Directory 11g Release 1 (11.1.1.6) node as Node E, you must first update Nodes A, B, C and G to 11g Release 1 (11.1.1.6).

  7. In LDAP-based replication, only the naming contexts listed in the namingcontexts attribute of the root DSE can be replicated to the consumer.

  8. The supplier of an LDAP-based replica can be a master node that is not a member of any replication group, a member of a multimaster replication group, or another LDAP-based replica.

    See Also:

    Oracle Fusion Middleware Installation Guide for Oracle Identity Management for instructions on installing Oracle Internet Directory.

  9. An LDAP-based replica can be a consumer for another LDAP-based replica. That consumer is then called a fan-out replica.

    Note:

    Make sure the schemas are synchronized. Otherwise, the replication server might not be able to apply changes to the consumer replica.

  10. The new consumer node must be empty. That is, Oracle Internet Directory must be newly installed.

40.1.8 Replication Security

This section contains these topics:

40.1.8.1 Authentication and the Directory Replication Server

Authentication is the process by which the Oracle directory replication server establishes the true identity of itself when connecting to the directory server. It occurs when an LDAP session is established by means of an ldapbind operation.

It is important that the directory replication server be properly authenticated before it is allowed access to the directory.

The directory replication server uses a unique identity and a password to authenticate with the directory server. The identity of the directory replication server is of the form cn=replication dn,orclreplicaid=unique_identifier_of_node,cn=replication configuration.

When it starts, the directory replication server reads its identity and password from an Oracle Internet Directory secure wallet, and uses these credentials for authentication. If you want to change the password for the replication bind DN, then you must use the -chgpwd, -presetpwd, or -pchgwalpwd option of the Replication Environment Management Tool. The wallet for replication identity is located at ORACLE_INSTANCE/OID/admin/oidpwdrOracle_SID.

See Also:

The remtool command-line tool reference in Oracle Fusion Middleware Reference for Oracle Identity Management.

Note:

In earlier releases, the replication server required the directory server to allow anonymous bind. The replication server no longer requires that.

40.1.8.2 Secure Sockets Layer (SSL) and Oracle Internet Directory Replication

You can deploy Oracle Internet Directory replication with or without SSL. The replication server automatically detects if it is binding to the SSL port of an Oracle Internet Directory instance. If so, it automatically works on top of the Secure Sockets Layer.

To configure LDAP-based replication to use SSL encryption, specify the port number of the SSL port in the orclReplicaURI attribute, which contains the supplier contact information.

To configure Oracle Database Advanced Replication to use SSL encryption, use Oracle Database Advanced Security. See the Secure Sockets Layer chapter in the Oracle Database Advanced Security Administrator's Guide.

Note:

The replication server cannot communicate over an SSL port that is configured for one-way authentication or two-way authentication. The replication server startup will fail and hang. You must configure the replication server to use either the non-SSL port or an SSL port configured for no authentication. You can use a separate Oracle Internet Directory server instance just for replication.

40.1.9 LDAP Replication Filtering for Partial Replication

This section describes rules and best practices to follow when specifying naming contexts in LDAP partial replication. It contains the following topics:

40.1.9.1 Included and Excluded Naming Contexts in LDAP Replication Filtering

In LDAP-based replication, you can include a given naming context for replication and exclude one or more of the subtrees within that naming context from replication. You can also exclude from replication one or more of the attributes in that naming context.

In LDAP-based replication, only naming contexts explicitly specified as included are replicated. In Oracle Database Advanced Replication, however, all naming contexts are included by default.

40.1.9.2 Attributes that Control Naming Contexts

The attributes that control naming contexts are described in Section 42.1.5, "The Replication Naming Context Object Entry." If you use the Replication Wizard in Oracle Enterprise Manager Fusion Middleware Control to set up replication, you set these attributes on the Scope page.

40.1.9.3 Rules for LDAP Replication Filtering

When two or more naming context objects are configured for replication, the filtering rules are as follows:

  1. The overall included naming context is the union of all included naming contexts defined in each naming context object.

  2. The overall excluded naming contexts is the union of all excluded naming contexts defined in each naming context object.

  3. The attribute exclusions in a naming context object are specific only to that naming context object.

  4. If there is a conflict between an included naming context and an excluded naming context, the excluded naming context overrules the included naming context. For example, if an included naming context in naming context object A is a subtree of an excluded naming context specified in another naming context object, B, the subtrees specified in orclexcludednamingcontexts of naming context object B are not replicated. That is, replication filtering in naming context object A is ignored.

  5. If you configure partial replication between two different versions of Oracle Internet Directory (for example 10g (10.1.4.0.1) and 11g Release 1 (11.1.1)), then you cannot exclude a naming context. Instead, you must explicitly specify the naming contexts to be replicated as included naming contexts.

40.1.9.4 Examples of LDAP Replication Filtering

The discussion in this section relies on the sample naming context illustrated in Figure 40-1. A partial list of user attributes is shown under cn=user1, cn=user2, and cn=user1000.

Figure 40-1 A Sample Naming Context

This illustration is described in the text.

See Also:

"Replication Schema Elements" in Oracle Fusion Middleware Reference for Oracle Identity Management for descriptions of the attributes in the replication naming context entry

The following examples show how these rules work:

Scenario A: The Included Naming Context in One Naming Context Object Is a Subtree of the Included Naming Context in Another Naming Context Object

In this scenario, the included naming context in naming context object #2 is a subtree of the included naming context in object #1.

Naming Context Object #1

dn:cn=namectx001,
 cn=replication namecontext,
 orclagreementid=unique_identifier_of_the_replication_agreement,
 orclreplicaid=unique_identifier_of_the_supplier,
 cn=replication configuration
orclincludednamingcontexts: cn=mycompany

Naming context object #1 includes the entire DIT under cn=myCompany, as shown in Figure 40-2.

Figure 40-2 Naming Context Object #1

The entire DIT is included.

Naming Context Object #2

dn:cn=namectx002,
 cn=replication namecontext,
 orclagreementid=unique_identifier_of_the_replication_agreement,
 orclreplicaid=unique_identifier_of_the_supplier,
 cn=replication configuration
orclincludednamingcontexts: cn=hr,c=us,cn=mycompany
orclexcludednamingcontexts: cn=user1,cn=hr,c=us,cn=mycompany
orclexcludedattributes: userPassword

Naming context object #2 includes the DIT under cn=hr,c=us,cn=mycompany, but excludes cn=user1 and the attribute userPassword, as shown in Figure 40-3.

Figure 40-3 Naming Context Object #2

This illustration is described in the text.

The result of combining naming context objects #1 and #2 is shown in Figure 40-4.

Figure 40-4 Result of Combining Naming Context Objects #1 and #2

This illustration is described in the text.

In this scenario, the naming context that is replicated is the highest one specified in the orclincludednamingcontexts attribute. Any excluded naming contexts are not replicated. All changes under the subtree cn=mycompany are replicated, except for cn=user1,cn=hr,c=us,cn=mycompany and the attribute userPassword under cn=hr,c=us,cn=mycompany, which are excluded. The attribute userPassword under the rest of the DIT, however, is not excluded from replication because exclusion of userPassword was specified only for naming context object #2, which only included the DIT under cn=hr.

Scenario B: The Included Naming Context in One Naming Context Object Is a Subtree of An Excluded Naming Context in Another Naming Context Object

In this scenario, the excluded naming context in naming context object #4 is a subtree of the excluded naming context defined in naming context object #3.

Naming Context Object #3

dn:cn=namectx001,cn=replication namecontext,
 orclagreementid=identifier,orclreplicaid=supplier,cn=replication configuration
orclincludednamingcontexts: cn=mycompany
orclexcludednamingcontexts: c=us,cn=mycompany     

Naming context object #3 excludes everything under c=us,cn=mycompany, as shown in Figure 40-5.

Figure 40-5 Naming Context Object #3

Everything under cn=us is excluded

Naming Context Object #4

dn:cn=namectx002,cn=replication     
 namecontext,orclagreementid=identifier,orclreplicaid=supplier,
 cn=replication configuration
orclincludednamingcontexts: cn=hr, c=us,cn=mycompany
orclexcludednamingcontexts: cn=user1,cn=hr,c=us,cn=mycompany
orclexcludedattributes: userPassword

Naming context object #4 includes the DIT under cn=hr,c=us,cn=mycompany but excludes user1, and the userPassword attribute for all users, as shown in Figure 40-6.

Figure 40-6 Naming Context Object #4

This illustration is described in the text.

The result of combining naming context objects #3 and #4 is shown in Figure 40-7.

Figure 40-7 Result of Combining Naming Context Objects #3 and #4

Result of Combining Naming Context Objects #3 and #4

In this scenario, the included naming context specified in naming context object #4 is not replicated. That naming context is a subtree of a specified excluded naming context in naming context object #3. In this case, naming context object #4 is ignored, and no changes under cn=hr,c=us,cn=mycompany are replicated.

40.1.9.5 Rules for Managing Naming Contexts and Attributes

The following naming contexts cannot be replicated:

  • DSE root-specific entry

  • orclagreementid=000001,cn=replication configuration

  • cn=subconfigsubentry

  • cn=Oracle Internet Directory

  • cn=subregistrysubentry

The following naming contexts cannot be excluded from replication:

  • cn=catalogs

  • cn=subschemasubentry

  • cn=oracleschemaversion

  • cn=replication configuration

The following attributes cannot be excluded from replication whether they are mandatory or optional. Even if you specify attributes in this list for exclusion from replication, they are always replicated.

  • orclguid

  • creatorsname

  • createtimestamp

  • cn

  • dn

  • attributetypes

  • objectclasses

  • objectclass

  • orclindexedattribute

  • orclproductversion

You cannot exclude mandatory attributes from replication. For example, suppose that you have an object class named my_object_class, which includes the following attributes: mandatory_attribute_1, optional_attribute_1, and optional_attribute_2. In this case, you cannot exclude from replication mandatory_attribute_1.

If you attempt to exclude from replication an attribute that is a mandatory attribute for an entry, replication server still replicates that attribute.

In partial replication, when a naming context is changed from included to excluded using the moddn operation, the replication server deletes the naming context at the consumer. Similarly, if the naming context is changed from excluded to included by using modn at the supplier, then the replication server synchronizes the entire naming context from supplier to consumer.

40.1.9.6 Optimization of Partial Replication Naming Context for Better Performance

You must plan partial replication carefully to avoid degrading the performance of the replication process. For best performance, use as few naming context objects as possible. For example, the combined use of naming context objects #5 and #6 fulfills the same requirement as the use of naming context object #7, but using naming context object #7 provides better performance.

This section contains these examples:

Naming Context Object #5

cn=namectx001,cn=replication namecontext,orclagreementid=identifier,orclreplicaid=supplier,cn=replication configuration
orclincludednamingcontexts: cn=mycompany
orclexcludednamingcontexts: c=europe,cn=mycompany
orclexcludedattributes: userPassword

Naming context object #5 is shown it Figure 40-8. It includes the DIT under cn=mycompany, but excludes everything under c=europe. It also excludes the attribute userPassword.

Figure 40-8 Naming Context Object #5

This illustration is described in the text.

Naming Context Object #6

cn=namectx002,cn=replication namecontext,orclagreementid=<id>,orclreplicaid=<supplier>,cn=replication configuration
orclincludednamingcontexts: cn=hr, c=us,cn=mycompany
orclexcludednamingcontexts: cn=user1,cn=hr, c=us,cn=mycompany
orclexcludedattributes: userPassword

Naming context object #6 is shown in Figure 40-9. It includes the DIT under cn=hr, c=us, cn=mycompany but excludes user1 and the attribute userPassword.

Figure 40-9 Naming Context Object #6

This illustration is described in the text.

If naming context objects #5 and #6 are combined, then all changes under cn=mycompany are replicated, except for c=europe,c=mycompany, cn=user1,cn=hr,c=us,cn=mycompany, and the attribute userPassword.

You could fulfill the same requirement, however, by using naming context object #7. Using a single naming context object provides better partial replication performance.

Naming Context Object #7

cn=namectx001,cn=replication namecontext,orclagreementid=identifier,orclreplicaid=supplier,cn=replication configuration
orclincludednamingcontexts: cn=mycompany
orclexcludednamingcontexts: c=europe,cn=mycompany
orclexcludednamingcontexts: cn=user1,cn=hr, c=us,cn=mycompany
orclexcludedattributes: userPassword

Naming context object #7 is shown in Figure 40-10.

Figure 40-10 Naming Context Object #7

Naming Context Object #7

40.2 Converting an Advanced Replication-Based Agreement to an LDAP-Based Agreement

You can convert an existing Oracle Database Advanced Replication-based agreement between two or more nodes to an LDAP multimaster agreement by using remtool -asr2ldap. The tool prompts you for information. For example:

remtool -asr2ldap
Enter replication administrator's name       : repadmin 
 
Enter replication administrator's password   : 
Enter global name of MDS                     : inst1.regress.rdbms.dev.example.com      
 Directory Replication Group (DRG) details :
 
-------- ------------- ----------------------- ------------- ------------- ----
Instance Host Name     Global Name             Version       Replicaid     Site
Name                                                                       Type
-------- ------------- ----------------------- ------------- ------------- ----
tst1     stacu14       INST1.REGRESS.RDBMS.DEV OID 11.1.1.0. stacu14_tst1  MDS
tst12    stacu14       INST2.REGRESS.RDBMS.DEV OID 11.1.1.0. stacu14_tst12 RMS
-------- ------------- ----------------------- ------------- ------------- ----
Do you want to continue? [y/n] : y     
 
------------------------------------------------------------------------------
Migrating ASR agreement to LDAP MM agreement...
 
Enter "SYSTEM" user password for "INST2.REGRESS.RDBMS.DEV.EXAMPLE.COM" database at "stacu14" host :       
Enter "SYSTEM" user password for "INST1.REGRESS.RDBMS.DEV.example.com" database at "stacu14" host :       
------------------------------------------------------------------------------
ASR setup has been cleaned up.------------------------------------------------------------------------------
 

40.3 Setting Up an LDAP-Based Replication Agreement by Using the Replication Wizard

You configure a one-way, two-way, or multimaster LDAP replica by using the Replication Wizard in Oracle Enterprise Manager Fusion Middleware Control.

Note:

You cannot use the Replication Wizard in Oracle Enterprise Manager Fusion Middleware Control to configure an Oracle Database Advanced Replication-based replication agreement. You must do that from the command line.

You configure an LDAP replication agreement as follows.

  1. From the Oracle Internet Directory menu on the home page, select Administration, then Replication Management.

  2. You are prompted to log into the replication DN account. Provide the host, port, replication DN, and replication DN password. If anonymous binds are enabled on this OID component, the replication DN, host, and port fields fill in automatically and are greyed out. You only need to enter the password.

  3. Click the Create icon.

  4. On the Type screen, select the replication type: One Way Replication, Two Way Replication, or Multimaster Replication.

  5. Click Next. The Replicas screen displays the replication type you selected.

  6. Provide an agreement name. This must be unique across all the nodes.

  7. For one way or two way replication, enter the host, port, user name (replication DN), and replication password for the consumer node. Fields for the supplier node are populated and greyed out.

    For multimaster replication, enter the host, port, user name (replication DN), and replication password for the secondary nodes. Fields for the primary node are populated and greyed out.

  8. Click Next to go the Settings page.

  9. In the LDAP Connection field, select Keep Alive if you want the replication server to use same connection for performing multiple LDAP operations. Select Always Use New Connection if you want the server to open a new connection for each LDAP operation.

  10. Enter the Replication Frequency.

  11. Enter the Human Intervention Queue Schedule. This is the interval, in seconds, at which the directory replication server repeats the change application process.

  12. If you have specified Two Way Replication or Multimaster Replication as the agreement type, the settings page contains a section called Replication Server Start Details. You can select Start Server to start the server instance and you can enable bootstrap by selecting Enable Bootstrap. First select the host, then select Instance Name and Component Name for that host. Then you can select Start Server or Enable Bootstrap or both.

  13. Click Next to go to the Scope page. The default primary naming context is filled in.

  14. To exclude a secondary naming context within the default primary naming context, select the primary naming context and click the Create button. Then proceed to Step 16.

  15. To create another primary naming context, click the Create Primary Naming Context button. This invokes the Primary Naming Context dialog.

    To specify a primary naming context, either enter the DN manually in the Primary Naming Context field or click Select and browse to the DN you want to use as your primary naming context. Select the container and click OK.

  16. To exclude a secondary naming context, click the Add icon below the Excluded Secondary Naming Contexts field. This invokes the Select Secondary Naming Context to be Excluded dialog. Select the naming context and click OK. The naming context appears in the Excluded Secondary Naming Contexts field.

  17. To exclude an attribute, click the Add icon below the ExcludedAttributes field. This invokes the Select Excluded Attributes screen. Select the attributes you want to exclude and click OK. The attribute now appears in the Excluded Attributes field.

  18. Click OK. The primary naming context is now listed on the Scope page.

  19. Click Next. The Summary page displays a summary of the replication agreement you are about to create.

  20. Click Finish to create the replication agreement.

40.4 Testing Replication by Using Oracle Directory Services Manager

Use Oracle Directory Services Manager to test directory replication by doing the following:

  1. Invoke Oracle Directory Services Manager and connect to the Oracle Internet Directory server as described in Section 7.4.5, "Invoking Oracle Directory Services Manager."

  2. From the task selection bar, select Data Browser.

  3. Create a single entry on the MDS node, as described in Section 13.2.6, "Adding a New Entry by Using Oracle Directory Services Manager."

    The identical entry appears in approximately 1 to 10 minutes on the RMS. You can adjust the timing in the replication server configuration set entry. If entries are modified on any nodes in the DRG, then the changes are replicated.

40.5 Setting Up an LDAP-Based Replication by Using the Command Line

This section contains these topics:

40.5.1 Copying Your LDAP Data by Using ldifwrite and bulkload

You can use ldifwrite and bulkload to copy LDAP data from one host to another. Use the ldifwrite utility to back up LDAP data with operational attributes preserved. After this is done, use the bulkload utility to load data to all replicas in a group.

Use bulkload with the check="TRUE", generate="TRUE", and restore="TRUE" arguments, and then with the load="TRUE" argument. Preserve the operational attributes by using the same intermediate files (generated by using the generate="TRUE" argument) for all replicas. You can load multiple replicas in the same invocation of the bulkload command by using connect="connect_string" with the appropriate connect string for each replica.

Using this method can take a long time for a directory with one million entries.

40.5.2 Setting Up an LDAP-Based Replica with Customized Settings

To establish customized settings, you must first install the new node. To do so, follow the instructions in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

After configuring LDAP-based replication with remtool, you can customize the namingcontext defining what is replicated for that LDAP-based node.

There are two ways to set up an LDAP-based replica with customized setting, based on how you will migrate the data from the directory:

  • Use the command-line tools. Use ldifwrite to backup the data from the supplier replica, then use bulkload to restore the data to the consumer replica

  • Use automatic bootstrapping. This is a replication server feature that automatically bootstrap the data from the supplier replica to the consumer replica, based upon replication configuration.

Table 40-1 compares these two methods.

Table 40-1 Data Migration Using ldifwrite/bulkload versus Automatic Bootstrapping

Migration Using ldifwrite/bulkload Migration Using Automatic Bootstrapping

Manual procedure

Faster performance

Good for a large amount of data

Automatic procedure

Uses the filtering capability of partial replication

Good for a smaller number of entries


If automatic bootstrapping is your chosen data migration method, customize your LDAP-based replica using Section 40.5.2.1, "Setting Up an LDAP-Based Replica by Using Automatic Bootstrapping."

If ldifwrite/bulkload is your chosen data migration method, configure your LDAP-based replica using Section 40.5.2.2, "Setting Up an LDAP-Based Replica by Using the ldifwrite Tool."

40.5.2.1 Setting Up an LDAP-Based Replica by Using Automatic Bootstrapping

The following eight tasks enable you to configure an LDAP-based replica by using automatic bootstrapping. They are explained in the paragraphs that follow this list.

40.5.2.1.1 Task 1: Identify and Start the Directory Server on the Supplier Node

Identify the supplier for an LDAP-based replica. The supplier can be

  • A directory that is not a member of any replication group

  • A node of a multimaster replication group

  • Another LDAP-based replica

Make sure the Oracle Internet Directory server is started on the Supplier node. To start the directory server, type the following command:

opmnctl startproc ias_component=oid1
40.5.2.1.2 Task 2: Create the New Consumer Node by Installing Oracle Internet Directory

Install a new Oracle Internet Directory on the replica, as documented in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

40.5.2.1.3 Task 3: Back Up the Metadata from the New Consumer Node

Before configuring the new node as an LDAP-based replica with customized settings, you must first migrate its metadata to the supplier node, as follows:

  • Make sure the Oracle Internet Directory server is up and running on both the supplier node and the new node created in Task 2, so that the backup process (remtool –backupmetadata) can succeed.

  • From the newly created node, run the following command:

    remtool –backupmetadata \
            –replica "new_node_host:new_node_port" \
            –master "master_host:master_port" 
    

    where master_host:master_port are the hostname and port number for the desired replica's supplier. you are prompted for replication DN password.

    Note:

    If Oracle Delegated Administration Services is not configured, you might see an error message similar to this when you run remtool with the -backupmetadata option:

    Failed to add "orclApplicationCommonName=ias.example.com,
    cn=IAS Instances, cn=IAS, cn=Products, cn=OracleContext" 
    as "uniquemember" to entry "cn=Associated Mid-tiers,
    orclapplicationcommonname=DASApp, cn=DAS,cn=products,
    cn=OracleContext at replica ldap://myhost:3060
    

    Please ignore this error message.

    See Also:

    The remtool command-line tool reference in Oracle Fusion Middleware Reference for Oracle Identity Management for more information about remtool options, including -backupmetadata.

  • Apart from loading the metadata into master replica, this command creates a file named ocbkup.new_replica_id.TO.master_replicaid.timestamp.ldif containing the metadata as back up. This file is created under the ORACLE_INSTANCE /diagnostics/logs/OID/tools directory. This file contains the changes made to master replica in LDIF format, a copy of the SSO container entry [orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO, cn=Products, cn=OracleContext] and DAS URL container entry [cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContext].

  • If the metadata backup succeeds, it shows the following message in the terminal:

    Backup of metadata will be stored in ORACLE_INSTANCE/diagnostics
     /logs/OID/tools/ocbkup.replicaid_pilot.TO.replcicaid_master.timestamp.ldif.
    
    Metadata copied successfully.
    

    The message contains the path of your ORACLE_INSTANCE and filename.

  • If the metadata backup is unsuccessful, the ORACLE_INSTANCE/diagnostics/logs/OID/tools/remtool.log file contains error messages. If you invoked remtool from a terminal, error messages appear on that terminal.

40.5.2.1.4 Task 4: Add an LDAP-Based Replica by Using the Replication Environment Management Tool

To add a replica, enter the following on the consumer replica:

remtool -paddnode [-v] [-bind supplier_host_name:port]

you are prompted for the replication_dn_password.

The remtool utility prompts for agreement type. Select One-Way, Two-Way, or Multimaster LDAP, depending on which type of replica you are adding.

you are prompted for the replica ID of the supplier. This is the value of the attribute orclreplicaid in the root DSE entry. To find the value to supply, type:

ldapsearch -D cn=orcladmin -q  -p port -b "" -s base "objectclass=*" orclreplicaid

you are prompted for the list of available naming contexts in the supplier replica. If you are planning to set up partial replication between server instances running different versions of Oracle Internet Directory, enter e.

After remtool has completed successfully, add a separate naming context for each subtree to be replicated, as follows:

  1. Determine the replica ID of the supplier and consumer replica nodes by executing the following search command on both nodes:

    ldapsearch -h host -p port -D cn=orcladmin -q -b "" \
       -s base "objectclass=*" orclreplicaid
    
  2. Determine the replication agreement entry, which is of the form:

    "orclagreementid=unique_identifier_of_the_replication_agreeement,orclreplicaid=supplier_replica_id,cn=replication configuration"
    

    To find it, type:

    ldapsearch -D cn=orcladmin -q -h supplier_host -p supplier_port \
       -b "orclreplicaid=supplier_replica_id,cn=replication configuration" \
       -s sub "(&(orclreplicadn=*consumer_replica_id*)(objectclass=orclreplagreemententry))" dn
    
  3. For each naming context that you plan to include in replication, add an entry like the following on both the consumer and supplier replica nodes. The following LDIF file specifies a naming context (subtree) to be included in replication and a some attributes to exclude from replication.

    dn: cn=includednamingcontext000002,
     cn=replication namecontext,orclagreementid=000003,
     orclreplicaid=stajv18_oid10143,cn=replication configuration
    objectclass: top
    objectclass: orclreplnamectxconfig
    orclincludednamingcontexts: cn=users,dc=small,dc=com
    orclexcludedattributes: userpassword
    orclexcludedattributes: telephonenumber
    cn: includednamingcontext000002
    

    Add the LDIF file to Oracle Internet Directory on the consumer and supplier replica using the following LDAP add command:

    ldapadd -D cn=orcladmin -q -h host -p port -v -f ldif_file
    
  4. Repeat Step3 for each naming context (subtree) to be configured in partial replication.

See Also:

40.5.2.1.5 Task 5: On the Consumer, Configure the Consumer Replica for Automatic Bootstrapping

To use the automatic bootstrap capability, on the consumer, set the orclReplicaState attribute of the consumer replica subentry to 0 as follows:

  1. Edit the sample file mod.ldif as follows:

    Dn: orclreplicaid=unique_replicaID_of_consumer, cn=replication configuration
    Changetype:modify
    replace:orclReplicaState
    OrclReplicaState: 0
    

    Note:

    On Windows systems, ensure that the replication server is not running before you enable bootstrapping by changing the value of orclReplicaState to 0.

  2. Use ldapmodify at the consumer to update the consumer replica's subentry orclreplicastate attribute.

    ldapmodify –D "cn=orcladmin" -q -h consumer_host -p port -f mod.ldif
    

    See Also:

    Chapter 43, "Managing and Monitoring Replication" for more information about the bootstrap capability of the LDAP-based replication

40.5.2.1.6 Task 6: Optional: Change Default Replication Parameters

You can change the default parameters for replication agreements and for the replica subentry.

40.5.2.1.7 Task 7: Ensure the Directory Replication Servers are Started

The exact procedure for starting the replication servers depends on whether this is a one-way or a two-way replica or multimaster replica.

  • For one-way LDAP replication, you must start the replication server at the consumer. For example, to start the replication server at oid1, type:

    oidctl connect=connStr server=oidrepld instance=1 \
      name=asinst_1 component name=oid1 \
      flags="-h consumer_host -p consumer_port" start
    

    Note:

    If you are deploying a single master with read-only replica consumers, you can reduce performance overhead by turning off conflict resolution. To do so, change the value of orclconflresolution to 0 by using the following ldif file with ldapmodify:

    dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry   
     changetype: modify
     replace: orclconflresolution
     orclconflresolution: 0 
    
  • For two-way or multimaster LDAP replication, you must start the Oracle Internet Directory replication server at each node, as follows:

    oidctl connect=connStr server=oidrepld instance=1 \
       name=instance_name componentname=component_name flags="-h \
       LdapHost -p LdapPort" start
    

When the replication server is started, it starts to bootstrap the data from the supplier to the consumer. After the bootstrap has completed successfully, the replication server automatically change to ONLINE mode (orclreplicastate=1) to process changes from the supplier to the consumer. You can monitor the value of orclreplicastate by using the following command line:

ldapsearch -p port-h host -D cn=orcladmin -q \
  -b "orclreplicaid=unique_replicaID_of_consumer, cn=replication configuration" \
  -s base "objectclass=*" orclreplicastate 
40.5.2.1.8 Task 8: If Oracle Delegated Administration Services or Oracle Single Sign-On Are Installed on the New Node, Restore Their Entries in the New Node's Directory

The entries for Oracle Delegated Administration Services and Oracle Single Sign-On must refer to the local instances of these services. However, the initial replication download from the supplier to the consumer creates these entries with values replicated from the supplier. If these services are in fact configured on the consumer node, then these values need to be replaced by the correct information appropriate to the consumer node.

  • If the Delegated Administration Service (DAS) is configured on the consumer node, it must be restored using the following steps:

    1. In the ocbkup.new_replicaid.TO.master_replicaid.timestamp.ldif file created by Task 3, locate and copy the DAS URL. The DN of the DAS URL container entry is "cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContext". It is usually the next-to-last entry in the file.

    2. Create an LDIF file called change_das_url.ldif with the following contents:

      dn: cn=OperationURLs,cn=DAS,cn=Products,cn=OracleContext
      changetype: modify
      replace: orcldasurlbase
      orcldasurlbase: copy_paste_the_URL_from_backup_file
      
    3. Execute the following command to change the DAS URL:

      ldapmodify –p consumer_port -h consumer_host -D super_user_DN \
                 -q -f change_das_URL.ldif
      
  • Similarly, if Single Sign-on (SSO) is configured on the consumer node, it must be restored using the following steps:

    1. In the ocbkup.timestamp.dat file created by Task 3, locate and copy the SSO container entry. Copy only the attributes shown in step 2. The DN of the SSO container entry is "orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO, cn=Products, cn=OracleContext". It is usually the last entry in the file.

      See Also:

      Oracle Application Server Single Sign-On Administrator's Guide in the 10g (10.1.4.0.1) library.

    2. Create an LDIF file add_SSO_container.ldif with the following contents:

      dn: orclApplicationCommonName=ORASSO_SSOSERVER,
       cn=SSO,cn=Products,cn=OracleContext
      orclapplicationcommonname: ORASSO_SSOSERVER
      orclappfullname: ORASSO_SSOSERVER
      orclversion: 10.1.2.0.0
      objectclass: orclApplicationEntity
      objectclass: top
      userpassword: userpassword_copied_from_backup_file
      

      Note:

      Do not copy the authpassword;oid, createtimestamp, creatorsname, modifiersname, modifytimestamp, or orclguid attributes.

    3. Execute the following command to add the SSO container entry:

      ldapadd –p consumer_port -h consumer_host -D super_user_DN \
              -q -f add_SSO_container.ldif
      
    4. Create an LDIF file mod.ldif with the following contents:

      dn: cn=OracleUserSecurityAdmins,cn=Groups,cn=OracleContext
      changetype:modify 
      add: uniquemember 
      uniquemember: orclApplicationCommonName=ORASSO_SSOSERVER,
       cn=SSO,cn=Products,cn=OracleContext
       
      dn: cn=verifierServices, cn=Groups,cn=OracleContext
      changetype:modify 
      add: uniquemember
      uniquemember: orclApplicationCommonName=ORASSO_SSOSERVER,
       cn=SSO,cn=Products,cn=OracleContext
      
    5. Execute the following command to apply mod.ldif:

      ldapmodify -p consumer_port -h consumer_host -D super_user_DN \
                 -q -f mod.ldif
      
    6. Using a browser, test the Oracle Delegated Administration Services and Oracle Single Sign-On pages.

      To test Oracle Delegated Administration Services, try to log in as the admin user "orcladmin" on the Oracle Delegated Administration Services page, http(s)://new_node_hostname:new_node_http_port/oiddas/. If you cannot log in, see the troubleshooting appendix in Oracle Identity Management Guide to Delegated Administration. in the 10g (10.1.4.0.1) library.

      To test Oracle Single Sign-On, try to log in as the super admin user "orcladmin" on the Oracle Single Sign-On page, http(s)://new_node_hostname:new_node_http_port/pls/orasso/. If you cannot log in, see the troubleshooting appendix in Oracle Application Server Single Sign-On Administrator's Guide. in the 10g (10.1.4.0.1) library.

40.5.2.2 Setting Up an LDAP-Based Replica by Using the ldifwrite Tool

This section discuss the general tasks you perform when configuring an LDAP-based replica by using the ldifwrite tool. It contains these topics:

40.5.2.2.1 Task 1: Start the Directory Server on Both the Supplier and the Consumer Nodes
  1. Identify the supplier for an LDAP-based replica. The supplier can be:

    • A directory that is not a member of any replication group

    • A node of a multi-master replication group

    • Another LDAP-based replica

    Make sure the Oracle Internet Directory server is started on the Supplier node. To start the directory server, type the following command:

    opmnctl startproc ias_component=oid1
    
  2. Identify the consumer node, which must be a new Oracle Internet Directory install. To install a new Oracle Internet Directory as a Master, follow the directions in Oracle Fusion Middleware Installation Guide for Oracle Identity Management Make sure the Oracle Internet Directory server is started on the new consumer node. To start the directory server, type the following command:

    opmnctl startproc ias-component=oid1
    
40.5.2.2.2 Task 2: Back Up the Metadata from the New Consumer Node

Before configuring the consumer as an LDAP-based replica with customized settings, you must first migrate its metadata to the supplier node, as follows:

  • Make sure the Oracle Internet Directory server is up and running on both the supplier node and the new node created in Task 2, so that the backup process (remtool –backupmetadata) can succeed.

  • From the consumer node, run the following command:

    remtool –backupmetadata \
            –replica "consumer_host:consumer_port" \
            –master "supplier_host:supplier_port"   
    

    you are prompted for the passwords.

  • Apart from loading the metadata into master replica, this tool creates a file named ocbkup.consumer_replica_id.TO.supplier_replica_id.timestamp.dat containing the metadata as back up. This file is created in the ORACLE_INSTANCE/diagnostics/logs/OID/tools directory. This file contains the changes made to the master replica in LDIF format, a copy of SSO container entry [orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO, cn=Products, cn=OracleContext] and DAS URL container entry [cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContext].

  • If the metadata backup succeeded, remtool displays the following message in the terminal:

    Backup of metadata will be stored in ORACLE_INSTANCE/diagnostics
     /logs/OID/tools/ocbkup.replicaid_pilot.TO.replcicaid_master.timestamp.ldif.
    
    Metadata copied successfully.
    

    The message contains the path of your ORACLE_INSTANCE.

    The message contains the actual path of your ORACLE_INSTANCE and filename.

    If the metadata backup is unsuccessful, the ORACLE_INSTANCE/diagnostics/logs/OID/tools/remtool.log file contains error messages. If you invoked remtool from a terminal, error messages appear on that terminal.

40.5.2.2.3 Task 3: Change the Directory Server at the Supplier to Read-Only Mode

To ensure data consistency, change the directory server on the supplier node to read-only. To switch the server from read/write to read-only mode, use one of the procedures in Section 15.2, "Changing Server Mode."

40.5.2.2.4 Task 4: Add an LDAP-Based Replica by Using the Replication Environment Management Tool

To add a replica, enter the following on the consumer replica:

remtool -paddnode [-v] [-bind supplier_host_name:port]

you are prompted for the replication_dn_password. The remtool utility prompts for agreement type. Select One-Way or Two-Way LDAP, depending on which type of replica you are adding.

See Also:

The remtool command-line tool reference in Oracle Fusion Middleware Reference for Oracle Identity Management for more information about the Replication Environment Management Tool

40.5.2.2.5 Task 5: Back Up the Naming Contexts to Be Replicated

If there is a large number of entries in the naming contexts that you want to replicate to the LDAP-based replica, then Oracle recommends that you back up these naming contexts at the supplier node and then load them to the LDAP-based replica.

To back up the naming contexts:

  1. Identify the replication agreement DN created in "Task 4: Add an LDAP-Based Replica by Using the Replication Environment Management Tool".

    ldapsearch -h supplier_host -p port \
               -b "orclreplicaid=supplier_replicaID,cn=replication configuration" \
               -s sub "(orclreplicadn= orclreplicaid=consumer_replica_ID, \
                        cn=replication configuration)" dn
    
  2. On the supplier, ensure that ORACLE_INSTANCE is set, the use the following command to get the data from the supplier. Data loaded into the file will be based on the agreement configured:

    ldifwrite connect="connect_string_of_sponsor_node" \
              baseDN="replication_agreement_dn_retrieved_in_step_1" \
              file="name_of_output_LDIF_file"
    

    See Also:

40.5.2.2.6 Task 6: Change the Directory Server at the Supplier to Read/Write Mode

If you performed "Task 3: Change the Directory Server at the Supplier to Read-Only Mode", then change the directory server on the supplier back to read/write mode. Use one of the procedures in Section 15.2, "Changing Server Mode."

40.5.2.2.7 Task 7: Load the Data on the New Consumer

To do this:

  1. If there are multiple files, then combine them into one file—for example, backup_data.ldif.

  2. If naming contexts exist on the LDAP-based consumer replica, then remove them by using bulkdelete. Ensure ORACLE_INSTANCE is set, then enter the following:

    bulkdelete connect="connect_string_of_replica" baseDN="naming_context" 
    

Perform this step for each naming context that was backed up in "Task 5: Back Up the Naming Contexts to Be Replicated".

On the consumer, load the data to the replica by using bulkload in the append mode. Ensure ORACLE_INSTANCE is set, then enter the following:

bulkload connect="connect_string_of_replica" append="TRUE" check="TRUE" \
   generate="TRUE" restore="TRUE" file="backup_data.ldif"

bulkload connect="connect_string_of_replica" load="TRUE"

Note:

If you load data from an earlier version of Oracle Internet Directory, such as 10g Release 2 (10.1.2.0.2) onto a node running 11g Release 1 (11.1.1), you must update the password policy entries as described in Section 40.5.3, "Password Policy and Fan-out Replication."

See Also:

40.5.2.2.8 Task 8: If Oracle Delegated Administration Services or Oracle Single Sign-On Are Installed on the New Node, Restore Their Entries in the New Node's Directory

Follow the procedure described in "Task 8: If Oracle Delegated Administration Services or Oracle Single Sign-On Are Installed on the New Node, Restore Their Entries in the New Node's Directory".

40.5.2.2.9 Task 9: Optional: Change Default Replication Parameters

You can change the default parameters for replication agreements, for the replica subentry, and for the replication naming context configuration objects.

40.5.2.2.10 Task 10: Ensure the Directory Replication Servers are Started

The exact procedure for starting the replication servers depends on whether this is a one-way or a two-way replica.

  • For one-way LDAP replication, you must start the replication server at the consumer. Type:

    oidctl connect=connStr server=oidrepld instance=1 \
       name=instance_name componentname=oidComponentName \
       flags="-h LdapHost -p LdapPort" start
    

    Note:

    If you are deploying a single master with read-only replica consumers, you can reduce performance overhead by turning off conflict resolution. To do so, change the value of orclconflresolution to 0 by using the following ldif file with ldapmodify:

    dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry     
     changetype: modify
     replace: orclconflresolution
     orclconflresolution: 0  
    
  • For two-way LDAP replication, you must start the Oracle Internet Directory replication servers at both the sponsor replica and the new replica, as follows:

    1. Start or restart the replication server at the sponsor replica. Type:

      oidctl connect=connStr server=oidrepld instance=1 \
         name=instance_name componentname=component_name \
         flags="-h LdapHost -p LdapPort" start
      
    2. Start the replication server at the new replica. Type:

      oidctl connect=connStr server=oidrepld instance=1 \
         name=instance_name componentname=oidComponentName \
         flags="-h LdapHost -p LdapPort" start
      

40.5.3 Password Policy and Fan-out Replication

Oracle Internet Directory 11g Release 1 (11.1.1) supports more fine-grained password policies than in releases prior to 10g Release 2 (10.1.2.0.2). This can cause problems when a master node is an earlier version, such as 10g Release 2 (10.1.2.0.2), and the new fan-out node is 11g Release 1 (11.1.1). The password policy entries from the master node might not behave as expected when bootstrapped or migrated to the fan-out node. To correct this problem, as part of the fan-out node setup, after the data from the master is bootstrapped or migrated, you must update the password policy entries by invoking the Java class oracle.ldap.oidinstall.backend.OIDUpgradePasswordPolicies. The command-line syntax is as follows:

java –cp ORACLE_HOME/ldap/lib/oidca.jar:ORACLE_HOME/ldap/jlib/ldapjclnt10.jar \
oracle.ldap.oidinstall.backend.OIDUpgradePasswordPolicies host port bindDN \
bindPassword ORACLE_HOME[protocol] 

Table 40-2 describes the command-line parameters.

Table 40-2 Command-line Parameters to OIDUpgradePasswordPolicies

Parameter Description

host

The host on which the 11g Release 1 (11.1.1) directory server is running

port

The port on which the 11g Release 1 (11.1.1) directory server is listening. If the protocol is ssl, port must be an SSL port.

bindDN

The privileged administrative user, usually cn=orcladmin

bindPwd

The user password associated with the bindDN

ORACLE_HOME

The Oracle home for this instance of Oracle Internet Directory

protocol

An optional parameter. It should be ssl in an SSL environment


All actions performed by the tool are logged to ppUpgrade.log in the ORACLE_HOME\ldap\log directory.

Note:

Before running the tool, ensure that the appropriate environment variable is set correctly:

  • On Linux or Solaris, the LD_LIBRARY_PATH variable must include ORACLE_HOME/lib and ORACLE_HOME/network/lib.

  • On 64-bit Solaris, the LD_LIBRARY_PATH variable must include ORACLE_HOME/lib32 and ORACLE_HOME/network/lib32.

  • On Windows, the PATH variable must include ORACLE_HOME\bin and ORACLE_HOME\network\bin.

40.5.4 Deleting an LDAP-Based Replica

This section explains how to delete an LDAP-based replica. It contains these topics:

Note:

You cannot delete a replica if it is a supplier for another replica. To delete such a replica, you must first delete all its consumers from the replication group.

40.5.4.1 Task 1: Stop the Directory Replication Server on the Node to be Deleted

Stop the Oracle directory replication server by typing:

oidctl connect=connStr server=oidrepld instance=1 componentname=oidComponentName \
 flags="-h LdapHost -p LdapPort" stop

40.5.4.2 Task 2: Delete the Replica from the Replication Group

Do this by using the Replication Environment Management Tool. Enter:

remtool -pdelnode [-v] [-bind hostname:port_number]

See Also:

The remtool command-line tool reference in Oracle Fusion Middleware Reference for Oracle Identity Management

you are prompted for the replication_dn_password.

40.6 Setting Up a Multimaster Replication Group with Fan-Out

To help you set up a multimaster replication group with fan-out, this section offers an example with four systems as described in Table 40-3.

Table 40-3 Nodes in Example of Partial Replication Deployment

Node Host Name Port

Node1

mycompany1.com

3000

Node2

mycompany2.com

4000

Node3

mycompany3.com

5000

Node4

mycompany4.com

6000

Node5

mycompany5.com

7000


In this example, the user has set up the following requirements:

Figure 40-11 Example of Fan-Out Replication

Fan-Out Replication
Description of "Figure 40-11 Example of Fan-Out Replication"

To meet the first requirement in this example, we set up a multimaster replication group for Node1 and Node2. To meet the second, we set up a partial replica for Node2 and Node3, and for the third, full LDAP replication from Node2 to Node4.

This section contains these topics:

Task 1: Set up the Multimaster Replication Group for Node1 and Node2

To set up an LDAP-based multimaster replication group for Node1 and Node2, follow the instructions in Section 40.5.2, "Setting Up an LDAP-Based Replica with Customized Settings."

If you prefer to use Advanced Replication-based replication for your multimaster replication group, follow Tasks 1 through 5 in Section C.2.2, "Setting Up an Advanced Replication-Based Multimaster Replication Group."

Task 2: Configure the Replication Agreement

In the replication agreement between Node1 and Node2, specify the value for the orclExcludedNamingcontexts attribute as cn=private users,cn=mycompany. To do this:

  1. Edit the example file mod.ldif as follows:

    dn: orclAgreementID=000001,cn=replication configuration
    Changetype:modify
    Replace: orclExcludedNamingcontexts
    orclExcludedNamingcontexts: cn=private users,cn=mycompany
    
  2. Use ldapmodify to update the replication agreement orclExcludedNamingcontexts attribute at both Node1 and Node2. To do this, enter:

    ldapmodify -D "cn=orcladmin" -q -h mycompany1.com -p 3000 -f mod.ldif
    ldapmodify -D "cn=orcladmin" -q -h mycompany2.com -p 4000 -f mod.ldif
    

Task 3: Start the Replication Servers on Node1 and Node2

To do this, if you are using LDAP-based replication, follow the instructions on

If you are using Advanced replication, follow the instructions in "Task 6: Start the Replication Servers on All Nodes in the DRG" in Appendix C, "Setting Up Oracle Database Advanced Replication-Based Replication."

Task 4: Test the Directory Replication Between Node1 and Node2.

To do this, follow the instructions in Section 40.4, "Testing Replication by Using Oracle Directory Services Manager."

Task 5: Install and Configure Node3 as a Partial Replica of Node2

If you want to use the bootstrap capability of partial replication, then follow Tasks 1 through 5 in Section 40.5.2.1, "Setting Up an LDAP-Based Replica by Using Automatic Bootstrapping."

If you want to configure the replica by using the ldifwrite tool, then follow Tasks 1 through 9 in Section 40.5.2.2, "Setting Up an LDAP-Based Replica by Using the ldifwrite Tool."

Identify Node2 as the supplier and Node3 as the consumer.

Task 6: Customize the Partial Replication Agreement

To do this:

Task 7: Start the Replication Servers on All Nodes in the DRG

To do this, start the replication server at each node.

Type:

oidctl connect=connStr server=oidrepld instance=1 \
   componentname=oidComponentName flags="-h LdapHost -p LdapPort" start

Task 8: Install and Configure Node4 as a Full Replica of Node2

Since full replica replication is the default configuration when the new node is installed as an LDAP replica, use the instructions in Section 40.5, "Setting Up an LDAP-Based Replication by Using the Command Line." When the installer prompts for the supplier information, provide the supplier hostname, mycompany2.com, the supplier port, 4000, and the superuser password.

Task 9: Test the Replication from Node2 to Node4

Test this replication using the instructions in the section entitled

If you are using Advanced replication, use the instructions in the section "Task 7: Test Directory Replication" in Appendix C, "Setting Up Oracle Database Advanced Replication-Based Replication."

Task 10: Install and Configure Node5 as a Two-Way Replica of Node1

Follow the instructions in Section 40.3, "Setting Up an LDAP-Based Replication Agreement by Using the Replication Wizard" or in Section 40.5, "Setting Up an LDAP-Based Replication by Using the Command Line." Provide the supplier hostname, mycompany1.com, the supplier port, 3000, and the superuser password.

Task 11: Test the Two-Way Replication Between Node1 and Node5

Create an entry at Node1 using either Oracle Enterprise Manager or the ldapadd command-line tool. Wait for the entry to be replicated at Node5. After the entry is replicated to Node5, apply a change to that entry at Node5 using either the ldapmodify command-line tool or Oracle Enterprise Manager. The change is replicated to Node1.