41 Setting Up Replication

Understand how to perform replication for Oracle Internet Directory and how to set up LDAP-based replication and multi-master replication with fan-out.

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, see Understanding Oracle Internet Directory Replication for an introduction to basic replication concepts.

See Also:

Transport Mechanism: LDAP.

Oracle Internet Directory High Availability in High Availability Guide for information on setting up replication in high availability configurations.

This section contains the following topics:

• Introduction to Setting Up Replication

• Testing Replication by Using Oracle Directory Services Manager

• Setting Up a LDAP-Based Replication by Using the Command Line

• Scenario: Setting Up a Multimaster Replication Group with Fan-Out

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 Fusion Middleware Performing Self Service Tasks with Oracle Identity Manager in 12c Release 2 (12.2.1.3.0).

41.1 Introduction to Setting Up Replication

This section provides an overview of how to set up replication.

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

This introduction contains the following topics:

• Replication Transport Mechanisms

• Replication Setup Methods

• Bootstrap Rules for Replication

• The Replication Agreement

• Other Replication Configuration Attributes

• Replication Process and Architecture

• Rules for Configuring LDAP-Based Replication

• Replication Security

• LDAP Replication Filtering for Partial Replication

41.1.1 Replication Transport Mechanisms

Oracle Internet Directory supports LDAP-based replication transport mechanisms. It 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.

41.1.2 Replication Setup Methods

This section provides information on replication setup methods.

To setup Oracle Internet Directory replication, use one of these methods:

• Command-line Tools to Setup and Modify Replication

• Database Copy Procedure to Replicate from an Existing Host

Note:

You must use Command-line Tools to Setup and Modify Replication (ldifwrite and bulkload) for the following scenario:

• Replication for a directory that has more than 100,000 entries

41.1.2.1 Command-line Tools to Setup and Modify Replication

You can use command-line tools to set up LDAP-based replication.

Command-line setup of LDAP-based replication is described in Setting Up a LDAP-Based Replication by Using the Command Line.

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.

Note:

If you start the replication server by using the command line, then you must stop it by using the command line.

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

• 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 Reference for Oracle Identity Management for more information about the Replication Environment Management Tool

41.1.2.2 Database Copy Procedure to Replicate from an Existing Host

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 Adding a Directory Node by Using the Database Copy Procedure.

41.1.3 Bootstrap Rules for Replication

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.

See Also:

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

• LDAP Replica States

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

Note:

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

41.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 Understanding Replication Agreement Entry.

The replication agreement also contains the replication contexts. These are discussed in more detail in LDAP Replication Filtering for Partial Replication. The attributes are described in Understanding Replication Agreement Entry.

41.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 Managing Replication Configuration Attributes. Once you have set up replication, you can manage these attributes.

You can modify replication attributes by using LDAP tools. These methods are described in Managing and Monitoring Replication.

41.1.6 Replication Process and Architecture

In this section you can find reference information about replication architecture and the replication process.

See How Replication Works for detailed information about replication architecture and the replication process.

41.1.7 Rules for Configuring LDAP-Based Replication

Learn about the rules that apply to LDAP-based replication.

The rules that apply to LDAP-based replication are:

• 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.

• LDAP Multimaster replication is not backward compatible. It is only supported between replicas that are running 12c Release 2.

• 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.

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

• 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.

• More specifically, if you add a new Oracle Internet Directory 12c Release (12.2.1.3.0) 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, before adding an Oracle Internet Directory 12c Release (12.2.1.3.0) node as Node E, you must first update Nodes A, B, C and G to 12c Release (12.2.1.3.0).

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

  See Also:

  The discussion of namingcontexts in:

  • Filtering of Naming Contexts in LDAP Replication

  • Implications of LDAP-Based Partial Replication

• 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:

  Configuring Oracle Internet Directory in Installing and Configuring Oracle Internet Directory for instructions on installing Oracle Internet Directory.

• 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.

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

41.1.8 Replication Procedure for a Mixed Deployment of 10g and 11gR1 Nodes

Consider a deployment with a combination of Oracle Internet Directory 10g nodes and 11gR1 nodes.

For example:

• Two 10g nodes with a supplier node and consumer node

• Two new 11gR1 nodes (for example, nodes 1 and 2) with LDAP multimaster replication

Replication must be setup as follows:

1. Setup LDAP one-way replication from one of the 10g nodes to 11gR1 node 1.
2. Setup replication bootstrap (if less than 100,000 entries) and then start the replication server on the 11gR1 node 1.
3. When the bootstrap is complete, setup LDAP multimaster replication between 11gR1 node 1 and node 2.
4. Setup the replication bootstrap on 11gR1 node 2 and then start the replication server.

Most important, replication from the 10g node to an 11gR1 node must be setup before replication between the 11gR1 nodes is setup.

41.1.9 Replication Security

You can ensure security in replication by using authentication and SSL encryption mechanisms.

This section contains these topics:

• Authentication of the Directory Replication Server

• Use of SSL Encryption in Oracle Internet Directory Replication

41.1.9.1 Authentication of 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 $DOMAIN_HOME/config/fmwconfig/components/OID/admin/oidpwdrOracle_SID.

See Also:

The remtool command-line tool reference in 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.

41.1.9.2 Use of SSL Encryption in 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.

Note:

Starting from 12.2.1.3.0, replication server can communicate over an SSL port that is configured for one-way or two-way authentication. No-auth mode of SSL is disabled out-of-box in Oracle Internet Directory 12.2.1.3.0. To enable no-auth mode of SSL, anonymous cipher should be configured. See Configuring ODSM Connection with SSL Enabled for the LDIF file configuration.

See Also:

Configuring Secure Sockets Layer (SSL).

A sample replication entry with SSL two-way configuration for supplier node:

dn: orclreplicaid=myhost1_repl1,cn=replication configuration
orclreplicauri:ldap://myhost1:3131/
orclreplicauri;wallet:<location of auto-login wallet>
orclreplicauri;authmode:64
orclreplicatype: 0
orclreplicasecondaryuri:ldap://myhost1:3131/
objectclass:top
objectclass:orclreplicasubentry
orclreplicaid:myhost1_repl1

where orclreplicauri;authmode has the SSL authmode(values are 1/32/64 for no-auth/one-way/two-way authentication)

While bringing up oidrepld in one-way or two-way authentication mode, we need to pass value for parameters in oidctl startup command, sslauth and wurl. The sslauth is for SSL authentication mode(supports value 1/2/3 for no-auth/one-way or two-way authentication) and wurl is the location of wallet to connect to consumer node.

Sample oidctl command to bring up replication server in two-way authentication connectivity to consumer node is:

oidctl connect=inst2 server=oidrepld inst=1 flags=" -h localhost -p 3132 -sslauth 3 -wurl<location of auto-login wallet> start”

41.1.10 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:

• Filtering of Naming Contexts in LDAP Replication

• Attributes that Control Naming Contexts

• Filtering Rules for Naming Contexts in LDAP Replication

• Scenarios of Filtering Naming Context in LDAP Replication

• Rules for Including or Excluding Naming Contexts and Attributes

• Optimization of Partial Replication Naming Context for Better Performance

See Also:

How to Decide Full or Partial Content Replication?.

41.1.10.1 Filtering of Naming Contexts in LDAP Replication

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.

41.1.10.2 Attributes that Control Naming Contexts

The attributes that control naming contexts are described in Understanding Replication Naming Context Object Entry.

41.1.10.3 Filtering Rules for Naming Contexts in LDAP Replication

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

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

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

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

• 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.

• 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.0.0)), then you cannot exclude a naming context. Instead, you must explicitly specify the naming contexts to be replicated as included naming contexts.

41.1.10.4 Scenarios of Filtering Naming Context in LDAP Replication

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

Figure 41-1 A Sample Naming Context

See Also:

Oracle Directory Replication Schema Elements in 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: Included Naming Context is a Subtree of an Included Naming Context in Another Object

• Scenario B: Included Naming Context is a Subtree of an Excluded Naming Context in Another Object

41.1.10.4.1 Scenario A: Included Naming Context is a Subtree of an Included Naming Context in Another Object

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 41-2.

Figure 41-2 Naming Context Object #1

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 41-3.

Figure 41-3 Naming Context Object #2

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

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

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.

41.1.10.4.2 Scenario B: Included Naming Context is a Subtree of an Excluded Naming Context in Another Object

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 41-5.

Figure 41-5 Naming Context Object #3

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 41-6.

Figure 41-6 Naming Context Object #4

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

Figure 41-7 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.

41.1.10.5 Rules for Including or Excluding Naming Contexts and Attributes

Oracle Internet Directory has rules to include and exclude 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.

