Managing Directory Data Replication | LDAP in the Solaris Operating Environment[c] Deploying Secure Directory Services

Sun ONE Directory Server 5.2 software provides replication management tools that allow you to monitor replication between servers. Monitoring replication activity assists in troubleshooting the causes of replication problems. All of the Directory Server replication monitoring tools can be used when the TLS/SSL transport is used for replication traffic.

The three replication management tools are:

insync
entrycmp
repldisc

The insync tool indicates the state of synchronization between a master replica and one or more consumer replicas. Being aware of the degree of synchronization is vital when it comes to managing potential conflicts.

The entrycmp tool allows you to compare the same entry on two or more servers. An entry is retrieved from the master replica, and the entry's unique ID is used to retrieve the same entry from a given consumer. All of the entries attributes and values are compared, and if everything is identical, the entries are considered to be the same.

The repldisc tool allows you to discover a replication topology. Topology discovery starts with one server and builds a graph of all known servers within the topology. The repldisc tool then prints an adjacency matrix describing the topology. This replication topology discovery tool is useful for large, complex deployments where it might be difficult to recall the global topology.

Creating Replication Agreements from Scripts

Replication can be set up and managed through the Sun ONE Directory Console. It can also be set up and managed from the command line or scripts. As with most directory configuration procedures, LDIF is used. In this section, example LDIF is presented to illustrate how tasks are performed. Once created, the LDIF is imported using the ldapmodify command.

Multi-Master Replication Example

The first step is to create a new database instance on each server if the one you want to replicate does not already exist. This is necessary because the unit of replication is a database instance.

The following example shows the LDIF used for creating a new database instance.

 dn: cn=  example  ,cn=ldbm database,cn=plugins,cn=config changetype: add objectclass: top objectclass: extensibleObject objectclass: nsBackendInstance cn:  example  nsslapd-cachesize: -1 nsslapd-cachememsize: 2097152 nsslapd-suffix:  dc=example,dc=com  dn: cn="  dc=example,dc=com  ", cn=mapping tree, cn=config changetype: add objectclass: top objectclass: extensibleobject objectclass: nsmappingtree cn:  dc=example,dc=com  nsslapd-state: backend nsslapd-backend: example nsslapd-parent-suffix:  dc=example,dc=com

The next step is to configure the new database instance for replication. This requires:

Creating a replication account.
Defining the type of replication for which the server will partake.
Specifying a location for the change log.

The following example shows setting up a database instance for multi-master replication.

 dn: cn=Replication Manager, cn=replication, cn=config changetype: modify add: userpassword userpassword:  secret12  dn: cn=replica, cn="  dc=example,dc=com  ", cn=mapping tree, cn=config changetype: add objectclass: top objectclass: nsds5replica objectclass: extensibleObject cn: replica nsds5replicaroot:  dc=example,dc=com  nsds5replicaid:  2  nsds5replicatype: 3 nsds5flags: 1 nsds5replicabinddn: cn=Replication Manager, cn=replication, cn=    config nsds5ReplicaPurgeDelay: 86400 nsds5ReplicaTombstonePurgeInterval: 1800 dn: cn=changelog5,cn=config changetype: add objectclass: top objectclass: extensibleobject nsslapd-changelogdir:  /var/mps/serverroot/slapd-hosta/cl5db

Note

The replica ID number, nsds5replicaid , needs to be unique on each system. Also, this step needs to be completed before you can initialize replicas.

The next step is to set up a replication agreement that will determine how changes are propagated. The following example sets up a replication agreement on a system called ldaphost1 with a replication partner called ldaphost2 .

Replication Agreement for ldaphost1:

 dn: cn=  agmt1  , cn=replica, cn="  dc=example,dc=com  ", cn=mapping tree,   cn=config changetype: add objectclass: top objectclass: nsDS5ReplicationAgreement cn:  agmt1  nsDS5ReplicaHost:  ldaphost2  nsDS5ReplicaPort:  389  nsDS5ReplicaBindDN: cn=Replication Manager, cn=replication, cn=   config nsDS5ReplicaCredentials:  secret12  nsDS5ReplicaBindMethod: SIMPLE nsDS5ReplicaRoot:  dc=example,dc=com  description: A sample replication agreement.

Finally, you can initiate replication with the following example on ldaphost1 .

Consumer Initiation:

 dn: cn=  agmt1  , cn=replica, cn="  dc=example,dc=com  ", cn=mapping tree,   cn=config changetype: modify replace: nsds5BeginReplicaRefresh nsds5BeginReplicaRefresh: start

