Replication

Directory Server, Version 6.1

Replication

Replication is a technique used by directory servers to improve performance, availability, and reliability. The replication process keeps the data in multiple directory servers synchronized.
Replication provides three main benefits:

Redundancy of information - Replicas back up the content of their supplier servers.
Faster searches - Search requests can be spread among several different servers, instead of a single server. This improves the response time for the request completion.
Security and content filtering - Replicas can contain subsets of the data in a supplier server.

Replication terminology

Cascading replication

A replication topology in which there are multiple tiers of servers. A peer/master server replicates to a set of read-only (forwarding) servers, which in turn replicate to other servers. Such a topology off-loads replication work from the master servers.

Consumer server

A server that receives changes through replication from another (supplier) server.

Credentials

Identify the method and required information that the supplier uses in binding to the consumer. For simple binds, this includes the DN and password. The credentials are stored in an entry the DN of which is specified in the replica agreement.

Forwarding server

A read-only server that replicates all changes sent to it. This contrasts with a peer/master server in that it is read only and it can have no peers.

Gateway server

A server that forwards all replication traffic from the local replication site where it resides to other Gateway servers in the replicating network. Also receives replication traffic from other Gateway servers within the replication network, which it forwards to all servers on its local replication site.
Gateway servers must be masters (writable).

Master server

A server that is writable (can be updated) for a given subtree.

Nested subtree

A subtree within a replicated subtree of the directory.

Peer server

The term used for a master server when there are multiple masters for a given subtree. A peer server does not replicate changes sent to it from another peer server; it only replicates changes that are originally made on it.

Replica group

The first entry created under a replication context has objectclass ibm-replicaGroup and represents a collection of servers participating in replication. It provides a convenient location to set ACL's to protect the replication topology information. The administration tools currently support one replica group under each replication context, named ibm-replicagroup=default.

Replica subentry

Below a replica group entry, one or more entries with objectclass ibm-replicaSubentry can be created; one for each server participating in replication as a supplier. The replica subentry identifies the role the server plays in replication: master or read-only. A read-only server might, in turn, have replication agreements to support cascading replication.

Replicated subtree

A portion of the directory information tree (DIT) that is replicated from one server to another. Under this design, a given subtree can be replicated to some servers and not to others. A subtree can be writable on a given server, while other subtrees may be read-only.

Replicating network

A network that contains connected replication sites.

Replication agreement

Information contained in the directory that defines the 'connection' or 'replication path' between two servers. One server is called the supplier (the one that sends the changes) and the other is the consumer (the one that receives the changes). The agreement contains all the information needed for making a connection from the supplier to the consumer and scheduling replication.

Replication context

Identifies the root of a replicated subtree. The ibm-replicationContext auxiliary object class may be added to an entry to mark it as the root of a replicated area. The configuration information related to replication is maintained in a set of entries created below the base of a replication context.

Replication site

A Gateway server and any master, peer, or replica servers configured to replicate together.

Schedule

Replication can be scheduled to occur at particular times, with changes on the supplier accumulated and sent in a batch. The replica agreement contains the DN for the entry that supplies the schedule.

Supplier server

A server that sends changes to another (consumer) server.

Replication topology

The set of objects in a directory that control what kind of information is replicated between LDAP servers and how it is replicated. These objects include:

Replication contexts
Replication groups
Replication subentries
Replication agreements
Replication credentials
Replication schedule entries
All LDAP servers in the replicating network should have the same replication topology.

Replication topology

Specific entries in the directory are identified as the roots of replicated subtrees, by adding the ibm-replicationContext objectclass to them. Each subtree is replicated independently. The subtree continues down through the Directory Information Tree (DIT) until reaching the leaf entries or other replicated subtrees (context). Entries are added below the root of the replicated subtree to contain the replication configuration information. These entries are one or more replica group entries, under which are created replica subentries. Associated with each replica subentry are replication agreements that identify the servers that are supplied (replicated to) by each server, as well as defining the credentials and schedule information.
Through replication, a change made to one directory is propagated to one or more additional directories. In effect, a change to one directory shows up on multiple different directories. The IBM® Tivoli® Directory supports an expanded master-replica replication model. Replication topologies are expanded to include:

Replication of subtrees of the Directory Information Tree to specific servers
A multi-tier topology referred to as cascading replication
Assignment of server role (supplier or consumer) by subtree.
Multiple master servers, referred to as peer to peer replication.
Gateway servers that replicate across networks.

The advantage of replicating by subtrees is that a replica does not need to replicate the entire directory. It can be a replica of a part, or subtree, of the directory.
The expanded model changes the concept of master and replica. These terms no longer apply to servers, but rather to the roles that a server has regarding a particular replicated subtree. A server can act as a master for some subtrees and as a replica for others. The term, master, is used for a server that accepts client updates for a replicated subtree. The term, replica, is used for a server that only accepts updates from other servers designated as a supplier for the replicated subtree.
There are four types of directory roles as defined by function: master/peer, gateway, forwarding (cascading), and replica (read-only).
Table 22. Server roles

Master/peer

The master/peer server contains the master directory information from where updates are propagated to the replicas. All changes are made and occur on the master server, and the master is responsible for propagating these changes to the replicas.
There can be several servers acting as masters for directory information, with each master responsible for updating other master servers and replica servers. This is referred to as peer replication. Peer replication can improve performance and reliability. Performance is improved by providing a local server to handle updates in a widely distributed network. Reliability is improved by providing a backup master server ready to take over immediately if the primary master fails.
Notes:

Master servers replicate all client updates, but do not replicate updates received from other masters.
Updates among peer servers can be immediate or scheduled. See Creating replication schedules for more information.

Forwarding (Cascading)

A forwarding or cascading server is a replica server that replicates all changes sent to it. This contrasts to a master/peer server in that a master/peer server only replicates changes that are made by clients connected to that server. A cascading server can relieve the replication workload from the master servers in a network which contains many widely dispersed replicas.
Gateway

Gateway replication uses Gateway servers to collect and distribute replication information effectively across a replicating network. The primary benefit of Gateway replication is the reduction of network traffic.
Replica (read-only)

An additional server that contains a copy of directory information. The replicas are copies of the master (or the subtree that it is a replica of). The replica provides a backup of the replicated subtree.

We can request updates on a replica server, but the update is actually forwarded to the master server by returning a referral to the client. If the update is successful, the master server then sends the update to the replicas. Until the master has completed replication of the update, the change is not reflected on the replica server where it was originally requested. If the replication fails, it is repeated even if the master is restarted. Changes are replicated in the order in which they are made on the master. See Replication error handling.
If you are no longer using a replica, remove the replica agreement from the supplier. Leaving the definition causes the server to queue up all updates and use unnecessary directory space. Also, the supplier continues trying to contact the missing consumer to retry sending the data.

Overview of replication

This section presents a high-level description of the various types of replication topologies.

Simple replication

The basic relationship in replication is that of a master server and its replica server. The master server can contain a directory or a subtree of a directory. The master is writable, which means it can receive updates from clients for a given subtree. The replica server contains a copy of the directory or a copy of part of the directory of the master server. The replica is read only; it cannot be directly updated by clients. Instead it refers client requests to the master server, which performs the updates and then replicates them to the replica server.
A master server can have several replicas. Each replica can contain a copy of the master's entire directory, or a subtree of the directory. In the following example Replica 2 contains a copy of the complete directory of the Master Server, Replica 1 and Replica 3 each contain a copy of a subtree of the Master Server's directory.
Figure 7. Master-replica replication

The relationship between two servers can also be described in terms of roles, either supplier or consumer. In the previous example the Master Server is a supplier to each of the replicas. Each replica in turn is a consumer of the Master Server.

Cascading replication

Cascading replication is a topology that has multiple tiers of servers. A master server replicates to a set of read-only (forwarding) servers that in turn replicate to other servers. Such a topology off-loads replication work from the master server. In the example of this type of topology, the master server is a supplier to the two forwarding servers. The forwarding servers serve two roles. They are consumers of the master server and suppliers to the replica servers associated with them. The replica servers are consumers of their respective forwarding servers. For example:
Figure 8. Cascading replication

Peer-to-peer replication

There can be several servers acting as masters for directory information, with each master responsible for updating other master servers and replica servers. This is referred to as peer replication. Peer replication can improve performance, availability, and reliability. Performance is improved by providing a local server to handle updates in a widely distributed network. Availability and reliability are improved by providing a backup master server ready to take over immediately if the primary master fails. Peer master servers replicate all client updates to the replicas and to the other peer masters, but do not replicate updates received from other master servers.

Conflict resolution for add and modify operations in peer-to-peer replication is based on Timestamp. See Replication conflict resolution.

In a Peer-to-peer replication setup with one replica server for each peer-master, if the primary master fails, the proxy server directs the requests to the backup master server. However, the proxy server will not fall back to the primary master until the backup master server fails.
The following is an example of peer-to-peer replication:
Figure 9. Peer-to-peer replication

Gateway replication

Gateway replication is a more complex adaptation of peer-to-peer replication that extends replication capabilities across networks. The most notable difference is that a gateway server does replicate changes received from other peer servers through the gateway.
A gateway server must be a master server, that is, writable. It acts as a peer server within its own replication site. That is, it can receive and replicate client updates and receive updates from the other peer-master servers within the replication site. It does not replicate the updates received from the other peer-masters to any servers within its own site.
Within the gateway network, the gateway server acts as a two-way forwarding server. In one instance, the peers in its replication site act as the suppliers to the gateway server and the other gateway servers are its consumers. In the other instance the situation is reversed. The other gateway servers act as suppliers to the gateway server and the other servers within its own replication site are the consumers.
Gateway replication uses gateway servers to collect and distribute replication information effectively across a replicating network. The primary benefit of gateway replication is the reduction of network traffic. For example:
Figure 10. Gateway replication

Partial replication

Partial replication is a replication feature that replicates only the specified entries and a subset of attributes for the specified entries within a subtree. Using partial replication, an administrator can enhance the replication bandwidth depending on the deployment requirements. The attributes that are to be replicated are specified using a replication filter. For more information on partial replication, see Partial Replication

Replication conflict resolution

If replication conflicts occur involving delete or modifyDN operations, errors that require human intervention might result. For example, if an entry is renamed on one server while it is being modified on a second server, the rename (modifyDN) might arrive at a replica before the modify. Then when the modify arrives, it fails. In this case, the administrator needs to respond to the error by applying the modify to the entry with the new DN. All information necessary to redo the modify with the correct name is preserved in the replication and error logs. Replication errors are rare occurrences in a correctly configured replication topology, but it is not safe to assume that they never occur.
Conflict resolution for add and modify operations in peer-to-peer replication is based on Timestamp. The entry update with the most recent modify TimeStamp on any server in a multi-master replication environment is the one that takes precedence. Replicated delete and rename request are accepted in the order received without conflict resolution. When a replication conflict is detected the replaced entry is archived for recovery purposes in the Lost and Found log. See Logging Utilities for more information.
Updates to the same entry made by multiple servers might cause inconsistencies in directory data because conflict resolution is based on the TimeStamp of the entries. The most recent modify TimeStamp takes precedence. If the data on your servers become inconsistent, see the ldapdiff command information in the IBM Tivoli Directory Server version 6.1 Command Reference for information on resynchronizing servers.
For IBM Tivoli Directory Server versions 6.0 and above to resolve replication conflict, it needs the supplier to provide the entry's timestamp before the entry was updated on the supplier. For a previous version of the server, such as IBM Directory Server 5.1 or IBM Tivoli Directory Server 5.2, the server does not have the capability to supply this kind of information. Therefore, replication conflict resolution is not applicable to cases where the supplier is a downlevel server. The IBM Tivoli Directory Server 6.0 consumer server, in this case, takes the replicated timestamp and update and applies it without conflict checking.
Notes:

Earlier versions of the IBM Tivoli Directory Server do not support time stamp conflict resolution. If your topology contains earlier versions of the IBM Tivoli Directory Server, data consistency is not ensured for the network. See Appendix B. Object Identifiers (OIDs) and attributes in the root DSE and OIDs for supported and enabled capabilities to find out how to determine, if your servers support conflict resolution.
To resolve replication conflict, a regular database entry which has a later timestamp is not replaced by a replicated entry which has an earlier timestamp. However, conflict resolution does not apply to entry cn=schema which is always replaced by a replicated cn=schema.

Setting up a load balancer is one method of resolving data conflict resolution.
A load balancer, such as the IBM WebSphere® Edge Server, has a virtual host name that applications use when sending updates to the directory. The load balancer is configured to send those updates to only one server. If that server is down, or unavailable because of a network failure, the load balancer sends the updates to the next available peer server until the first server is back on line and available. Refer to your load balancer product documentation for information on how to install and configure the load balancing server.

Replication error handling

Replication errors are any replicated updates for which the consumer returns a result other than LDAP_SUCCESS. Replication conflict errors return LDAP_OTHER and a special control, and are not treated as errors unless the data is greater than allowed by the server configuration.
Replication errors can be logged in the database. The size of the replication error log is in the server configuration (ibm-slapdReplMaxErrors) and can be updated dynamically. Replication errors are stored and managed per replication agreement, that is, if there are two agreements, then one agreement might have some errors logged, and the other agreement might have no errors logged.
How errors are addressed depends on the replication method. For single-threaded replication, the following occurs:
ibm-slapdReplMaxErrors: 0 means that no errors are logged and the first error is retried every minute until it succeeds or is skipped.
If the number of errors for an agreement reaches the limit, the next error is retried until the error succeeds, is skipped, the number of errors for an agreement limit is increased, or an error is cleared from the log. The data for an entry that is being retried is displayed by the replication status attribute ibm-replicationChangeLDIF.
The status for the replication agreement is:
ibm-replicationStatus: retrying
For multi-threaded replication, the following occurs:
ibm-slapdReplMaxErrors: 0 means that no errors should be logged, but any errors are logged and replication is suspended until all of the errors are cleared.
If the number of errors for an agreement exceeds the limit, replication is suspended until at least one error is cleared, or the number of errors for an agreement limit is increased.
The status for the replication agreement is:
ibm-replicationStatus: error log full
For more information about viewing replication errors, see the IBM Tivoli Directory Server Version 6.1 Problem Determination Guide.

Replication agreements

A replication agreement is an entry in the directory with the object class ibm-replicationAgreement created beneath a replica subentry to define replication from the server represented by the subentry to another server. These objects are similar to the replicaObject entries used by prior versions of the IBM Tivoli Directory Server. The replication agreement consists of the following items:

A user friendly name, used as the naming attribute for the agreement.
An LDAP URL specifying the server, port number, and whether SSL should be used.
The consumer server ID, if known -- 'unknown' for a server whose server ID is not known (if a server is running a release earlier than IBM Tivoli Directory Server version 5.2, or if the server ID could not be retrieved while setting up the topology).
The DN of an object containing the credentials used by the supplier to bind to the consumer.
An optional DN pointer to an object containing the schedule information for replication. If the attribute is not present, changes are replicated immediately.
Replication method (single threaded or multi-threaded).
Number of consumer: For a replication agreement using the single-threaded replication method, the number of consumer connections is always one, the attribute value is ignored. For an agreement using multi-threaded replication, the number of connections can be configured from 1 to 32. If no value is specified on the agreement, the number of consumer connections is set to one.

For the cn=ibmpolicies subtree, all replication agreements will use the single-threaded replication method and one consumer connection, ignoring the attribute values.

The user friendly name might be the consumer server name or some other descriptive string.
To aid in enforcing the accuracy of the data, when the supplier binds to the consumer, it retrieves the server ID from the root DSE and compares it to the value in the agreement. A warning is logged if the server IDs do not match.
The consumer server ID is used by the Web Administration Tool to traverse the topology. Given the consumer's server ID, the Web Administration Tool can find the corresponding subentry and its agreements.
Because the replication agreement can be replicated, a DN to a credentials object is used. This allows the credentials to be stored in a nonreplicated area of the directory. Replicating the credentials objects (from which 'clear text' credentials must be obtainable) represents a potential security exposure. The cn=localhost suffix is an appropriate default location for creating credentials objects. Use of a separate object also makes it easier to support various authentication methods; new object classes can be created rather than trying to make sense of numerous optional attributes.
Object classes are defined for each of the supported authentication methods:

Simple bind
SASL EXTERNAL mechanism with SSL
Kerberos authentication

We can designate that part of a replicated subtree not be replicated by adding the ibm-replicationContext auxiliary class to the root of the subtree, without defining any replica subentries.
The following sections are examples of setting up replication using either the Web Administration Tool or the command line utilities, and an LDIF file. The scenarios are of increasing complexity:

One master and one replica
One master, one forwarder, and one replica
Two peer/masters, two forwarders, and four replicas.
Gateway replication.

Things to consider before configuring replication

Before setting up an LDAP replication configuration, there are some administrative responsibilities that we need to consider. In order to ensure that replication is operating smoothly and that your replicas are staying up-to-date, the administrator needs to take some periodic actions to monitor the replication status. After replication is correctly configured, it continues to automatically propagate updates to all defined replica servers. However, if errors occur, human intervention might be required to fully correct the problem.
Interfaces are provided to allow you to view information about updates queued for replication, and to take actions like suspending or resuming replication to a specific replica. See Managing queues for details. These replication queues should be checked periodically for errors. Read Viewing server errors to understand how to check for errors that may have occurred during replication to a specified consumer server.
Detailed status and error information is also available to the administrator by reading operational attributes on the replication agreements. See Monitoring replication status for a description of the information available.
Configuring multiple master servers adds to the potential error cases that an administrator must be aware of. If the same entry is updated at two different master servers at approximately the same time, those updates are likely to conflict when they are replicated to other servers in the topology. The replication algorithm is designed to detect and resolve any replication conflicts between adds or modifies. See Replication conflict resolution.
We can use a time synchronization product to keep your LDAP servers synchronized. Such a utility is not provided by IBM Tivoli Directory Server.
Attention: When you create a new directory server instance, be aware of the information that follows. If you want to use replication, synchronize the encryption keys of the server instances to obtain the best performance.
If you are creating a directory server instance that must be cryptographically synchronized with an existing directory server instance, synchronize the encryption keys on the server instances before you do any of the following because the server will generate server encryption keys:

Start the second server instance
Run the idsbulkload command from the second server instance
Run the idsldif2db command from the second server instance
See Appendix J. Synchronizing two-way cryptography between server instances for information about synchronizing directory server instances.

The server does not allow subtree deletion if the subtree contains replication agreements. Because the order of entries to be deleted is not fixed, deleted entries can be replicated randomly. For example, if a replication agreement is deleted first in a subtree, then the delete operation cannot be replicated. This restriction works only when a context is deleted with the -s option. If you want to delete the subtree, first delete the replication agreements.

You must synchronize the replication topology entries before starting replication. Set up the servers in the network.

Replicating schema and password policy updates

Schema and password policy updates are only updated using the cn=ibmpolicies subtree. To ensure that the schemas and password policy is synchronized across all of your servers, create an additional replication context for cn=ibmpolicies. This replication context needs to include all the servers that are in your directory topology.

If you are using a proxy server, password policy updates are replicated. Schema changes, however, are not. To ensure that schemas are kept synchronized in a proxy environment, the schema update needs to be made on each proxy server and also on a master server in the cn=ibmpolicies directory subtree.
Consider the following with respect to replication:

