Skip Headers
Oracle® Internet Directory Administrator's Guide,
10g Release 2 (10.1.2)
B14082-02
  Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

25 Oracle Internet Directory Replication Administration

Replication is the mechanism that maintains exact duplicates of specified naming contexts on multiple nodes. This chapter tells you how to install, configure, and manage replication in Oracle Internet Directory.

This chapter contains these topics:

25.1 Installing and Configuring Multimaster Replication

This section tells you how to install and configure multimaster replication groups, and how to resolve conflicts manually in them. It contains these topics:


See Also:

  • "Installing Oracle Internet Directory in Replicated Mode" in Oracle Application Server Installation Guide

  • Chapter 11, "Deploying OracleAS Cluster (Identity Management) with Multimaster Replication" in ASHIA


25.1.1 Rules for Configuring Directory Replication Based on Oracle Database Advanced Replication

The following nine rules apply to replication based on Advanced Replication (sometimes referred to as ASR):

  1. In this type of Directory Replication Group (DRG), there must be one node identified as the Master Definition Site (MDS): this is the group master. All other nodes taking part in the replication are replicas, which in database replication are termed "Remote Master Sites" (RMS). The MDS must be created as a master node, not as a replica, that is, neither as an Advanced Replication-based replica nor as an LDAP-based replica.


    Note:

    Even though it is not the central master, an Advanced Replication-based replica is sometimes called a remote master site (RMS), due to two facts. The first is that in Advanced Replication, when information is moved from one site to another, the recipient of the transferred information is called a "remote master site." The second fact is that independent changes made directly to an Advanced Replication-based replica are also replicated to all members of its group, making it a "master" during that interaction. Such a group, in which changes to any member are replicated to all other members, is called a multimaster replication group.


    See Also:


  2. When you install and configure Multimaster replication, the master node for a Directory Replication Group (DRG) and each node that is to become an Advanced Replication-based replica must be initially empty, that is, a new Oracle Internet Directory installation.


    Note:

    If the Master node is not a new installation, use the procedure described in "Adding a Node for Multimaster Replication (Oracle Database Advanced Replication Types Only)" to add replicas. That procedure will also initialize the replication group.

  3. When you add an Oracle Database Advanced Replication-based replica, the new replica must be empty. That is, Oracle Internet Directory must be newly installed.

  4. The sponsor node for each Advanced Replication-based replica can be any of the following:

    • A master node

    • An Advanced Replication-based replica of an existing multi-master DRG

    • A supplier of an LDAP replica that is not a consumer LDAP replica of any other LDAP replica

  5. An Advanced Replication-based replica cannot be a consumer of an LDAP replica.

  6. In Oracle Internet Directory 10g Release 2 (10.1.2), a node cannot be part of more than one multimaster replication group.

  7. The data replicated between servers in a directory replication group does not include DSE root-specific data, server configuration data, and replication agreement data.

  8. When an multimaster replication group is configured, the Oracle Application Server Single Sign-On database schema is automatically configured in replication.

  9. You cannot add an Oracle Internet Directory 10g Release 2 (10.1.2) node to an Oracle Internet Directory 10g (9.0.4) DRG. Instead, upgrade all 10g (9.0.4) nodes to 10g Release 2 (10.1.2), then add the new 10g Release 2 (10.1.2) node to the DRG.

25.1.2 Installing and Configuring a Multimaster Replication Group

This section discusses the general tasks you perform when installing and configuring a multimaster replication group. It contains these topics:

Preliminary Information for Installing and Configuring a Multimaster Replication Group

Task 1: Install Oracle Internet Directory as a Master on the Master Definition Site (MDS)

Task 2: Install the Oracle Internet Directory as a Replica, on the Remote Master Sites (RMS)

Task 3: Set Up Oracle Database Advanced Replication for a Directory Replication Group

Task 4 (Optional): Load Data into the Directory

Task 5: Ensure that Oracle Directory Server Instances are Started on All the Nodes

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

Task 7: Test Directory Replication


Note:

  • The instructions in this section apply to setting up replication in a group of empty nodes. They assume that there is no pre-existing directory data on any of the nodes in the DRG. For instructions on adding a node to an existing DRG, see "Adding a Node for Multimaster Replication (Oracle Database Advanced Replication Types Only)".

  • During entry replication, the directory replication server does not always preserve the spaces between RDN components in the DN. In some rare cases, it may not preserve the case of the letters in the DN.


25.1.2.1 Preliminary Information for Installing and Configuring a Multimaster Replication Group

This section describes the types of installation you need to perform to configure a multimaster replication group. It also introduces the Replication Environment Management Tool that enables you to perform various configuration tasks.

25.1.2.1.1 Oracle Internet Directory Installation

When you install Oracle Internet Directory as part of Oracle Application Server on any node, you are prompted to select a product. Choose the Oracle Application Server Infrastructure.

Later in the installation process, you are prompted to choose an installation type.

  • For multimaster replication, you need a single master definition site (MDS). For that, follow the directions in the section entitled "If you are installing Oracle Internet Directory as a Master".

  • Each other site is a replica, either an Advanced Replication-based replica or an LDAP replica.

    • Oracle Database Advanced Replication-based replicas do true multimaster replication: changes made to the master are replicated to the replicas and changes made to any replica are replicated to the master and all other replicas.

      Although a site that will be used as an Advanced Replication-based replica can be initially installed as a master, Oracle recommends against that option. Oracle recommends installing each intended replica as a replica right from the start.

      Therefore, to create an Advanced Replication-based replica, follow the directions in the section entitled "If you are installing Oracle Internet Directory as a Replica", and choose "Advanced Replication" when that choice appears.

    • LDAP replicas are one-way and read-only: only changes made to the master are replicated to the replica, not from the replica to the master. LDAP replicas can also be used to replicate a portion of the directory information tree rather than the entire directory information tree. In partial replication, you determine what is or is not replicated by defining replica naming context objects.

      To create an LDAP replica, follow the directions in the section entitled "If you are installing Oracle Internet Directory as a Replica", and choose "LDAP replica" when that choice appears.


      See Also:

      Detailed explanations and examples of setting up and using naming contexts appear in later sections of this chapter.

25.1.2.1.2 If you are installing Oracle Internet Directory as a Master

  1. Follow the installation procedure documented in the chapter "Installing Oracle Internet Directory in Replicated Mode" in the Oracle Application Server Installation Guide. When the Oracle Universal Installer prompts you to select a product to install, choose the Oracle Application Server Infrastructure.

  2. For the Installation Type, select as follows:

    1. If you do not have (or will not be using) an existing Oracle Application Server Metadata Repository, choose Identity Management and Oracle Application Server Metadata Repository.

    2. If you wish to use an existing Oracle Application Server Metadata Repository, choose Identity Management.

  3. Ensure that Oracle Internet Directory is checked on the Select Configuration Options screen.

  4. When installing a master, do not check High Availability and Replication in the Select Configuration Options screen for replication. When you do not check High Availability and Replication, Oracle Universal Installer will perform a default Oracle Internet Directory install, that is, it will install a new Oracle Internet Directory as a master node. (You may still check High Availability and Replication in the Select Configuration Options screen for configuring Virtual Host or OracleAS Clusters though.)

  5. Complete the installation as described in "Installing Oracle Internet Directory in Replicated Mode" in the Oracle Application Server Installation Guide.

25.1.2.1.3 If you are installing Oracle Internet Directory as a Replica
  1. Follow the installation procedure documented in the chapter "Installing Oracle Internet Directory in Replicated Mode" in the Oracle Application Server Installation Guide. When the Oracle Universal Installer prompts you to select a product to install, choose the Oracle Application Server Infrastructure.

  2. For the Installation Type, select as follows:

    1. If you do not have (or will not be using) an existing Oracle Application Server Metadata Repository, choose Identity Management and Oracle Application Server Metadata Repository.

    2. If you wish to use an existing Oracle Application Server Metadata Repository, choose Identity Management.

  3. For Configuration Options, ensure that both Oracle Internet Directory and High Availability and Replication are checked.

  4. Because you checked High Availability and Replication in the Select Configuration Options screen, you will see the Select High Availability or Replication Option screen. Select Replication.

  5. Next, you will see the Oracle Internet Directory Replication Mode screen. Choose the type of replica you want to create:

    • For Advanced Replication-based (multimaster) replication, select Advanced Replication.

    • For read-only or partial replication, select LDAP.

  6. On the screen labeled Oracle Internet Directory Master Node, specify the hostname and port for the supplier node to be replicated by this node presently being created. If connecting with that node requires SSL protocol, check that box on this screen.

  7. Complete the installation as described in Oracle Application Server Installation Guide.

25.1.2.1.4 The Replication Environment Management Tool

During installation and configuration, you use the Replication Environment Management Tool to perform various tasks. This tool assists you in:

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


    Note:

    You do not need Advanced Replication to perform partial—that is, LDAP-based—replication.

    Even in a directory replication group whose nodes have different patchset versions of Oracle Database 10g, you can replicate if they have the same version of Oracle Internet Directory.

    However, if the nodes in a directory replication group are running different versions of Oracle Internet Directory, there is a constraint on modifying directory servers on those nodes: 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.



    See Also:

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