41.1.10.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.

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 41-8. It includes the DIT under cn=mycompany, but excludes everything under c=europe. It also excludes the attribute userPassword.

Figure 41-8 Naming Context Object #5

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 41-9. It includes the DIT under cn=hr, c=us, cn=mycompany but excludes user1 and the attribute userPassword.

Figure 41-9 Naming Context Object #6

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 41-10.

Figure 41-10 Naming Context Object #7

41.2 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 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 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.

41.3 Setting Up a LDAP-Based Replication by Using the Command Line

You can setup a LDAP-based replication by using the command line.

This section contains these topics:

• Copying Your LDAP Data by Using ldifwrite and bulkload

• Setting Up an LDAP-Based Replica with Customized Settings

• Deleting an LDAP-Based Replica

See Also:

Replication Direction: One-Way, Two-Way, or Peer to Peer

41.3.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.

See Also:

• Performing Bulk Operations

• Backing Up and Restoring Oracle Internet Directory

• Command-Line Tools Overview in Reference for Oracle Identity Management

41.3.2 Setting Up an LDAP-Based Replica with Customized Settings

To establish customized settings, you must first install the new node.

To install the new node, follow the instructions in Installing and Configuring Oracle Internet Directory.

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

See Also:

The discussion of naming contexts in Implications of LDAP-Based Partial Replication.

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 41-1 compares these two methods.

The following sections explain these methods further:

• Data Migration Using ldifwrite/bulkload versus Automatic Bootstrapping

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

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

41.3.2.1 Data Migration Using ldifwrite/bulkload versus Automatic Bootstrapping

You must use the ldifwrite/bulkload or automatic bootstrapping methods for data migration for different fitting scenarios.

Table 41-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

Note:

You must use Command-line Tools to Setup and Modify Replication (ldifwrite and bulkload) for the following scenario:

• Replication for a directory that has more than 100,000 entries

For other scenarios, you can use either migration method.

41.3.2.2 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.

• Identifying and Starting the Directory Server on the Supplier Node

• Creating the New Consumer Node by Installing Oracle Internet Directory

• Backing Up Metadata from the New Consumer Node

• Adding a LDAP-Based Replica by Using the Replication Environment Management Tool

• Configuring the Consumer Replica for Automatic Bootstrapping

• Changing Default Replication Parameters

• Ensuring the Directory Replication Servers are Started

41.3.2.2.1 Identifying and Starting the Directory Server on the Supplier Node

You can 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:

start(name='instance-name',type='OID')

41.3.2.2.2 Creating the New Consumer Node by Installing Oracle Internet Directory

Install a new Oracle Internet Directory on the replica, as documented in Installing and Configuring Oracle Internet Directory.

41.3.2.2.3 Backing Up 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, as discussed in Creating the New Consumer Node by Installing Oracle Internet Directory, 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.

  See Also:

  The remtoolcommand-line tool reference in 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 $DOMAIN_HOME /tools/OID/logs 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 $DOMAIN_HOME/tools/OID/logs/ocbkup.replicaid_pilot.TO.replcicaid_master.timestamp.ldif.
  
  Metadata copied successfully.
  

  The message contains the path of your DOMAIN_HOME and filename.

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

41.3.2.2.4 Adding a LDAP-Based Replica by Using the Replication Environment Management Tool

To add a LDAP-based 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 the previous step for each naming context (subtree) to be configured in partial replication.

See Also:

• The remtoolcommand-line tool reference in Reference for Oracle Identity Management for more information about the Replication Environment Management Tool

• LDAP Replication Filtering for Partial Replication

41.3.2.2.5 Configuring 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:

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

41.3.2.2.6 Changing Default Replication Parameters

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

See Also:

• Managing Replication Configuration Attributes

• Implications of LDAP-Based Partial Replication

41.3.2.2.7 Ensuring 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 

41.3.2.3 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:

• Starting the Directory Server on Both the Supplier and the Consumer Nodes

• Backing Up Metadata from the New Consumer Node

• Changing the Directory Server at the Supplier to Read-Only Mode

• Adding a LDAP-Based Replica by Using the Replication Environment Management Tool

• Backing Up the Naming Contexts to Be Replicated

• Changing the Directory Server at the Supplier to Read/Write Mode

• Loading the Data on the New Consumer

• Changing Default Replication Parameters

• Ensuring the Directory Replication Servers are Started