For best results, replicate changes to the schema before replicating data changes.
We can use the idsldapdiff utility to identify differences in schema, but the idsldapdiff utility cannot automatically correct differences in schema.
We can synchronize schemas by copying the schemas between replicas.

Creating a master-replica topology

Before setting up your replication topology, make a backup copy of your original ibmslapd.conf, ibmslapdcfg.ksf, and ibmslapddir.ksf files. We can use this backup copy to restore your original configuration if you encounter difficulties with replication.
The following diagram shows a basic master-replica topology:
Figure 11. Basic master-replica topology

To define a basic master-replica topology, :

Create a master server and define what it contains. Select the subtree that you want to be replicated and specify the server as the master.
Create credentials to be used by the supplier.
Create a replica server.
Export data to the replica.

The following sections explain how to accomplish these tasks.
Note:

If the entry that you are trying to make the root of a new replication context is not a suffix in the server, before you can use the Add subtree function to add the replication configuration information, ensure that its ACLs are defined as follows:
For Non-filtered ACLs :
ownersource : <the entry DN> 
ownerpropagate : TRUE  
aclsource : <the entry DN> 
aclpropagate: TRUE
Filtered ACLs :
ownersource : <the entry DN> 
ownerpropagate : TRUE  
ibm-filteraclinherit : FALSE
ibm-filteraclentry : <any value> 
To satisfy the ACL requirements, if the entry is not a suffix in the server, edit the ACL for that entry in the Manage entries panel:

Click Directory management–>Manage entries in the left nav panel.
Select an entry and open the Select Action menu.
Select Edit ACL and click Go. If you want to add Non-filtered ACLs, select that tab and add an entry cn=this with the role access-id for both ACLs and owners.
Ensure that Propagate ACLs and Propagate owner are checked. If you want to add Filtered ACLs select that tab and add an entry cn=this with the role access-id for both ACLs and owners.
Ensure that Accumulate filtered ACLs is unchecked and that Propagate owner is checked. See Working with ACLs for more detailed information.

Using Web Administration:

These procedures assume that all servers involved are IBM Tivoli Directory Server version 5.x and 6.x servers. They also assume that you have installed and can use the Web Administration Tool with administrative rights. See the IBM Tivoli Directory Server Version 6.1 Installation and Configuration Guide for information about installing the Web Administration Tool.

Creating a master server (replicated subtree)

The server must be running to perform this task.
This task designates an entry as the root of an independently replicated subtree and creates an ibm-replicasubentry entry under it representing this server as the single master for the subtree. To create a replicated subtree, designate the subtree that you want the server to replicate.

On the Linux®, Solaris, and HP-UX platforms, if a referral fails because the server being referred to is not running, ensure that the environment variable LDAP_LOCK_REC has been set in your system environment. No specific value is required.
set LDAP_LOCK_REC=anyvalue
Use the Web Administration Tool to log on to the master server.
Expand the Replication management category in the navigation area of the Web Administration Tool and click Manage topology.
Click Add subtree.
Enter the DN of the subtree that you want to replicate or click Browse to expand the entries to select the entry that is to be the root of the subtree. For this example, use o=sample.
Notes:

If you are replicating a subtree, and the subtree is not a suffix, you must replicate the parent of the subtree on the replica first.
The master server referral URL is displayed in the form of an LDAP URL, for example:
For non-SSL:
ldap://<myservername>.<mylocation>.<mycompany>.com:<port>
For SSL:
ldaps://<myservername>.<mylocation>.<mycompany>.com:<port>
The default URL is ldap://localhost:389

The master server referral URL is optional. It is used only:

If the server contains (or will contain) any read-only subtrees.
To define a referral URL that is returned for updates to any read-only subtree on the server.
Click OK.
The new subtree is displayed on the Manage topology panel under the heading Replicated subtrees.
Select the subtree from the Replicated subtrees table and click Show topology. The topology is displayed under the Topology for selected subtree heading. By default, if subtrees are available in the Replicated subtrees table, the topology of the first subtree in the table is displayed under the Topology for selected subtree heading.
Depending on the selection of the node in the topology tree, the operations allowed on the node vary. Some of the operations are applicable only when a node other than the root is selected. Also, some operations are specific to the type of node, such as master server, forwarding server, replica server, and gateway server.
Creating the credentials

Credentials identify the method and required information, such as a DN and password, that the supplier uses in binding to the consumer.

If you have not already done so, use the Web Administration Tool to log on to the master server.
Expand the Replication management category in the navigation area of the Web Administration Tool and click Manage credentials.
Select cn=replication,cn=IBMpolicies from the list of locations to store the credentials.

The Web Administration Tool allows you to define credentials in three locations. See Adding credentials for additional information about the different types of credentials that we can create.
Click Add.
Enter the name for the credentials you are creating; for example, mycreds, cn= is prefilled in the field for you.
Select Simple bind as the type of authentication and click Next.

We can also select Kerberos or SSL with certificates.

Enter the DN that the server uses to bind to the replica; for example, cn=any

This DN cannot be the same as your server administration DN.
Enter the password the server uses when it binds to the replica; for example, secret.
Enter the password again to confirm that there are no typographical errors.
If you want, enter a brief description of the credentials.
Click Finish.

You might want to record the credential's bind DN and password for future reference.

Creating a replica server

The servers must be running to perform this task.
On the master server:

If you have not already done so, use the Web Administration Tool to log on to the master server.
Expand the Replication management category in the navigation area of the Web Administration Tool and click Manage topology.
Select the subtree that you want to replicate and click Show topology.
Select the supplier server and click Add replica.
On the Server tab of the Add replica window:

From the Server hostname:port drop-down list, select an LDAP server for the replica server.
If you want to provide another server as replica server, which is not registered on the console server, select Use entry from below item from the Server hostname:port drop-down list and then enter the host name and port number for the replica server in the field in the hostname:port format. The default port is 389 for non-SSL and 636 for SSL.
Leave the Enable SSL check box unchecked.
Enter the replica name or leave this field blank to use the host name.
Enter the replica ID. If the server on which you are creating the replica is running, click Get replica ID to automatically prefill this field. This is a required field. If you don't know the replica ID, enter unknown.
Enter a description of the replica server.
Specify the credentials that the replica uses to communicate with the master.

Click Select.
Click the radio button next to cn=replication,cn=IBMpolicies.
Click Show credentials.
Select cn=replication,cn=ibmpolicies.
Click Show credentials.

Click OK.
See Adding credentials for additional information on agreement credentials.

Click the Additional tab.

Keep the Select a replication schedule or enter DN (optional) set to None. This sets the default as immediate replication.
Do not deselect any capabilities. See Adding a replica server.
Keep the Replication method set to Single threaded.

Only IBM Tivoli Directory Server versions 6.0 and above can have the replication method set to either Single threaded or Multi-threaded. IBM Tivoli Directory Server 5.x is always single threaded.
Click to select the Add credential information on consumer check box.

If the credential is external, we need to set up the IBM WebSphere Application Server environment variable. See ***.
Enter the administrator DN for the consumer (replica) server. For example cn=root.

If the administrator DN which was created during the server configuration process was cn=root, then enter the full administrator DN. Do not just use root.
Enter the administrator password for the consumer (replica) server. For example secret.

The consumer server should be running.
Click OK to create the replica.

If the credentials exist, a message is displayed saying the credentials exist. If the credentials don't exist, they are added, and a message prompt is displayed. You are also prompted to restart the server. The panel also shows two port numbers: server port number (this port number cannot be edited) and the admin daemon port number. Make sure you have the correct admin daemon port number for the specific instance used. If the wrong admin daemon port number is specified, the admin daemon fails to restart the server.
Click OK.

A message is displayed, indicating that the server attempted to add the topology to the consumer. The message indicates whether this attempt is successful.
Click OK.

See Adding a replica server for more detailed information.
Copying data to the replica

To ensure that the servers are synchronized, first quiesce the master. This means that the master does not accept any updates from its clients.

If you have not already done so, use the Web Administration Tool to log on to the master server.
Expand the Replication management category in the navigation area of the Web Administration Tool and click Manage topology.
Select the subtree you have replicated.
Click Quiesce/Unquiesce to quiesce the subtree.
Click OK.

You must now export the data from the master to the replica. This is a manual procedure.
On the master server create an LDIF file for the data. To copy all the data contained on the master server, issue the command:
idsdb2ldif -o <masterfile.ldif>  -I <instance_name> -k <key seed> -t <key salt>
You must use the -I option if there is more than one instance. You must use the -k and -t options if keys on the server are not in sync.
If you want to copy just the data from a single subtree the command is:
idsdb2ldif -o <masterfile.ldif> -s <subtreeDN> -I <instance_name> 
		-k <key seed> -t <key salt>
You must use the -I option if there is more than one instance. You must use the -k and -t options if keys on the server are not in sync.

The four operational attributes, createTimestamp, creatorsName, modifiersName, and modifyTimestamp are exported to the LDIF file unless the -j option is specified.
On the computer where you are creating the replica:
Ensure that the suffixes used by the master are defined in the ibmslapd.conf file.
Stop the replica server.
Copy the <masterfile.ldif> file to the replica and issue the command:
idsldif2db -r no -i <masterfile.ldif> -I <instance name>
The replication agreements, schedules, credentials (if stored in the replicated subtree) and entry data are loaded on the replica.
Start the server.
Attention: If you are exporting data that will be imported into an Advanced Encryption Standard (AES)-enabled server and if the two servers are not cryptographically synchronized, select the Export data for AES-enabled destination server check box. Then complete the Encryption seed and Encryption salt fields. (See Appendix J. Synchronizing two-way cryptography between server instances for information about cryptographic synchronization of servers.)
When the source server (the server you are exporting data from) and the destination server (the server into which you will be importing the data) are using non-matching directory key stash files, and you specify the encryption seed and salt values of the destination server, any AES-encrypted data will be decrypted using the source server's AES keys, then re-encrypted using the destination server's encryption seed and salt values. This encrypted data is stored in the LDIF file.
The encryption seed is used to generate a set of AES secret key values. These values are stored in a directory stash file and used to encrypt and decrypt directory stored password and secret key attributes. The encryption seed must contain only printable ISO-8859-1 ASCII characters with values in the range of 33 to 126, and must be a minimum of 12 and a maximum of 1016 characters in length. See Appendix D. ASCII characters from 33 to 126 for information about these characters.
The encryption salt is a randomly generated value that is used to generate AES encryption keys. We can obtain the destination server's salt value by searching (using the idsldapsearch utility) the destination server's "cn=crypto,cn=localhost" entry. The attribute type is ibm-slapdCryptoSalt.

Adding the supplier information to the replica

If you did not select to add the credential information to the consumer or if a problem occurred in adding the credential information to the replica, we need to change the replica's configuration to identify who is authorized to replicate changes to it, and add a referral to a master.

Use the Web Administration Tool to log on as the directory administrator to the computer where you are creating the replica.
Expand Replication management in the navigation area of the Web Administration Tool and click Manage replication properties.
Under Supplier information, click Add.
Select a supplier from the Replicated subtree drop-down menu, select Use entry from below, and enter the name of the replicated subtree for which you want to configure supplier credentials.
Enter the replication bindDN. In this example, cn=any is used.
Enter and confirm the credential password. In this example, secret is used. See Adding credentials.
Click OK.
You must restart the replica for the changes to take effect.

See Adding the supplier information to a replica for more detailed information about supplier information.

Starting replication

The replica is in a suspended state and no replication is occurring. After you have finished setting up your replication topology, on the master you must:

If you have not already done so, use the Web Administration Tool to log on to the master server.
Expand the Replication management category in the navigation area of the Web Administration Tool and click Manage queues.
Select the new replica.
Click Queue details.
Click Pending changes.
If there are any pending changes, click Skip all. If there are no changes pending click Cancel. This prevents duplication of the topology information that was loaded with the <masterfile.ldif> file. If you have created multiple new replicas, repeat steps 1 through 6 for each of the new servers.
Click Manage topology under the Replication management category in the navigation area.
Select the subtree you have replicated. The status should be Quiesced.
Click Quiesce/Unquiesce to unquiesce the subtree.
Click OK. The master now receives updates from its clients and places them in the replication queues.
Click Manage queues under the Replication management category in the navigation area.
Select the replica.
Click Suspend/resume to start receiving replication updates for that server. Repeat steps 10 through 13 for each server that was suspended.

If you promote to a master, we need to resume the queues on the master.

See Managing queues for more detailed information about managing queues.

Using the command line:

This scenario assumes that you are creating a new replicated subtree and that only server1 contains any entry data. All other servers are newly installed and have a configured database.
dn: o=sample
objectclass: organization
objectclass: ibm-replicationContext
o: ibm
is the subtree you want to create. If this entry already exists, then modify it to add objectclass=ibm-replicationContext instead of adding the entire entry.
To create a replica for a subtree, we need to create a replication agreement between the master and the replica, see Replication agreements. This agreement needs to be loaded on both the master and the replica.
The relationship between the two servers is that the master is a supplier to the replica and the replica is a consumer of the master.
To create the master (server1) and replica (server2) for the subtree o=sample:
At the machine where the master is located, create a file to contain the agreement information, for example, myreplicainfofile, where myreplicainfofile contains:

Replace all occurrences of <server1-uuid> in the following files with the value of the ibm-slapdServerId attribute from the master server's cn=Configuration entry. This value is generated by the server the first time it is started. We can find it either by performing an idsldapsearch of the cn=Configuration entry or using the grep command on the ibmslapd.conf file, if you have a UNIX-based system. Similarly, all occurrences of the <server2-uuid> must be replaced with the value of the ibm-slapdServerId attribute from the replica server's cn=Configuration entry.
###Replication Context  - needs to be on all suppliers and consumers
dn: cn=replication,cn=IBMpolicies
objectclass: container

dn: o=sample
objectclass: organization
objectclass: ibm-replicationContext


###Copy the following to servers at v5.x and above.

###Replica Group
dn: ibm-replicaGroup=default, o=sample
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicaGroup: default

###Bind Credentials/method to replica server - replication agreement 
###points to this.
dn: cn=server2 BindCredentials,cn=replication,cn=IBMpolicies
objectclass: ibm-replicationCredentialsSimple
cn: server2 BindCredentials
replicaBindDN: cn=any
replicaCredentials: secret
description: Bind method of the master (server1) to the replica (server2)

###Replica SubEntry
dn: ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server1-uuid>
ibm-replicationServerIsMaster: true
cn: server1
description: master server

###Replication Agreement to the replica server
dn: cn=server2,ibm-replicaServerId=<server1-uuid>,
    ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server2
ibm-replicaConsumerId: <server2-uuid>
ibm-replicaUrl: ldap://server2:389
ibm-replicaCredentialsDN: cn=server2 BindCredentials,cn=replication,
                          cn=IBMpolicies
description: replica server (server2)
Stop the master, if it is not already stopped.
ibmdirctl -h server1 -D <adminDN> -w <adminPW> -p 389 stop
To load the new replication topology to the master, issue the command:
idsldif2db -r no -i <myreplicainfofile> -I <instance name>
To generate a file with all of the data necessary to synchronize the new replica, issue the command:
idsdb2ldif -o <masterfile.ldif> -I <instance_name> -s o=sample
		-k <key seed> -t <key salt>
You must use the -I option if there is more than one instance. You must use the -k and -t options if keys on the server are not in sync.
Attention: If you are exporting data that will be imported into an Advanced Encryption Standard (AES)-enabled server and if the two servers are not cryptographically synchronized, see Appendix J. Synchronizing two-way cryptography between server instances, for information about cryptographic synchronization of servers.Attention.
See the idsdb2ldif command information in the IBM Tivoli Directory Server version 6.1 Command Reference for more information.

Perform steps 5 through 9 on the machine where server2 is located.
Copy <masterfile.ldif> to the replica.
Start the replica, server2, in configuration only mode.
idsslapd -I <instance name> -a
Make sure you have a backup of the original ibmslapd.conf, ibmslapdcfg.ksf, and ibmslapddir.ksf files.
You must configure server2 to be a replica server. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server2. On server2 issue the following command:
idsldapadd -D <adminDN> -w<adminPW> -i<filename>
where <filename> contains:
dn: cn=Master Server, cn=configuration
objectclass: ibm-slapdReplication
cn: Master Server
ibm-slapdMasterDN: cn=any
ibm-slapdMasterPW: secret
ibm-slapdMasterReferral: ldap://server1:389/
The ibm-slapdMasterDN and ibm-slapdMasterPW values must match the values stored on the master server, server1, in the entry "cn=server2 BindCredentials" in step 1.
Stop the replica, server2. To stop the server issue the command:
ibmdirctl -h server2 -D <AdminDN> -w <Adminpwd> -p 389 stop
Save the ibmslapd.conf file as a new backup.
Issue the following command:
idsldif2db -r no -i <masterfile.ldif> -I <instance name>
Start the master (server1) and the replica (server2). On each of the servers issue the command:
idsslapd -I <LDAPinstance>
If you are copying a subtree to a v4.1 or earlier server, not copy the ibm-replicagroup=default subtree and remove the ibm-replicationcontext auxiliary class, because neither of these are supported by the 4.1 schema.

Setting up a simple topology with peer replication

Peer replication is a replication topology in which multiple servers are masters. Use peer replication only in environments where the update vectors are well known. Updates to particular objects within the directory must be done only by one peer server. This is intended to prevent a scenario in which one server deletes an object, followed by another server modifying the object. This scenario creates the possibility of a peer server receiving a delete command followed by a modify command for the same object, which creates a conflict. Replicated delete and rename requests are accepted in the order received without conflict resolution. See Creating replication schedules for more information about conflict resolution.
Figure 12. Basic peer-to-peer topology

This section shows how to set up a replication topology between two servers only.

Using Web Administration:

Before you start, be sure that:

Both servers are running.
The servers are cryptographically synchronized if necessary. See Appendix J. Synchronizing two-way cryptography between server instances, in the IBM Tivoli Directory Server version 6.1 Administration Guide.
In the Web Administration Tool, be sure that you are logged in to one of the servers. (This procedure assumes that you are logged in to the first of the two servers, server1.)

To set up two peer masters:

In the Web Administration Tool, expand the Replication management category in the navigation area and click Manage topology
Select the subtree that you want to replicate and click Show topology.
If you want to view the existing topology, click the box next to the existing servers to expand the list of supplier servers.
Click Replication topology to highlight it, and then click Add master.
On the Server tab of the Add master window:

Select Server is a gateway to make this server a Gateway server or select Supplier gateway and then select a server from the drop-down list to add the server as a master server.
From the Server hostname:port drop-down list, select an LDAP server for the master server.
If you want to provide another server as master server, which is not registered on the console server, select Use entry from below item from the Server hostname:port drop-down list and then enter the host name and port number for the master server in the field in the hostname:port format.

The default port is 389 for non-SSL and 636 for SSL.
Select the Enable SSL encryption check box to enable SSL communications.
In the Peer master name field, enter the server name or leave this field blank to use the host name.
Enter the server ID. If the server on which you are creating the peer-master is running, click Get server ID to automatically prefill this field. If you do not know the server ID, enter unknown.
Optionally, enter a description of the server.
You must specify the credentials that the server uses to communicate with the master server. Click Select beside the Credential object field. The Select credential window is displayed. On the Select credential window:

Select the location for the credentials you want to use. Preferably this is cn=replication,cn=localhost.

The Web Administration Tool allows you to define credentials in the following places:

cn=replication,cn=localhost, which keeps the credentials only on the server that uses them. Placing credentials in cn=replication,cn=localhost is considered more secure.
cn=replication,cn=IBMpolicies, which is available even when the server under which you are trying to add a replica is not the same server that you are connected to with the Web Administration Tool. Credentials placed under this location are replicated to the servers.
The location cn=replication,cn=IBMpolicies is available only if the IBMpolicies support OID, 1.3.18.0.2.32.18, is present under the ibm-supportedcapabilities of the root DSE.
Within the replicated subtree, in which case the credentials are replicated with the rest of the subtree. Credentials placed in the replicated subtree are created beneath the ibm-replicagroup=default entry for that subtree.

If you have already created a set of credentials:

Click Show credentials. A list of existing credentials is shown in the Select credentials field.
Expand the list of credentials and select the one you want to use.

If you do not have preexisting credentials, click Add credentials to create the credentials. See Adding credentials , in the IBM Tivoli Directory Server version 6.1 Administration Guide for additional information about agreement credentials.
Click OK.

On the Additional tab:

If you want to use an existing replication schedule, select the replication schedule from the drop-down list.
If you want to create a new replication schedule:

Click Add.
See Creating replication schedules , in the IBM Tivoli Directory Server version 6.1 Administration Guide for information about replication schedules.
When you return to the Add master panel, select the schedule you created from the list of schedules.

From the Capabilities replicated to consumer list, we can deselect any capabilities that you do not want replicated to the consumer.
If your network has a mix of servers at different releases, capabilities are available on later releases that are not available on earlier releases. Some capabilities, like filter ACLs and password policy, make use of operational attributes that are replicated with other changes. In most cases, if these features are used, you want all servers to support them. If all of the servers do not support the capability, you do not want to use it. For example, you would not want different ACLs in effect on each server. However, there might be cases where you want to use a capability on the servers that support it, and not have changes related to the capability replicated to servers that do not support the capability. In such cases, we can use the capabilities list to mark certain capabilities to not be replicated.
Check the Add credential information on consumer check box. This selection automatically updates the supplier credentials in the configuration file of the consumer server. This enables the topology information to be replicated to server2.

Type the Administrator DN for the consumer server (server2); for example, cn=root.

If the administrator DN that was created during the server configuration process was cn=root, then enter the full administrator DN. Do not use only root.
Type the Administrator password for the consumer server; for example, secret.

Click OK.
On the Create additional supplier agreements panel, supplier and consumer agreements are listed between the new master server and any existing servers. Clear the check boxes for any agreements that you do not want to be created.
Click Continue.
If a message is displayed asking if you want to restart server2, click Yes. Other messages might be displayed noting that additional actions must be taken. Perform or take note of the appropriate actions. When you are finished, click OK.
Add the appropriate credentials to configure agreements from server2 to server1:

Select the location for the credentials you want to use. Preferably this is cn=replication,cn=localhost.
If you have already created a set of credentials:

Click Show credentials. A list of existing credentials is shown in the Select credentials field.
Expand the list of credentials and select the one you want to use.

Click OK.

In some cases the Select credentials panel will pop up asking for a credential that is located in a place other than cn=replication,cn=localhost. In such situations provide a credential object that is located in a place other than cn=replication,cn=localhost. Select the credentials the subtree is going to use from the existing sets of credentials or create new credentials. See Adding credentials , in the IBM Tivoli Directory Server version 6.1 Administration Guide for information about credentials.
Click OK to create the peer-master.
Messages might be displayed noting that additional actions must be taken. Perform or take note of the appropriate actions. When you are finished, click OK.

Using the command line:

This scenario assumes that you are creating a new replicated subtree and that only server1 contains any entry data. All other servers are newly installed, have a configured database, and have been started at least once for initialization purposes. (Be sure to read Appendix J. Synchronizing two-way cryptography between server instances , in the IBM Tivoli Directory Server version 6.1 Administration Guide before you start the server instances.)

The subtree you want to create is the following:
dn: o=sample
objectclass: organization
objectclass: ibm-replicationContext
o: ibm
If this entry already exists, then modify it to add objectclass=ibm-replicationContext instead of adding the entire entry.
server1 and server2 are peer-master servers. That means that while they receive updates from each other, they only replicate entries received from clients. While both masters have the same entry content, only the server that has received the client request replicates the entry. Both masters are suppliers and consumers to each other and suppliers to the other servers.
To create the peer-masters (server1 and server2) for the subtree o=sample:
Start servers server1 and server2 in configuration only mode. On each of the servers issue the command:
idsslapd -I <LDAPinstance> -a
If the administration daemon (idsdiradm) is not running for any instance, start idsdiradm:
idsdiradm -I <LDAP_instance>
You must configure server1 and server2 to be peer servers. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server1 and server2. On server1 and server2 issue the following command:
idsldapadd -D <adminDN> -w<adminPW> -i<filename>
where <filename> contains:
dn: cn=Master Server, cn=configuration
objectclass: ibm-slapdReplication
cn: Master Server
ibm-slapdMasterDN: cn=any
ibm-slapdMasterPW: secret
It is critical that these entries be exactly the same on both servers because this example uses a credentials object that is shared on all the servers. The password is entered in cleartext, but is encrypted in the file.
Stop server1 and server2. To stop the servers issue the following command on each of the servers:
idsslapd -I <instancename> -k
where <instancename> is the name of the directory server instance you want to stop.
ibmdirctl -h <serverx> -D <adminDN>-w <adminPW>-p 389 stop
where <serverx> is the name of the server.
Save the ibmslapd.conf files.
At the computer where the master server, server1, is located, create a file to use for updates to the agreement information; for example mycredentialsfile, where mycredentialsfile contains:
dn: cn=replication,cn=IBMpolicies
objectclass: container
 
###Bind Credentials/method to peer server - replication agreement
###points to this.
dn: cn=simple,cn=replication,cn=IBMpolicies
objectclass:ibm-replicationCredentialsSimple
cn:simple
replicaBindDN:cn=any
replicaCredentials:secret
description:Bind method of the peer master (server1)to the peer (server2)
Issue the command:
idsldif2db -r no -i  <mycredentialsfile> -I <instance_name>
Copy <mycredentialsfile> to the computer where server2 is located and issue the command:
idsldif2db -r no -i  <mycredentialsfile> -I <instance_name>
At the computer where server1 is located create a file, <mytopologyfile>, where <mytopologyfile> includes the following:

Replace all occurrences of <server1-uuid> in the following files with the value of the ibm-slapdServerId attribute from the master server's cn=Configuration entry. This value is generated by the server the first time it is started. We can find it either by performing an idsldapsearch of the cn=Configuration entry or using the grep command on the ibmslapd.conf file, if you have an AIX®, Linux, Solaris, or HP-UX system. Similarly, all occurrences of the <serverx-uuid> (where x represents 1 or 2) must be replaced with the value of the ibm-slapdServerId attribute from the respective server's cn=Configuration entry.
dn: o=sample
o: ibm
objectclass: top
objectclass: container
objectclass: ibm-replicationContext

dn: ibm-replicaGroup=default, o=sample
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicaGroup: default

dn: ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server1-uuid>
ibm-replicationServerIsMaster: true
cn: server1
description: server 1 (peer master) ibm-replicaSubentry 

dn: ibm-replicaServerId=<server2-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server2-uuid>
ibm-replicationServerIsMaster: true
cn: server2
description: server2 (peer master) ibm-replicaSubentry 

#server1 to server2 agreement
dn: cn=server2,ibm-replicaServerId=<server1-uuid>,
    ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server2
ibm-replicaConsumerId: <server2-uuid>
ibm-replicaUrl: ldap://server2:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server1(master) to server2(master) agreement

#server2 to server1 agreement
dn: cn=server1,ibm-replicaServerId=<server2-uuid>,
    ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server1
ibm-replicaConsumerId: <server1-uuid>
ibm-replicaUrl: ldap://server1:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server2(master) to server1(master) agreement
To load this topology, issue the command:
idsldif2db -r no -i  <mytopologyfile> -I <instance_name>
where -r no prevents replication of the set of entries.
At this point you might want to load additional data for your subtree.

Use the -r no flag to prevent replication of the set of entries.
When you have finished loading the data, to be able to export the topology and any additional data for the replication context to populate the other servers, issue the command:
idsdb2ldif  -s"o=sample" -o <mymasterfile.ldif>  -I <instance_name> 
		-k <key seed> -t <key salt>
You must use the -I option if there is more than one instance. You must use the -k and -t options if keys on the server are not synchronized. See the idsdb2ldif command information in the IBM Tivoli Directory Server version 6.1 Command Reference for more information.
Attention: If you are exporting data that will be imported into an Advanced Encryption Standard (AES)-enabled server and if the two servers are not cryptographically synchronized, see Appendix J. Synchronizing two-way cryptography between server instances , for information about cryptographic synchronization of servers.
When the source server (the server you are exporting data from) and the destination server (the server into which you will be importing the data) are using non-matching directory key stash files, and you specify the encryption seed and salt values of the destination server, any AES-encrypted data will be decrypted using the source server's AES keys, then re-encrypted using the destination server's encryption seed and salt values. This encrypted data is stored in the LDIF file.
The encryption seed is used to generate a set of AES secret key values. These values are stored in a directory stash file and used to encrypt and decrypt directory stored password and secret key attributes. The encryption seed must contain only printable ISO-8859-1 ASCII characters with values in the range of 33 to 126, and must be a minimum of 12 and a maximum of 1016 characters in length. See Appendix D. ASCII characters from 33 to 126 , in the IBM Tivoli Directory Server version 6.1 Administration Guide for information about these characters.
The encryption salt is a randomly generated value that is used to generate AES encryption keys. You can obtain the destination server's salt value by searching (using the idsldapsearch utility) the destination server's "cn=crypto,cn=localhost" entry. The attribute type is ibm-slapdCryptoSalt.
Restart server1.
Copy the <mymasterfile.ldif> file to the computer where server2 is located.
On the computer where server2 is located, issue the following command:
idsldif2db -r no -i <mymasterfile.ldif> -I <instance_name>
Start server2:
idsslapd -I <instance_name>
Creating a master-forwarder-replica topology

The following diagram shows a master-forwarder-replica topology:
Figure 13. Master-forwarding server-replica topology

To define a master-forwarder-replica topology, :

Create a master server and a replica server. You have already done this; see Creating a master-replica topology.
Create a new replica server for the original replica. See Adding a replica server.
Copy data to the replicas. See Copying data to the replica.

Changing the replica to a forwarding server

Before starting to set up your replication topology, make a backup copy of your original ibmslapd.conf file for each server. We can use this backup copy to restore your original configuration if you encounter difficulties with replication.
If you have set up a replication topology with a master (server1) and a replica (server2), we can change the role of server2 to that of a forwarding server. To do this create a new replica (server3) under server2.

Using Web Administration:

Start all the servers.
If you have not already done so, use the Web Administration Tool to log on to the master server (server1).
Expand the Replication management category in the navigation area and click Manage topology.
Select the subtree that you want to replicate and click Show topology.
Click the box next to the server1 selection to expand the list of servers.
Select server2 and click Add replica.
On the Server tab of the Add replica window:

From the Server hostname:port drop-down list, select an LDAP server for the replica server.
If you want to provide another server as replica server, which is not registered on the console server, select Use entry from below item from the Server hostname:port drop-down list and then enter the host name and port number for the replica server in the field in the hostname:port format. The default port is 389 for non-SSL and 636 for SSL.
Leave the Enable SSL check box unchecked.
Enter the replica name or leave this field blank to use the host name.
Enter the replica ID. If the server on which you are creating the replica is running, click Get replica ID to automatically prefill this field. This is a required field.
Enter a description of the replica server.
Specify the credentials that the replica uses to communicate with the master.

Click Select.
Click the radio button next to cn=replication,cn=IBMpolicies.

The mycreds credentials need to be created under cn=replication,cn=ibmpolicies on the forwarder, unless cn=ibmpolicies is replicated.
Click Show credentials.
Expand the list of credentials and select mycreds.
Click OK.
See Adding credentials for additional information on agreement credentials.

Click the Additional tab.

Keep the Specify a replication schedule or enter DN (optional) set to None. This sets the default as immediate replication.
Do not deselect any capabilities.
Keep the Replication method set to Single threaded.
Click to select the Add credential information on consumer check box.
Enter the administrator's DN for the consumer (replica) server. For example cn=root.

If the administrator DN which was created during the server configuration process was cn=root, then enter the full administrator DN. Do not just use root.
Enter the administrator's password for the consumer (replica) server. For example secret.
Click OK to create the replica. A message is displayed noting that additional actions must be taken, including restarting the replica server. Take the appropriate actions.
Click OK.

Copy data from server1 to the new replica server3. See Copying data to the replica for information about how to do that.

The topology changes are replicated to server2 by the master server1.
Add the supplier agreement to server3 that makes server2 a supplier to server3 and server3 a consumer to server2. See Adding the supplier information to a replica for information about how to do this.

This step needs to be performed only if you did not select the Add credential information on consumer check box, or supplier information failed to be added to the consumer configuration file.

The server roles are represented by icons in the Web Administration Tool. Your topology in now:

server1 (master)

server2 (forwarder)

server3 (replica)

Using the command line:

This scenario assumes that you are creating a new replicated subtree and that only server1 contains any entry data. All other servers are newly installed, have a configured database, and have been started at least once for initialization purposes. (Be sure to read Appendix J. Synchronizing two-way cryptography between server instances, in the IBM Tivoli Directory Server version 6.1 Administration Guide before you start the server instances.)

The subtree you want to create is the following:
dn: o=sample
objectclass: organization
objectclass: ibm-replicationContext
o: ibm
If this entry already exists, then modify it to add objectclass=ibm-replicationContext instead of adding the entire entry.
This procedure is similar to the one for a single master and replica, except that the entire topology must be added to each of the servers and the content of the agreement information file is more complex. The file now includes information for the forwarding server and supplier-consumer information.
The supplier-consumer relationship for this scenario is:

The master is a supplier to the forwarder.
The forwarder has two roles:

A consumer of the master
A supplier to the replica

The replica is a consumer of the forwarder.

To create the master (server1), a forwarder (server2), and replica (server3) for the subtree o=sample:
At the computer where the master server is located, create a file to contain the agreement information; for example myreplicainfofile where myreplicainfofile contains the following:

Replace all occurrences of <server1-uuid> in the following files with the value of the ibm-slapdServerId attribute from the master server's cn=Configuration entry. This value is generated by the server the first time it is started. We can find it either by performing an idsldapsearch of the cn=Configuration entry or by using the grep command on the ibmslapd.conf file, if you have an AIX, Linux, Solaris, or HP-UX system. Similarly, all occurrences of the <server2-uuid> and the <server3-uuid> must be replaced with the value of the ibm-slapdServerId attribute from the respective server's cn=Configuration entry.
dn: cn=replication,cn=IBMpolicies
objectclass: container

dn: o=sample
objectclass: organization
objectclass: ibm-replicationContext

dn: ibm-replicaGroup=default, o=sample 	
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicaGroup: default

dn: cn=server2 BindCredentials,cn=replication,cn=IBMpolicies
objectclass: ibm-replicationCredentialsSimple                            	
#or ibm-replicationCredentialsExternal or
#ibm-replicationCredentialsKerberos
cn: server2 BindCredentials
replicaBindDN: cn=any
replicaCredentials: secret
description: Bindmethod of server 1 (the master)  to server2

dn: cn=server3 BindCredentials,cn=replication,cn=IBMpolicies
objectclass: ibm-replicationCredentialsSimple 
cn: server3 BindCredentials
replicaBindDN: cn=any
replicaCredentials: secret
description: Bindmethod of server2 (the forwarder) to server3 (the replica)

dn: ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server1-uuid>        #whatever the ID is in the config
ibm-replicationServerIsMaster: true		#true if master, false if forwarder
cn: server1
description: master ibm-replicaSubentry

dn: ibm-replicaServerId=<server2-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server2-uuid>
ibm-replicationServerIsMaster: false    			
cn: server2
description: forwarder ibm-replicaSubentry

dn: cn=forwarder1,ibm-replicaServerId=<server1-uuid>,
    ibm-replicaGroup=default,o=sample	
objectclass: top
objectclass: ibm-replicationAgreement
cn: server2
ibm-replicaConsumerId: <server2-uuid>
ibm-replicaUrl: ldap://server2:389
ibm-replicaCredentialsDN: cn=server2 BindCredentials,cn=replication,
                          cn=IBMpolicies
description: server1 (the master) to server2 (the forwarder) agreement

dn: cn=server3,ibm-replicaServerId=<server2-uuid>,
    ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server3
ibm-replicaConsumerId: <server3-uuid>-uuid
ibm-replicaUrl: ldap://server3:389
ibm-replicaCredentialsDN: cn=server3 BindCredentials,cn=replication,
                          cn=IBMpolicies
description: server2 (the forwarder) to server3 (the replica) agreement
Stop the master, if it is not already stopped, by using the following command:
ibmdirctl -h server1 -D <adminDN> -w <adminPW> -p 389 stop
To load the new replication topology to the master, issue the command:
idsldif2db -r no -i  <myreplicainfofile> -I <instance_name>
To generate a file with all of the data to synchronize the new replica, issue the command:
idsdb2ldif -o <masterfile.ldif>  -I <instance_name> -s o=sample
	-k <key seed> -t <key salt>