25.1.2.2 Task 1: Install Oracle Internet Directory as a Master on the Master Definition Site (MDS)

You must be able to use Oracle Net Services to connect to the master definition site database and all other nodes in the DRG.


Note:

During installation, make sure that each Oracle Internet Directory database instance name is unique on each machine.

To do the actual installation, as a master, use the instructions in the section entitled "If you are installing Oracle Internet Directory as a Master".


See Also:

Installing Oracle Internet Directory in Replicated Mode" in Oracle Application Server Installation Guide.

25.1.2.3 Task 2: Install the Oracle Internet Directory as a Replica, on the Remote Master Sites (RMS)

Oracle recommends that the sites to be used as Advanced Replications-based replicas be installed initially as replicas, and not as masters.

To do the actual installation, as a replica, use the instructions in the section entitled "If you are installing Oracle Internet Directory as a Replica".

25.1.2.3.1 If an Existing Master is Used as a Remote Master Site

Although Oracle recommends starting with empty replicas, you can set up replication using machines initially configured as masters rather than replicas. To use a machine initially configured as a master as an RMS, you must first migrate its metadata to the MDS, as follows:

  • Make sure the Oracle Internet Directory server is up and running on both the MDS and each such desired replica so that the process (remtool –backupmetadata) can succeed.

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

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

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

  • Apart from loading the metadata into master replica, this tool creates a file named ocbkup.new_replica_id.TO.master_replicaid.timestamp.dat containing the metadata as backup. This file is created under the $ORACLE_HOME/ldap/log directory. This file contains the changes made to 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, it displays a message in the terminal:

    Backup of metadata will be stored in 
    $ORACLE_HOME/ldap/log/ocbkup.new_replica_id.TO.master_replica_id.timestamp.dat.
    Metadata copied successfully.
    
    

    The message will contain the actual path of ORACLE_HOME.

  • If an error occurs during this operation, remtool reports the error in the terminal from which it was invoked. The error messages are also logged in $ORACLE_HOME/ldap/log/remtool.log file.

After successfully migrating the master's metadata to the MDS, you can now safely continue with "Task 3: Set Up Oracle Database Advanced Replication for a Directory Replication Group" .

25.1.2.4 Task 3: Set Up Oracle Database Advanced Replication for a Directory Replication Group

The following sections lead you through installing and configuring Advanced Replication by using the Replication Management Tool.


See Also:

Oracle Database Advanced Replication in the Oracle Database Documentation Library, and the online Help for the Replication Management Tool, for information on configuring Oracle Database Advanced Replication.

To establish a directory replication group (DRG), you must configure the Advanced Replication environment by performing the tasks discussed in these topics:

25.1.2.4.1 On All Nodes, Prepare the Oracle Net Services Environment for Replication

For each node in the directory replication group, perform the steps listed here. (Each step is described more fully in the subsections that directly follow this list.)

  1. Configure sqlnet.ora.

  2. Configure tnsnames.ora.

  3. Stop and restart the listener.

  4. Test Oracle Net connections to all nodes from each node in the DRG.

To prepare the Oracle Net Services environment for replication:

  1. Configure sqlnet.ora.

    The sqlnet.ora file should contain the following parameters at minimum:

    names.directory_path = (TNSNAMES)
    names.default_domain = global_database_domain
    
    

    On UNIX, the sqlnet.ora file is in $ORACLE_HOME/network/admin.

    On Microsoft Windows, the sqlnet.ora file is in %ORACLE_HOME%\network\admin.

  2. Configure tnsnames.ora.

    On each node in the DRG, define all Oracle Internet Directory database instances in the DRG. Each tnsnames.ora file must contain connect descriptor information in the following format for each Oracle Internet Directory database:

    net_service_name =
    (DESCRIPTION =
    (ADDRESS =
    (PROTOCOL = TCP)
    (HOST = HOST_NAME_OR_IP_ADDRESS)
    (PORT = port_no_of_listener))
    (CONNECT_DATA =(service_name = service_name_of_database)))
    
    

    where net_service_name is the global name of the database. For example, if the database global name is mds.sales.com, then your net_service_name must be mds.sales.com. Ensure that your database global name and your net_service_name are domain-qualified. In this example, the global name and net_service_name are domain-qualified with sales.com.


    Note:

    • The database global name is composed of the DB_NAME and DB_DOMAIN initialization parameters of your database. For example, if your database's DB_NAME is mds and DB_DOMAIN is sales.com, your database global name is mds.sales.com. The global name will not be domain qualified if the DB_DOMAIN initialization parameter is not defined.

    • The value of the NAMES.DEFAULT_DOMAIN parameter in the sqlnet.ora file must match the value of the DB_DOMAIN initialization parameter of the database.



    See Also:

    Oracle Database Net Services Reference for more information on tnsnames.ora syntax.

    On UNIX, the tnsnames.ora file is in $ORACLE_HOME/network/admin.

    On Microsoft Windows, the tnsnames.ora file is in %ORACLE_HOME%\network\admin.


    Note:

    You must domain-qualify the net service name (for example, sales.com), but be sure that the domain component matches the one specified in the NAMES.DEFAULT_DOMAIN parameter in the sqlnet.ora file.

  1. Stop and restart the listener.

    To stop the listener for the Oracle Internet Directory database, use the listener control utility (lsnrctl). Type the following command at the LSNRCTL command prompt:

    SET PASSWORD password
    STOP [listener_name]
    
    

    SET PASSWORD is required only if the password is set in the listener.ora file. The password defaults to ORACLE. The default listener name is LISTENER.

    To restart the listener for the Oracle Internet Directory database, type the following command at the LSNRCTL command prompt:

    START [listener_name]
    
    quit
    
    
  1. Test Oracle Net connections to all nodes from each node in the DRG.

    IMPORTANT: Try to connect using both of these commands:

    sqlplus ods/ods_password@net_service_name_without_domain_name
    sqlplus ods/ods_password@net_service_name_with_domain_name
    
    

    If you cannot connect, then replication will not work.

25.1.2.4.2 From the MDS, Configure Oracle Database Advanced Replication For Directory Replication

To do this:

  1. From the MDS console, connect as the system user on all nodes, including the MDS. Ensure the following on all nodes:

    • The Oracle Internet Directory database is running

    • The Oracle Internet Directory listener is running

    • The connect string is correct

    • The system password is correct

  2. Ensure the following wallets exist on the remote sites:

    • A wallet for storing the password to the database designated for Oracle Internet Directory. This wallet is named oidpwdlldap1 and is located in the directory $ORACLE_HOME/ldap/admin.

    • A wallet for storing the password of the replication administrator. This wallet is named oidpwdroracle_sid, and is located in the directory $ORACLE_HOME/ldap/admin. (The oracle_sid is obtained not from the environment variable SID but from the connected database.)

  3. Check the prerequisites in the attached Note. Then, at a command prompt in the MDS, use remtool (the Replication Environment Management Tool) to configure Advanced Replication by running the following script:

    $ORACLE_HOME/bin/remtool -asrsetup
    
    

    Note:

    • The "remtool" command-line tool reference in Oracle Identity Management User Reference for information about using the -asrsetup option of the Replication Environment Management Tool (remtool).

    • Oracle Database Administrator's Guide in the Oracle Database Documentation Library for instructions on ensuring that the database and listener are running

    • Oracle Database Net Services Administrator's Guide in the Oracle Database Documentation Library for instructions on ensuring that the connect string is correct



    Note:

    If you encounter errors, then clean up the environment by using the -asrcleanup option of the Replication Environment Management Tool. Then repeat Step 3.


Note:

As part of "Task 3: Set Up Oracle Database Advanced Replication for a Directory Replication Group", the Replication Environment Management Tool (remtool) sets default values for the replication configuration parameters, which enables you to simply start the replication servers. If you wish to change the replication configuration parameters, see "Managing Replication".

25.1.2.5 Task 4 (Optional): Load Data into the Directory

You can choose either of two ways to load data into the directory:

  • To add just a small number of entries to the DRG, you can wait until you have completely configured the DRG. Then use ldapadd to load the data to one of the nodes. The entries will then be replicated to the other nodes at the specified time.

  • To add a large amount of data to load into the DRG, use the bulkload utility:

    1. Stop the LDAP server at all nodes of the DRG by typing:

      opmnctl stopproc ias-component=OID
      
    2. On the node that is part of the DRG and where you have the ldif file to be loaded onto the directories enter:

      bulkload.sh -connect connect_string -check \
                  -generate file_with_absolute_path_name
      

      Note:

      If data is extracted from Oracle Internet Directory using ldifwrite, then, in addition to other options, use the -restore option to restore the operational attributes.

    3. On the same node, enter:

      bulkload.sh -connect connect_string_1 -load
      
      

    Repeat step c on the same node, each time replacing connect_string_1 with the connect string of another node in the DRG, until you have loaded the data onto all the nodes in the DRG. For example, enter:

    bulkload.sh –connect connect_string_2 -load
    
    

    then enter

    bulkload.sh –connect connect_string_3 –load
    
    

    and so on, until you loaded the data onto all the nodes in the DRG.