Test the configuration by creating an entry on ldaphost1 and see if it propagates to ldaphost2 .

To complete the process, set up a replication on ldaphost2 .

Note

Online replication initialization as shown in these examples is best suited for directories with small amounts of data. For large directories offline initialization is recommended.

Replication Agreement for ldaphost2

 dn: cn=  agmt1  , cn=replica, cn="  dc=example,dc=com  ", cn=mapping tree, cn=config changetype: add objectclass: top objectclass: nsDS5ReplicationAgreement cn:  agmt1  nsDS5ReplicaHost:  ldaphost1  nsDS5ReplicaPort:  389  nsDS5ReplicaBindDN: cn=  Replication Manager  , cn=config nsDS5ReplicaCredentials:  secret12  nsDS5ReplicaBindMethod: SIMPLE nsDS5ReplicaRoot:  dc=example,dc=com  description: A sample replication agreement.

Replication Management

There are a number of useful functions that can be performed through the command line or scripts. These are:

Displaying replicas
Displaying replication agreements
Forcing replication from a consumer
Stopping replication
Restarting replication

Displaying Replicas

The following example shows how to display replication agreements that have already been established on a directory server.

 #  ldapsearch -L -D "cn=directory manager" -w netscape -b "cn=   mapping tree, cn=config" objectclass=nsds5replica  dn: cn=replica, cn="dc=example,dc=com", cn=mapping tree, cn=config objectClass: top objectClass: nsds5replica objectClass: extensibleObject cn: replica nsDS5ReplicaRoot: dc=example,dc=com nsDS5ReplicaId: 1 nsDS5ReplicaType: 3 nsDS5Flags: 1 nsDS5ReplicaBindDN: cn=Replication Manager, cn=config nsds5ReplicaPurgeDelay: 86400 nsds5ReplicaTombstonePurgeInterval: 1800 nsState:: AAEAAD35/CoAAAAAAAAAAAABAAA= nsDS5ReplicaName: 999c2182-1dd111b2-801ff648-85a3fef3 nsds5ReplicaChangeCount: 2 #

Removing Replicas

The following example shows a shell script for removing replicas and agreements:

 #! /bin/sh ldapsearch -h ldaphost1 -D "cn=directory manager" -w mysecret\  -b "cn=replica,cn='dc=example,dc=com',cn=mapping tree, \ cn=config" "(objectclass=*)" dn  ldapdelete -h ldaphost1\ -D "cn=directory manager" -w mysecret

Checking Replication Status

This example of the replcheck.pl tool shows the output containing the comparison of the internal attribute, called the replication update vector, that stores the replication status.

In this scenario, the sample command checks the replication status for the entire replicated tree under the dc=example,dc=com suffix, between a supplier replica hosted by master and a read-only consumer hosted by ro-hub .

 $ perl -IinstallDir replcheck.pl -w password -b "dc=example,dc= com" \ master:1389 ro-hub:1389 Connected to masterConnected to ro-hub Getting replication update vector for master replica of dc= example,dc=com => {replica 1 ldap://master.example.com:1389} 3c63e0b0000000010000 3c63f44b000100010000 => {replica 3 ldap://ro-hub.example.com:1389} => {replicageneration} 3c63da79000000030000 Getting replication update vector for ro-hub replica of dc= example,dc=com => {replica 1 ldap://master.example.com:1389} 3c63e0b0000000010000 3c63f443000100010000 => {replica 3 ldap://ro-hub.example.com:1389} => {replicageneration} 3c63da79000000030000 **** <{replica 1 ldap://master.example.com:1389} 3c63e0b0000000010000 3c63f44b000100010000> ---- <{replica 1 ldap://master.example.com:1389} 3c63e0b0000000010000 3c63f443000100010000> **************** Replication Update Vector for ro-hub doesn't match with master Servers are not in sync $ echo $? ## show return value 1

The first part of the output up to the **** separator displays the replication update vector in each replica. The second part compares all vector elements for each pair of replicas being considered and displays those that do not match. These elements encode information about the latest replication operations, and any differences in this pair of values indicates that the replicas are not up to date.

In this example, the two elements differ slightly, and the tool displays the unmatched vector elements and human-readable explanation. Finally, the return value shows that the replcheck.pl tool reported that the second host on the command line, ro-hub, is out-of-date.