You must use the -I option if there is more than one directory server instance. You must use the -k and -t options if keys on the server are not synchronized. See the idsdb2ldif command information in the IBM Tivoli Directory Server version 6.1 Command Reference for more information.
Attention: If you are exporting data that will be imported into an Advanced Encryption Standard (AES)-enabled server and if the two servers are not cryptographically synchronized, see Appendix J. Synchronizing two-way cryptography between server instances, in the IBM Tivoli Directory Server version 6.1 Administration Guide for information about cryptographic synchronization of servers.
When the source server (the server you are exporting data from) and the destination server (the server into which you will be importing the data) are using non-matching directory key stash files, and you specify the encryption seed and salt values of the destination server, any AES-encrypted data will be decrypted using the source server's AES keys, then re-encrypted using the destination server's encryption seed and salt values. This encrypted data is stored in the LDIF file.
The encryption seed is used to generate a set of AES secret key values. These values are stored in a directory stash file and used to encrypt and decrypt directory stored password and secret key attributes. The encryption seed must contain only printable ISO-8859-1 ASCII characters with values in the range of 33 to 126, and must be a minimum of 12 and a maximum of 1016 characters in length. See Appendix D. ASCII characters from 33 to 126, in the IBM Tivoli Directory Server version 6.1 Administration Guide for information about these characters.
The encryption salt is a randomly generated value that is used to generate AES encryption keys. We can obtain the destination server's salt value by searching (using the idsldapsearch utility) the destination server's "cn=crypto,cn=localhost" entry. The attribute type is ibm-slapdCryptoSalt.
Copy the <masterfile.ldif> file to the computer where server2 is located.
Start the forwarder, server2, in configuration only mode.
idsslapd -I <LDAPinstance> -a
You must configure server2 to be a replica server. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server2. On server2 issue the following command:
idsldapadd -D <adminDN> -w<adminPW> -i<filename>
where <filename> contains:
dn: cn=Master Server, cn=configuration
objectclass: ibm-slapdReplication
cn: Master Server
ibm-slapdMasterDN: cn=any
ibm-slapdMasterPW: secret
ibm-slapdMasterReferral: ldap://server1:389/         
#referral to master when trying to add to consumer.  
#Referral can also be added to replicaContext, which would be 
#checked first for a valid server.
The ibm-slapdMasterDN and ibm-slapdMasterPW values must match the values stored on the master server, server1, in the entry "cn=server2 BindCredentials".
Stop server2.
ibmdirctl -h server2 -D <adminDN> -w <adminPW> -p 389 stop
Save the ibmslapd.conf file.
Copy the <masterfile.ldif> file to the computer where server3 is located.
Start the replica, server3, in configuration only mode.
idsslapd -I <LDAPinstance> -a
You must configure server3 to be a replica server. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server3. On server3 issue the following command:
idsldapadd -D <adminDN> -w<adminPW> -i<filename>
where <filename> contains:
dn: cn=Master Server, cn=configuration
objectclass: ibm-slapdReplication
cn: Master Server
ibm-slapdMasterDN: cn=any
ibm-slapdMasterPW: secret
ibm-slapdMasterReferral: ldap://server2:389/
The ibm-slapdMasterDN and ibm-slapdMasterPW values must match the values stored on the master server, server1, in the entry "cn=server3 BindCredentials".
Stop server3.
ibmdirctl -h server3 -D <adminDN> -w <adminPW> -p <port> stop
Save the ibmslapd.conf file.
At the computers where server2 and server3 are located, issue the following command:
idsldif2db -r no -i <masterfile.ldif> -I <instance_name>
Start the master (server1), the forwarder (server2) and the replica (server3). On each of the servers issue the command:
idsslapd -I <LDAPinstance>
Remember to ensure that all the servers have been added to the topology under cn=ibmpolicies in order to replicate global updates such as cn=schema.

Setting up a complex topology with peer replication

Initially, the ibm-replicagroup object created by this process inherits the ACL of the root entry for the replicated subtree. These ACLs might be inappropriate for controlling access to the replication information in the directory.
For the Add subtree operation to be successful, the entry DN that you are adding must have correct ACLs, if it is not a suffix in the server.
For Non-filtered ACLs :
ownersource : <the entry DN> 
ownerpropagate : TRUE  
aclsource : <the entry DN> 
aclpropagate: TRUE
Filtered ACLs :
ownersource : <the entry DN> 
ownerpropagate : TRUE  
ibm-filteraclinherit : FALSE
ibm-filteraclentry : <any value> 
Use the Edit ACLs function of the Web Administration Tool to set ACLs for the replication information associated with the newly created replicated subtree (see Editing access control lists for the subtree).
Using the forwarding topology created in Changing the replica to a forwarding server, you are going to create a peer-forwarder-replica topology consisting of two peer-master servers, two forwarding servers, and four replicas. To create this topology, :

Create two additional replica servers for the master server. See Adding a replica server.
Create two replicas under each of the two newly created replica servers.
Add a new peer master server. See Adding a peer-master or gateway server.

The server that you want to promote to a master must be a leaf replica with no subordinate replicas.
Copy the data from the master to the new master and replicas. See Copying data to the replica.
Start replication. See Managing queues.

Using the command line:

This scenario assumes that you are creating a new replicated subtree and that only server1 contains any entry data. All other servers are newly installed, have a configured database, and have been started at least once for initialization purposes. (Be sure to read Appendix J. Synchronizing two-way cryptography between server instances, in the IBM Tivoli Directory Server version 6.1 Administration Guide before you start the server instances.)
dn: o=sample
objectclass: organization
objectclass: ibm-replicationContext
o: ibm
is the subtree you want to create. If this entry already exists, then modify it to add objectclass=ibm-replicationContext instead of adding the entire entry.
In this example the topology is more complex. It includes two peer-masters (server1 and server5), two forwarders (server2 and server4) and four replicas (server3, server6, server7, and server8). The relationship among the servers is as follows:
Figure 14. A peer-to-peer topology

server1 and server5 are peer-master servers. That means that while they receive updates from each other, they only replicate entries received from clients. While both masters have the same entry content, only the server that has received the client request replicates the entry. Both masters are suppliers and consumers to each other and suppliers to the forwarding servers.
server2 and server4 have two roles. They are both consumers of server1 and server5 and suppliers to their respective replicas. They do not perform any client updates. They pass replicated updates to their consumers. In this scenario

server2 is a supplier to server3 and server6
server4 is a supplier to server7 and server8
There is no interaction between server2 and server4.
replica 1 and replica 2 are consumers of server2 and server7 and server8 are consumers of server4.

To create the peer-masters (server1 and server5), the forwarders (server2 and server4), and the replicas (server3, server6, server7, and server8) for the subtree o=sample:
Start servers server1 and server5 in configuration mode. On each of the servers issue the command:
idsslapd -I <LDAPinstance> -a
You must configure server1 and server5 to be peer servers. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server1 and server5. On server1 and server5 issue the following command:
idsldapadd -D <adminDN> -w<adminPW> -i<filename>
where <filename> contains:
dn: cn=Master Server, cn=configuration
objectclass: ibm-slapdReplication
cn: Master Server
ibm-slapdMasterDN: cn=any
ibm-slapdMasterPW: secret
It is critical that these entries be exactly the same on both servers because this example uses a credentials object that is shared on all the servers.
Stop server1 and server5. To stop the servers issue the following command on each of the servers:
ibmdirctl -h <serverx> -D <adminDN>-w <adminPW>-p 389 stop
where <serverx> is the name of the server.
Make sure that you have a backup of the ibmslapd.conf file.
At the computer where the master server, server1, is located, create a file to contain the agreement information; for example, mycredentialsfile, where mycredentialsfile contains the following:
dn: cn=replication,cn=IBMpolicies
objectclass: container
 
###Bind Credentials/method to peer/forwarder server - replication agreement
###points to this.
dn: cn=simple,cn=replication,cn=IBMpolicies
objectclass:ibm-replicationCredentialsSimple
cn:simple
replicaBindDN:cn=any
replicaCredentials:secret
description:Bind method of the master to the peer/forwarder
Issue the following command:
idsldif2db -r no -i  <mycredentialsfile> -I <instance_name>
Stop server2 and server4. To stop the servers, issue the following command on each of the servers:
ibmdirctl -h <serverx> -D <adminDN>-w <adminPW>-p 389 stop
where <serverx> is the name of the server.
Copy the <mycredentialsfile> file to the computers where server5, server2, and server4 are located and issue the following command on each computer:
idsldif2db -r no -i  <mycredentialsfile> -I <instance_name>
At the computer where server1 is located create a file, <mytopologyfile>, where <mytopologyfile> includes:

Replace all occurrences of <master-uuid> in the following files with the value of the ibm-slapdServerId attribute from the master server's cn=Configuration entry. This value is generated by the server the first time it is started. We can find it either by performing an idsldapsearch of the cn=Configuration entry or using the grep command on the ibmslapd.conf file, if you have an AIX, Linux, Solaris, or HP-UX system. Similarly, all occurrences of the <serverx-uuid> (where x represents a number) must be replaced with the value of the ibm-slapdServerId attribute from the respective server's cn=Configuration entry.
dn: o=sample
o: ibm
objectclass: top
objectclass: organization
objectclass: ibm-replicationContext

dn: ibm-replicaGroup=default, o=sample
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicaGroup: default

dn: ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server1-uuid>
ibm-replicationServerIsMaster: true
cn: server1
description: server 1 (peer master) ibm-replicaSubentry 

dn: ibm-replicaServerId=<server5-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server5-uuid>
ibm-replicationServerIsMaster: true
cn: server5
description: server5 (peer master) ibm-replicaSubentry 

dn: ibm-replicaServerId=<server2-uuid>,
    ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server2-uuid>
ibm-replicationServerIsMaster: false
cn: server2
description: server2 (forwarder) ibm-replicaSubentry 

dn: ibm-replicaServerId=<server4-uuid>,
    ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server4-uuid>
ibm-replicationServerIsMaster: false
cn: server4
description: server4 (forwarder) ibm-replicaSubentry 

#server1 to server5 agreement
dn: cn=server5,ibm-replicaServerId=<server1-uuid>,
    ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server5
ibm-replicaConsumerId: <server5-uuid>
ibm-replicaUrl: ldap://server5:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server1(master) to server5(master) agreement

#server1 to server2 agreement
dn: cn=server2,ibm-replicaServerId=<server1-uuid>,
    ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server2
ibm-replicaConsumerId: <server2-uuid>
ibm-replicaUrl: ldap://server2:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server1(master) to server2(forwarder) agreement


#server1 to server4 agreement
dn: cn=server4,ibm-replicaServerId=<server1-uuid>
    ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server4
ibm-replicaConsumerId: <server4-uuid>
ibm-replicaUrl: ldap://server4:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server1(master) to server4(forwarder) agreement

#server5 to server1 agreement
dn: cn=server1,ibm-replicaServerId=<server5-uuid>,
    ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server1
ibm-replicaConsumerId: <server1-uuid>
ibm-replicaUrl: ldap://server1:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server5(master) to server1(master) agreement

#server5 to server2 agreement
dn: cn=server2,ibm-replicaServerId=<server5-uuid>
    ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server2
ibm-replicaConsumerId: server2-uid
ibm-replicaUrl: ldap://server2:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server5(master) to server2(forwarder) agreement

#server5 to server4 agreement
dn: cn=server4,ibm-replicaServerId=<server5-uuid>,
    ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server4
ibm-replicaConsumerId: <server4-uuid>
ibm-replicaUrl: ldap://server4:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server5(master) to server4(forwarder) agreement

#server2 to server3 agreement
dn: cn=server3,ibm-replicaServerId=<server2-uuid>,
    ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server3
ibm-replicaConsumerId: <server3-uuid>
ibm-replicaUrl: ldap://server3:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server2(forwarder) to server3(replica) agreement

#server2 to server6 agreement
dn: cn=server6,ibm-replicaServerId=<server2-uuid>,
    ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server6
ibm-replicaConsumerId: <server6-uuid>
ibm-replicaUrl: ldap://server6:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server2(forwarder) to server6(replica) agreement

#server4 to server7 agreement
dn: cn=server7,ibm-replicaServerId=<server4-uuid>,
    ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server7
ibm-replicaConsumerId: <server7-uuid>
ibm-replicaUrl: ldap://server7:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server4(forwarder) to server7(replica) agreement

#server4 to server8 agreement
dn: cn=server8,ibm-replicaServerId=<server4-uuid>,
    ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server8
ibm-replicaConsumerId: <server8-uuid>
ibm-replicaUrl: ldap://server8:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server4(forwarder) to server8(replica) agreement
To load this topology, issue the command:
idsldif2db -r no -i  <mytopologyfile> -I <instance_name>
where -r no prevents replication of the set of entries.
At this point you might want to load additional data for your subtree.
When you have finished loading the data, to be able to export the topology to populate the other servers, issue the command:
idsdb2ldif  -s"o=sample" -o <mymasterfile.ldif>  -I <instance_name> 
		-k <key seed> -t <key salt>
You must use the -I option if there is more than one instance. You must use the -k and -t options if keys on the server are not synchronized. See the idsdb2ldif command in the IBM Tivoli Directory Server version 6.1 Command Reference for more information.
Attention: If you are exporting data that will be imported into an Advanced Encryption Standard (AES)-enabled server and if the two servers are not cryptographically synchronized, see Appendix J. Synchronizing two-way cryptography between server instances, in the IBM Tivoli Directory Server version 6.1 Administration Guide for information about cryptographic synchronization of servers.
When the source server (the server you are exporting data from) and the destination server (the server into which you will be importing the data) are using non-matching directory key stash files, and you specify the encryption seed and salt values of the destination server, any AES-encrypted data will be decrypted using the source server's AES keys, then re-encrypted using the destination server's encryption seed and salt values. This encrypted data is stored in the LDIF file.
The encryption seed is used to generate a set of AES secret key values. These values are stored in a directory stash file and used to encrypt and decrypt directory stored password and secret key attributes. The encryption seed must contain only printable ISO-8859-1 ASCII characters with values in the range of 33 to 126, and must be a minimum of 12 and a maximum of 1016 characters in length. See Appendix D. ASCII characters from 33 to 126 , in the IBM Tivoli Directory Server version 6.1 Administration Guide for information about these characters.
The encryption salt is a randomly generated value that is used to generate AES encryption keys. We can obtain the destination server's salt value by searching (using the idsldapsearch utility) the destination server's "cn=crypto,cn=localhost" entry. The attribute type is ibm-slapdCryptoSalt.
Start server2, server3, server4, server6, server7, and server8 in configuration only mode. On each of the servers issue the command:
idsslapd -I <LDAPinstance> -a
You must configure server2 and server4 to be forwarding servers and configure server3, server6, server7, and server8 to be replica servers. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on each of the servers:
idsldapadd -D <adminDN> -w<adminPW> -p <port> -i<filename>
where <filename> contains:
dn: cn=Master Server, cn=configuration
objectclass: ibm-slapdReplication
cn: Master Server
ibm-slapdMasterDN: cn=any
ibm-slapdMasterPW: secret
ibm-slapdMasterReferral: ldap://server1:389/  
This ensures that all updates from the clients are referred to server1.
Stop server2, server3, server4, server6, server7, and server8. To stop the servers, issue the following command on each of the servers:
ibmdirctl -h <serverx> -D <adminDN>-w <adminPW> -p <port> stop
where <serverx> is the name of the server.
Save the ibmslapd.conf file as a new backup.
Copy the <mymasterfile.ldif> file to the computers where server2, server3, server4, server5, server6, server7, and server8 are located.
At each of these computers, issue the following command:
idsldif2db -r no -i <mymasterfile.ldif> -I <instance_name>
Start server1, server2, server3, server4, server5, server6, server7, and server8. On each of the servers issue the command:
idsslapd  -I <instance_name>
Unconfiguring a master/replica configuration

There are several ways to remove a replica server from a master (supplier)/replica (consumer) topology.
Use the following command to remove all master/replica information by unconfiguring the ldap server's database on both machines and reconfiguring:
idsucfgdb -I <instance_name>
A message box will display, asking you if you want to remove the database and the database instance. Click Yes.

This process unconfigures the entire database on the replica server and all data will be lost.
Alternately, use the following steps to remove your replica from the topology. With this option, you are required to unconfigure and reconfigure one server only (replica):
Stop the replica server.
Suspend the master server.
Remove supplier information from your master server. Go to Replication management–> Manage topology.
Delete a replica server.

Click Show topology.
Select a replica.
Click Delete.

Delete a master server.

Click Show topology.
Select a master.
Click Delete.

Remove a subtree from master server.

Click Show topology.
Select a subtree.
Select Delete subtree from the drop-down list.
Click Go.

Remove credentials from a master server.

Click Manage credentials.
Select a subtree.
Click Show credentials.
Select credentials.
Click Delete.
Click OK.
Run the following command on the replica server to unconfigure the database and remove all data:
idsucfgdb -I <instance_name>
A message box will display, asking you if you want to remove the database and the database instance. Click Yes. All information or entries will be lost in each of your databases.
We can also do the following to unconfigure your replica server without unconfiguring your entire database:
Remove supplier information from your master server. Go to Replication management–> Manage topology.
Delete replica server.

Click Show topology.
Select a replica.
Click Delete.

Delete master server.

Click Show topology.
Select a master.
Click Delete.

Remove subtree from master server.

Click Show topology.
Select a subtree.
Select Delete subtree from the drop-down list.
Click Go.

Remove credentials from the master server.

Click Manage credentials.
Select a subtree.
Click Show credentials.
Select credentials.
Click Delete.
Click OK.

Remove the credentials from the replica server.

Click Manage credentials.
Select a subtree.
Click Show credentials.
Select credentials.
Click Delete.
Click OK.

Remove supplier information from your replica server. Click Manage replication properties. Click Delete.
Go to Directory management.
Select the subtree and expand.
Select ibm-replica Group=default and expand.
Select the replicaSubentry entry and expand.
Delete all agreements.
Collapse and delete replicaSubentry entry.
Collapse and delete ibm-replica Group=default.
Select the subtree. From the drop-down list, select Delete auxiliary objectclass and click Go.
A new panel is displayed. In this panel, select the ibm-replicationContext and click Delete.
Click OK.
Confirm your server no longer has replication information by performing the following searches on the replica server. Nothing should be returned for the second search. If an empty container is returned for the first search, that is acceptable.
idsldapsearch -D cn=root -w secret -b " " -s sub 
	objectclass=ibm-repl*
This operation will return any replication topology that remains in the directory.

We can perform this step on the master if there are no replicas left in the topology.
Setting up a gateway topology

A gateway server must be an IBM Tivoli Directory Server 5.2 or later, or an IBM Directory Server version 5.1 FP 1 server that supports gateway replication.
Gateway replication uses gateway servers to collect and distribute replication information effectively across a replicating network. The primary benefit of gateway replication is the reduction of network traffic.
Gateway servers must be masters (writable). The following figure illustrates how gateway replication works:
Figure 15. A replicating network with Gateway servers

The replicating network in the preceding figure contains four replication sites, each containing a gateway server. A gateway server:

Collects replication updates from the peer/master servers in the replication site where it resides and sends the updates to all the other gateway servers within the replicating network.
Collects replication updates from other gateway servers in the replication network and sends those updates to the peers/masters and replicas in the replication site where it resides.

Gateway servers use server IDs and consumer IDs to determine which updates are sent to other gateway servers in the replicating network and which updates are sent to local servers within the replication site.
To set up gateway replication, create at least two gateway servers. The creation of a gateway server establishes a replication site. You must then create replication agreements between the gateway and any masters/peers and replicas you want to include in that gateway's replication site.
Gateway servers must be masters (writable). If you attempt to add the gateway object class, ibm-replicaGateway, to a subentry that is not a master, an error message is returned.
There are two methods for creating a gateway server. We can:

Create a new gateway server
Convert an existing master server to a gateway server

It is very important that you assign only one gateway server per replication site. The master and replica servers within the replication site can only have agreements with the gateway server for that site.

Using Web Administration:

Before starting to set up your replication topology, make a backup copy of your original configuration file (ibmslapd.conf) and the key stash files (ibmslapddir.ksf and ibmslapdconf.ksf) ibmslapd.conf file. We can use this backup copy to restore your original configuration if you encounter difficulties with replication. In addition we need to save the replication topology information stored in the directory. Use the idsdb2ldif utility to export the ibm-replicagroup=default subtree of the replicated subtree. For example, if you are changing the topology for the subtree o=sample, we need to export the subtree ibm-replicagroup=default,o=sample.
Attention: If restoring, restore to the same operating system as the operating system on which the failure occurred. If you don't restore to the same operating system, there might be errors.

To set up a gateway using the complex topology with peer replication from the previous scenario:
Figure 16. Initial peer-to-peer topology

Convert an existing peer server (peer1) to a Gateway server to create replication site1.
Create a new gateway server for replication site 2 and agreements with peer1.
Create the topology for replication site 2 (not illustrated in this example).
Copy the data from the master to all the machines in the topology.