Note:

  • connect_string is the connect string of the local Oracle Internet Directory database.

  • For successful replication, an entry must have the same orclguid (global identifier) at all replicated nodes. This is accomplished by performing Step b once and repeating Step c for all nodes in the DRG.



Note:

To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities:


See Also:

The "bulkload" command-line tool reference in Oracle Identity Management User Reference for syntax and usage notes

25.1.2.6 Task 5: Ensure that Oracle Directory Server Instances are Started on All the Nodes

The out-of-box configuration has Oracle Internet Directory LDAP Server instance #1 configured with change logging set to TRUE. This default instance of Oracle Internet Directory LDAP Server can be started using opmn as follows:

opmnctl startproc ias-component=OID

Note:

Do not use the opmnctl startall command at this point. If you do, the HTTP server and the Oracle Internet Directory server will start, but the command will hang while trying to start the OC4J server. The OC4J server can be started only after Task 6 is complete. Once the replication server has been started on all nodes of the DRG and replication has propagated to all nodes, you may safely use the opmnctl startall command.


See Also:

Chapter 3, "Post-Installation Tasks and Information" for more information on starting an Oracle directory server instance.

25.1.2.7 Task 6: Start the Replication Servers on All Nodes in the DRG

To start replication servers on all nodes, type the following command on each node:

oidctl connect=connect_string server=oidrepld instance=1 \
       flags='-h host_on_which_the_directory_server_is_running -p port' start

Note that the instance number need not be unique across the entire DRG.


Note:

If you are deploying a single master with read-only replica consumers, you can reduce performance overhead by turning off the multimaster flag in the directory replication server. To do so, change the value of the -m flag in the OID Control Utility command for Oracle directory replication server from the default (TRUE) to FALSE. The multimaster option controls conflict resolution, which serves no purpose if you are deploying a single master.

Once the Oracle Internet Directory replication server has been started using oidctl, any opmnctl command to stop or start the Oracle Internet Directory component will ensure that the Oracle Internet Directory replication server process is also stopped or started.


See Also:

"Process Control of Oracle Internet Directory Components" for information on Oracle Internet Directory process control.

"Conflict Resolution in Multimaster Replication"

Chapter 5, " Oracle Directory Server Administration" for information on starting the replication servers


25.1.2.8 Task 7: Test Directory Replication

Use Oracle Directory Manager to verify that the directory replication servers are running, and then test directory replication by doing the following:

  1. Log in to Oracle Directory Manager as orcladmin.

  2. In the navigator pane, expand in succession Oracle Internet Directory Servers, directory server instance, Entry Management.

  3. Create a single entry on the MDS node.

    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 will be replicated.


    Note:

    If you want to configure replication for Oracle Application Server Single Sign-On, then follow the post-installation steps specific to Oracle Application Server Single Sign-On. These are found in the replication installation section of the Oracle Application Server Single Sign-On Administrator's Guide.

25.1.3 Adding a Node for Multimaster Replication (Oracle Database Advanced Replication Types Only)


Note:

A new node that you add to an existing multimaster replication group must have an Oracle Application Server Infrastructure installed on it. During its installation, the installation type selected had to have been Oracle Application Server with Metadata Repository. For more information, see "Task 2: Install the Oracle Internet Directory as a Replica, on the Remote Master Sites (RMS)".

You can add a node to a master node, or to an LDAP-based supplier replica that is not a consumer of any other LDAP based replicas, to form a multimaster DRG. When you do so, the steps in this section will automatically perform an initial install and configuration of Advanced Replication.

To add a new replication node to a live, functioning replication group or to a master node of any significant size, perform the following steps:


Note:

Commands shown in the following tasks require the following types of items to be stored as follows:
  • Binaries: $ORACLE_HOME/bin

  • SQL scripts: $ORACLE_HOME/ldap/admin

  • UNIX scripts: $ORACLE_HOME/ldap/bin

Before beginning "Task 2: Identify a Sponsor Node and Install Oracle Internet Directory as a Replica on the Remote Site", be sure that all three of these types of items are in the path.


25.1.3.1 Prepare the Oracle Net Services Environment

The process that prepares this environment is described in Section 25.1.2.4.1, "On All Nodes, Prepare the Oracle Net Services Environment for Replication".

25.1.3.2 Task 1: Stop the Directory Replication Server on All Nodes

To stop the directory replication server, run the following command on each node in the LDAP replication group, type:

oidctl connect=db_connect_string server=oidrepld instance=1 stop

Note:

The instance number might not be 1. Check the running process to discover the instance number in use here.

25.1.3.3 Task 2: Identify a Sponsor Node and Install Oracle Internet Directory as a Replica on the Remote Site

You must identify a sponsor node for this Task. It is the node that will supply the data to the new node.

For the RMS, Oracle recommends that you install the new instance of Oracle Internet Directory as an Advanced Replication replica. (You could use an existing master node as the RMS, but extra manual steps are required.)

To install a new Oracle Internet Directory as an Advanced Replication replica for RMS, use the instructions in "If you are installing Oracle Internet Directory as a Replica" and choose Advanced Replication when that choice appears.

If an existing master is used as RMS, you need to follow the instructions in "If an Existing Master is Used as a Remote Master Site" to migrate the master's metadata to the sponsor node. After successfully migrating the master's metadata to the MDS, you can now safely continue with "Task 3: Switch the Sponsor Node to Read-Only Mode".

25.1.3.4 Task 3: Switch the Sponsor Node to Read-Only Mode

A sponsor node is the node that supplies the data to the new node. To switch the sponsor node to read-only mode:

  1. Create a new file, change_mode.ldif, containing the following:

    dn:
    changetype: modify
    replace: orclservermode
    orclservermode: r
    

  1. Run the following command against the identified sponsor node:

    ldapmodify -D "cn=orcladmin" -w adminPassword -h host_name_of_sponsor_node \
                -p port -f change_mode.ldif
    
    

This command changes the Oracle directory server name_of_sponsor_node from sponsor mode to read-only mode.


Note:

While the sponsor node is in read-only mode, you may not make any updates to it. You may, however, update any of the other nodes, but those updates are not replicated immediately.

Also, the sponsor node and the MDS may be the same node.


25.1.3.5 Task 4: Back up the Sponsor Node by Using ldifwrite

Because this may take a long time, you may start "Task 5: Perform Advanced Replication Add Node Setup" while backup is in process.

On the sponsor node, enter the following command:

ldifwrite -c connect_string \
          -b "orclAgreementID=000001,cn=replication configuration" \
          -f output_ldif_file

This backs up the directory of the sponsor node.

25.1.3.6 Task 5: Perform Advanced Replication Add Node Setup


Note:

Oracle Net Service must be configured properly on all nodes for replication. See: "On All Nodes, Prepare the Oracle Net Services Environment for Replication".

You can perform the Advanced Replication add node setup at the same time that you perform "Task 4: Back up the Sponsor Node by Using ldifwrite".

On the sponsor node, enter this command:

remtool -addnode

The Replication Environment Management Tool adds the node to the DRG.


Notes:

When you run remtool -addnode to add the first Advanced Replication replica of a replication group, the tool does the initial replication setup for you, as if you had used remtool -asrsetup. You must specify the sponsor node's connect identifier when you use remtool -addnode.

When you use remtool -addnode, the operation might take a long time to complete, depending on the number of rows available in replicated tables and the network latency between the nodes. Use the -v option to view the progress of this operation.

If you encounter errors, then use the -asrverify option first. If it reports errors, then rectify them by using the -asrrectify option. Both -asrverify and -asrrectify list all nodes in the DRG. If the new node is in the list, remove the new node by running the Replication Environment Management tool with -delnode option. Then add the new node again using the -addnode option.



See Also:

The "remtool" command-line reference in Oracle Identity Management User Reference for instructions on using the -addnode option of the Replication Environment Management Tool

25.1.3.7 Task 6: Switch the Sponsor Node to Updatable Mode

To switch the sponsor node to updatable mode:

  1. Edit change_mode.ldif to the following:

    dn: 
    changetype: modify
    replace: orclservermode
    orclservermode: rw
    

  1. Run the following commands on the sponsor node:

    ldapmodify -D adminDN -w adminPassword -h host_name_of_sponsor_node \
               -p port -f change_mode.ldif
    
    

This command changes the Oracle directory server host_name_of_sponsor_node from sponsor mode back to read/write mode.


Note:

Task 6 is very similar to Task 3. The only difference is that the orclservermode parameter in change_mode.ldif is being set back to rw, that is, read/write, in this step.

25.1.3.8 Task 7: Start the Directory Replication Server on All Nodes Except the New Node

To start the directory replication server, type the following command on all nodes except the new node:

oidctl connect=db_connection_string server=oidrepld instance=1 \
      flags='-h host -p port' start

To ensure that no directory or replication processes are running on the new node, type:

opmnctl stopproc ias-component=OID

25.1.3.9 Task 8: Load Data into the New Node by Using bulkload