41.3.2.3.1 Starting the Directory Server on Both the Supplier and the Consumer Nodes

To 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:

   $DOMAIN_HOME/bin/startComponent.sh <instance-name>
   

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 Installing and Configuring Oracle Internet Directory Make sure the Oracle Internet Directory server is started on the new consumer node. To start the directory server, type the following command:

   $DOMAIN_HOME/bin/startComponent.sh <instance-name>
   

41.3.2.3.2 Backing Up 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, as discussed in Creating the New Consumer Node by Installing Oracle Internet Directory, 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 $DOMAIN_HOME/tools/OID/logs 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 $DOMAIN_HOME/tools/OID/logs/ocbkup.replicaid_pilot.TO.replcicaid_master.timestamp.ldif.
  
  Metadata copied successfully.
  

  The message contains the path of your DOMAIN_HOME.

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

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

41.3.2.3.3 Changing 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 Changing the Server Mode.

41.3.2.3.4 Adding a 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 Reference for Oracle Identity Management for more information about the Replication Environment Management Tool

41.3.2.3.5 Backing 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 "Adding a 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 DOMAIN_HOME 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:

   • Implications of LDAP-Based Partial Replication

   • The ldifwritecommand-line tool reference in Reference for Oracle Identity Management for more instructions on using ldifwrite to back up part of the naming context

41.3.2.3.6 Changing the Directory Server at the Supplier to Read/Write Mode

If you performed "Changing 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 Changing the Server Mode.

41.3.2.3.7 Loading the Data on the New Consumer

To load data on the new consumer:

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 DOMAIN_HOME 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 "Backing Up the Naming Contexts to Be Replicated".

On the consumer, load the data to the replica by using bulkload in the append mode. Ensure DOMAIN_HOME 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"

See Also:

• The bulkload command-line tool reference in Reference for Oracle Identity Management for instructions on using bulkload in either the default mode or the append mode

• The bulkdelete command-line tool reference in Reference for Oracle Identity Management

41.3.2.3.8 Changing Default Replication Parameters

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

See Also:

• Managing Replication Configuration Attributes

• Implications of LDAP-Based Partial Replication

41.3.2.3.9 Ensuring 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
     

41.3.3 Deleting an LDAP-Based Replica

This section explains how to delete an LDAP-based replica.

This section contains the following topics:

• Stopping the Directory Replication Server on the Node to be Deleted

• Deleting the Replica from the Replication Group

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.

41.3.3.1 Stopping 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

41.3.3.2 Deleting the Replica from the Replication Group

You can delete the replica from the replication group by using the Replication Environment Management Tool. Enter:

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

You are prompted for the password. Enter a value for replication_dn_password.

See Also:

The remtoolcommand-line tool reference in Reference for Oracle Identity Management

41.4 Scenario: Setting Up a Multimaster Replication Group with Fan-Out

The following topics describe how to set up a multimaster replication group:

• Understanding Multimaster Replication

• Setting Up the Multimaster Replication Group for Node1 and Node2

• Configuring the Replication Agreement

• Starting the Replication Servers on Node1 and Node2

• Testing the Directory Replication Between Node1 and Node2

• Installing and Configuring Node3 as a Partial Replica of Node2

• Customizing the Partial Replication Agreement

• Starting the Replication Servers on All Nodes in the DRG

• Installing and Configuring Node4 as a Full Replica of Node2

• Testing the Replication from Node2 to Node4

• Installing and Configuring Node5 as a Two-Way Replica of Node1

• Testing the Two-Way Replication Between Node1 and Node5

41.4.1 Understanding Multimaster Replication

To help you set up a multimaster replication group with fan-out, this section offers an example with four systems.

See Table 41-2.

Table 41-2 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:

• Requirement 1: Node1 and Node2 must be synchronized so that changes made on either node are replicated to the other— but the naming context cn=private users, cn=mycompany is to be excluded from this replication.

• Requirement 2: The naming context ou=Americas,cn=mycompany on node3 is to be partially synchronized from Node2 so that only changes made under ou=Americas, cn=mycompany on Node2 are replicated to Node3. The following are to be excluded from this replication:

  • Changes made under cn=customer profile, ou=Americas, cn=mycompany

  • Changes in the attribute userpassword.

• Requirement 3: Node4 is to be configured as a full replica of node 2, that is, changes to all naming contexts in Node2 are replicated (one-way) to Node4.