Use the Web Administration Tool to log on to the master (server1).
Expand the Replication management category in the navigation area and click Manage topology.
Select the subtree that you want and click Show topology.
To convert an existing server to a gateway server, click Manage gateway servers. Select server1 or its peer server5. For this example use server1 and click Make gateway.
Click OK.

If the server you want to use as a gateway is not already a master, it must be a leaf replica with no subordinate replicas that we can first promote to be a master and then designate as a gateway.
To create a new gateway server, Click Add server.
Create the new server, server9 as a gateway server. See Adding a peer-master or gateway server for information about how to do that.
The Create additional supplier agreements panel is displayed. Ensure that the supplier agreement boxes are checked for server1 only. Deselect the other agreements.

Select Supplier Consumer

X server1 server9
X server9 server1
server2 server9
server9 server2
server4 server9
server9 server4
server9 server5
server5 server9

Click Continue.
Click OK.
Add the appropriate credentials and consumer information.

In some cases the Select credentials panel will pop up asking for a credential that is located in a place other than cn=replication,cn=localhost. In such situations provide a credential object that is located in a place other than cn=replication,cn=localhost. Select the credentials the subtree is going to use from the existing sets of credentials or create new credentials. See Adding credentials.
Click OK. The server roles are represented by icons in the Web Administration Tool. Your topology is now:

server1 (master-gateway for replication site1)

server2 (forwarder)

server3 (replica)
server6 (replica)

server4 (forwarder)

server7 (replica)
server8 (replica)

server5 (master)
server9 (master-gateway for replication site 2)

server5 (master)

server1 (master)
server2 (forwarder)

server3 (replica)
server6 (replica)

server4 (forwarder)

server7 (replica)
server8 (replica)

server9 (master-gatway)

server1 (master-gateway)

Figure 17. A gateway topology with two replication sites

Add servers to server9 to create the topology for replication site 2. Remember to deselect any agreement for the new servers to any servers outside of replication site 2.
Repeat this process to create additional replication sites. Remember to create only one gateway server per replication site. However, each gateway server must be present in the topologies with agreements to the other gateway servers.
When you have finished creating the topology, copy the data from server1 to the all the new servers in all the replication sites and if required, add the supplier credential information to all the new servers. See Copying data to the replica and Adding the supplier information to a replica for information about how to do that.

Using the command line:

In this example you are going to change the previous two peer, two forwarder, and four replica scenario to:

Change the role of server1 to a gateway server for its topology (replication site1).
Create a new gateway server, server9, for replication site2.

Replication site2 has its own topology with server9 as its gateway server. That replication topology is not being illustrated in this example. We can use the topology for replication site1 as a model. However, all the topology does need to be included for all replication sites in your actual topology setup.

Figure 18. A gateway topology with two replication sites
Create server9. Create an instance (see "Creating and administering instances" in the IBM Tivoli Directory Server Version 6.1 Installation and Configuration Guide) for server9.

Remember the server ID for this instance. You will use it in this task.
Configure server9 as a consumer of server1. Use the idsldapmodify command to add the following entry to the ibmslapd.conf file on server9:
idsldapmodify -D <adminDN> -w<adminPW> -p <port> -i <filename>
where <filename> contains:
dn: cn=Master Server, cn=configuration
objectclass: ibm-slapdReplication
cn: Master Server
ibm-slapdMasterDN: cn=any
ibm-slapdMasterPW: secret
Make server1 a gateway. Modify the following entry on server1 by adding the objectclass: ibm-replicaGateway attribute:
dn: ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,
	ou=test,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
objectclass: ibm-replicaGateway
ibm-replicaServerId: <server1-uuid>
ibm-replicationServerIsMaster: true
cn: server1
description: server1 (gateway server from  replication site 1 to 
            replication site 2)
Add the server9 subentry to server1:
dn: ibm-replicaServerId=<server9-uuid>,ibm-replicaGroup=default,
	ou=test,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
objectclass: ibm-replicaGateway
ibm-replicaServerId: <server9-uuid>
ibm-replicationServerIsMaster: true
cn: server9
description: server9 (gateway server from replication site 2 to 
             replication site 1)
Suspend the server5 to server1 queue:
idsldapexop -D <adminDN> -w <admin_password> -h server5 -p <port> -op controlrepl 
	-action suspend -rc "ou=test,o=sample"
Add the replication agreement from server9 to server1 on server1:
#server9 to server1 agreement
dn: cn=server1,ibm-replicaServerId=<server9-uuid>,
    ibm-replicaGroup=default,ou=test,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server1
ibm-replicaConsumerId: <server1-uuid>
ibm-replicaUrl: ldap://server1:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMPolicies
description: supplier agreement from replication site2 to replication site 1
Add the replication agreement from server1 to server9 on server1:
#server1 to server9 agreement
dn: cn=server9,ibm-replicaServerId=<server1-uuid>,
    ibm-replicaGroup=default,ou=test,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server9
ibm-replicaConsumerId: <server9-uuid>
ibm-replicaUrl: ldap://server9:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMPolicies
description: supplier agreement from replication site1 to replication site2
Quiesce server1:
idsldapexop -D <adminDN> -w <admin_password> -h server1 -p <port> -op quiesce 
	-rc "ou=test,o=sample"
Flush the server1 to server9 queue:
idsldapexop -D <adminDN> -w <admin_password> -h server1 -p <port> -op controlqueue 
	-skip all -ra "cn=server9,ibm-replicaServerId=<server1-uuid>,
    ibm-replicaGroup=default,ou=test,o=sample"
Perform an idsdb2ldif command to create an LDIF file on server1:
idsdb2ldif  -s "ou=test,o=sample" -o <filename1>.ldif  
	-I <instance_name> -k <key seed> 
	-t <key salt>
where <filename1>.ldif is the first LDIF file. For more information about file contents, see ***.
Perform an idsdb2ldif command to create a second LDIF file on server1:
idsdb2ldif  -s "cn=replication,cn=ibmpolicies" -o <filename2>.ldif  
	-I <instance_name> -k <key seed> 
	-t <key salt>
where <filename2>.ldif is the second LDIF file. For more information about file contents, see ***.
Unquiesce server1:
idsldapexop -D <adminDN> -w <admin_password> -h server1 -p <port> -op 
	quiesce -end -rc "ou=test,o=sample"
Resume the server5 to server1 queue on server5:
idsldapexop -D <adminDN> -w <admin_password> -h server5 -p <port> -op 
	controlrepl -action resume -rc "ou=test,o=sample"
At this point, server5 and server1 are fully functional.
Copy the <filename1>.ldif file to server9.
Load the <filename1>.ldif onto server9:
idsldif2db -r no -i <filename1>.ldif -I <instance_name>
Copy the <filename2>.ldif file to server9.
Load the <filename2>.ldif onto server9:
idsldif2db -r no -i <filename2>.ldif -I <instance_name>
Start server9:
idsslapd -I <instance_name> -a
If you want the global policy information replicated, remember to ensure that all the servers have been added to the topology under cn=ibmpolicies.
The following are partial file contents of both the first and second LDIF files loaded onto server9:
<filename1>.ldif
The items in bold are the entries that were modified or added to create this Gateway topology.
dn: cn=ou=test,o=sample
o: ibm
objectclass: top
objectclass: organization
objectclass: ibm-replicationContext

dn: ibm-replicaGroup=default,ou=test,o=sample
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicaGroup: default

#Make server1 a gateway server for site 1
dn: ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,
	ou=test,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
objectclass: ibm-replicaGateway
ibm-replicaServerId: <server1-uuid>
ibm-replicationServerIsMaster: true
cn: server1
description: server1 (gateway server from  replication site 1 to 
            replication site 2)

#Add server9 as a gateway server for site 2
dn: ibm-replicaServerId=<server9-uuid>,ibm-replicaGroup=default,
	ou=test,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
objectclass: ibm-replicaGateway
ibm-replicaServerId: <server9-uuid>
ibm-replicationServerIsMaster: true
cn: server9
description: server9 (gateway server from replication site 2 to 
             replication site 1)

dn: ibm-replicaServerId=<server5-uuid>,ibm-replicaGroup=default,
	ou=test,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server5-uuid>
ibm-replicationServerIsMaster: true
cn: server5
description: server5 (master)

dn: ibm-replicaServerId=<server2-uuid>,
    ibm-replicaGroup=default,ou=test,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server2-uuid>
ibm-replicationServerIsMaster: false
cn: server2
description: server2 (forwarder server number one)

dn: ibm-replicaServerId=<server4-uuid>,
    ibm-replicaGroup=default,ou=test,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server4-uuid>
ibm-replicationServerIsMaster: false
cn: server4
description: server4 (forwarder server number two)

#server1 to server9 agreement
dn: cn=server9,ibm-replicaServerId=<server1-uuid>,
    ibm-replicaGroup=default,ou=test,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server9
ibm-replicaConsumerId: <server9-uuid>
ibm-replicaUrl: ldap://server9:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMPolicies
description: supplier agreement from replication site1 to replication site2

#server9 to server1 agreement
dn: cn=server1,ibm-replicaServerId=<server9-uuid>,
    ibm-replicaGroup=default,ou=test,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server1
ibm-replicaConsumerId: <server1-uuid>
ibm-replicaUrl: ldap://server1:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMPolicies
description: supplier agreement from replication site2 to replication site 1 

#server1 to server5 agreement
dn: cn=server5,ibm-replicaServerId=<server1-uuid>,
    ibm-replicaGroup=default,ou=test,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server5
ibm-replicaConsumerId: <server5-uuid>
ibm-replicaUrl: ldap://server5:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMPolicies
description: server1 (gateway-master) to server5 (peer-master) agreement

#server1 to server2 agreement
dn: cn=server2,ibm-replicaServerId=<server1-uuid>,
    ibm-replicaGroup=default,ou=test,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server2
ibm-replicaConsumerId: <server2-uuid>
ibm-replicaUrl: ldap://server2:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMPolicies
description: server1 (gateway-master) to server2 (forwarder) agreement

#server1 to server4 agreement
dn: cn=server4,ibm-replicaServerId=<server1-uuid>
    ibm-replicaGroup=default,ou=test,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server4
ibm-replicaConsumerId: <server4-uuid>
ibm-replicaUrl: ldap://server4:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMPolicies
description: server1 (gateway-master) to server4 (forwarder) agreement

#server5 to server1 agreement
dn: cn=server1,ibm-replicaServerId=<server5-uuid>,
    ibm-replicaGroup=default,ou=test,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server1
ibm-replicaConsumerId: <server1-uuid>
ibm-replicaUrl: ldap://server1:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMPolicies
description: server5 (peer-master) to server1 (gateway-master) agreement

#server5 to server2 agreement
dn: cn=server2,ibm-replicaServerId=<server5-uuid>
    ibm-replicaGroup=default,ou=test,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server2
ibm-replicaConsumerId: server2-uid
ibm-replicaUrl: ldap://server2:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMPolicies
description: server5 (peer-master) to server2 (forwarder) agreement

#server5 to server4 agreement
dn: cn=server4,ibm-replicaServerId=<server5-uuid>,
    ibm-replicaGroup=default,ou=test,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server4
ibm-replicaConsumerId: <server4-uuid>
ibm-replicaUrl: ldap://server4:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMPolicies
description: server5 (peer-master) to server4 (forwarder) agreement

#server2 to server3 agreement
dn: cn=server3,ibm-replicaServerId=<server2-uuid>,
    ibm-replicaGroup=default,ou=test,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server3
ibm-replicaConsumerId: <server3-uuid>
ibm-replicaUrl: ldap://server3:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMPolicies
description: server2 (forwarder) to server3 (replica)agreement

#server2 to server6 agreement
dn: cn=server6,ibm-replicaServerId=<server2-uuid>,
    ibm-replicaGroup=default,ou=test,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server6
ibm-replicaConsumerId: <server6-uuid>
ibm-replicaUrl: ldap://server6:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMPolicies
description: server2 (forwarder) to server6 (replica)agreement

#server4 to server7 agreement
dn: cn=server7,ibm-replicaServerId=<server4-uuid>,
    ibm-replicaGroup=default,ou=test,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server7
ibm-replicaConsumerId: <server7-uuid>
ibm-replicaUrl: ldap://server7:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMPolicies
description: server4 (forwarder) to server7 (replica)agreement

#server4 to server8 agreement
dn: cn=server8,ibm-replicaServerId=<server4-uuid>,
    ibm-replicaGroup=default,ou=test,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server8
ibm-replicaConsumerId: <server8-uuid>
ibm-replicaUrl: ldap://server8:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMPolicies
description: server4 (forwarder) to server8 (replica)agreement
<filename2>.ldif
dn: cn=replication,cn=ibmpolicies
o: ibm
objectclass: top
objectclass: container
objectclass: ibm-replicationContext

dn: cn=simple,cn=replication,cn=ibmpolicies 
objectclass: ibm-replicationCredentialsSimple 
cn: simple 
replicaBindDN: cn=any 
replicaCredentials: secret 
Partial Replication

Partial replication is a replication feature that replicates only the specified entries and a subset of attributes for the specified entries within a subtree. The entries and attributes that are to be replicated are specified by the LDAP administrator. Using partial replication, an administrator can enhance the replication bandwidth depending on the deployment requirements. For instance, an administrator may choose the entries of the object class person with cn, sn, and userPassword attributes to be replicated and description attribute not to be replicated.
The attributes that are to be replicated are specified using a replication filter. A replication filter may be associated with a particular replication agreement and will be based on object classes. A set of attributes pertaining to an object class constitutes a replication filter. The list of attributes selected for an object class can either be a part of an inclusion list or an exclusion list. An inclusion list is list of attributes that will be selected for replication while an exclusion list is list of attributes that will not be selected for replication.
The following attributes are always replicated, irrespective of their presence in the exclusion list

Object class attributes of an entry
Naming attribute
All operational attributes

For information about known limitations of partial replication, see Chapter 10, "General Information, Known Limitations and General Troubleshooting" in the IBM Tivoli Directory Server Version 6.1 Problem Determination Guide
The partial replication feature can be managed using the web administration tool or from the command line.

Using Web Administration Tool

If you have not done so already, expand the Replication management category in the navigation area of the Web Administration Tool and click Manage filters. This panel is available only if the server supports the filter-based replication capability.
On this panel we can:

View subtrees where replication filters are stored
Add filters
Edit filters
Delete filters
Copy filters
View filters

Add filters

To add a replication filter, you first select a subtree from the Select a subtree box on the Manage filters panel and then click Add to display the Add Replication Filter panel.
Add Replication Filter- General

This panel contains controls for adding details for a replication filter.
To add a replication filter:

In the Filter name box, enter a name for the filter. For example, myfilter1.
From the Available object classes box, select the object classes on which you want to create filter.
Click Add to populate the Selected object classes box with the object classes from the Available object classes box.
Select the Define filter for remaining object classes check box.
To continue with adding a replication filter for filtered attributes, click Next.

Add Replication Filter- Filtered Attributes

This panel provides the facility to choose the attributes to be replicated for the selected object classes. This panel is invoked on clicking the Next button on the Add Replication Filter- General panel.
To specify the attributes to be replicated for an object class:

Click the Select column of the object class row for which you want to specify attributes to be replicated.
Click the Manage filter attribute button or select Manage filter attribute from the Select Action list and then click Go.

Manage filter attributes

The Manage filter attributes panel is used for specifying object class attributes for replication filter.
To specify attributes for replication filter:

Clear the Select all attributes as filtered attributes check box.

If you want to specify all the attributes of the selected object class in a replication filter, select the Select all attributes as filtered attributes check box.
Select the required attributes in the Available attributes box.
Click Add to move the selected attributes from Available attributes to Filtered attributes.
To include the attributes in the Filtered attributes box in the replication filter, click Include selected filtered attributes.
To exclude the attributes in the Filtered attributes box from the replication filter, click Exclude selected filtered attributes.
Click OK.
To save the replication filter, click Finish on the Add Replication Filter- Filtered Attributes panel.

Delete filters

To delete a replication filter, select a replication filter in the Filters for selected subtree box on the Manage filters panel and then click Delete.

Edit filters

To edit a replication filter, you select a filter from the Filters for selected subtree box on the Manage filters panel and then click Edit.
Edit Replication Filter- General

This panel contains controls for modifying the content of a selected filter.
To edit a replication filter:

From the Available object classes box, select the object classes that you want to add to the filter.
To edit the existing filter:

Click Add to populate the Selected object classes box with the object classes from the Available object classes box.
Click Remove to remove a selected object class from the Selected object classes box.

Select the Define filter for remaining object classes check box.
To continue editing the replication filter for filtered attributes, click Next.

Edit Replication Filter- Filtered Attributes

This panel provides the facility to choose the attributes to be replicated, when the filter is selected. This panel is invoked on clicking the Next button on the Edit Replication Filter- General panel.
To specify the attributes to be replicated for an object class:

Click the Select column of the object class row for which you want to edit the existing attributes list for the selected object class in the replication filter.
Click the Manage filter attribute button or select Manage filter attribute from the Select Action list and then click Go to display the Manage filter attributes panel.
In the Manage filter attributes panel, specify the attributes that are to be included or excluded in the replication filter definition.

Copy Filters

To copy the details of a replication filter to another replication filter, you first select a subtree from the Select a subtree box and then select a filter stored under that subtree from Filters for selected subtree on the Manage filters panel and then click Copy.
Copy Replication Filter- General

To copy a replication filter:

From the Filter location box, select the subtree under which you want to copy the selected replication filter.
In the Filter name box, enter a name for the filter. For example, myfilter2.
From the Available object classes box, select the object classes that you want to add to the existing filter.
Click Add to populate the Selected object classes box with the object classes from the Available object classes box.
Select the Define filter for remaining object classes check box.
To continue with copying of the filter for filtered attributes, click Next.

Copy Replication Filter- Filtered Attributes

This panel provides the facility to choose the attributes to be replicated for the selected object classes. This panel is invoked on clicking the Next button on the Copy Replication Filter- General panel.
To specify the attributes to be replicated for an object class:

Click the Select column of the object class row for which you want to specify attributes to be replicated.
Click the Manage filter attribute button or select Manage filter attribute from the Select Action list and then click Go to display the Manage filter attributes panel.
In the Manage filter attributes panel, specify the attributes that are to be included or excluded in the replication filter definition.

Using command line

Issue the following command to add a replication filter:
ldapadd -D cn=root -w root 

dn: cn=replicationfilter,cn=localhost
objectclass: ibm-replicationfilter
ibm-replicationFilterAttr: (objectclass=person):(cn,sn,description)
ibm-replicationFilterAttr: (objectclass=printer):!(cn,color)
ibm-replicationFilterAttr: (objectclass=*): (*)
The above example states that for entries of type "person", the attributes cn, sn, and description will be sent to the replica. The rest of the attributes present in the entry will not be sent. For entries of type "printer", all attributes except cn and color will be sent. For the remaining entries, all attributes will be sent.
Now, modify the replication agreement to add the DN of the filter entry. To do this, issue the following command:
ldapmodify -D cn=root -w root 

dn: cn=replica1,ibm-replicaServerId=master-uuid,ibm-replicaGroup=default,o=sample
changetype: modify
add: ibm-replicationFilterDN
ibm-replicationFilterDN: cn=replicationfilter,cn=localhost
Examples of replication filter