To load data, type the following command on the new node:

bulkload.sh -connect db_connect_string_of_new_node -check -generate -load \
            -restore absolute_path_to_the_ldif_file_generated_by_ldifwrite


Note:

To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities:

25.1.3.10 Task 9: Start the Directory Server on the New Node

To start the directory server, type the following command on the new node:

oidctl connect=db_connect_string_of_new_node server=oidldapd \
       instance=1 flags='-p port' start

25.1.3.11 Task 10: Start the Directory Replication Server on the New Node


Note:

If you need to change configuration or agreement parameters, see "Managing Replication".

To start the directory replication server, type the following command on the new node:

opmnctl startproc ias-component=OID


Note:

Once a directory server instance is participating in a replication agreement, do not use the bulkload tool to add data into the node. Instead, use ldapadd.

If Oracle Application Server Single Sign-On is desired in replication, then follow the Oracle Application Server Single Sign-On Administrator's Guide in the replication installation section for the post-installation steps specific to Oracle Application Server Single Sign-On.


25.1.4 Deleting a Node from a Multimaster Replication Group

At times, you may want to delete a node from a DRG (for example, if the addition of a new node did not fully succeed as a result of system errors).

To delete a replication node, perform the tasks described in these topics:

25.1.4.1 Task 1: Stop the Directory Replication Server on All Nodes

To stop the directory replication server, run the following command on each node in the DRG:

oidctl connect=connect_string server=oidrepld instance=1 stop

Note:

The instance number may vary.

25.1.4.2 Task 2: Stop All Oracle Internet Directory Processes in the Node to be Deleted

On the node to be deleted, shut down Oracle Internet Directory using opmn.

$ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=OID


See Also:

The "opmn" command-line tool reference in Oracle Identity Management User Reference for more information about shutting down Oracle Internet Directory.

25.1.4.3 Task 3: Delete the Node from the Master Definition Site

From the MDS, run the following script:

remtool -delnode

The Replication Environment Management Tool deletes the node from the replication group.


See Also:

The "remtool" command-line tool reference in Oracle Identity Management User Reference for instructions on using the -delnode option of the Replication Environment Management Tool

This process can take a long time, depending on your system resources and the size of your DRG. If you use the -v option, the tool keeps you informed of its progress.


Note:

If you encounter errors, then use the -asrverify option first. If it reports errors, then rectify them by using the -asrrectify option. Both -asrverify and -asrrectify list all nodes in the DRG. If the node to be deleted is in the list, then delete it by running the Replication Environment Management tool again, using the -delnode option.

25.1.4.4 Task 4: Start the Directory Replication Server on All Nodes

To start the directory replication server, type the following command on each of the remaining nodes of the DRG:

oidctl connect=connect_string server=oidrepld instance=1 \
       flags='-h host -p port' start

See Also:

The "opmn" command-line tool reference in Oracle Identity Management User Reference

25.1.5 Resolving Conflicts Manually in a Multimaster Replication Group

This section contains these topics:

25.1.5.1 Monitoring Replication Change Conflicts

If a conflict has been written into the log, then it means that the system is not able to resolve it by following its resolution procedure. To avoid further replication change conflicts arising from earlier unapplied changes, it is important to monitor the logs regularly.

To monitor replication change conflicts, examine the contents of the replication log. You can distinguish between messages by their respective timestamps.

25.1.5.2 Examples of Conflict Resolution Messages

Conflict resolution messages, examples of which are shown in this section, are logged in the file oidrepld00.log. The path for this file is $ORACLE_HOME/ldap/log. The result of each attempt to resolve the replication conflict is displayed at the end of each conflict resolution message.

Example 25-1 An Attempt to Modify a Non-Existent Entry

2000/08/03::10:59:05:  ************ Conflict Resolution Message ************
2000/08/03::10:59:05:  Conflict reason: Attempted to modify a non-existent entry.
2000/08/03::10:59:05:  Change number:1306.
2000/08/03::10:59:05:  Supplier:eastlab-sun.
2000/08/03::10:59:05:  Change type:Modify.
2000/08/03::10:59:05:  Target DN:cn=ccc,ou=Recruiting,ou=HR,ou=Americas,o=IMC,c=US.
2000/08/03::10:59:05:  Result: Change moved to low priority queue after failing on 10th retry.

Example 25-2 An Attempt to Add an Existing Entry

2000/08/03::10:59:05:  ************ Conflict Resolution Message ************
2000/08/03::10:59:05:  Conflict reason: Attempted to add an existing entry.
2000/08/03::10:59:05:  Change number:1209.
2000/08/03::10:59:05:  Supplier:eastlab-sun.
2000/08/03::10:59:05:  Change type:Add.
2000/08/03::10:59:05:  Target DN:cn=Lou Smith, ou=Recruiting, ou=HR, ou=Americas, o=IMC, c=US.
2000/08/03::10:59:05:  Result: Deleted duplicated target entry which was created later than the change entry. Apply the change entry again.

Example 25-3 An Attempt to Delete a Non-Existent Entry

2000/08/03::10:59:06:  ************ Conflict Resolution Message ************
2000/08/03::10:59:06:  Conflict reason: Attempted to delete a non-existent entry.
2000/08/03::10:59:06:  Change number:1365.
2000/08/03::10:59:06:  Supplier:eastlab-sun.
2000/08/03::10:59:06:  Change type:Delete.
2000/08/03::10:59:06:  Target DN:cn=Lou Smith,ou=recruiting,ou=hr,ou=americas,o=imc,c=us.
2000/08/03::10:59:06:  Result: Change moved to low priority queue after failing on 10th retry.

25.1.5.3 About the Human Intervention Queue Manipulation Tool

The Human Intervention Queue Manipulation Tool enables you to move changes from the human intervention queue to either the retry queue or the purge queue. Moving the change to the purge queue means that there are no further attempts to re-apply the changelog entry. To address changes in the human intervention queue, follow these general steps:

  1. Shut down the directory replication server.

  2. Analyze the replication log.

  3. Use the Human Intervention Queue Manipulation Tool to move the changes to either the retry queue or the purge queue as described in the following sections.


    Note:

    The Oracle Internet Directory server parameter orclSizeLimit, which is 1000 by default, limits the number of entries that the Human Intervention Queue Manipulation Tool can process. If you have more than 1000 entries in the human intervention queue, you must increase orclSizeLimit, or some entries will never be processed. Setting the parameter orclSizeLimit very high will impact server performance, because orclSizeLimit also controls the maximum number of entries to be returned by a search.


    See Also:

    The "hiqretry.sh" command-line tool reference in Oracle Identity Management User Reference for instructions on how to use the Human Intervention Queue Manipulation Tool

25.1.5.4 About the Oracle Internet Directory Reconciliation Tool

When the directory replication server encounters inconsistent data, you can use the Oracle Internet Directory Reconciliation Tool to synchronize the entries on the consumer with those on the supplier. When you do this, perform the following general steps:

  1. Set the supplier and the consumer to read-only mode.

  2. Ensure that the supplier and the consumer are in a tranquil state—that is, that neither is supplying or applying changes. If they are not in a tranquil state, then wait until they have finished updating.

  3. Identify the inconsistent entries or subtree on the consumer.

  4. Use the OID Reconciliation Tool to fix the inconsistent entries or subtree on the consumer.

  5. Set the participating supplier and consumer back to read/write mode.


    See Also:


25.2 Installing and Configuring LDAP-Based Replication

This section contains these topics:


See Also:

"Supplementary Procedures for Configuring LDAP-Based Replicas" in Oracle Application Server Administrator's Guide

25.2.1 Rules for Configuring LDAP-Based Replication

The following rules apply to both full and partial LDAP-based replication:

  1. An LDAP-based replica cannot have two suppliers.

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

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


    See Also:

    For instructions on installing on a standalone node, see "If you are installing Oracle Internet Directory as a Master"

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

  5. You can add an Oracle Internet Directory 10g Release 2 (10.1.2) LDAP replica to an Oracle Internet Directory 10g (9.0.4) master. You can also upgrade a 10g (9.0.4) LDAP replica of a 10g (9.0.4) master to 10g Release 2 (10.1.2).


    Note:

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

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

25.2.2 Back Up Your LDAP Data by Using ldifwrite and bulkload

Use the ldifwrite utility to back up LDAP data with operational attributes preserved. Once this is done, the bulkload utility is then used to load data to all replicas in a group.

Use bulkload with the -check, -generate, and -restore arguments once, and then with the -load argument once for each replica. When using the -load argument on each replica, preserve the operational attributes by using the same intermediate files generated by using the -generate argument.

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


See Also:

"Oracle Identity Management Command-line Tool Reference" in Oracle Identity Management User Reference presents the syntax and multiple examples for both ldifwrite and bulkload.

25.2.3 Installing and Configuring an LDAP Replica with Default Settings

This section discusses default namingcontext configuration settings as one way to configure LDAP- based replication from the supplier replica to the consumer replica, with all namingcontexts included. That is, replication is configured so that the entire DIT of the supplier replica will be replicated to the consumer.