• Requirement 4: Node5 is to be configured as a two-way (updatable) full replica of Node1.

Figure 41-11 Example of Fan-Out Replication

Description of "Figure 41-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.

41.4.2 Setting Up the Multimaster Replication Group for Node1 and Node2

This section gives information to set up an LDAP-based multimaster replication group for Node1 and Node2,

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

41.4.3 Configuring the Replication Agreement

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

Perform the following steps:

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

41.4.4 Starting the Replication Servers on Node1 and Node2

To start replication servers on node1 and node2, if you are using LDAP-based replication, follow the instructions on

To start replication servers on node1 and node2, if you are using LDAP-based replication, follow the instructions on

41.4.5 Testing the Directory Replication Between Node1 and Node2

Follow the instructions given in this section.

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

41.4.6 Installing and Configuring Node3 as a Partial Replica of Node2

If you want to use the bootstrap capability of partial replication, then follow the instructions given in this section.

If you want to use the bootstrap capability of partial replication, then follow Tasks 1 through 5 in 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 Setting Up an LDAP-Based Replica by Using the ldifwrite Tool.

Identify Node2 as the supplier and Node3 as the consumer.

41.4.7 Customizing the Partial Replication Agreement

You can customize the partial replication agreement as described in this section.

• To achieve Requirement 2 in this example, the default replication between Node2 and Node3 must be configured first:

  In partial replication, the cn=oraclecontext naming context is replicated by default. You can choose not to replicate it by deleting it at both the supplier (Node2, mycompany2.com) and the consumer (Node3, mycompany3.com).

  ldapdelete -D "cn=orcladmin" -q -h mycompany2.com \
             -p 4000 "cn=includednamingcontext000001, \
                      cn=replication namecontext,orclagreementid=000002, \
                      orclreplicaid==node2_replica_id, \
                      cn=replication configuration"
  
  ldapdelete -D "cn=orcladmin" -q -h mycompany3.com \
             -p 5000 "cn=includednamingcontext000001, \
                      cn=replication namecontext,orclagreementid=000002, \
                      orclreplicaid==node2_replica_id, \
                      cn=replication configuration"
  

• To replicate the naming context ou=Americas,cn=mycompany, and to exclude from replication the naming context cn=customer profile, ou=Americas, cn=mycompany and the attribute userpassword, create a naming context object as follows:

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

     dn: cn=includednamingcontext000002,cn=replication namecontext,
      orclagreementid=000002,orclreplicaid=node2_replica_id,
      cn=replication configuration
     orclincludednamingcontexts: ou=Americas,cn=mycompany
     orclexcludednamingcontexts: cn=customer profile, ou=Americas, cn=mycompany
     orclexcludedattributes: userpassword
     objectclass: top
     objectclass: orclreplnamectxconfig
     

  2. Use ldapadd to add the partial replication naming context object at both Node2 and Node3.

     ldapadd -D "cn=orcladmin" -q -h mycompany2.com -p 4000 -f mod.ldif
     ldapadd -D "cn=orcladmin" -q -h mycompany3.com -p 5000 -f mod.ldif
     

• If you decide to use the automatic bootstrap capability of partial replication, then edit the example file mod.ldif and use ldapmodify to modify the partial replica orclreplicastate attribute at both Node2 and Node3, as described in "Configuring the Consumer Replica for Automatic Bootstrapping".

41.4.8 Starting the Replication Servers on All Nodes in the DRG

Start the replication server at each node before starting the replication process.

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

41.4.9 Installing and Configuring Node4 as a Full Replica of Node2

Full replica replication is the default configuration when the new node is installed as an LDAP replica.

Since full replica replication is the default configuration when the new node is installed as an LDAP replica, use the instructions in Setting Up a 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.

41.4.10 Testing the Replication from Node2 to Node4

Test this replication using the instructions in the section entitled.

Test this replication using the instructions in the section entitled.

41.4.11 Installing and Configuring Node5 as a Two-Way Replica of Node1

Follow the instructions given in this section.

Follow the instructions in Setting Up a LDAP-Based Replication by Using the Command Line. Provide the supplier hostname, mycompany1.com, the supplier port, 3000, and the superuser password.

41.4.12 Testing the Two-Way Replication Between Node1 and Node5

Follow the instructions given in this section.

Create an entry at Node1 by using 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 the ldapmodify command-line tool. The change is replicated to Node1.