Given below are some examples that explain the usage of replication filter-:
Example 1
dn: cn=replicationfilter, cn=localhost
objectclass: ibm-replicationFilter
ibm-replicationFilterAttr: (objectclass=person):(*)
ibm-replicationFilterAttr: (objectclass=*): !(*) 
The first filter attribute in this example specifies that all attributes of entry type "person" will be replicated. The second filter attribute specifies that no other entries except those of type "person" will be replicated. This means that only entries of type "person" will be replicated and no other entries will be replicated.
Example 2
dn: cn=replicationfilter, cn=localhost
objectclass: ibm-replicationFilter
ibm-replicationFilterAttr: (objectclass=person):(cn,sn,userPassword)
ibm-replicationFilterAttr: (objectclass=managerOf):(managerOfDept)
ibm-replicationFilterAttr: (objectclass=*): !(managerOfDept)
For this example, consider an entry "cn=Ricardo Garcia,o=sample" of type "person". A new auxiliary objectclass "managerOf" is attached to the above entry. Therefore the entry "cn=Ricardo Garcia,o=sample" will contain both "person" and "managerOf" object classes.
The first filter attribute specifies that attributes cn, sn, and userpassword of entry type "person" will be replicated. The second filter attribute specifies that attribute managerOfDept of entry type "managerOf" will be replicated. The third filter attribute specifies that attribute managerOfDept will not be replicated for any other entry except those of type "person" or "managerOf".
Therefore, for an entry type person, the attribute cn, sn, and userPassword will be replicated. For the entry "cn=Ricardo Garcia,o=sample", containing objectclass person and managerOf, the attributes cn, sn, userPassword, and managerOfDept will be replicated. For any other entry that is not of type "person" or "managerOf", all attributes except managerOfDept will be replicated.
Example 3
dn: cn=replicationfilter, cn=localhost
objectclass: ibm-replicationFilter
ibm-replicationFilterAttr: (objectclass=person):(cn,sn,userPassword)
ibm-replicationFilterAttr: (objectclass=inetOrgPerson):!(userPassword,employeeNumber)
ibm-replicationFilterAttr: (objectclass=*): !(*)
For this example, consider an entry "cn=Ricardo Garcia,o=sample" of type "person" and another entry "cn=Jane Smith,o=sample" of type "inetOrgperson". The entry "cn=Jane Smith,o=sample" will contain both "person" and "inetOrgPerson" object classes.
The first filter attribute specifies that attributes cn, sn, and userpassword of entry type "person" will be replicated. The second filter attribute specifies that attributes userPassword and employeeNumber of entry type "inetOrgPerson" will not be replicated. The third filter attribute specifies that any attribute for any other entry except that of type "person" or "inetOrgPerson" will not be replicated.
Therefore, for the entry "cn=Ricardo Garcia,o=sample", the attributes cn, sn, and userPassword will be replicated. For the entry "cn=Jane Smith,o=sample", which matches the first and second replication filters, only attributes cn and sn will be replicated. The attribute userPassword being present in both the inclusion and exclusion list, will be eliminated as exclusion takes precedence over inclusion. For any other entry, that is not of type "person" or "inetOrgPerson" no attributes will be replicated.

Recovery procedures

The following procedures are based on a system topology with two peer master servers (server 1 and server 2) and two replica servers (server 3 and server 4). Server 2 is acting as a fail-over master, meaning that it does not accept updates directly from client machines unless server 1 is taken offline.

Required recovery information

After you have created your replication topology, we need to do the following:

Make a copy of the configuration file (ibmslapd.conf) and the key stash files (ibmslapddir.ksf and ibmslapdconf.ksf) of each server and store these files in a secure location. This location needs to be on a backup machine that is not part of the replication topology or on a separate media such as a diskette, CD, or tape. This information needs updating only if you change the topology or change your configuration parameters (any entries under cn=Configuration). If you have made changes to the existing schema or added a new schema you need to make copies of the schema files (V3.* files) as well.
Use the idsdbback utility to create a nightly backup directory. Tar or zip this directory and store it in a secure location. This location needs to be on a backup machine that is not part of the replication topology or on a separate media such as a CD, or tape. This file contains all the entries in the directory, the server configuration information and the schema files. This backup directory ensures that we can never lose more than 24 hours worth of data. Run this utility against either server 3 or server 4 during off peak hours to get the most current data.

Attention: If restoring, restore to the same operating system as the operating system on which the failure occurred. If you don't restore to the same operating system, there might be errors.

Creating the database backup file

Use either the Configuration Tool or the command line utility to create your backup file.
Before you create the backup file, be sure that you have enough space to copy all the data. The space required is approximately the sum of the size of the following directories:

<dblocation>/<dbname>
<dblocation>/ldap32kcont_<dbname>

By default <dblocation> is the installation path of the database instance.
The server must be stopped before we can back up the database. To back up the database:
Using the Configuration Tool

At a command prompt, type idsxcfg -I <instance_name> to start the Configuration Tool.
Click Backup database in the task list on the left.
In the Backup database window on the right, in the Backup directory field, type the directory path in which to back up all directory data and configuration settings. Alternatively, click Browse to locate the directory path. Make note of the exact directory path of the back up directory. This location is required for a successful restoration of data.
Click Create backup directory as needed if you want the directory to be created if it does not exist.
Click Backup.

Using the command line

On the server that you are using as the source server, if it does not already exist, create the backup directory, <backupdir>. Then issue the command:
idsdbback -k <backupdir>  -I <instance_name>
Where backupdir is the name of the backup directory you are creating. Make note of the exact directory path of the back up directory. This location is required for a successful restoration of data.
After you have created the backup directory, tar or zip the directory and its contents and store it in a secure location. This location needs to be on a backup machine that is not part of the replication topology or on a separate media such as a CD or tape.

Restoring the database

Use either the Configuration Tool or the command line utility to restore your database and configuration information.
Copy the most current backup directory file to the server and untar or unzip it.

This file must be copied to the exact location where the backup directory was originally created. Otherwise idsdbrestore fails.
The server must be stopped before we can back up the database. To restore the database:
Using the Configuration Tool

At a command prompt, type idsxcfg -I <instance_name> to start the Configuration Tool.
Click Restore database in the task list on the left.
In the Restore database window on the right, in the Backup directory field, type the path in which the directory was previously backed up. Alternatively, click Browse to locate the path.
Select the Restore data only (not configuration settings) check box.
Click Restore.

Using the command line

On the server that you are restoring the data:
Issue the command:
idsdbrestore -k <backupdir> -I <instance_name> -n
Where backupdir is the name of the backup directory you are restoring from.
Your database and configuration information have been restored.

Recovering from a single-server failure

Use this procedure to restore a server that has been repaired, for example had the hard drive replaced. For this example, server 3 is the server that is going to be restored. Server 2 is the server that is going to be used to restore server 3.

If the server is being replaced by a new machine, ensure that you use the same host name as the previous machine.
Attention: The following instructions assume you are recovering to the same operating system as the operating system on which the failure occurred. If you don't recover to the same operating system, there will be errors.
Install the IBM Tivoli Directory Server on server 3.
Configure a new database on server 3. Use the same instance owner name and database name that was previously used for server 3.
Copy the backup configuration file (ibmslapd.conf) and the key stash files (ibmslapddir.ksf and ibmslapdconf.ksf) for server 3 from the recovery source media on to server 3.

If recovering, recover to the same operating system as the operating system on which the failure occurred. If you don't recover to the same operating system, there might be errors.
Quiesce server 1.
idsldapexop –D <admin_dn> -w <admin_pw> –op quiesce –rc o=sample
Wait for server 1 to replicate all pending updates to server 2, when ibm-replicationpendingchangecount is zero.
idsldapsearch –D <admin_dn> -w <admin_pw> -h <server1> -b 
	<dn of agreement with server2>	-s base 
	objectclass=* ibm-replicationpendingchangecount
On server 1, purge the replication queue for server 3.
idsldapexop –D <admin_dn> -w <admin_pw> –op controlqueue –skip all –ra
	<dn of agreement with server3>  
On server 1, clear all errors logged for replication with server 3.
idsldapexop –D <admin_dn> -w <admin_pw>  –op controlreplerr –delete all –ra
	<dn of agreement with server3> 
On server 1, suspend replication to server 2 and server 3.
idsldapexop –D <admin_dn> -w <admin_pw>  –op controlrepl –action suspend –ra
	<dn of agreement with server2>
idsldapexop –D –D <admin_dn> -w <admin_pw>  –op controlrepl –action suspend –ra
	<dn of agreement with server3>  
Unquiesce server 1 so that it can accept updates again.
idsldapexop –D <admin_dn> -w <admin_pw> –op quiesce –end –rc o=sample
Stop server 3.
Stop server 2.
Use DB2® backup to back up the data on server 2.
Start server 2, and resume its replication queue on server 1.
idsldapexop –op controlrepl –action resume –ra <dn of agreement with server2>
Restore the DB2 data on server 3.
Start server 3, and resume its replication queue on server 1.
idsldapexop –op controlrepl –action resume –ra <dn of agreement with server3>
Recovering from a catastrophic failure

Use this procedure, if all the servers in the topology are lost and are being replaced.

Ensure that the same host names are used on the new machines that were used on the previous ones.
Reinstall the IBM Tivoli Directory Server Version 6.1 on all the new servers.
Configure a new database on each of the servers. Use the same instance owner names and database names as before.
Ensure that all the servers are stopped.
Copy the most current backup directory files to each of the servers.

This file must be copied to the exact location where the backup directory was originally created. Otherwise idsdbrestore fails.
Restore the database on each of the servers using the Configuration Tool or the idsdbrestore command. See Restoring the database.
Restart all the servers.

Your topology and data are restored to what they were less than 24 hours before the failure.

Multi-threaded replication

The multi-threaded replication function replaces the current single replication thread with a minimum of three threads to service the replication agreement:

Main thread
Sender thread
Receiver thread

We can have anywhere from 1 to 32 consumer connections. Set the number of consumer connections to match the number of processors on your machine.
Using multiple threads enables the supplier to send the updates to the consumer without waiting on the response from the consumer.
Anyone with a replication backlog might consider switching to multi-threaded replication. Candidate environments can include the following:

A high update rate
No downlevel servers
Common AES salt and synchronization if encryption is AES and passwords are updated often
Small fanout (for example, don't try 8 connections per agreement with 24 replicas)
Available servers and reliable network
Data consistency is not critical
All replication schedules are immediate
Multiprocessor machines

Multi-threaded replication is difficult to administer if servers or networks are not reliable.
When errors occur, the errors are logged and can be replayed by the administrator, but the error logs must be monitored closely. The following is a search to show the replication backlog for all agreements supplied by one server:
idsldapsearch -h supplier-host -D cn=admin -w ? -s sub 
	objectclass=ibm-replicationagreement 
	ibm-replicationpendingchangecount ibm-replicationstate
If the replication state is active, and the pending count is growing, there is a backlog that won't decrease unless the update rate decreases.

Replication error table

The replication error table logs failing updates for later recovery. When replication starts, the number of failures logged for each replication agreement is counted. This count is incremented if an update results in a failure, and a new entry is added into the table.
Each entry in the replication error table contains the following:

The replication agreement ID.
The replication change ID.
The timestamp for when the update was attempted.
The number of attempts made (this values is 1 by default, and increments for each attempt made).
The result code from the consumer.
All of the information from the replication operation pertaining to the update, for example, the DN, the actual data, controls, flags, and so forth.

If the value specified by the attribute ibm-slapdReplMaxErrors in the server configuration is 0, replication continues processing updates. The attribute ibm-slapdReplMaxErrors is an attribute in the replication configuration entry and it can be changed dynamically.
If the value specified by the attribute ibm-slapdReplMaxErrors is greater than 0, then when the error count for a replication agreement exceeds this value, replication does one of the following:

Single threaded

Replication goes into a loop trying to replicate the failing update.

Multi-threaded

Replication is suspended.

If the server is configured to use a single connection, replication attempts to send the same update after waiting for 60 seconds and keeps trying until replication succeeds or the administrator skips the update.
For a server configured to use multiple connections, replication is suspended for this agreement. The receiver threads continue polling for status from any updates that have been sent, but no more updates are replicated. To resume replication, the directory administrator must clear at least one error for this agreement or increase the limit with a dynamic modification of the server configuration.
For more information, see "Replication error log extended operation" in IBM Tivoli Directory Server C-Client SDK Programming Reference Version 6.1.

Web Administration tasks for managing replication

Use the Web Administration Tool to perform the following tasks.

Replicating subtrees

Adding a subtree

The server must be running to perform this task.
Expand the Replication management category in the navigation area and click Manage topology.
Click Add subtree.
Enter the DN of the subtree that you want to replicate or click Browse to expand the entries to select the entry that is to be the root of the subtree.
Enter the master server referral URL in the form of an LDAP URL, for example:
For non-SSL:
ldap://<myservername>.<mylocation>.<mycompany>.com:<port>
For SSL:
ldaps://<myservername>.<mylocation>.<mycompany>.com:<port>
The default URL is ldap://localhost:389

The master server referral URL is optional. It is used only:

If the server contains (or will contain) any read-only subtrees.
To define a referral URL that is returned for updates to any read-only subtree on the server.
Click OK.
The new server is displayed on the Manage topology panel under the heading Replicated subtrees.
On the Linux, Solaris, and HP-UX platforms, if a referral fails, ensure that the environment variable LDAP_LOCK_REC has been set in your system environment. No specific value is required.
set LDAP_LOCK_REC=anyvalue
Editing a subtree

Use this option to change the URL of the master server that this subtree and its replicas send updates to. You need do this if you change the port number or host name of the master server, change the master to a different server
Select the subtree you want to edit.
Expand the Select Action menu, select Edit subtree and click Go.
Enter the master server referral URL. This must be in the form of an LDAP URL, for example:
ldap://<mynewservername>.<mylocation>.<mycompany>.com:<port>
Depending on the role being played by the server on this subtree (whether it is a master, replica or forwarding), different labels and buttons appear on the panel.

When the subtree's role is replica, a label indicating that the server acts as a replica or forwarder is displayed along with the button Make server a master. If this button is clicked then the server which the Web Administration Tool is connected to becomes a master.
When the subtree is configured for replication only by adding the auxiliary class (no default group and subentry present), then the label This subtree is not replicated is displayed along with the button Replicate subtree. If this button is clicked, the default group and the subentry is added so that the server with which the Web Administration Tool is connected to becomes a master.
If no subentries for the master servers are found, the label No master server is defined for this subtree is displayed along with the button titled Make server a master. If this button is clicked, the missing subentry is added so that the server with which the Web Administration Tool is connected to becomes a master.

Removing a subtree

Select the subtree you want to remove
Expand the Select Action menu, select Delete subtree and click Go.
When asked to confirm the deletion, click OK.

The subtree is removed from the Replicated subtree list.

This operation succeeds only if the ibm-replicaGroup=default is entry is empty.

Quiescing the subtree

This function is useful when you want to perform maintenance on or make changes to the topology. It minimizes or stops completely the number of updates that can be made to the server. A quiesced server does not accept client requests. It accepts requests only from an administrator using the Server Administration control.
This function is Boolean.

Click Quiesce/Unquiesce to quiesce the subtree.
When asked to confirm the action, click OK.
Click Quiesce/Unquiesce to unquiesce the subtree.
When asked to confirm the action, click OK.

Editing access control lists for the subtree

Replication information (replica subentries, replication agreements, schedules, possibly credentials) are stored under a special object, ibm-replicagroup=default. The ibm-replicagroup object is located immediately beneath the root entry of the replicated subtree. By default, this subtree inherits ACL from the root entry of the replicated subtree. This ACL might not be appropriate for controlling access to replication information.
Required authorities:

Control replication - You must have write access to the ibm-replicagroup=default object (or be the owner/administrator).
Cascading control replication - You must have write access to the ibm-replicagroup=default object (or be the owner/administrator).
Control queue - You must have write access to the replication agreement.

To view ACL properties using the Web Administration Tool utility and to work with ACLs:

Select the subtree you want to edit the ACLs on.
Expand the Select Action menu, select Edit ACLs and click Go.

See Working with ACLs for information on how to edit ACLs and see Access control lists for additional information about ACLs.

Working with credentials

We can use the Web Administration Tool to perform the following tasks:

Adding credentials

Expand the Replication management category in the navigation area of the Web Administration Tool and click Manage credentials
Select the location that you want to use to store the credentials from the list of subtrees. The Web Administration Tool allows you to define credentials in three locations.

cn=replication,cn=localhost, which keeps the credentials only on the current server.

In most replication cases, locating credentials in cn=replication,cn=localhost is preferred because it provides greater security than replicated credentials located on the subtree. However, there are certain situations in which credentials located on cn=replication,cn=localhost are not available.
If you are trying to add a replica under a server, for example serverA and you are connected to a different server with the Web Administration Tool, serverB, the Select credentials field does not display the option cn=replication,cn=localhost. This is because we cannot read the information or update any information under cn=localhost of the serverA when you are connected to serverB.
The cn=replication,cn=localhost is only available when the server under which you are trying to add a replica is the same server that you are connected to with the Web Administration Tool.
cn=replication,cn=IBMpolicies, which is available even when the server under which you are trying to add a replica is not the same server that you are connected to with the Web Administration Tool. Credentials placed under this location are replicate to the servers.

The location cn=replication,cn=IBMpolicies is only available, if the IBMpolicies support OID, 1.3.18.0.2.32.18, is present under the ibm-supportedcapabilities of the root DSE.
Within the replicated subtree, in which case the credentials are replicated with the rest of the subtree. Credentials placed in the replicated subtree are created beneath the ibm-replicagroup=default entry for that subtree.

If no subtrees are displayed, go to Adding a subtree for instructions about creating the subtree that you want to replicate.

Click Add.
Enter the name for the credentials you are creating, for example, mycreds, cn= is prefilled in the field for you.
Select the type of authentication method you want to use and click Next.
If you selected simple bind authentication:

Enter the DN that the server uses to bind to the replica, for example, cn=any
Enter the password uses when it binds to the replica, for example, secret.
Enter the password again to confirm that there are no typographical errors.
If you want, enter a brief description of the credentials.
Click Finish.

You might want to record the credential's bind DN and password for future reference. You will need this password when you create the replica agreement.
If you selected Kerberos authentication:
Enter your Kerberos bind DN.
Enter a keyfile (the fully-qualified file specification of the key database file). Leave this field blank to use the server's LDAP service name.

The server's LDAP service principal name is service/hostname@realm. This comes from standard Kerberos conventions. The service is always ldap. For example, for host myserver.mytown.mycompany.com in Kerberos realm "MYTOWN.MYCOMPANY.COM", the server's principal name is:
ldap/myserver.mytown.mycompany.com@MYTOWN.MYCOMPANY.COM
The server gets the host name from the system TCP/IP configuration; the realm name comes from the realm name configured on the Kerberos tab on the Security properties panel.
If you want, enter a brief description of the credentials. No other information is necessary. See Setting Kerberos for additional information.
Click Finish.
The Kerberos panel takes an optional bind DN of the form ibm-kn=xxx@realm and an optional key tab file name (referred to as keyfile on the Web Administration Tool). If a bind DN is specified, the server uses the specified principal name to authenticate to the consumer server. Otherwise, the server's Kerberos service name (ldap/host-name@realm) is used.
If a key tab file is used, the server uses the key tab file to obtain the credentials for the specified principal name. If no key tab file is specified, the server uses the key tab file specified in the server's Kerberos configuration.
By default, the supplier uses its own service principal to bind with the consumer. For example, if the supplier is named master.our.org.com and the realm is SOME.REALM, the DN is ibm-Kn=ldap/master.our.org.com@SOME.REALM. The realm value is case insensitive.

If more than one supplier uses Kerberos authentication to replicate to the same consumer, configure all suppliers to use the same Kerberos principal rather than letting them default to using their Kerberos service name.
If you selected SSL with certificate authentication you do not need to provide any additional information, if you are using the server's certificate. If you choose to use a certificate other than the server's:

Enter the key file name.
Enter the key file password.
Reenter the key file password to confirm it.
Enter the key label.
If you want, enter a brief description.
Select the Enable PKCS#11 interface support check box to enable PKCS#11 support of crypto hardware.
Click Finish.
See Secure Sockets Layer for additional information.
If an external credential object is selected while you are adding credentials on consumers during an Add master operation using the Web Administration Tool, then the following settings need to be configured on the machine where the Web server is running:
The JAVA_HOME\jre\lib\ext\ has the following jar files:

ibmjceprovider.jar
ibmpkcs.jar
ibmjcefw.jar
local_policy.jar
US_export_policy.jar
ibmjlog.jar
gsk7cls.jar
The JAVA_HOME\jre\lib\security\java.security file must have the following two lines to register CMS provider amd JCE provider:
security.provider.2=com.ibm.spi.IBMCMSProvider  	
security.provider.3=com.ibm.crypto.provider.IBMJCE 
Gskit must be installed and gsk7\lib must be in the system path.
For the Web Administration Tool to read the keyfile containing credentials information that the master server uses to connect to the replica, and create credentials on replica, the keyfile must be present in C:\temp for Windows® platforms, and in /tmp for UNIX®.
Modifying credentials

Expand the Replication management category in the navigation area of the Web Administration Tool and click Manage credentials.

Select a subtree and click Show credentials.
In the credentials box for the selected subtree, select the credentials you want to modify and click Edit.

If the credential is simple authentication. In the Edit credential panel we can modify:

The Bind DN
The Password
The Description of the credential

If the credential is kerberos authentication. In the Edit credential panel we can modify:

The Bind DN
The Key file
The Description of the credential

If the credential is SSL with certificate authentication.

In the Edit credential panel we can modify:

The Key file
The Password
The Key label
The Description of the credential

Select the Enable PKCS#11 interface support check box to enable PKCS#11 support of crypto hardware.

When you are finished, click OK.

Removing credentials

Expand the Replication management category in the navigation area of the Web Administration Tool and click Manage credentials

Select a subtree and click Show credentials.
In the credentials box for the selected subtree, select the credentials you want to remove and click Delete.
A message confirming that you want to delete the credential object is displayed. Click OK to remove the credential or click Cancel to return to the Manage credentials panel without saving any changes.

Managing credential ACLs

Use this information if you want to enable others to work with credentials. You need to assign ACLs to enable this function.
Expand the Replication management category in the navigation area of the Web Administration Tool and click Manage credentials

Select a subtree and click Show credentials.
In the credentials box for the selected subtree, select the credentials you want to modify the ALCs for and click Edit ACL.
See Working with ACLs for information on editing ACLs.

Managing topologies

Topologies are specific to the replicated subtrees.

Viewing the topology

The server must be running to perform this task.
Expand the Replication management category in the navigation area and click Manage topology.

Select the subtree that you want to view and click Show topology.

The topology is displayed in the Replication topology list. Expand the topologies. From this list we can:

Add a master
Add a replica
Manage gateway servers
Edit an agreement
View the replication schedule
View replication errors
Move a server to a different role in the topology
Delete a server.

Adding a peer-master or gateway server

The server must be running to perform this task.
Expand the Replication management category in the navigation area and click Manage topology.

Select the subtree that you want to replicate and click Show topology.
Click the box next to the Replication Topology to expand the list of supplier servers, if you want to view the existing topology.
Click Add master.

On the Server tab of the Add master window:

Select Server is a gateway to make this server a Gateway server or select Supplier gateway and then select a server from the drop-down list to add the server as a master server.
From the Server hostname:port drop-down list, select an LDAP server for the master server.
If you want to provide another server as master server, which is not registered on the console server, select Use entry from below item from the Server hostname:port drop-down list and then enter the host name and port number for the master server in the field in the hostname:port format.

The default port is 389 for non-SSL and 636 for SSL.
Select the Enable SSL encryption check box to enable SSL communications.
Enter the server name or leave this field blank to use the host name.
Enter the server ID. If the server on which you are creating the peer-master is running, click Get server ID to automatically prefill this field.
Enter a description of the server.
You must specify the credentials that the server uses to communicate with the other master server. Click Select.

The Web Administration Tool allows you to define credentials in the following places:

cn=replication,cn=localhost, which keeps the credentials only on the server that uses them. Placing credentials in cn=replication,cn=localhost is considered more secure.
cn=replication,cn=IBMpolicies, which is available even when the server under which you are trying to add a replica is not the same server that you are connected to with the Web Administration Tool. Credentials placed under this location are replicate to the servers.

The location cn=replication,cn=IBMpolicies is only available, if the IBMpolicies support OID, 1.3.18.0.2.32.18, is present under the ibm-supportedcapabilities of the root DSE.
Within the replicated subtree, in which case the credentials are replicated with the rest of the subtree. Credentials placed in the replicated subtree are created beneath the ibm-replicagroup=default entry for that subtree.

Select the location for the credentials you want to use. Preferably this is cn=replication,cn=localhost.
If you have already created a set of credentials, click Show credentials.
Expand the list of credentials and select the one you want to use.
Click OK.
If you do not have preexisting credentials, click Add to create the credentials. See Adding credentials for additional information on agreement credentials.

On the Additional tab:

Specify a replication schedule from the drop-down list or click Add to create one. See Creating replication schedules
From the list of supplier capabilities, we can deselect any capabilities that you do not want replicated to the consumer.
If your network has a mix of servers at different releases, capabilities are available on later releases that are not available on earlier releases. Some capabilities, like filter ACLs (Filtered ACLs) and password policy (Setting password policy), make use of operational attributes that are replicated with other changes. In most cases, if these features are used, you want all servers to support them. If all of the servers do not support the capability, you do not want to use it. For example, you would not want different ACLs in effect on each server. However, there might be cases where you might want to use a capability on the servers that support it, and not have changes related to the capability replicated to servers that do not support the capability. In such cases, we can use the capabilities list to mark certain capabilities to not be replicated.
Check the Add credential information on consumer check box, if you want to enable dynamic updates of the supplier credentials. This selection automatically updates the supplier information in the configuration file of the server you are creating. This enables the topology information to be replicated to the server.

Type the Administration DN for this, the consumer, server. For example cn=root.

If the administrator DN which was created during the server configuration process was cn=root, then enter the full administrator DN. Do not just use root.
Type the Administration password for this, the consumer, server. For example secret.

Click OK.
Supplier and consumer agreements are listed between new master server and any existing servers. Uncheck any agreements that you do not want to be created. This is especially important if you are creating a gateway server.
Click Continue.
Messages might be displayed noting that additional actions must be taken. Perform or take note of the appropriate actions. When you are finished, click OK.
Add the appropriate credentials.

In some cases the Select credentials panel will pop up asking for a credential that is located in a place other than cn=replication,cn=localhost. In such situations provide a credential object that is located in a place other than cn=replication,cn=localhost. Select the credentials the subtree is going to use from the existing sets of credentials or create new credentials. See Adding credentials.
Check the Add credential information on consumer check box, if you want to enable dynamic updates of the supplier credentials. This selection automatically updates the supplier information in the configuration file of the server you are creating. This enables the topology information to be replicated to the server.

Type the Administration DN for this, the consumer, server. For example cn=root.

If the administrator DN which was created during the server configuration process was cn=root, then enter the full administrator DN. Do not just use root.
Type the Administration password for this, the consumer, server. For example secret.

Click OK to create the peer-master.
Messages might be displayed noting that additional actions must be taken. Perform or take note of the appropriate actions. When you are finished, click OK. See Starting replication.

Note:

If an external credential object is selected while you are adding credentials on consumers during an Add master operation using the Web Administration Tool, then the following settings need to be configured on the machine where the IBM WebSphere Application Server is running:
The WAS_HOME\java\jre\lib\ext\ has the following jar files:

ibmjceprovider.jar
ibmpkcs.jar
ibmjcefw.jar
local_policy.jar
US_export_policy.jar
ibmjlog.jar
gsk7cls.jar
The WAS_HOME\java\jre\lib\security\java.security file must have the following two lines to register CMS provider amd JCE provider:
security.provider.2=com.ibm.spi.IBMCMSProvider  	
security.provider.3=com.ibm.crypto.provider.IBMJCE 
Restart IBM WebSphere Application Server.
Gskit must be installed and gsk7\lib must be in the system path.
For the Web Administration Tool to read the keyfile containing credentials information that the master server uses to connect to the replica, and create credentials on replica, the keyfile must be present in C:\temp for Windows platforms, and in /tmp for UNIX.
Adding a replica server

The server must be running to perform this task.
Expand the Replication management category in the navigation area and click Manage topology.

Select the subtree that you want to replicate and click Show topology.
Click the box next to the existing servers to expand the list of supplier servers.
Select the supplier server and click Add replica.

On the Server tab of the Add replica window:

From the Server hostname:port drop-down list, select an LDAP server for the replica server.
If you want to provide another server as replica server, which is not registered on the console server, select Use entry from below item from the Server hostname:port drop-down list and then enter the host name and port number for the replica server in the field in the hostname:port format. The default port is 389 for non-SSL and 636 for SSL.
Select whether to enable SSL communications.
Enter the replica name or leave this field blank to use the host name.
Enter the replica ID. If the server on which you are creating the replica is running, click Get replica ID to automatically prefill this field.
Enter a description of the replica server.
You must specify the credentials that the replica uses to communicate with the master. Click Select.

The Web Administration Tool allows you to define credentials in the following places:

cn=replication,cn=localhost, which keeps the credentials only on the server that uses them. Placing credentials in cn=replication,cn=localhost is considered more secure.
cn=replication,cn=IBMpolicies, which is available even when the server under which you are trying to add a replica is not the same server that you are connected to with the Web Administration Tool. Credentials placed under this location are replicate to the servers.

The location cn=replication,cn=IBMpolicies is only available, if the IBMpolicies support OID, 1.3.18.0.2.32.18, is present under the ibm-supportedcapabilities of the root DSE.
Within the replicated subtree, in which case the credentials are replicated with the rest of the subtree. Credentials placed in the replicated subtree are created beneath the ibm-replicagroup=default entry for that subtree.

Select the location for the credentials you want to use. Preferably this is cn=replication,cn=localhost.
If you have already created a set of credentials, click Show credentials.
Expand the list of credentials and select the one you want to use.
Click OK.
If you do not have preexisting credentials, click Add to create the credentials. See Adding credentials for additional information on agreement credentials.

On the Additional tab:

Specify a replication schedule from the drop-down list or click Add to create one. See Creating replication schedules
From the list of supplier capabilities, we can deselect any capabilities that you do not want replicated to the consumer.
If your network has a mix of servers at different releases, capabilities are available on later releases that are not available on earlier releases. Some capabilities, like filter ACLs (Filtered ACLs) and password policy (Setting password policy), make use of operational attributes that are replicated with other changes. In most cases, if these features are used, you want all servers to support them. If all of the servers do not support the capability, you do not want to use it. For example, you would not want different ACLs in effect on each server. However, there might be cases where you might want to use a capability on the servers that support it, and not have changes related to the capability replicated to servers that do not support the capability. In such cases, we can use the capabilities list to mark certain capabilities to not be replicated.
Select the either Single threaded or Multi-threaded for the method of replication. If you specify Multi-threaded, also specify the number (between 2 and 32) of connections to use for replication. The default number of connections is 2.
Check the Add credential information on consumer check box, if you want to enable dynamic updates of the supplier credentials. This selection automatically updates the supplier information in the configuration file of the server you are creating. This enables the topology information to be replicated to the server.

Type the Administration DN for this, the consumer, server. For example cn=root.

If the administrator DN which was created during the server configuration process was cn=root, then enter the full administrator DN. Do not just use root.
Type the Administration password for this, the consumer, server. For example secret.

Click OK to create the replica.
A message is displayed noting that additional actions must be taken. Click OK.

Notes:

If you are adding more servers as additional replicas or are creating a complex topology, do not proceed with Copying data to the replica or Adding the supplier information to a replica until you have finished defining the topology on the master server. If you create the masterfile.ldif after you have completed the topology, it contains the directory entries of the master server and a complete copy of the topology agreements. When you load this file on each of the servers, each server then has the same information.
If an external credential object is selected while you are adding credentials on consumers during an Add replica operation using the Web Administration Tool, see ***.

Removing a server

Expand the Replication management category in the navigation area and click Manage topology.

Select the subtree that you want and click Show topology.
Select the server that you want to remove from the topology.
Click Delete.
When asked to confirm the deletion, click OK.

When removing a replica from your topology, remember to delete the supplier credential entry from the consumer if no master server will be using this credential entry again. A master server should not have any agreements under it. See Removing credentials.

Moving or promoting a server

Expand the Replication management category in the navigation area and click Manage topology.

Select the subtree that you want and click Show topology.
Select the server that you want and click Move.
Select the server that you want to move the replica to, or select Replication topology to promote the replica to a master. Click Move.
The Create additional supplier agreements is displayed. Deselect the supplier agreements that are not appropriate for the role of the server. You are prompted to select the credentials and consumer information for each new supplier credential being created. Existing supplier agreements from the other servers to the newly promoted server are still in effect and do not need to be recreated.

In some cases the Select credentials panel will pop up asking for a credential which is located in a place other than cn=replication,cn=localhost. In such situations provide a credential object which is located in a place other than cn=replication,cn=localhost. Select the credentials the subtree is going to use form the existing sets of credentials or create new credentials. The credential entry should exist or be created on the other masters. See Adding credentials.
Click OK.

The change in the topology tree reflects the moving of the server.
See Setting up a complex topology with peer replication for more information.

Demoting a master

To change the role of a server from a master to a replica, expand the Replication management category in the navigation area and click Manage topology.

Connect the Web Administration Tool to the server that you want to demote.
Click Manage topology.
Select the subtree and click Show topology.
Select the server you are demoting and click Move.
Select the server under which you are going to place the demoted server and click Move.
Delete all the agreements for the server you want to demote. Click Yes.

Managing gateway servers

A gateway server must be an IBM Tivoli Directory Server version 6.0 or above, or version 5.2 server, or an IBM Directory Server version 5.1 server with a fix pack that supports gateway replication.
We can designate whether a master server is to have the role of a gateway server in the replication site.
To designate a master to be a gateway server, expand the Replication management category in the navigation area and click Manage topology.

Select the subtree that you want to view and click Show topology.
Click Manage gateway servers.
Select the server from the Master servers box that you want to make a gateway server.
Click Make gateway. The server is moved from the Master servers box to the Gateway servers box.
Click OK.

To remove the role of a gateway server from a master server.

Click Manage gateway servers.
Select the server from the Gateway servers box that you want to make a master server.
Click Make master. The server is moved from the Gateway servers box to the Master servers box
Click OK.

Remember that there can be only one gateway server per replication site. When you create additional gateway servers in your topology, the Web Administration Tool treats the gateway as a peer server and creates agreements to all the servers in the topology. Ensure that you deselect any agreements that are not with the other gateway servers or not within the gateways own replication site.
See Setting up a gateway topology for more information.

Editing an agreement

We can change the following information for the replica:
On the Server tab we can only change

Hostname and port

The port is editable only for switching from non-SSL-enabled to SSL-enabled, and back.
Enable SSL
Description
Credentials - see Adding credentials.

On the Additional tab we can change:

Replication schedules - see Creating replication schedules.
Change the capabilities replicated to the consumer replica. From the list of supplier capabilities, we can deselect any capabilities that you do not want replicated to the consumer.
Replication method.
Consumer information.
When you are finished, click OK.

Viewing the replication schedule

Expand the Replication management category in the navigation area of the Web Administration Tool and click Manage topology

Select the subtree that you want to view and click Show topology.
Select the master or gateway server that you want to view.
Click View schedule.

If a replication schedule exists between the selected server and its consumers, they are displayed. We can modify or delete these schedules. If no schedules exist and you want to create one, use the Manage schedules function from the Web Administration Tool navigation area. See Creating replication schedules for information about managing schedules.

Viewing server information

Expand the Replication management category in the navigation area of the Web Administration Tool and click Manage topology

Select the subtree that you want to view and click Show topology.
Select the server that you want to view.
Click View server to display the view server panel.

The View Server panel displays the following information:

Server name

This field displays the name of the server on which the directory instance is running. This information is displayed in the hostname:port format.

Host Name

This field displays the host name of the machine on which the directory server instance is running.

Port

This field displays the nonsecure port on which the server is listening.

Server ID

This field displays the unique ID assigned to the server at the first startup of the server. This ID is used in replication topology to determine a server's role.

Role

This field displays the configured role of the server in a replication topology.

Configuration mode

This field identifies whether the server is running in configuration mode. If TRUE, the server is in configuration mode. If FALSE, the server is not in configuration mode.

Instance name

This field displays the name of the directory server instance running on the server.

Security

This field displays the secure SSL port the server is listening on.

The server name, ID and role and consumer information are displayed.

Viewing server errors

We can view replication updates that were not completed because of errors that occurred during replication.
Expand the Replication management category in the navigation area of the Web Administration Tool and click Manage topology

Select the subtree that you want to view and click Show topology.
Select the server (replica agreement) that you want to view.
Click View errors.

The subtree, supplier and consumer information is displayed. Replication errors are displayed in a table that supplies the following information:

Change ID

The ID assigned to the failed update.

Last update time

Indicates the time when the last attempt to replicate the entry was made.

Number of attempts

Indicates the number of attempts made to replicate the entry.

Result code

Result code obtained by the last attempt to replicate the entry.

The order this information is displayed in is defined by failure ID. Failure IDs are assigned as they happen. The failure ID is not the same as the change ID. The change ID remains constant, but the failure ID is changed on every failed attempt.
We can select an error and perform the following actions:

Click Show details to view more information about the error.
Click Retry to attempt the update again.
Click Remove to remove the error from the Replication error management table.

We can also

Click Retry all to attempt all the update again.
Click Remove all to remove all the errors from the Replication error management table.

See Managing queues for additional information.

Adding the supplier information to a replica

If you did not select to add the credential information to the consumer or if a problem occurred in adding the credential information to the replica, we need to change the replica's configuration to identify who is authorized to replicate changes to it, and add a referral to a master.
On the machine where you are creating the replica:

Expand Replication management in the navigation area and click Manage replication properties.
Click Add.
Select a supplier from the Replicated subtree drop-down menu or enter the name of the replicated subtree for which you want to configure supplier credentials. If you are editing supplier credentials, this field is not editable.
Enter the replication bindDN. In this example, cn=any.

We can use either of these two options, depending on your situation.

Set the replication bind DN (and password) and a default referral for all subtrees replicated to a server using the 'default credentials and referral'. This might be used when all subtrees are replicated from the same supplier.
Set the replication bind DN and password independently for each replicated subtree by adding supplier information for each subtree. This might be used when each subtree has a different supplier (that is, a different master server for each subtree).

Depending on the type of credential, enter and confirm the credential password. (You previously recorded this for future use.)

Simple Bind - Specify the DN and password
Kerberos - If the credentials on the supplier do not identify the principal and password, that is, the server's own service principal is to be used, then the bind DN is ibm-kn=ldap/<yourservername@yourrealm>. If the credentials has a principal name such as <myprincipal@myrealm>, use that as the DN. In either case a password in not needed.
SSL w/ EXTERNAL bind - Specify the subject DN for the certificate and no password
See Adding credentials.
Click OK.
You must restart the replica for the changes to take effect.

See Modifying replication properties for additional information.
The replica is in a suspended state and no replication is occurring. After you have finished setting up your replication topology, click Manage queues, select the replica and click Suspend/resume to start replication. See Managing queues for more detailed information. The replica now receives updates from the master.

Modifying replication properties

Expand the Replication management category in the navigation area and click Manage replication properties.
On this panel we can:

Change the maximum number of pending changes to return from replication status queries. The default is 200.
Set the maximum number of replication errors that a server allows while replicating updates. To do this, click Error and enter a numeric value in the field. Otherwise, to set the maximum number of replication errors a server allows while replicating updates to a consumer as unlimited, click Unlimited.

Logging is enabled if a value greater than zero is specified.
Change the size in bytes of the replication context cache. The default is 100 000 bytes.
Set the replication conflict maximum entry size in bytes . If the total size of an entry in bytes exceeds the value in this field, the entry is not sent again by the supplier to resolve a replication conflict on the consumer. The default is 0 for unlimited.
Select a value from the Restrict access to replication topology combo box to specify whether the access to replication topology is restricted or not.
Add, edit, or delete supplier information.

Adding supplier information

Click Add.
Select a supplier from the drop-down menu or enter the name of the replicated subtree that you want to add as a supplier .
Enter the replication bind DN for the credentials.

You can use either of these two options, depending on your situation.

Set the replication bind DN (and password) and a default referral for all subtrees replicated to a server using the 'default credentials and referral'. This might be used when all subtrees are replicated from the same supplier.
Set the replication bind DN and password independently for each replicated subtree by adding supplier information for each subtree. This might be used when each subtree has a different supplier (that is, a different master server for each subtree).

Depending on the type of credential, enter and confirm the credential password. (You previously recorded this for future use.)

Simple Bind - specify the DN and password
Kerberos - specify a pseudo DN of the form 'ibm-kn=LDAP-service-name@realm' without a password
SSL w/ EXTERNAL bind - specify the subject DN for the certificate and no password
See Adding credentials.
Click OK.

The subtree of the supplier is added to the Supplier information list.

Editing supplier information

Select the supplier subtree that you want to edit.
Click Edit.
If you are editing Default credentials and referral, which is used to create the cn=Master Server entry under cn=configuration, enter the URL of the server from which the client wants to receive replica updates in the Default supplier's LDAP URL field. This needs to be a valid LDAP URL (ldap://). Otherwise, skip to step 4.
To specify whether the server supports replication conflict resolution, select a value from the Replication conflict resolution combo box.
Enter the replication bind DN for the new credentials you want to use.

Set the replication bind DN and password independently for each replicated subtree by adding supplier information for each subtree. This might be used when each subtree has a different supplier (that is, a different master server for each subtree).
Enter and confirm the credential password.
Click OK.

Removing supplier information

Select the supplier subtree that you want to remove.
Click Delete.
When asked to confirm the deletion, click OK.

The subtree is removed from the Supplier information list.

Creating replication schedules

We can optionally define replication schedules to schedule replication for particular times, or to not replicate during certain times. If you do not use a schedule, the server schedules replication whenever a change is made. This is equivalent to specifying a schedule with immediate replication starting at 12:00 AM on all days.
Expand the Replication management category in the navigation area and click Manage schedules.
On the Weekly schedule tab, select the subtree for which you want to create the schedule and click Show schedules. If any schedules exist, they are displayed in the Weekly schedules box. To create or add a new schedule:

Click Add.
Enter a name for the schedule. For example schedule1.
For each day, Sunday through Saturday, the daily schedule is specified as None. This means that no replication update events are scheduled. The last replication event, if any, is still in effect. Because this is a new replica, there are no prior replication events, therefore, the schedule defaults to immediate replication.
We can select a day and click Add a daily schedule to create a daily replication schedule for it. If you create a daily schedule it becomes the default schedule for each day of the week. We can:

Keep the daily schedule as the default for each day or select a specific day and change the schedule back to none. Remember that the last replication event that occurred is still in effect for a day that has no replication events scheduled.
Modify the daily schedule by selecting a day and clicking Edit a daily schedule. Remember changes to a daily schedule affect all days using that schedule, not just the day you selected.
Create a different daily schedule by selecting a day and clicking Add a daily schedule. After you have created this schedule it is added to the Daily schedule drop-down menu. You must select this schedule for each day that you want the schedule to be used.
See Creating a daily schedule for more information on setting up daily schedules.
When you are finished, click OK.

Creating a daily schedule

Expand the Replication management category in the navigation area and click Manage schedules.
On the Daily schedule tab, select the subtree for which you want to create the schedule and click Show schedules. If any schedules exist, they are displayed in the Daily schedules box. To create or add a new schedule:

Click Add.
Enter a name for the schedule. For example monday1.
Select the time zone setting, either UTC or local.
Select a replication type from the drop-down menu:

Immediate

Performs any pending entry updates since the last replication event and then updates entries continuously until the next scheduled update event is reached.

Once

Performs all pending updates prior to the starting time. Any updates made after the start time wait until the next scheduled replication event.

Select a start time for the replication event.
Click Add. The replication event type and time are displayed.
Add or remove events to complete your schedule. The list of events is refreshed in chronological order.
When you are finished, click OK.

For example:

Replication type Start time

Immediate 12:00 AM
Once 10:00 AM
Once 2:00 PM
Immediate 4:00 PM
Once 8:00 PM

In this schedule, the first replication event occurs at midnight and updates any pending changes prior to that time. Replication updates continue to be made as they occur until 10:00 AM. Updates made between 10:00 AM and 2:00 PM wait until 2:00 PM to be replicated. Any updates made between 2:00 PM and 4:00 PM wait the replication event scheduled at 4:00 PM, afterwards replication updates continue until the next scheduled replication event at 8:00 PM. Any updates made after 8:00 PM wait until the next scheduled replication event.

If replication events are scheduled too closely together, a replication event might be missed if the updates from the previous event are still in progress when the next event is scheduled.

Managing queues

This task allows you to monitor status of replication for each replication agreement (queue) used by this server.
Expand the Replication management category in the navigation area and click Manage queues.
The Manage queues table contains the following information in columns:

Select

Selects the replica on which you want to perform an action.

Replica

Specifies the name of the replica in the replication queue.

Subtree

Specifies the subtree under which the replica is located.

Last result

Indicates the last return code/status (success/failed)

State

Indicates the state of replication with the consumer:

Active

Actively sending updates to consumer.

Ready

In immediate replication mode, ready to send updates as they occur.

Waiting

Waiting for next scheduled replication time.

Binding

In the process of binding to the consumer.

Connecting

In the process of connecting to the consumer.

On Hold

This replication agreement has been suspended or "held".

Error Log Full

For a server configured to use multiple connections, replication is suspended for this agreement. The receiver threads continue polling for status from any updates that have been sent, but no more updates are replicated.

Retrying

If the server is configured to use a single connection, replication attempts to send the same update after waiting for 60 seconds and keeps trying until replication succeeds or the administrator skips the update.

Queue size

Specifies the number of pending changes returned from replication status queries.

Select the replica for which you want to manage the queue.
Depending on the status of the replica, we can click Suspend/resume to stop or start replication.
Click Force replication to replicate all the pending changes regardless of when the next replication is scheduled.
Click Queue details, for more complete information about the replica's queue. We can also manage the queue from this selection.
Click Refresh to update the queues, obtain the current status, and clear server messages.

Queue details

If you clicked Queue details, three tabs are displayed:

Status
Last attempted details
Pending changes

The Status tab displays the replica name, its subtree, its replication status, and a record of replication times. From this panel we can suspend or resume replication by clicking Suspend or Resume. The non-editable status field changes to reflect the change in status. Click Refresh to update the queue information.
The Last attempted details tab gives the following information about the last update attempt on the selected replica:

Replica - The name of the replica in the replication queue.
Subtree - The subtree under which the replica is located.
Entry DN - The DN of the updated entry.
Last replicated at - The last time the entry was replicated.
Update type - The type of update, for example, add, delete or modify.
Last result - The error code assigned to the error.
Failed LDIF - The update in LDIF format.
Additional error messages - Any additional information about the error.

If an entry is not able to be loaded press Skip blocking entry to continue replication with the next pending entry. Click Refresh to update the queue information.
The Pending changes tab shows all the pending changes to the replica. The number of pending changes displayed depends on the value you entered on the Manage replication properties panel. The default is 200.
If replication is blocked we can delete all the pending changes by clicking Skip all. Click Refresh to update the list of pending changes to reflect any new update or updates that have been processed.

If you choose to skip blocking changes, ensure that the consumer server is eventually updated. See the ldapdiff command information in the IBM Tivoli Directory Server version 6.1 Command Reference for more information.

Command line tasks for managing replication

Specifying a supplier DN and password for a subtree

We can specify a supplier DN and PW for a particular subtree. To do this the following information is needed on all consumers:
Start the consumer servers.
You must configure replica1 to be a replica server. Do the following to add an entry to the ibmslapd.conf file on replica1:
idsldapmodify -D <admin_dn> -w <admin_pw> -I <instance_name> -i <LDIF_file>
where <LDIF_file> contains the following:
dn: cn=Master Server, cn=configuration
cn: Master Server
ibm-slapdMasterDN: cn=master
ibm-slapdMasterPW: <masterserverpassword>
ibm-slapdMasterReferral: ldap://<masterhostname:masterport>
objectclass: ibm-slapdReplication

dn: cn=Supplier s1, cn=configuration
cn: Supplier s1
ibm-slapdMasterDN: cn=s1
ibm-slapdMasterPW: s1
ibm-slapdReplicaSubtree: ou=Test, o=sample
objectclass: ibm-slapdSupplier
Save the ibmslapd.conf file.
Restart replica1.
Viewing replication configuration information

A great deal of information related to replication activity is available using searches. To see the replication topology information related to a particular replicated subtree, we can do a subtree search with the base set to the DN of the subtree and the filter set as (objectclass=ibm-repl*) to find the subentry that is the base of the topology information. If this replication context was created through the web admin interface, the name of the entry will be ibm-replicaGroup=default.
idsldapsearch -D <adminDN> -w <adminPW> -p <port> -b <suffixentryDN> 
	objectclass=ibm-repl*
The objects returned will include the replica group itself, plus the following:

An object with objectclass=ibm-replicaSubentry for each server that replicates data within this context. Replica subentries contain a server ID attribute and an indication of the role the server plays (ibm-replicationServerIsMaster).
For each replica subentry, there is a replication agreement object for each consumer server that receives replication updates from the server described by the replica subentry. Each replication agreement contains the following information:

ibm-replicaConsumerId: The server ID of the consumer server.
ibm-replicaURL: The LDAP URL of the consumer server.
ibm-replicaCredentialsDN: The DN of the entry containing the credentials used to bind to the consumer.
Agreements may also contain the following:

ibm-replicaScheduleDN: The DN of a schedule entry that determines when replication updates are sent to this consumer. If no schedule is specified, replication defaults to "immediate" mode.
ibm-replicationOnHold: A boolean indicating that replication to this consumer is suspended (or not).
ibm-replicationExcludedCapability: The values of this attribute list OIDs of features that the consumer does not support. Operations related to these capabilities are then excluded from the updates sent to this consumer.
ibm-replicationMethod: Single threaded or multi-threaded.
ibm-replicationConsumerConnections: For a replication agreement using the single-threaded replication method, the number of consumer connections is always one, the attribute value is ignored. For an agreement using multi-threaded replication, the number of connections can be configured from 1 to 32. If no value is specified on the agreement, the number of consumer connections is set to one.

Monitoring replication status

In addition, there are many operational attributes that provide replication status information when explicitly requested on a search. One of these attributes is associated with the entry that is the base of the replicated subtree, that is, the entry that the ibm-replicationContext objectclass was added to. If you do a base search of that entry, and request that the ibm-replicationIsQuiesced attribute is returned. This attribute is a boolean that indicates if the subtree has been quiesced. If the subtree is quiesced, no client updates are allowed (only updates from replication suppliers are accepted). There is an extended operation that can be used to quiesce a subtree, see the ldapexop command information in the IBM Tivoli Directory Server version 6.1 Command Reference for more information.
The remainder of the status-related operational attributes are all associated with a replication agreement object. These attributes are only returned when explicitly requested on the search. The attributes available are:
ibm-replicationLastActivationTime: The time that the last replication session started between this supplier and consumer.
ibm-replicationLastFinishTime: The time that the last replication session finished between this supplier and consumer.
ibm-replicationLastChangeId: The change ID of the last update sent to this consumer.
ibm-replicationState: The current state of replication with this consumer. Possible values are:

Active

Actively sending updates to consumer.

Ready

In immediate replication mode, ready to send updates as they occur.

Retrying

If the server is configured to use a single connection, replication attempts to send the same update after waiting for 60 seconds and keeps trying until replication succeeds or the administrator skips the update.

Waiting

Waiting for next scheduled replication time.

Binding

In the process of binding to the consumer.

Connecting

In the process of connecting to the consumer.

On Hold

This replication agreement has been suspended or "held".

Error Log Full

For a server configured to use multiple connections, replication is suspended for this agreement. The receiver threads continue polling for status from any updates that have been sent, but no more updates are replicated.

error xxxx

An error has occurred where xxxx is the id of the message that describes the error.
ibm-replicationLastResult The results of the last attempted update to this consumer, in the form:
<time stamp> <change id> <result code> <operation> <entry DN>
This information is available for single threaded replication only.
ibm-replicationLastResultAdditional: Any additional error information returned from the consumer for the last update.

This information is available for single threaded replication only.
ibm-replicationPendingChangeCount: The number of updates queued to be replicated to this consumer.
ibm-replicationPendingChanges: Each value of this attribute gives information about one of the pending changes in the form:
<change id> <operation> <entry DN>
Requesting this attribute might return many values. Check the change count before requesting this attribute.
ibm-replicationChangeLDIF: Gives the full details of the last failing update in LDIF.

This information is available for single threaded replication only.
ibm-replicationFailedChanges: Similar to ibm-replicationPendingChanges in that it lists the IDs, DNs, update types, result codes, timestamps, numbers of attempts for failures logged for a specified replication agreement. The number of failures displayed are less than or equal to ibm-slapdMaxPendingChangesDisplayed.
ibm-replicationFailedChangeCount: Similar to ibmreplicationPendingChangeCount in that it returns a count of the failures logged for a specified replication agreement.
ibm-replicationPerformance: Information about multi-threaded replication.
Only the following are allowed to view ibm-replicationPendingChanges, ibm-replicationPendingChangesCount, ibm-replicationFailedChanges and ibm-replicationChangeLDIF:

The administrator
Members of the administrative group
Members of the global administrative group
Any user explicitly given update access to the replication topology entries through ACLs

Creating gateway servers

Creating a new Gateway server

After creating a Gateway server, create new replication agreements to reflect the new topology. See theReplication agreements for more information.
Create a new replica context, replica group and replica subentry in the DIT. The replica subentry must contain the ibm-replicaSubentry object class and ibm-replicaGateway auxiliary object class. The ibm-replicaSubentry object class and ibm-replicaGateway auxiliary object class are bold in the following example:
dn: o=sample
objectclass: top
objectclass: organization
objectclass: ibm-replicationContext

dn: ibm-replicagroup=default,o=sandbox
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicagrpoup: default

dn: ibm-replicaServerId=<serverid>,ibm-replicagroup=default,o=sandbox
objectclass: top
objectclass: ibm-replicaSubentry
objectclass: ibm-replicaGateway
ibm-replicaServerId:<serverid>
ibm-replicationServerIsMaster: TRUE
cn: <servername>
Where <servername> is the name of the server, and where <serverid> is a 37 character string assigned the first time a server is started. The server ID can be found by typing the following at a command prompt:
idsldapsearch -p <port> -b "" -s base objectclass=*
Converting an existing peer server to a Gateway server

Before converting a peer server to a Gateway server, make sure the subtree is quiesced and there are no pending changes. The following example shows a replica subentry that is NOT configured as a Gateway server.
dn: ibm-replicaServerId=<serverid>,ibm-replicagroup=default,o=sandbox
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <serverid>
ibm-replicationServerIsMaster: TRUE
cn: <servername>
To convert this peer to a gateway, add the ibm-replicaGateway auxiliary object class to the desired replica subentry in the DIT. The ibm-replicaGateway auxiliary object class is bold in the following example.
dn: ibm-replicaServerId=<serverid>,ibm-replicagroup=default,o=sandbox
	changetype: modify
	add: objectclass
	objectclass: ibm-replicaGateway
Where <servername> is the name of the server, and where <serverid> is a 37 character string assigned the first time a server is started. The server ID can be found by typing the following at a command prompt:
idsldapsearch -p <port> -b "" -s base objectclass=*
For information about removing an auxiliary object class, see Deleting an auxiliary object class.

[ Top of Page | Previous Page | Next Page | Contents | Index ]

Master/peer	The master/peer server contains the master directory information from where updates are propagated to the replicas. All changes are made and occur on the master server, and the master is responsible for propagating these changes to the replicas. There can be several servers acting as masters for directory information, with each master responsible for updating other master servers and replica servers. This is referred to as peer replication. Peer replication can improve performance and reliability. Performance is improved by providing a local server to handle updates in a widely distributed network. Reliability is improved by providing a backup master server ready to take over immediately if the primary master fails. Notes: Master servers replicate all client updates, but do not replicate updates received from other masters. Updates among peer servers can be immediate or scheduled. See Creating replication schedules for more information.
Forwarding (Cascading)	A forwarding or cascading server is a replica server that replicates all changes sent to it. This contrasts to a master/peer server in that a master/peer server only replicates changes that are made by clients connected to that server. A cascading server can relieve the replication workload from the master servers in a network which contains many widely dispersed replicas.
Gateway	Gateway replication uses Gateway servers to collect and distribute replication information effectively across a replicating network. The primary benefit of Gateway replication is the reduction of network traffic.
Replica (read-only)	An additional server that contains a copy of directory information. The replicas are copies of the master (or the subtree that it is a replica of). The replica provides a backup of the replicated subtree.

Select	Supplier	Consumer
X	server1	server9
X	server9	server1
	server2	server9
	server9	server2
	server4	server9
	server9	server4
	server9	server5
	server5	server9

Replication type	Start time
Immediate	12:00 AM
Once	10:00 AM
Once	2:00 PM
Immediate	4:00 PM
Once	8:00 PM