When you install and configure an LDAP replica with default settings, automated bootstrap performs the initial data synchronization from the supplier to the consumer. After the installation of a new LDAP replica is completed, LDAP based replication will be configured and the replication process will be started automatically.


Note:

When you install an LDAP replica using default settings, the installer automatically migrates the consumer replica's metadata to the supplier replica. It is assumed all metadata are under the naming context cn=oraclecontext. If you need to use a different naming context, such as a realm-specific naming context, see the next section, "Installing and Configuring an LDAP-Based Replica with Customized Settings" .


See Also:

The discussion of automatic bootstrap in Appendix H, "LDAP Replica States"

25.2.3.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 standalone directory

  • 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=OID

25.2.3.2 Task 2: Installing Oracle Internet Directory As An LDAP Replica

Use the instructions in "If you are installing Oracle Internet Directory as a Replica" and in step 5 choose LDAP replica.

When you install an LDAP replica with the default settings, Oracle Universal Installer automatically invokes bootstrap to migrate data from the supplier to the consumer.


Note:

Bootstrapping may take a long time to complete.

Do not update the Oracle Internet Directory schema on the supplier when bootstrapping is in progress. If you do, replication bootstrap might fail. If it fails, verify that the Oracle Internet Directory schema at the consumer is synchronized with that of the supplier before you try to bootstrap again.

If you update the supplier Oracle Internet Directory during bootstrapping, the Oracle Internet Directory replication server will log a warning message. Changes you make to the supplier will be replicated to the consumer. Some of the changes, however, might be moved to the human intervention queue.

Once installation is complete, LDAP replication will be configured. The replication server on the consumer will replicate changes from the supplier.

You can check replication activity by viewing the replication log file on the new LDAP replica.

25.2.4 Installing and Configuring an LDAP-Based Replica with Customized Settings

To establish customized settings, you must first install the new node as a Master node (standalone). To do so, follow the instructions in "If you are installing Oracle Internet Directory as a Master" .

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


See Also:

The discussion of naming contexts in "Determining What Is to Be Replicated in LDAP-Based Partial Replication"

There are two ways to install and configure 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 25-1 compares these two methods.

Table 25-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 "Configuring an LDAP-Based Replica by Using Automatic Bootstrapping" .

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

25.2.4.1 Configuring 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.

25.2.4.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 standalone directory

  • 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=OID

25.2.4.1.2 Task 2: Create the New Consumer Node by Installing Oracle Internet Directory as a Master

To install and configure an LDAP-based replica with customized setting, you must install the new consumer node as a master. To install a new Oracle Internet Directory as a master, follow the directions in "If you are installing Oracle Internet Directory as a Master" .

25.2.4.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/new_node_repldn_pwd" \
            –master "master_host:master_port/master_repl_dn_pwd" 
    
    

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


    See Also:

    The "remtool" command-line tool reference in Oracle Identity Management User Reference 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.dat containing the metadata as back up. This file is created under the $ORACLE_HOME/ldap/log 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_HOME/ldap/log/ocbkup.new_replica_id.TO.master_replicaid.timestamp.dat.
    Metadata copied successfully.
    
    

    The message will contain the path of your ORACLE_HOME.

  • If the metadata backup is unsuccessful, the $ORACLE_HOME/ldap/log/remtool.log file will contain error messages. If you invoked remtool from a terminal, error messages appear on that terminal.

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

To add a replica, enter the following:

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

See Also:

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

25.2.4.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
    add:orclReplicaState
    OrclReplicaState: 0
    
    
  2. Use ldapmodify at the consumer to update the consumer replica's subentry orclreplicastate attribute.

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

    See Also:

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

25.2.4.1.7 Task 7: Start the Directory Replication Server on the Consumer Replica

On the consumer, start the Oracle Internet Directory replication server by typing:

oidctl connect=db_connect_string_of_consumer_node \
       server=oidrepld instance=1 \
       flags='-h consumer_host -p consumer_port' start

See Also:

The "oidctl" command-line tool reference in Oracle Identity Management User Reference

When the replication server is started, it will start to bootstrap the data from the supplier to the consumer. Once the bootstrap has completed successfully, the replication server will automatically change to ONLINE mode to process changes from the supplier to the consumer.

25.2.4.1.8 Task 8: If DAS or SSO Are Installed on the New Node, Restore Their Entries in the New Node's Directory

The entries for DAS and SSO 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.dat 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 \
                 –w super_user_password -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.

    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 \
              –w super_user_password -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 \
                 –w super_user_password -f mod.ldif
      
      

      Restart OC4J security for the change to take effect:

      $ORACLE_HOME/opmn/bin/opmnctl  stopproc process-type=OC4J_SECURITY
      $ORACLE_HOME/opmn/bin/opmnctl startproc process-type=OC4J_SECURITY
      
      
    6. Using a browser, test the Oracle Delegated Administration Services and OracleAS 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.

      To test OracleAS Single Sign-On, try to log in as the super admin user "orcladmin" on the OracleAS 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.

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

25.2.4.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:

    • standalone directory

    • 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=OID
    
    
  2. Identify the consumer node, which must be an new Oracle Internet Directory install as a master. To install a new Oracle Internet Directory as a Master, follow the directions in "If you are installing Oracle Internet Directory as a Master" . 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=OID
    
    
25.2.4.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/consumer_repl_dn_pwd" \
            –master "supplier_host:supplier_port/supplier_repl_dn_pwd"   
    
    
  • 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_HOME/ldap/log 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_HOME/ldap/log/ocbkup.consumer_replica_id.TO.supplier_replicaid.timestamp.dat.
    Metadata copied successfully.
    
    

    The message will contain the actual path of your ORACLE_HOME and filename.

    If the metadata backup is unsuccessful, the $ORACLE_HOME/ldap/log/remtool.log file will contain error messages. If you invoked remtool from a terminal, error messages appear on that terminal.

25.2.4.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 do this:

  1. Create an LDIF file containing the following:

    Dn:
    Changetype: modify
    Replace: orclservermode
    Orclservermode: r
    
    
  2. On the supplier, run the following command:

    ldapmodify –D "cn=orcladmin" –w administrator_password \
               –h host_name_of_supplier_node –p port –f name_of_LDIF_file.ldif
    
25.2.4.2.4 Task 4: Add an LDAP-Based Replica by Using the Replication Environment Management Tool

To add a replica, enter the following:

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

See Also:

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

25.2.4.2.5 Task 5: Initialize the lastappliedchangenumber Attribute

To do this:

  1. Search for the last applied change number on the supplier node.

    ldapsearch -D "cn=orcladmin" -w administrator_password -h supplier_host \
               -p port_number -b "" -s base "objectclass=*" lastchangenumber
    
    
  2. Modify the corresponding agreement with the retrieved last applied number at the supplier. To do this:

    1. On the supplier, create an LDIF file with the retrieved last applied change number:

      dn:orclagreementid=agreement_identifier,
       orclreplicaid=supplier_replica_identifier,cn=replication configuration
      changetype: modify
      replace: orclLastAppliedChangeNumber
      orclLastAppliedChangeNumber: last_change_number_retrieved_in_step_1.
      
      
    2. On the supplier, modify the agreement by using ldapmodify:

      ldapmodify -D "cn=orcladmin" -w password -h host_name -p port_number \
                 -f LDIF_file
      
25.2.4.2.6 Task 6: 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 Corporation 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
    

  1. On the supplier, use the following command to get the data from the supplier. Data loaded into the file will be based on the agreement configured:

    ldifwrite –c connect_string_of_sponsor_node \
              -b "replication_agreement_dn_retrieved_in_step_1" \
              –f name_of_output_LDIF file
    
    

    See Also:

    "Determining What Is to Be Replicated in LDAP-Based Partial Replication"

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


25.2.4.2.7 Task 7: 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. To do this:

  1. Create an LDIF file containing the following:

    Dn:
    Changetype: modify
    Replace: orclservermode
    Orclservermode: rw
    
    
  2. Run the following command:

    ldapmodify –D "cn=orcladmin" –w administrator_password \
               –h host_name_of_supplier_node –p port –f name_of_LDIF_file
    
25.2.4.2.8 Task 8: 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. Enter the following:

    bulkdelete.sh –connect connect_string_of_replica -base "naming_context" 
    

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

On the consumer, load the data to the replica by using bulkload in the append mode. Enter the following:

bulkload.sh –connect connect_string_of_replica –append –check \
            –generate –restore backup_data.ldif
bulkload.sh –connect  connect_string_of_replica -load 


See Also:


25.2.4.2.9 Task 9: If DAS or SSO Are Installed on the New Node, Restore Their Entries in the New Node's Directory

Follow the procedure described in "Task 8: If DAS or SSO Are Installed on the New Node, Restore Their Entries in the New Node's Directory".

25.2.4.2.10 Task 10: 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.

25.2.4.2.11 Task 11: Start the Directory Replication Server on the Consumer Replica

Start the Oracle directory replication server, following the procedure described in the "oidctl" command-line tool reference in Oracle Identity Management User Reference.

25.2.5 Deleting an LDAP-Based Replica

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

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

Stop the Oracle directory replication server, following the procedure described in the "oidctl" command-line tool reference in Oracle Identity Management User Reference.

25.2.5.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/replication_dn_password]

See Also:

The "remtool" command-line tool reference in Oracle Identity Management User Reference

25.2.5.3 Task 3: Stop the Directory Server on the Node to be Deleted


See Also:

The "oidctl" command-line tool reference in Oracle Identity Management User Reference

25.2.6 Determining What Is to Be Replicated in LDAP-Based Partial Replication

In LDAP-based partial replication, you can determine what is or is not replicated by defining replica naming context objects. The parameters for these objects are stored in entries that have this DN:

cn=namingcontext_ID,cn=replication namecontext,
 orclAgreementID=numeric_identifier_of_replication_agreement,
 orclReplicaId=unique_identifier_of_replica, cn=replication configuration

Note:

Because the directory replication server reads replica naming context objects from the agreement located at the supplier, you must apply all modifications against naming context objects at the supplier and, optionally, at the consumer.

25.2.6.1 Viewing and Modifying Replica Naming Context Objects by Using Oracle Directory Manager

To view and modify parameters for replica naming context objects:

  1. In the navigator pane, expand in succession Oracle Internet Directory Servers, directory server instance, Replication Management, Replica Node: replica identifier, Replica Agreement: replication agreement identifier

  2. Select the replica naming context you want to modify. The Replica Naming Context tab page appears in the right pane. The fields in this tab page are described in Table A-20, "Fields in the Replica Naming Context Tab Page".

  3. After you have entered the appropriate information, choose OK.

25.2.6.2 Adding Replica Naming Context Objects by Using Oracle Directory Manager

  1. In the navigator pane, expand in succession Oracle Internet Directory Servers, directory server instance, Replication Management, Replica Node: replica identifier, Replica Agreement: replication agreement identifier.

  2. Select Naming Context:naming context identifier.

  3. From the toolbar, choose Create. The New Replica Agreement Naming Context dialog box appears.

  4. In the fields in the New Replica Agreement Naming Context dialog box, enter the appropriate information. The fields in this dialog box are described inTable A-20, "Fields in the Replica Naming Context Tab Page".

  5. Choose OK.

25.2.6.3 Deleting Replica Naming Context Objects by Using Oracle Directory Manager

  1. In the navigator pane, expand in succession Oracle Internet Directory Servers, directory server instance, Replication Management, Replica Node: replica identifier, Replica Agreement: replication agreement identifier.

  2. Using your mouse, right-click Naming Context:naming context identifier.

  3. Select Delete.

25.2.6.4 Modifying Replica Naming Context Object Parameters by Using ldapmodify

Replica naming context object parameters are listed and described under Replication Schema Elements in Oracle Identity Management User Reference.


Note:

The replication server reads naming context objects from the supplier replica.

Example 25-4 Adding a Naming Context Object for an LDAP-Based Replica

This example creates a naming context object that does the following:

  • Replicates the naming context ou=Americas,cn=mycompany

  • Excludes from replication the naming context cn=customer profile, ou=Americas,cn=mycompany

  • Excludes from replication the attribute userpassword

The steps are:

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

    dn: cn=naming_context_identifier, cn=replication  namecontext,
     orclagreementid=replication_agreement_identifier,
     orclreplicaid=supplier_replica_identifier,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 to the supplier.

    ldapadd -D "cn=orcladmin" -w administrator_password -h supplier_host \
            -p port_number -f mod.ldif
    

Example 25-5 Deleting a Naming Context Object

To delete the naming context object created in Example 25-4, type:

ldapdelete -D "cn=orcladmin" -w administrator_password \
           -h supplier_host -p supplier_host_port_number \
           "cn=naming_context_identifier, cn=replication namecontext, \
            orclagreementid=replication_agreement_identifier, \
            orclreplicaid=supplier_replica_identifier, \
            cn=replication configuration"

Example 25-6 Modifying the orclIncludedNamingContexts Attribute for a Replica Naming Context Object

The directory replication server uses the orclIncludedNamingcontexts attribute value of the replica naming context object to specify the top-level subtree included in partial replication.

In this example, the included naming context is set to c=us, which means that c=us is to be included in partial replication.

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

    DN:cn=naming_context_identifier,cn=replication namecontext,
     orclagreementid=replication_agreement_identifier,
     orclreplicaid=supplier_replica_identifier,cn=replication configuration
    Changetype:modify
    Replace: orclIncludedNamingcontexts
    orclIncludedNamingcontexts: c=us
    
    
  2. Use ldapmodify to update the replication agreement orclupdateschedule attribute.

    ldapmodify -D "cn=orcladmin" -w administrator_password -h supplier_host \
               -p port -f mod.ldif
    
    
  3. Restart the directory replication server.

Example 25-7 Modifying the orclExcludedNamingContexts Attribute for a Replica Naming Context Object

The directory replication server uses the orclExcludedNamingcontexts attribute value of the replica naming context object to specify the top-level subtrees excluded from partial replication.

In this example, the excluded naming contexts are set to ou=Europe,c=us and ou=Americas,c=us, which means that these two naming contexts are to be excluded from partial replication.

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

    DN:cn=naming_context_identifier,
     cn=replication namecontext,
     orclagreementid=replication_agreement_identifier,
     orclreplicaid=supplier_replica_identifier,cn=replication configuration 
    Changetype:modify
    Replace: orclExcludedNamingcontexts
    orclExcludedNamingcontexts: ou=Europe, c=us
    orclExcludedNamingcontexts: ou=Americas, c=us
    
    
  2. Use ldapmodify to update the replication agreement orclupdateschedule attribute.

    ldapmodify -D "cn=orcladmin" -w administrator_password \
               -h supplier_host -p port -f mod.ldif
    
    
  3. Restart the directory replication server.


Note:

A subtree specified in the orclexcludednamingcontexts attribute must also be a subtree of the specified includednamingcontext of the same replica naming context object.

Example 25-8 Modifying the orclExcludedAttributes Attribute for a Replica Naming Context Object

You can specify that certain changes made to the included naming context be excluded, at attribute level, from partial replication. To determine which attributes are to be excluded, the directory replication server uses the value of the orclExcludedAttributes attribute of the replica naming context object.

In this example, the telephonenumber and title attributes of the naming context specified in the orclincludednamingcontexts attribute are excluded from replication.

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

    DN:cn=naming_context_identifier,
     cn=replication namecontext,
     orclagreementid=replication_agreement_identifier,
     orclreplicaid=supplier_replica_identifier,cn=replication configuration 
    Changetype:modify
    Replace: orclExcludedAttributes
    orclExcludedAttributes: telephonenumber
    orclExcludedAttributes: title
    
    
  2. Use ldapmodify to update the replication agreement orclupdateschedule attribute.

    ldapmodify -D "cn=orcladmin" -w administrator_password -h my_host \
               -p port -f mod.ldif
    
    
  3. Restart the directory replication server.

25.3 Managing Replication

Once you have installed and configured replication, you can view or modify the default values for replication-related objects. This section contains these topics:

25.3.1 Viewing and Modifying Directory Replication Server Configuration Parameters

The section "Directory Server Configuration Parameters" under "Replication Schema Elements" in Oracle Identity Management User Reference lists and describes the directory replication server configuration parameters. These parameters are stored in the replication server "configuration set entry", which has the following DN: cn=configset0,cn=osdrepld,cn=subconfigsubentry. This entry contains replication attributes that control replication processing. You can modify some of these attributes.

25.3.1.1 Viewing Configuration Parameters of the Directory Replication Server by Using Oracle Directory Manager

To view configuration parameters of the directory replication server:

  1. In the navigator pane, expand in succession Oracle Internet Directory Servers, directory server instance, Server Management.

  2. Select Replication Server. The following tab pages appear in the right pane.

    • Active Replication Servers, which tells you which directory replication servers are now running

    • Replication Status, which tells you the number of the last change applied from each supplier to each consumer in the DRG

    • Changelog Subscriber Status, which lists subscribers to the change log, and gives the number of the last change applied from this node

25.3.1.2 Modifying Configuration Parameters of the Directory Replication Server by Using Oracle Directory Manager

To modify configuration parameters of the directory replication server:

  1. In the navigator pane, expand Oracle Internet Directory Servers, directory server instance, Server Management, Replication Server.

  2. Select the replication configuration set whose parameters you want to modify. The corresponding tab pages appear in the right pane.

  3. In the General tab page, modify the fields as appropriate.

    For a description of these fields, see Table A-16, "Fields in the Replication Server Configuration Set: General Tab Page".

  4. For Advanced Replication-based agreements, in the ASR Agreement tab page, modify the fields as appropriate.

    For a description of these fields, see Table A-17, "Fields in the ASR Agreement Tab Page".

  5. Restart the directory replication server to effect your changes.


    Note:

    Be sure to add all host names for all nodes in the DRG into the Replication Group Nodes field. Do this for all nodes in the DRG.

25.3.1.3 Modifying Directory Replication Server Configuration Parameters by Using Command-Line Tools

To modify replication configuration parameters by using command-line tools, use the syntax documented in the "ldapmodify" command-line tool reference in Oracle Identity Management User Reference.

"Replication Schema Elements" in Oracle Identity Management User Reference describes the replication server configuration parameters. As noted in that table, the modifiable replication configuration parameters are:

  • orclChangeRetryCount

  • orclThreadsPerSupplier

Example 25-9 Modifying the Number of Retries Before a Change Is Moved into the Purge Queue

This example uses an input file named mod.ldif to change the number of retry attempts from the default of ten times to five times. Specifically, after attempting to apply an update five times, the update is dropped and logged in the replication log.

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

    dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry
    changetype: modify 
    replace: orclChangeRetryCount
    orclChangeRetryCount: 5
    
  2. Use ldapmodify to update the replication server configset0 parameter value as follows:

    ldapmodify –D "cn=orcladmin" –w administrator_password -h my_host \
              -p port -f mod.ldif
    
    
  3. Restart the directory replication server.

Example 25-10 Modifying the Number of Worker Threads Used in Change Log Processing

This example uses an input file named mod.ldif to change the number of worker threads used in change log processing to 7.

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

    dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry 
    changetype: modify
    replace: orclthreadspersupplier
    orclthreadspersupplier: 7
    
    
  2. Use ldapmodify to update the replication server configset0 parameter value as follows:

    ldapmodify –D "cn=orcladmin" –w administrator_password -h my_host \
               -p port -f mod.ldif
    
    
  3. Restart the directory replication server.


    See Also:

    The "oidctl" command-line tool reference in Oracle Identity Management User Reference for instructions on restarting the directory replication server

25.3.2 Viewing and Modifying Parameters for Particular Replica Nodes

To modify a particular replica node, you modify the replica subentry. "Replication Schema Elements" in Oracle Identity Management User Reference describes the parameters you can modify in the replica subentry.


Note:

Because the directory replication server reads replication node objects from the consumer, you must apply all changes to the consumer and, optionally, to the supplier.


See Also:

"The Replica Subentry" for more information about the replica subentry

25.3.2.1 Viewing and Modifying Parameters for a Particular Replica Node by Using Oracle Directory Manager

To view and modify a particular replica node by using Oracle Directory Manager:

  1. In the navigator pane, expand Oracle Internet Directory Servers, directory server instance, Replication Management.

  2. Select the replica node you want to view or modify. The corresponding tab pages appear in the right pane.

  3. In the General tab page, you can modify the fields as appropriate. Table A-18, "Fields in the Replica Node: General Tab Page" describes the fields in this tab page.

  4. The Replica Agreements tab page enables you to view the details of the replication agreement in which the specified node participates. The columns in this tab page are described in Table A-19, "Columns in the Replica Agreements Tab Page".

  5. After you have viewed and modified the replica node, restart the directory replication server.

25.3.2.2 Modifying a Particular Replica Node by Using Command-Line Tools

To modify replication configuration parameters by using command-line tools, use the syntax documented in the "ldapmodify" command-line tool reference in Oracle Identity Management User Reference.

Example 25-11 Modifying the orclReplicaURI Attribute for a Particular Replica Node

The directory replication server uses the orclReplciaURI attribute value of the replica subentry to locate the directory server for that replica. If the port or host where the directory server is running is changed, then this attribute must be modified accordingly.

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

    Dn: orclreplicaid=unique_replica_identifier, cn=replication configuration
    Changetype:modify
    Replace:orclReplicaURI
    OrclReplicaURI: ldap://host_name:port_number/
    
    
  2. Use ldapmodify to update the replica subentry orclreplicauri attribute.

    ldapmodify –D "cn=orcladmin" –w administrator_password -h my_host \
               -p port -f mod.ldif
    
    
  3. Restart the directory replication server.

Example 25-12 Modifying the orclReplicaSecondaryURI Attribute for a Particular Replica

The directory replication server uses the orclReplicaSecondaryURI attribute value as an alternate location to contact the directory server for a particular replica. A user can add an alternate ldapURI attribute at which the directory server can be contacted for that particular replica. To add additional ldapURI attribute:

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

    Dn: orclreplicaid=unique_replica_identifier, cn=replication configuration
    Changetype:modify
    add:orclReplicaSecondaryURI
    OrclReplicaSecondaryURI: ldap://host_name:port_number/
    
    
  2. Use ldapmodify to update the replica subentry OrclReplicaSecondaryURI attribute.

    ldapmodify –D "cn=orcladmin" –w administrator_password -h my_host \
               -p port -f mod.ldif
    
    
  3. Restart the directory replication server.

Example 25-13 Modifying the orclReplicaState Attribute for a Particular Replica

OrclReplicaState represents the state of a particular replica. To bootstrap (re-initialize) a replica, update this attribute in the following manner:

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

    Dn: orclreplicaid=unique_replicaID, cn=replication configuration
    Changetype:modify
    replace:orclReplicaState
    OrclReplicaState: 0
    
    
  2. On the host where the consumer replica is running, use ldapmodify to update the replica subentry orclreplicastate attribute.

    ldapmodify –D "cn=orcladmin" –w administrator_password -h consumer_host \
               -p port -f mod.ldif
    
    
  3. Restart the directory replication server.

25.3.3 Modifying Parameters for Replication Agreements

This section contains instruction for modifying replication agreements that are based on both Advanced Replication and LDAP.

25.3.3.1 Modifying Parameters for Replication Agreements Based on Oracle Database Advanced Replication

Replication agreement parameters based on Advanced Replication are stored in replication agreement entries, which have the following DN:

orclAgreementID=000001,cn=replication configuration


Note:

  • For replication agreements based on Advanced Replication, in the parameter DirectoryReplicationGroupDSAs, enter the host names for all of the nodes in the DRG. This list must be identical on all the nodes.

  • For Oracle Internet Directory 10g Release 2 (10.1.2), only one replication agreement based on Oracle Database Advanced Replication can be used. The DN of this replication agreement is orclagreementid=000001,cn=replication configuration.

  • Before you modify replication agreement parameters, be sure that you have started the Oracle Internet Directory on all nodes.


25.3.3.1.1 Viewing and Modifying Replication Agreements Based on Oracle Database Advanced Replication by Using Oracle Directory Manager

To view and modify replication agreement parameters by using Oracle Directory Manager:

  1. In the navigator pane, expand Oracle Internet Directory Servers, then directory server instance, then Replication Management. The following tab pages appear in the right pane:

    • Replication Status, which tells you the number of the last change applied from each supplier to each consumer in the DRG

    • Replica Status, which tells you the state of the replica—that is, whether it is online, offline, or in the bootstrapping process.

    • Changelog Subscriber, which lists subscribers to the change log, and gives the number of the last change applied from this node

    • ASR Agreement, in which you can view and modify the information for an Advanced Replication-based replication agreement. The fields in this tab page are described in Table A-17, "Fields in the ASR Agreement Tab Page".


      Note:

      Be sure to add all host names for all nodes in the DRG into the Replication Group Nodes field. Do this for all nodes in the DRG.

  1. If you are modifying the values, and want to return to the values that appeared when you first opened this pane, then click Revert. If you are satisfied with your changes, then click Apply.

25.3.3.1.2 Managing Replication Agreements Based on Advanced Replication by Using ldapmodify

"Replication Schema Elements" in Oracle Identity Management User Reference lists and describes the replication agreement parameters and indicates those that you can modify.

To add more nodes to the values in a replication agreement entry, run ldapmodify at the command line, referencing an LDIF-formatted file.

Example 25-14 Adding Nodes to a Replication Agreement

This example uses an input file named mod.ldif to add two nodes to a replication agreement:

  1. Edit mod.ldif as follows:

    dn: orclagreementid=000001,cn=replication configuration
    changetype: modify 
    add: orcldirreplgroupdsas
    orcldirreplgroupdsas: hollis
    orcldirreplgroupdsas: eastsun-11
    
  2. Use ldapmodify to update the replication server configset0 parameter value as follows:

    ldapmodify –D "cn=orcladmin" –w administrator_password -h host \
              -p port -f mod.ldif
    
    
  3. Restart the directory replication server.

This procedure modifies the entry containing the replication agreement whose DN is orclagreementid=000001,cn=replication configuration. The input file adds the two nodes, hollis and eastsun-11, into the replication group governed by oraclagreementid=000001.


Note:

You must include the new nodes—for example, hollis and eastsun-11 in the previous sample LDIF file—in the orclDirReplGroupDSAs parameter on each node in the replicated environment before you start the replication process.

"Adding a Node for Multimaster Replication (Oracle Database Advanced Replication Types Only)" explains the process of adding a new node to a replication environment.


Because Oracle Internet Directory 10g Release 2 (10.1.2) supports only one configuration set for the directory replication server, you do not need to specify a configuration set.

Example 25-15 Modifying the orclExcludedNamingContexts Attribute for an Oracle Database Advanced Replication Replica Agreement

In a replication agreement based on Advanced Replication, the directory replication server uses the value of the orclExcludedNamingcontexts attribute of the replica agreement entry to specify the top level subtrees to be excluded from replication.

In this example, two top level naming contexts—c=us and c=uk—are excluded from Advanced Replication.

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

    dn: orclAgreementID=000001, cn=replication configuration
    Changetype:modify
    Replace: orclExcludedNamingcontexts
    orclExcludedNamingcontexts: c=us
    orclExcludedNamingcontexts: c=uk
    
    
  1. Use ldapmodify to update the replication agreement orclupdateschedule attribute.

    ldapmodify -D "cn=orcladmin" -w administrator_password -h consumer_host \
               -p port -f mod.ldif
    
    
  2. Restart the directory replication server.

25.3.3.2 Modifying Parameters for Replication Agreements Based on LDAP

LDAP-based replication agreement parameters are stored in replication agreement entries, which have the following DN:

orclAgreementID=unique_identifier_of_the_replication_agreement,
 orclReplicaId=unique_identifier_of_the_supplier, cn=replication configuration

Note:

Ensure that the agreement is identical at both the supplier and the consumer. The replication server reads the last applied change number and the naming context from the agreement at the supplier node. It reads the other agreement attributes from the consumer.

25.3.3.2.1 Viewing and Modifying LDAP-Based Replication Agreement Parameters by Using Oracle Directory Manager

To view and modify replication agreement parameters by using Oracle Directory Manager:

  1. In the navigator pane, expand in succession Oracle Internet Directory Servers, directory server instance, Replication Management, Replica Node: replica identifier.

  2. Select the replica agreement you want to view or modify. The following tab pages appear in the right pane:

25.3.3.2.2 Modifying LDAP-Based Replication Agreement Parameters by Using ldapmodify

"Replication Schema Elements" in Oracle Identity Management User Reference describes the replication agreement parameters and indicates those that you can modify.

Example 25-16 Modifying the orclUpdateSchedule Attribute for a Particular Replica Agreement

The directory replication server uses the orclupdateschedule attribute value of the replica agreement entry as time interval in minutes to determine how often the replication server process the new change logs from the supplier.

This example shows that replication server will process new change logs from the supplier for every minute.

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

    dn: orclAgreementID=id_number,orclReplicaId=replica_identifier, 
     cn=replication configuration
    Changetype:modify
    Replace: orclupdateschedule
    orclupdateschedule: 1
    
    
  2. Use ldapmodify to update the replication agreement orclupdateschedule attribute.

    ldapmodify -D "cn=orcladmin" -w administrator_password -h consumer_host \
               -p port -f mod.ldif
    
    
  3. Restart the directory replication server.

Example 25-17 Modifying the orclLastAppliedChangeNumber Attribute for a Particular Replica Agreement

The directory replication server uses the value orclLastAppliedChangeNumber attribute to determine the number of last applied change log processed by the consumer.

The modification of the orclLastAppliedChangeNumber attribute must be applied against the supplier node since replication server reads orclLastAppliedChangeNumber from the same duplicate agreement at the supplier.

In this example, orclLastAppliedChangeNumber attribute of the duplication agreement at the supplier is set to 700, which indicates all change logs with changelog number prior to 700 has been processed by the replication server.


Note:

Do not modify the orclLastAppliedChangeNumber attribute except as instructed during the partial replication add node procedure.

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

    dn: orclAgreementID=unique_identifier_of_the_replication_agreement,  
     orclReplicaId=unique_identifier_of_the_supplier,cn=replication configuration
    Changetype:modify
    Replace: orclLastAppliedChangeNumber
    orclLastAppliedChangeNumber: 700
    
    
  2. Use ldapmodify to update the replication agreement orclupdateschedule attribute at the supplier.

    ldapmodify -D "cn=orcladmin" -w administrator_password \
               -h supplier_host -p port -f mod.ldif
    
    
  3. Restart the directory replication server.

25.3.4 Changing the Replication Administrator's Password on All Nodes

You can change the password for the replication administrator database account on all nodes of a DRG by using the -chgpwd argument to the Replication Environment Management Tool, remtool. To use this argument, enter:

remtool -chgpwd

The remtool utility then prompts you for the MDS Global Name—that is, the name of the Master Definition Site—the current password, and the new password. It then asks you to confirm the new password. If you enter an incorrect current password, then you must run the Replication Environment Management Tool again.

You can also use the -pchgpwd argument to remtool to change the password of the replication DN of a replica.

To change the password only in the replication wallet, $ORACLE_HOME/dap/admin, use the -pchgwalpwd argument to remtool. To use this argument, enter:

remtool -pchgwalpwd 


See Also:

The "remtool" command-line tool reference in Oracle Identity Management User Reference for more information about using this tool

25.3.5 Managing the Change Log

Oracle Directory Manager enables you to view the last 25 changes you performed, listing them by change log number, the type of operation—namely, add, modify, or delete—in which each occurred, and the entry on which each was made. It allows you select a particular change to see more specific details about it.

To manage the change log, in the navigator pane expand in succession Oracle Internet Directory Servers, directory server instance, then select Change Log Management. The right pane lists the last 25 changes, beginning with the most recent. It tells you the change number, the type of operation in which each change occurred, and the entry on which the change was made.

To see the details of a particular change, in the right pane, select the change, then choose View Properties. The Change Log window appears. The fields for the Change Log window are listed and described in Table A-21, "Fields in the Change Log Window".

25.3.6 Modifying the Speed of Directory Replication

In the default configuration for replication, the orclupdateschedule attribute is set to a value of 1, representing 1 minute. You can shorten the replication processing time by changing the value of the orclupdateschedule attribute to 0, representing 1 second.

25.3.6.1 Modifying the Speed of Directory Replication When Using Oracle Database Advanced Replication

In directory replication based on Advanced Replication, the default configuration achieves a processing time that is approximately 2.5 minutes:

  • 1 minute for the supplier to prepare the change for sending to the consumer

  • 30 seconds for Advanced Replication to push the change to the consumer

  • 1 minute for the consumer to apply the change

In the case of Advanced Replication, changing the default value for the orclupdateschedule attribute to 0 results in a replication time of 32 seconds. To do this:

  1. Edit mod.ldif as follows:

    dn: orclagreementid=orclagreementid=000001, cn=replication configuration,  cn=replication configuration changetype:modify  replace: orclupdateschedule  orclupdateschedule: 0
    
    
  2. Upload mod.ldif as follows:

    ldapmodify -D "cn=orcladmin" -w administrator_password -h host_name -p port \
              -v -f mod.ldif
    
    
  3. Restart the directory replication server

    oidctl connect=connect_string server=oidrepld instance=instance_number restart
    

25.3.6.2 Modifying the Speed of Directory Replication When Using LDAP-Based Replication

In LDAP-based directory replication, the default configuration achieves a processing time that is approximately 1 minute during which the change is retrieved from the supplier and applied to the consumer. Changing the default value for the orclupdateschedule attribute to 0 results in a replication time of 1 second. To do this:

  1. Edit mod.ldif as follows:

    dn: orclAgreementID=unique_identifier_of_the_replication_agreement,
     orclReplicaId=unique_identifier_of_the_supplier,
     cn=replication configuration
    changetype:modify 
    replace: orclupdateschedule 
    orclupdateschedule: 0
    
    
  2. On the consumer host, upload mod.ldif as follows:

    ldapmodify -h consumer_host_name -p consumer_port -D cn=orcladmin \
               –w administrator_password -v -f mod.ldif
    
    
  3. Restart the directory replication server

    oidctl connect=connect_string server=oidrepld instance=instance_number restart
    

25.4 Example: Installing and Configuring a Multimaster Replication Group with Fan-Out

To help you install and configure a multimaster replication group with fan-out, this section offers an example with four systems as described in Table 25-2.

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


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

Figure 25-1 Example of Fan-Out Replication

LDAP-based fan-out replication
Description of "Figure 25-1 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 the multimaster replication group for Node1 and Node2, follow Tasks 1 through 5 in "Installing and Configuring a 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" -w administrator_password -h mycompany1.com \
               -p 3000 -f mod.ldif
    ldapmodify -D "cn=orcladmin" -w administrator_password -h mycompany2.com \
               -p 4000 -f mod.ldif
    

Task 3: Start the Replication Servers on Node1 and Node2

To do this, follow the instructions in "Task 6: Start the Replication Servers on All Nodes in the DRG".

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

To do this, follow the instructions in "Task 7: Test Directory Replication".

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 "Configuring 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 "Configuring 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, follow the instructions in "Task 11: Start the Directory Replication Server on the Consumer Replica".

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 "Installing and Configuring an LDAP Replica with Default Settings". When the installer prompts for the supplier information, provide the supplier hostname, mycompany2.com, the supplier port, 4000, and the super user password.


Note:

While installing node 4 as described in "If you are installing Oracle Internet Directory as a Replica", you will be asked to provide the supplier's hostname, port, and administrator_user_password. For example:
Hostname: mycompany2.com
Porg:4000
Administrator_user_password: admin_user_password

Task 9: Test the Replication from Node2 to Node4

Test this replication using the instructions in the section entitled "Task 7: Test Directory Replication".