Previous     Contents     Index     Next     
iPlanet Directory Server 5.1 Administrator's Guide



Chapter 8   Managing Replication


Replication is an important mechanism for extending your directory service beyond a single server configuration. This chapter describes the tasks to be performed on the supplier servers and the consumer servers to set up single master replication, multi-master replication, and cascading replication. This chapter includes the following topics:

For conceptual information on how you can use replication in your directory deployment, see the iPlanet Directory Server Deployment Guide.



Replication Overview


Replication is the mechanism by which directory data is automatically copied from one Directory Server to another. Updates of any kind—entry additions, modifications, or even deletions—are automatically mirrored to other Directory Servers using replication. This section contains information on the following replication concepts:


Replica

A database that participates in replication is defined as a replica. There are several kinds of replicas:

  • Master replica: a read-write database that contains a master copy of the directory data. A master replica can process update requests from directory clients.

  • Consumer replica: a read-only database that contains a copy of the information held in the master replica. A consumer replica can process search requests from directory clients but refers update requests to the master replica.

  • Hub replica: a read-only database just like a consumer replica. The difference is that the information stored in this database is used by a Directory Server that acts both as a consumer and supplier (hub) of replicated information.

You can configure a Directory Server to manage several databases. Each database can have a different role in replication. For example, you could have a Directory Server that stores the dc=engineering,dc=siroe,dc=com suffix in a master replica, and the dc=sales,dc=siroe,dc=com suffix in a consumer replica.


Supplier/Consumer

A server that manages a master replica that it replicates to other servers is called a supplier server or master server. A server that manages a consumer replica that is updated by a different server is called a consumer server.

It is convenient to talk about the role of a server as a supplier or a consumer, even though it is not always accurate because a server can be both a supplier and a consumer. This is true in the following cases:

  • When the Directory Server manages a combination of master replicas and consumer replicas;

  • When the Directory Server acts as a hub supplier, that is, it receives updates from a master server and replicates the changes to consumer servers. For more information, refer to "Cascading Replication".

  • In multi-master replication, when a master replica is mastered on two different Directory Servers: each Directory Server acts as a supplier and a consumer of the other Directory Server. For more information, refer to "Multi-Master Replication".

In iPlanet Directory Server 5.1, replication is always initiated by the supplier server, never by the consumer. This operation is called supplier-initiated replication. It allows you to configure a supplier server to push data to one or more consumer servers.

Earlier versions of the iPlanet Directory Server allowed consumer-initiated replication where you could configure consumer servers to pull data from a supplier server. This is replaced, in iPlanet Directory Server 5.1, by a procedure in which the consumer can prompt the supplier to send updates. For more information on this feature, refer to "Keeping Replicas in Sync".


Change Log

Every supplier server maintains a change log. A change log is a record that describes the modifications that have occurred on a master replica. The supplier server then replays these modifications to the replicas stored on consumer servers, or to other suppliers in the case of multi-master replication.

When an entry is modified, a change record describing the LDAP operation that was performed is recorded in the change log.

The change log can be configured in the same way as a regular LDBM database.

In iPlanet Directory Server 5.0, the format of the change log was modified. In earlier versions of Directory Server, the change log was accessible over LDAP. Now, however, it is intended only for internal use by the server. If you have applications that need to read the change log, you need to use the Retro Change Log Plug-in for backward compatibility. For more information, refer to "Using the Retro Change Log Plug-In".


Unit of Replication

In iPlanet Directory Server 5.1, the smallest unit of replication is a database. This means that you can replicate an entire database, but not a subtree within a database. Therefore, when you create your directory tree, you must take your replication plans into consideration. For more information on how to set up your directory tree, refer to iPlanet Directory Server Deployment Guide.

The replication mechanism also requires that one database correspond to one suffix. This means that you cannot replicate a suffix (or namespace) that is distributed over two or more databases using custom distribution logic. For more information on this topic, refer to "Creating and Maintaining Databases," on page 85.


Replication Identity

When replication occurs between two servers, the consumer server authenticates the supplier when it binds to send replication updates. This authentication process requires that the entry used by the supplier to bind to the consumer is stored on the consumer server. This entry is called the Replication Manager entry, or supplier bind DN.

The Replication Manager entry, or any entry you create to fulfill that role, must meet the following criteria:

  • You must have at least one on every server that manages consumer replicas (or hub replicas).

  • This entry must not be part of the replicated data for security reasons.


    Note This entry has a special user profile that bypasses all access control rules defined on the consumer server.


When you configure replication between two servers, you must identify the Replication Manager (supplier bind DN) on both servers:

  • On the consumer server or hub supplier, when you configure the consumer replica or hub replica, you must specify one or several supplier bind DNs, that correspond to the entries authorized to perform replication updates.

  • On the supplier server, when you configure the replication agreement, you must specify the DN of this entry in the replication agreement.


    Note In the Directory Server Console, this Replication Manager entry is referred to as the supplier bind DN, which may be misleading as the entry does not actually exist on the supplier server. It is called the supplier bind DN because it is the entry that must be present on the consumer so that it can authenticate the supplier when it binds to provide replication updates to the consumer.


For more information on creating the Replication Manager entry, refer to "Creating the Supplier Bind DN Entry".


Replication Agreement

Directory Servers use replication agreements to define their replication configuration. A replication agreement describes replication between one supplier and one consumer only. The agreement is configured on the supplier server. It specifies:

  • The database to be replicated

  • The consumer server to which the data is pushed

  • The times during which replication can occur

  • The DN and credentials that the supplier server must use to bind (called the Replication Manager entry or supplier bind DN)

  • How the connection is secured (SSL, client authentication)


Compatibility with Earlier Versions of Directory Server

The replication mechanism in iPlanet Directory Server 5.0 and 5.1 is different from the mechanism used in earlier versions of Directory Server. Compatibility is provided through:

  • The Legacy Replication Plug-in

  • The Retro Change Log Plug-in

The legacy replication plug-in makes Directory Server 5.1 behave as a 4.x directory server in a consumer role. For information on how to implement legacy replication using this plug-in, refer to "Replication with Earlier Releases".

The retro change log plug-in can be used when you want a Directory Server 5.1 supplier to maintain a 4.x style change log. This is sometimes necessary for applications, such as iPlanet Meta Directory, that have a dependency on the Directory Server 4.x change log format, because they read information from the change log. For more information on the retro change log plug-in, refer to "Using the Retro Change Log Plug-In".



Replication Scenarios


This section describes the most commonly used replication scenarios:

You can combine these basic scenarios to build the replication environment that best suits your needs.


Note Whatever replication scenario you choose to implement, remember to consider schema replication. For details, refer to iPlanet Directory Server Deployment Guide.



Single-Master Replication

In the simplest replication scenario, the master copy of directory data is held in a single master replica on one server called the supplier server. This server supplies updates to the consumer replica stored on a consumer server.

The supplier server maintains a change log that records all the changes made to the master replica. The supplier server also stores the replication agreement.

The consumer server stores the entry corresponding to the supplier bind DN, so that it can authenticate the supplier when it binds to send replication updates.

Figure 8-1   

Single-Master Replication

In the example illustrated in Figure 8-1, the ou=people,dc=siroe,dc=com suffix receives a large number of search and update requests from clients. Therefore, to distribute the load, this suffix, which is mastered on Server A, is replicated to a consumer replica located on Server B.

Server B can process and respond to search requests from clients, but cannot process requests to modify directory entries. Server B processes modification requests received from clients by sending back to the client a referral to Server A.


Note In replication, the consumer server stores referral information about the supplier server, but does not forward modification requests from clients to the supplier. The client must follow the referral sent back by the consumer.


For information on how to configure a single-master replication environment, refer to "Configuring Single-Master Replication".


Multi-Master Replication

iPlanet Directory Server 5.1 also supports more complex replication scenarios in which the same information can be mastered on two servers. This information is held in a master replica on each server. This means that each server maintains a change log for the replica.

This type of configuration can work with any number of consumer servers. The consumers can receive updates from both suppliers. The consumers also have referrals defined for both suppliers. Such scenarios are called multi-master configurations.

Figure 8-2 shows an example of multi-master replication scenario. For a more detailed view of the replication agreements, change logs, and supplier bind DNs that you need to set up for multi-master replication, refer to Figure 8-3.

Figure 8-2   

Multi-Master Replication

Multi-master configurations have the following advantages:

  • Automatic write failover when one supplier is inaccessible

  • Updates are made on a local supplier in a geographically distributed environment


    Note Replication, especially multi-master replication, works better over high speed links than over slow links such as a WAN used in geographically distributed environments.


Figure 8-3    Detailed view of Multi-Master Replication

In the example illustrated in Figure 8-3, to ensure that the ou=people,dc=siroe,dc=com suffix is always available for modification operations, it is mastered on two supplier servers. Each supplier server maintains its own change log. When one of the masters processes a modification request from a client, it records the operation in its change log, then sends the replication update to the other supplier server and to the consumers.

This is why the supplier servers have replication agreements with each other, as well as with the consumer servers. The supplier servers also each store a bind DN that allows the other master to bind to provide replication updates.

In this example, each consumer server stores two entries, corresponding to the supplier bind DNs, so that it can authenticate the suppliers when they bind to send replication updates. It is possible for each consumer to have just one entry for the supplier bind DN. In this case, both suppliers bind using the same supplier bind DN.

In a multi-master replication scenario, when consumers receive modification requests from clients, they send back to the client referrals to both suppliers.


Note The consumer servers store referral information about the supplier servers. The consumer servers do not forward modification requests from clients to the suppliers. The client must follow the referral sent back by the consumer.


For information on setting up multi-master replication with two supplier servers and two consumer servers, refer to "Configuring Multi-Master Replication".


Cascading Replication

In a cascading replication scenario, one server, often called a hub supplier, acts both as a consumer and a supplier for a particular replica. It receives updates from the supplier server that holds the master copy of the data, and in turn supplies those updates to the consumer. Cascading replication is very useful in the following cases:

  • When you need to balance heavy traffic loads: for example, because your supplier servers need to handle all update traffic, it would put them under very heavy load to support all replication traffic to consumers too. You can offload replication traffic to a hub server that can service replication updates to a large number of consumers.

  • To reduce connection costs by using a local hub supplier in geographically distributed environments.

  • To increase performance of your directory service: if you direct all client applications performing read operations to the consumers, and all those performing update operations to the supplier, you can remove all of the indexes (except system indexes) from your hub server. This will dramatically increase the speed of replication between the supplier and the hub server.

Figure 8-4 shows an example of cascading replication. This example shows a simple cascading replication scenario. You can create more complex scenarios with several hub suppliers, and a large number of consumers.

Figure 8-4    Cascading Replication

In the example illustrated in Figure 8-4, a hub supplier is used to balance the load of replication updates by sharing it between the supplier server and the hub supplier.

The supplier server and the hub supplier server both maintain a change log. However, only the supplier server can process directory modification requests from clients.

The consumer server and the hub supplier can process search requests received from clients, but in the case of modification requests, send back to the client a referral to the supplier server. Figure 8-4 shows that Consumer Servers C and D have a referral to Supplier Server A. These are the automatic referrals that are created when you specify the supplier server during configuration of the consumer replica.


Note The consumer server and hub supplier store referral information about the supplier servers. They do not forward modification requests from clients to the suppliers. The client must follow the referral sent back by the consumer.


For information on setting up cascading replication, refer to "Configuring Cascading Replication".


Note You can combine multi-master and cascading replication. For example, in the multi-master scenario illustrated in Figure 8-3, Server C and Server D could be hub suppliers that would replicate to any number of consumer servers.




Summary of Steps for Complex Replication Configurations


If you are configuring replication for a large number of servers, and your configuration is relatively complex, for reasons of efficiency you should proceed in the following order:

  1. On all consumer servers:

    • Create the replica databases

    • Create at least one Replication Manager or supplier bind DN entry

    • Specify the settings for a consumer replica

  2. On all hub suppliers:

    • Create the replica databases

    • Create the Replication Manager or supplier DN entry

    • Specify the supplier settings for replication (includes change log configuration)

    • Specify the settings for a hub replica

  3. On all suppliers:

    • Create the replica databases

    • Specify the supplier settings for replication (includes change log configuration)

    • Specify the settings for a supplier replica

  4. Configure replication agreements on all suppliers:

    • Between suppliers in a multi-master set

    • Between suppliers and consumers

    • Between suppliers and hub suppliers

    Optionally, you can initialize the replicas on the consumer servers and hub suppliers at this stage. In the case of multi-master replication, initialize one supplier replica from the other one. You must not attempt to do mutual initialization of the supplier replicas.

  5. Configure replication agreements on all hub suppliers, between the hub supplier and the dedicated consumers.

    Optionally, you can initialize the replicas on the consumer servers at this stage.


    Note It is very important to create and configure all replicas before you attempt to create a replication agreement. This also means that when you create the replication agreement, you can choose to initialize consumer replicas immediately. Consumer initialization is always the last stage in setting up replication.




Detailed Replication Tasks

This section contains a description of the tasks you need to perform to configure replication.


Creating the Supplier Bind DN Entry

A critical part of setting up replication is to create the entry, referred to as the Replication Manager or supplier bind DN entry, that the suppliers will use to bind to the consumer servers to perform replication updates.

The criteria and characteristics that the supplier bind DN entry must satisfy are described in "Replication Identity".

To create the supplier bind DN entry:

  1. On each server that acts as a consumer in replication agreements, create a special entry that the supplier will use to bind.

    This entry must not be part of the replicated database. For example, you could use cn=Replication Manager,cn=config. Make sure you create the entry with the attributes required by the authentication method you specify in the replication agreement.

  2. Specify a userPassword attribute-value pair.

  3. If you have enabled the password expiration policy, or intend to do so in the future, you must remember to disable it to prevent replication from failing due to passwords expiring. To disable the password expiration policy on the userPassword attribute, add the passwordExpirationTime attribute with a value of 20380119031407Z, which means that the password will never expire.

When you configure a consumer replica, you must use the DN of this entry to define the supplier bind DN.


Note The supplier bind DN corresponds to a privileged user because it is not subject to access control.



Configuring Supplier Settings

On any server that holds a supplier replica or a hub replica, you must specify supplier settings, namely, the change log parameters.

To configure supplier settings:

  1. In the Directory Server Console, click the Configuration tab.

    For information on starting the Directory Server Console, "Using the Directory Server Console," on page 26.

  2. In the left navigation tree, highlight the Replication node.

  3. In the right navigation window, click the Supplier Settings tab.

  4. Check the Enable Change Log checkbox.

    This activates all of the fields in the pane below that were previously unavailable.

  5. Specify a change log by clicking the Use Default button, or click Browse to display a file selector.

  6. Set the change log number and age parameters.

    You must clear the unlimited checkboxes to specify different values.

  7. Click Save to save the supplier settings for the directory server.


Configuring a Supplier Replica

For each supplier replica, you must specify the appropriate replication settings.

To configure a supplier replica:

  1. In the Directory Server Console, click the Configuration tab.

    For information on starting the Directory Server Console, refer to "Using the Directory Server Console," on page 26.

  2. In the left navigation tree, expand the Replication folder and highlight the database to replicate.

    The Replica Settings tab is displayed in the right navigation window.

  3. Check the Enable Replica checkbox.

  4. In the Replica Role section, select the Single Master or Multiple Master radio button.

  5. In the Common Settings section, specify a Replica ID (an integer between 1 and 65534 inclusive).

    The replica ID must be unique for each supplier replica. Make sure you specify an ID that is different from the IDs used for other supplier replicas on this server and on other servers.

  6. In the Common Settings section specify a purge delay in the Purge delay field.

    This option indicates for how long the state information is stored in the replicated entries. The delay before purging must be long enough to allow replication shutdown or errors and recovery, and short enough to avoid keeping too much data in the entry. The default is 1 week.

  7. Click Save to save the replication settings for the database.


Configuring a Consumer Replica

For each consumer replica, you must specify the appropriate replication settings.

  1. In the Directory Server Console, click the Configuration tab.

    For information on starting the Directory Server Console, refer to "Using the Directory Server Console," on page 26.

  2. In the left navigation tree, expand the Replication folder, and highlight the replica database.

    The Replica Settings tab is displayed in the right navigation window.

  3. Check the Enable Replica checkbox.

  4. In the Replica Role section, select the Dedicated Consumer radio button.

  5. In the Common Settings section specify a purge delay in the Purge delay field.

    This option indicates for how long the state information is stored in the replicated entries. The delay before purging must be long enough to allow replication shutdown or errors and recovery, and short enough to avoid keeping too much data in the entry. The default is 1 week.

    The Replica ID field remains unavailable because you do not need to specify a Replica ID for a consumer (it is automatically set to 65535 for all consumer replicas).

  6. In the Update Settings section, specify the supplier bind DN (Replication Manager DN) that the supplier will use to bind to the replica.

    The list of "Current Supplier DNs " is empty if you are configuring the replica for the first time. You can have multiple supplier bind DNs per replica but only one supplier DN per replication agreement.

    To specify a new supplier bind DN:

    1. Enter a new supplier bind DN in the corresponding field.

      The DN you enter must correspond to the entry you created on the consumer server (for example cn=Replication Manager,cn=config).

    2. Click Add.

      The supplier bind DN will appear in the list of "Current Supplier DNs" directly above.

    3. Repeat the operation for every supplier bind DN that you want to include in the list.

  7. Specify the LDAP URL of servers to which you want to refer updates.

    The list of "Current URLs for Referrals" is empty if you are configuring the replica for the first time. By default, this list does not display the URL of the server that masters the data of the replica (the consumer server creates this referral automatically).

    Automatic referrals assume that clients will bind over a regular connection, and therefore, are of the form ldap://servername:port. If you want clients to bind to the supplier using SSL, you can use this field to specify a referral of the form ldaps://servername:port where the s in ldaps indicates secure connections.

    If you specify an LDAP URL for referrals, the directory server first refers modification requests to the URL you specified. If you specify none, modification requests are referred to the suppliers of the current replica.

    To specify a new URL for referrals:

    1. Enter a new LDAP URL in the corresponding field, or click Construct to display a dialog box that will help you build an LDAP URL.

    2. Click Add.

      Your LDAP URL will appear in the list of "Current URLs for Referrals" directly above.

    3. Repeat the operation for every referral you want to include in the list.

  8. Click Save to save the replication settings for the replica.


Configuring a Hub Replica

In a cascading replication environment, configure the hub supplier as follows:

  1. On the Directory Server Console, click the Configuration tab.

    For information on starting the Directory Server Console, refer to "Using the Directory Server Console," on page 26.

  2. In the left navigation tree, expand the Replication folder and highlight the database to replicate.

    The Replica Settings tab is displayed in the right navigation window.

  3. Check the Enable Replica checkbox.

  4. In the Replica Role section, select the Hub radio button.

  5. In the Common Settings section specify a purge delay in the Purge delay field.

    This option indicates for how long the state information is stored in the replicated entries. The delay before purging must be long enough to allow replication shutdown or errors and recovery, and short enough to avoid keeping too much data in the entry. The default is 1 week.

    The Replica ID field remains unavailable because you do not need to specify a Replica ID for a hub supplier (it is automatically set to 65535, just like for a consumer replica).

  6. In the Update Settings section, specify the supplier bind DN (Replication Manager DN) that the supplier will use to bind to the hub replica.

    The list of "Current Supplier DNs" is empty if you are configuring the replica for the first time. You can have multiple supplier bind DNs per replica but only one supplier DN per replication agreement.

    To specify a new supplier bind DN:

    1. Enter a new supplier bind DN in the corresponding field.

      The DN you enter must correspond to the entry you created on the consumer server (for example cn=Replication Manager,cn=config).

    2. Click Add.

      The supplier bind DN will appear in the list of "Current Supplier DNs" directly above.

    3. Repeat the operation for every supplier bind DN that you want to include in the list.

  7. Specify the LDAP URL of servers to which you want to refer updates.

    The list of "Current URLs for Referrals" is empty if you are configuring the replica for the first time. By default, this list does not display the URL of the server that masters the data of the replica (the hub server creates this referral automatically).

    Automatic referrals assume that clients will bind over a regular connection, and therefore, are of the form ldap://servername:port. If you want clients to bind to the supplier using SSL, you can use this field to specify a referral of the form ldaps://servername:port where the s in ldaps indicates secure connections.

    If you specify an LDAP URL for referrals, the directory server first refers modification requests to the URL you specified. If you specify none, modification requests are referred to the suppliers of the current replica.

    To specify a new URL for referrals:

    1. Enter a new LDAP URL in the corresponding field, or click Construct to display a dialog box that will help you build an LDAP URL.

    2. Click Add.

      Your LDAP URL will appear in the list of "Current URLs for Referrals" directly above.

    3. Repeat the operation for every referral you want to include in the list.

  8. Click Save to save the replication settings for the database.


Creating a Replication Agreement

This section explains how to create a replication agreement. You must create a replication agreement on the supplier server for each supplier replica that is supplied to a consumer server or a hub supplier.

Before you can create a replication agreement, you must:

To create a replication agreement:

  1. On the Directory Server Console, click the Configuration tab.

  2. In the navigation tree, expand the Replication folder, right-click the database to replicate, and select New Replication Agreement.

    Alternatively, highlight the database and select New Replication Agreement from the Object menu. This will start the Replication Agreement Wizard.

  3. Go through the steps in the Replication Wizard by clicking Next to move to the following step.

    For detailed instructions on the input expected in each field, refer to the online help.

    When you have finished, an icon representing the replication agreement is displayed under the database icon. This replication agreement icon indicates that your replication agreement is set up.



Configuring Single-Master Replication

This section provides step-by-step information on how to configure single-master replication. To set up single-master replication such as the configuration shown in Figure 8-1, between supplier Server A that holds a supplier replica, and a consumer Server B that holds a consumer replica, you need to:

  1. Configure the consumer server (supplier bind DN and, optionally, referrals for modification requests), and the consumer replica.

    This procedure is described in "Configuring the Consumer Server and Replica".

  2. Configure the supplier server (change log and replica ID), and the supplier replica.

    This procedure is described in "Configuring the Supplier Server and Replica".

  3. Initialize the replica on the consumer server.

    This procedure is described in "Initializing Replicas in Single-Master Replication".


Configuring the Consumer Server and Replica

  1. Create the database for the replica, if it does not exist.

    For instructions, refer to "Creating Suffixes," on page 76.

  2. Create the entry corresponding to the supplier bind DN on the consumer server, if it does not exist. This is the special entry that the supplier will use to bind.

    1. In the Directory Server Console, click the Directory tab, and create an entry. For example you could use cn=Replication Manager,cn=config.

    2. Specify a userPassword attribute-value pair.

    3. If you have enabled the password expiration policy, or intend to do so in future, you must remember to disable it to prevent replication from failing due to passwords expiring. To disable the password expiration policy on the userPassword attribute, add the passwordExpirationTime attribute with a value of 20380119031407Z, which means that the password will never expire.


      Note The supplier bind DN corresponds to a privileged user because it is not subject to access control. This entry must not be part of the replicated database.


  3. Specify the replication settings required for a consumer replica.

    1. In the Directory Server Console, click the Configuration tab.

    2. In the navigation tree, expand the Replication folder, and highlight the replica database.

      The Replica Settings tab is displayed in the right side of the window.

    3. Check the Enable Replica checkbox.

    4. In the Replica Role section, select the Dedicated Consumer radio button.

    5. In the Common Settings section specify a purge delay in the Purge delay field.

      This option indicates for how long the state information is stored in the replicated entries. The delay before purging must be long enough to allow replication shutdown or errors and recovery, and short enough to avoid keeping too much data in the entry. The default is 1 week.

      The Replica ID field remains unavailable because you do not need to specify a Replica ID for a consumer (it is automatically set to 65535 for all consumer replicas).

    6. In the Update Settings section, specify the supplier bind DN (Replication Manager DN) that the supplier will use to bind to the replica.

      The list of "Current Supplier DNs" is empty if you are configuring the replica for the first time. You can have multiple supplier bind DNs per replica but only one supplier DN per replication agreement.

      To specify a new supplier bind DN:

    7. Enter a new supplier bind DN in the corresponding field. The DN you enter must correspond to the entry you created in Step 2 (for example cn=Replication Manager,cn=config).

    8. Click Add. Your supplier bind DN will appear in the list of "Current Supplier DNs" directly above.

    9. Repeat the operation for every supplier bind DN that you want to include in the list.

    10. Optionally, specify the LDAP URL of servers to which you want to refer updates.

      The list of "Current URLs for Referrals" is empty if you are configuring the replica for the first time. By default, this list does not display the URL of the server that masters the data of the replica (the server creates this referral automatically).

      Automatic referrals assume that clients will bind over a regular connection, and therefore, are of the form ldap://servername:port. If you want clients to bind to the supplier using SSL, you can use this field to specify a referral of the form ldaps://servername:port where the s in ldaps indicates secure connections.

      If you specify an LDAP URL for referrals, the directory server first refers update requests to the URL you specified. If you specify none, updates are referred to the suppliers of the current replica.

      To specify a new URL for referrals:

    11. Enter a new LDAP URL in the corresponding field, or click Construct to display a dialog box that will help you build an LDAP URL.

    12. Click Add. Your LDAP URL will appear in the list of "Current URLs for Referrals" directly above.

    13. Repeat the operation for every referral you want to include in the list.

  4. Click Save to save the replication settings for the replica.


Configuring the Supplier Server and Replica

  1. Specify the supplier settings for the server.

    1. In the Directory Server Console, click the Configuration tab.

    2. In the navigation tree, highlight the Replication node.

    3. In the right side of the window, on the Supplier Settings tab, check the Enable Changelog checkbox.

      This activates all of the fields in the pane below that were previously unavailable.

    4. Specify a change log by clicking the Use Default button, or click the Browse button to display a file selector.

    5. Set the change log parameters (number and age).

      You must clear the unlimited checkboxes if you want to specify different values.

    6. Click Save to save the supplier settings.

  2. Specify the replication settings required for a supplier replica.

    1. In the navigation tree on the Configuration tab, expand the Replication node and highlight the database to replicate.

      The Replica Settings tab is displayed in the right side of the window.

    2. Check the Enable Replica checkbox.

    3. In the Replica Role section, select the Single Master radio button.

    4. In the Common Settings section, specify a Replica ID (an integer between 1 and 65534 inclusive).

      The replica ID must be unique for each supplier replica. Make sure you specify an ID that is different from the IDs used for other supplier replicas on this server and on other servers.

    5. In the Common Settings section specify a purge delay in the Purge delay field.

      This option indicates for how long the state information is stored in the replicated entries. The delay before purging must be long enough to allow replication shutdown or errors and recovery, and short enough to avoid keeping too much data in the entry. The default is 1 week.

    6. Click Save to save the replication settings for the database.

  3. Create a replication agreement between this supplier and the consumer.

    1. In the navigation tree on the Configuration tab, right-click the database to replicate, and select New Replication Agreement.

      Alternatively, highlight the database and select New Replication Agreement from the Object menu. This will start the Replication Agreement Wizard.

    2. Go through the steps in the replication wizard by clicking Next to move to the following step.

      For detailed instructions on the input expected in each field, refer to the online help.

    3. When you have finished, the replication agreement is set up.


Initializing Replicas in Single-Master Replication

You can initialize the consumer replica from the Replication Agreement Wizard, or at anytime afterwards. For information on initializing consumer replicas, refer to "Initializing Consumers".



Configuring Multi-Master Replication


This section provides information on configuring multi-master replication. In a multi-master configuration, two suppliers can accept updates, synchronize with each other, and update all consumers. The consumers can refer update requests to both masters. This section provides step-by-step information on how to set up multi-master replication.

To set up multi-master replication such as the configuration shown in Figure 8-2, between two suppliers, Server A and Server B, that each hold a supplier replica, and two consumers, Server C and Server D, that each hold a consumer replica, you need to:

  1. Configure the consumer servers (supplier bind DN and, optionally, referrals for modification requests), and the consumer replicas.

    This procedure is described in "Configuring the Consumer Servers and Replicas".

  2. Configure the supplier servers (change log and replica ID), and the supplier replicas.

    This procedure is described in "Configuring the Supplier Servers and Replicas".

  3. Initialize the consumer replicas on the consumer servers.

    This procedure is described in "Initializing Replicas in Multi-Master Replication".


Configuring the Consumer Servers and Replicas

Perform these steps on each consumer server:

  1. Create the database for the replica, if it does not exist.

    For instructions, refer to "Creating Suffixes," on page 76.

  2. Create the entry corresponding to the supplier bind DN, if it does not exist. This is the special entry that the supplier will use to bind.

    1. In the Directory Server Console, click the Directory tab, and create an entry. For example, you could use cn=Replication Manager,cn=config.

    2. Specify a userPassword attribute-value pair.

    3. If you have enabled the password expiration policy, or intend to do so in the future, you must remember to disable it to prevent replication from failing due to passwords expiring. To disable the password expiration policy on the userPassword attribute, add the passwordExpirationTime attribute with a value of 20380119031407Z, which means that the password will never expire.


      Note The supplier bind DN corresponds to a privileged user because it is not subject to access control. This entry must not be part of the replicated database.


  3. Specify the replication settings required for a consumer replica.

    1. In the Directory Server Console, click the Configuration tab.

    2. In the navigation tree, expand the Replication folder, and highlight the replica database.

      The Replica Settings tab is displayed in the right side of the window.

    3. Check the Enable Replica checkbox.

    4. In the Replica Role section, select the Dedicated Consumer radio button.

    5. In the Common Settings section specify a purge delay in the Purge delay field.

      This option indicates for how long the state information is stored in the replicated entries. The delay before purging must be long enough to allow replication shutdown or errors and recovery, and short enough to avoid keeping too much data in the entry. The default is 1 week.

      The Replica ID field remains unavailable because you do not need to specify a Replica ID for a consumer (it is automatically set to 65535 for all consumer replicas).

    6. In the Update Settings section, specify the supplier bind DN (Replication Manager DN) that the supplier will use to bind to the replica.

      The list of "Current Supplier DNs" is empty if you are configuring the replica for the first time. You can have multiple supplier bind DNs per replica but only one supplier DN per replication agreement.

      To specify a new supplier bind DN:

    7. Enter a new supplier bind DN in the corresponding field. The DN you enter must correspond to the entry you created in Step 2 (for example cn=Replication Manager,cn=config).

    8. Click Add. Your supplier bind DN will appear in the list of "Current Supplier DNs" directly above.

    9. Repeat the operation for every supplier bind DN that you want to include in the list.

    10. Optionally, specify the LDAP URL of servers to which you want to refer updates.

      The list of "Current URLs for Referrals" is empty if you are configuring the replica for the first time. By default, this list does not display the URL of the server that masters the data of the replica (the consumer server creates this referral automatically).

      Automatic referrals assume that clients will bind over a regular connection, and therefore, are of the form ldap://servername:port. If you want clients to bind to the supplier using SSL, you can use this field to specify a referral of the form ldaps://servername:port where the s in ldaps indicates secure connections.

      If you specify an LDAP URL for referrals, the directory server first refers update requests to the URL you specified. If you specify none, updates are referred to the suppliers of the current replica.

      To specify a new URL for referrals:

    11. Enter a new LDAP URL in the corresponding field, or click Construct to display a dialog box that will help you build an LDAP URL.

    12. Click Add. Your LDAP URL will appear in the list of "Current URLs for Referrals" directly above.

    13. Repeat the operation for every referral you want to include in the list.

  4. Click Save to save the replication settings for the replica.

Repeat these steps for every consumer server in your replication configuration.


Configuring the Supplier Servers and Replicas

Perform these steps on each supplier server:

  1. On Server A and Server B, specify the supplier settings for each server.

    1. In the Directory Server Console, click the Configuration tab.

    2. In the navigation tree, highlight the Replication node.

    3. In the right side of the window, click the Supplier Settings tab.

    4. Check the Enable Change Log checkbox.

      This activates all of the fields in the pane below that were previously unavailable.

    5. Specify a change log by clicking the Use Default button, or click the Browse button to display a file selector.

    6. Set the change log parameters (number and age).

      You must clear the unlimited checkboxes if you want to specify different values.

    7. Click Save to save the supplier settings.

  2. Create the entry corresponding to the supplier bind DN, if it does not exist. For multi-master replication, it is necessary to create this supplier bind DN on the supplier servers (as well as the consumers), because they act as both consumer and supplier to the other supplier server.

    1. In the Directory Server Console, click the Directory tab, and create an entry. For example you could use cn=Replication Manager,cn=config.

    2. Specify a userPassword attribute-value pair.

    3. If you have enabled the password expiration policy, or intend to do so in the future, you must remember to disable it to prevent replication from failing due to passwords expiring. To disable the password expiration policy on the userPassword attribute, add the passwordExpirationTime attribute with a value of 20380119031407Z, which means that the password will never expire.


      Note The supplier bind DN corresponds to a privileged user because it is not subject to access control. This entry must not be part of the replicated database.


  3. On Server A and Server B, specify the replication settings for the multi-mastered supplier replica.

    1. In the navigation tree on the Configuration tab, expand the Replication node and highlight the database to replicate.

      The Replica Settings tab is displayed in the right side of the window.

    2. Check the Enable Replica checkbox.

    3. In the Replica Role section, select the Multiple Master radio button.

    4. In the Common Settings section, specify a Replica ID (an integer between 1 and 65534 inclusive).

      The replica ID must be unique for each supplier replica. Make sure you specify an ID that is different from the IDs used for other supplier replicas on this server and on other servers.

    5. In the Common Settings section specify a purge delay in the Purge delay field.

      This option indicates for how long the state information is stored in the replicated entries. The delay before purging must be long enough to allow replication shutdown or errors and recovery, and short enough to avoid keeping too much data in the entry. The default is 1 week.

    6. In the Update Settings section, specify the supplier bind DN (Replication Manager DN) that the supplier will use to bind to the replica.

      The list of "Current Supplier DNs" is empty if you are configuring the replica for the first time. You can have multiple supplier bind DNs per replica but only one supplier DN per replication agreement.

      To specify a new supplier bind DN:

    7. Enter a new supplier bind DN in the corresponding field. The DN you enter must correspond to the entry you created in Step 2 (for example cn=Replication Manager,cn=config).

    8. Click Add. The supplier bind DN will appear in the list of "Current Supplier DNs" directly above.

    9. Repeat the operation for every supplier bind DN that you want to include in the list.


      Note On a supplier server, you do not need to specify an LDAP URL for referrals.


    10. Click Save to save the replication settings for the database.

  4. On Server A, set up the following replication agreements:

    • One with supplier Server B, where B is configured as a consumer for the replica.

    • One for each consumer, Server C and Server D.

    • In the navigation tree on the Configuration tab, right-click the database to replicate, and select New Replication Agreement.

      Alternatively, highlight the database and select New Replication Agreement from the Object menu. This will start the Replication Agreement Wizard.

    • Go through the steps in the replication wizard by clicking Next to move to the following step.

      For detailed instructions on the input expected in each field, refer to the online help.

      You can initialize the consumer replicas and the supplier replica on Server B from the Replication Agreement Wizard, or at anytime afterwards. For information on the order and procedure for initializing consumer replicas, refer to"Initializing Replicas in Multi-Master Replication", and "Initializing Consumers".

    When you have finished, the replication agreement is set up.

  5. On Server B, set up the following replication agreements:

    • One with supplier Server A, where A is declared as a consumer for the replica. During this operation, do not initialize Server A from Server B if you have already initialized Server B from Server A in Step 4.

    • One for each consumer, Server C and Server D.


      Note Once you have completed these procedures, Server A and Server B have mutual replication agreements, which means that they can accept updates from each other.


When you have configured the servers holding the supplier replicas, the necessary replication agreements, and the servers holding the consumer replicas, you are ready to initialize replication. You can perform this task when you create the replication agreements on the supplier servers, or at anytime afterwards.


Initializing Replicas in Multi-Master Replication

In the case of multi-master replication, you should initialize replicas in the following order:

  1. Ensure one master has the complete set of data to replicate. Use this master to initialize the supplier replica on the other master in the multi-master replication set.

  2. Initialize the consumer replicas on the consumer servers from any one of the two masters.

For information on initializing replicas, refer to "Initializing Consumers".



Configuring Cascading Replication


This section provides information on setting up cascading replication. In a cascading replication scenario, a supplier server updates an intermediate server (called a hub server), which in turn updates one or several consumer servers. This section provides step-by-step information on how to set up cascading replication.

To set up cascading replication such as the configuration shown in Figure 8-4, between the supplier on Server A, the Hub Server B, and the consumer Server C, you need to:

  1. Configure the consumer server (supplier bind DN and, optionally, referrals for modification requests), and the consumer replica.

    This procedure is described in "Configuring the Consumer Server and Replica".

  2. Configure the hub supplier (change log, supplier bind DN, and optionally, referrals for modification requests), and the hub replica.

    This procedure is described in "Configuring the Hub Supplier and Replica".

  3. Configure the supplier server (change log and replica ID), and the supplier replica.

    This procedure is described in "Configuring the Supplier Server and Replica".

  4. Configure the replication agreements on the supplier server and on the hub supplier.

    This procedure is described in "Configuring Replication Agreements".

  5. Initialize the replicas on the hub supplier, and on the consumer server.

    This procedure is described in "Initializing Replicas in Cascading Replication".


Configuring the Consumer Server and Replica

  1. On the consumer server, create the database for the replica if it does not exist.

    For instructions, refer to "Creating Suffixes," on page 76.

  2. On the consumer server, create the entry corresponding to the supplier bind DN, if it does not exist. This is the special entry that the supplier will use to bind.

    1. In the Directory Server Console, click the Directory tab, and create an entry. For example you could use cn=Replication Manager,cn=config.

    2. Specify a userPassword attribute-value pair.

    3. If you have enabled the password expiration policy, or intend to do so in the future, you must remember to disable it to prevent replication from failing due to passwords expiring. To disable the password expiration policy on the userPassword attribute, add the passwordExpirationTime attribute with a value of 20380119031407Z, which means that the password will never expire.


      Note The supplier bind DN corresponds to a privileged user because it is not subject to access control. This entry must not be part of the replicated database.


  3. On the consumer server, specify the replication settings for the consumer replica.

    1. In the Directory Server Console, click the Configuration tab.

    2. In the navigation tree, expand the Replication folder, and highlight the replica database.

      The Replica Settings tab is displayed in the right side of the window.

    3. Check the Enable Replica checkbox.

    4. In the Replica Role section, select the Dedicated Consumer radio button.

    5. In the Common Settings section specify a purge delay in the Purge delay field.

      This option indicates for how long the state information is stored in the replicated entries. The delay before purging must be long enough to allow replication shutdown or errors and recovery, and short enough to avoid keeping too much data in the entry. The default is 1 week.

      The Replica ID field remains unavailable because you do not need to specify a Replica ID for a consumer (it is automatically set to 65535 for all consumer replicas).

    6. In the Update Settings section, specify the supplier bind DN (Replication Manager DN) that the supplier will use to bind to the replica.

      The list of "Current Supplier DNs" is empty if you are configuring the replica for the first time. You can have multiple supplier bind DNs per replica but only one supplier DN per replication agreement.

      To specify a new supplier bind DN:

    7. Enter a new supplier bind DN in the corresponding field. The DN you enter must correspond to the entry you created in Step 2 (for example cn=Replication Manager,cn=config).

    8. Click Add. The supplier bind DN will appear in the list of "Current Supplier DNs" directly above.

    9. Repeat the operation for every supplier bind DN that you want to include in the list.

    10. Optionally, specify the LDAP URL of servers to which you want to refer updates.

      The list of "Current URLs for Referrals" is empty if you are configuring the replica for the first time. By default, this list does not display the URL of the server that masters the data of the replica (the consumer server creates this referral automatically).

      Automatic referrals assume that clients will bind over a regular connection, and therefore, are of the form ldap://servername:port. If you want clients to bind to the supplier using SSL, you can use this field to specify a referral of the form ldaps://servername:port where the s in ldaps indicates secure connections.

      If you specify an LDAP URL for referrals, the directory server first refers update requests to the URL you specified. If you specify none, updates are referred to the suppliers of the current replica.

      To specify a new URL for referrals:

    11. Enter a new LDAP URL in the corresponding field, or click Construct to display a dialog box that will help you build an LDAP URL.

    12. Click Add. Your LDAP URL will appear in the list of "Current URLs for Referrals" directly above.

    13. Repeat the operation for every referral you want to include in the list.

  4. Click Save to save the replication settings for the replica.


Configuring the Hub Supplier and Replica

Perform these steps on the hub supplier that receives replication updates from the master, and propagates them to consumers:

  1. Create the database for the replica if it does not exist.

    For instructions, refer to "Creating Suffixes," on page 76.

  2. Create the entry corresponding to the supplier bind DN, if it does not exist. This is the special entry that the supplier will use to bind.

    1. In the Directory Server Console, click the Directory tab, and create an entry. For example you could use cn=Replication Manager,cn=config.

    2. Specify a userPassword attribute-value pair.

    3. If you have enabled the password expiration policy, or intend to do so in the future, you must remember to disable it to prevent replication from failing due to passwords expiring. To disable the password expiration policy on the userPassword attribute, add the passwordExpirationTime attribute with a value of 20380119031407Z, which means that the password will never expire.


      Note The supplier bind DN corresponds to a privileged user because it is not subject to access control. This entry must not be part of the replicated database.


  3. Specify the replication settings for the hub replica.

    1. In the Directory Server Console, click the Configuration tab.

    2. In the navigation tree, expand the Replication folder, and highlight the replica database.

      The Replica Settings tab is displayed in the right side of the window.

    3. Check the Enable Replica checkbox.

    4. In the Replica Role section, select the Hub radio button.

    5. In the Common Settings section specify a purge delay in the Purge delay field.

      This option indicates for how long the state information is stored in the replicated entries. The delay before purging must be long enough to allow replication shutdown or errors and recovery, and short enough to avoid keeping too much data in the entry. The default is 1 week.

      The Replica ID field remains unavailable because you do not need to specify a Replica ID for a hub supplier (it is automatically set to 65535, just like a consumer replica).

    6. In the Update Settings section, specify the supplier bind DN (Replication Manager DN) that the supplier will use to bind to the replica.

      The list of "Current Supplier DNs " is empty if you are configuring the replica for the first time. You can have multiple supplier bind DNs per replica but only one supplier DN per replication agreement.

      To specify a new supplier bind DN:

    7. Enter a new supplier bind DN in the corresponding field. The DN you enter must correspond to the entry you created in Step 2 (for example cn=Replication Manager,cn=config).

    8. Click Add. The supplier bind DN will appear in the list of "Current Supplier DNs" directly above.

    9. Repeat the operation for every supplier bind DN that you want to include in the list.

    10. Optionally, specify the LDAP URL of servers to which you want to refer updates.

      The list of "Current URLs for Referrals" is empty if you are configuring the replica for the first time. By default, this list does not display the URL of the server that masters the data of the replica (the hub server creates this referral automatically).

      Automatic referrals assume that clients will bind over a regular connection, and therefore, are of the form ldap://servername:port. If you want clients to bind to the supplier using SSL, you can use this field to specify a referral of the form ldaps://servername:port where the s in ldaps indicates secure connections.

      If you specify an LDAP URL for referrals, the directory server first refers modification requests to the URL you specified. If you specify none, modification requests are referred to the suppliers of the current replica.

      To specify a new URL for referrals:

    11. Enter a new LDAP URL in the corresponding field, or click Construct to display a dialog box that will help you build an LDAP URL.

    12. Click Add. Your LDAP URL will appear in the list of "Current URLs for Referrals " directly above.

    13. Repeat the operation for every referral you want to include in the list.

  4. Click Save to save the replication settings for the replica.


Configuring the Supplier Server and Replica

Perform these steps on the supplier server that holds the original copy of the database:

  1. Specify the supplier settings for the server.

    1. In the Directory Server Console, click the Configuration tab.

    2. In the navigation tree, highlight the Replication node.

    3. In the right side of the window, click the Supplier Settings tab.

    4. Check the Enable Change Log checkbox.

      This activates all of the fields in the pane below that were previously unavailable.

    5. Specify a change log by clicking the Use Default button, or click the Browse button to display a file selector.

    6. Set the change log parameters (number and age).

      You must clear the unlimited checkboxes if you want to specify different values.

    7. Click Save to save the supplier settings.

  2. Specify the required replication settings.

    1. In the navigation tree on the Configuration tab, expand the Replication node and highlight the database to replicate.

      The Replica Settings tab is displayed in the right side of the window.

    2. Check the Enable Replica checkbox.

    3. In the Replica Role section, select the Single Master radio button.

    4. In the Common Settings section, specify a Replica ID (an integer between 1 and 65534 inclusive).

      The replica ID must be unique for each supplier replica. Make sure you specify an ID that is different from the IDs used for other supplier replicas on this server and on other servers.

    5. In the Common Settings section specify a purge delay in the Purge delay field.

      This option indicates for how long the state information is stored in the replicated entries. The delay before purging must be long enough to allow replication shutdown or errors and recovery, and short enough to avoid keeping too much data in the entry. The default is 1 week.

    6. Click Save to save the replication settings for the database.


Configuring Replication Agreements

When you configure a cascading replication environment, you must first create the replication agreements in the following order:

  • First, on the supplier server to define replication between the supplier and the hub supplier;

  • Second, on the hub supplier to define replication between the hub supplier and the consumer.

By performing the operations in this order, you can also initialize the replica on the hub supplier and the replica on the consumer as you create the replication agreements.

  1. On the supplier server, set up the replication agreement between this server and the hub supplier.

    1. In the navigation tree on the Configuration tab, right-click the database to replicate, and select New Replication Agreement.

      Alternatively, highlight the database and select New Replication Agreement from the Object menu. This will start the Replication Agreement Wizard.

    2. Go through the steps in the replication wizard by clicking Next to move to the following step.

      For detailed instructions on the input expected in each field, refer to the online help.

      You can initialize the replica on the hub supplier at this time, or anytime afterwards. For information on initializing replicas at a later stage, refer to "Initializing Consumers".

  2. On the hub supplier, set up the replication agreement between this server and the consumer.

    Follow the same procedure as described in Step 1. You can initialize the replica on the consumer server from the replication wizard. If you choose to initialize the consumer server at a later time, refer to "Initializing Consumers" for instructions.


Initializing Replicas in Cascading Replication

If you chose not to initialize the replicas while configuring the replication agreements, you can perform this operation at any time, by following the instructions given in "Initializing Consumers". However, in the case of cascading replication, remember that you should always initialize replicas in the following order:

  1. From the supplier server, initialize the replica on the hub supplier.

  2. From the hub supplier, initialize the replica on the consumer.



Deleting the Change Log

The change log is a record of all modifications on a given replica that the supplier uses to replay these modifications to replicas on consumer servers (or masters in the case of multi-master replication). In the event of a supplier server going off line, it is important to be able to delete the change log because it no longer holds a true record of all modifications, and, as a result, should not be used as a basis for replication. Once you have deleted the change log, you can initialize your consumers and begin the replication process afresh. To delete the change log you can either remove it or move it to a new location.

This section contains the information for the following procedures:


Removing the Change Log

You can remove the change log using the Directory Server Console. To remove the change log from the supplier server:

  1. On the Directory Server Console, select the Configuration tab.

  2. Select the Replication folder in the left navigation tree and then the Supplier Server Settings tab in the right pane.

  3. Clear the Enable Change Log checkbox.

    This deletes the change log.

  4. Click Save.

  5. Restart the Directory Server.

  6. Reinitialize your consumers.

    See "Initializing Consumers" for information.


    Note If you remove the change log, you will need to reinitialize your consumer servers.



Moving the Change Log to a New Location

To delete the change log while the server is still running and continuing to log changes, you simply move the change log to a new location. By moving the change log, a new change log is created in the directory you specify, and the old change log is deleted. Changing the location of the change log is equivalent to reinitializing it, which in turn requires consumer reinitialization.

For example, you could move the change log from the default location of installDir/slapd-serverID/changelogdb to installDir/slapd-serverID/newchangelog. This operation should be performed from the Directory Server Console, and not by using the filesystem rename or mv commands.



Initializing Consumers


Once you have created a replication agreement, you must initialize the consumer, that is, you must physically copy data from the supplier server to the consumer servers. This section first describes consumer initialization in detail, and then provides instructions on the two different methods for initializing consumers. This section is divided into the following parts:


When to Initialize a Consumer

Consumer initialization involves copying data from the supplier server to the consumer server. Once the subtree has been physically placed on the consumer, the supplier server can begin replaying update operations to the consumer server.

Under normal operations, the consumer should not ever have to be initialized again. However, if the data on the supplier server is restored from backup for any reason, then you should reinitialize all of the consumers supplied by it.

You can either initialize the consumer on line using the console or manually using the command line. Online consumer initialization using the console is an effective method of initializing a small number of consumers. However, since each replica is initialized in sequence, this method is not suited to initializing a large number of replicas. Online consumer initialization is the method used when you initialize the consumer while configuring the replication agreement on the supplier server.

Manual consumer initialization using the command line, is a more effective method of initializing a large number of consumers from a single LDIF file.


Online Consumer Initialization Using the Console

Online consumer initialization using the console is the easiest way to initialize or reinitialize a consumer. However, if you are replicating across a slow link, this process can be very time consuming, and you may find manual consumer initialization using the command line to be a more efficient approach (refer to "Manual Consumer Initialization Using the Command Line" for more information).


Note When a consumer server is being initialized using the online consumer creation method, all operations (including searches) on the replica are referred to the supplier server until the initialization process is completed.



Performing Online Consumer Initialization

To initialize or reinitialize a consumer on line:

  1. On the supplier server, on the Directory Server Console, select the Configuration tab.

  2. Expand the Replication folder, then expand the replicated database. Right-click the replication agreement, and choose Initialize Consumer from the drop-down menu.

    A message is displayed to warn you that any information already stored in the replica on the consumer will be removed.

  3. Click Yes in the confirmation box.

Online consumer initialization begins immediately. You can check the status of the online consumer initialization in the replication agreement. If online consumer initialization is in progress, the consumer initialization status shows that a replica is being initialized.

To update this window, right-click the Replication Agreement icon in the navigation tree, and choose Refresh. When online consumer initialization finishes, the status changes to reflect this.

For more information about monitoring replication and initialization status, see "Monitoring Replication Status".


Manual Consumer Initialization Using the Command Line

Manual consumer initialization using the command line is the fastest method of consumer initialization for sites that are replicating very large numbers of entries. However, the manual consumer initialization process is more complex than the online consumer initialization process. We suggest you use the manual process whenever you find that the online process is inappropriate due to performance concerns.

This section is divided into the the following parts:


Manual Consumer Initialization Overview

To manually initialize or reinitialize a server:

  1. Export the replica on the supplier server to an LDIF file.

    See "Exporting a Replica to LDIF".

  2. Import the LDIF file with the supplier replica contents to the consumer server.

    See "Importing the LDIF File to the Consumer Server" for instructions.


    Note In a cascading replication environment, you can use the LDIF file exported from the supplier server to initialize both hub servers and the consumers of the hub servers.



Exporting a Replica to LDIF

You can convert the replica to LDIF using one of the following three procedures:

  1. When you create a replication agreement by selecting "Create consumer initialization file" in the Initialize Consumer dialog box of the Replication Wizard.

  2. From the Directory Server Console, at any time, by right-clicking the replication agreement under the Replication folder, and choosing "Export Replica" from the pop-up menu.

  3. From the command line, by using the export command as described in "Exporting to LDIF From the Command Line," on page 148.


Importing the LDIF File to the Consumer Server

You can import the LDIF file that contains the supplier replica contents to the consumer server by using the import features in the Directory Server Console, or by using either the ldif2db command or ldif2db.pl script (directoryserver ldif2db or directoryserver ldif2db-task on the Solaris 9 platform). Both import methods are described in "Importing From the Command Line," on page 141.

If you use the ldif2db.pl script, remember to bind using the supplier bind DN configured on the consumer server.


Note If you use the ldif2db.pl script, the LDIF file import operation does not require shutting down the server beforehand. For more information on command-line scripts see iPlanet Directory Server Configuration, Command, and File Reference.




Keeping Replicas in Sync


After you stop a directory server involved in replication for regular maintenance, when it comes back on line, you need to ensure that it gets updated through replication immediately. In the case of a master in a multi-master environment, the directory information needs to be updated by the other master in the multi-master set. In other cases, after a hub supplier or a dedicated consumer is taken off line for maintenance, when they come back on line, they need to be updated by the supplier server.

This section describes the replication retry algorithm, and how to force replication updates to occur without waiting for the next retry.


Note The procedures described in this section can be used only when replication is already set up, and consumers have been initialized.



Replication Retry Algorithm

When a supplier server is unsuccessful in an attempt to replicate to a consumer, it retries periodically in incremental time intervals. The retry pattern is as follows: 10 seconds, 20, 40, 80, until the interval reaches 5 minutes. Then it will retry every 5 minutes forever.

Note that even if you have configured replication agreements to always keep the supplier server and the consumer server in sync, this is not sufficient to bring back up-to-date immediately a server that has been off line for over five minutes.

To ensure that directory information will be synchronized immediately when a server comes back on line, you can use either the Directory Server Console on the supplier server that holds the reference copy of the directory information or a customizable script.


Forcing Replication Updates from the Console

To ensure that replication updates are sent immediately when a consumer or a supplier in a multi-master replication configuration comes back on line after a period of time, you can perform these steps on the supplier server that holds the most recent version of the directory information:

  1. On the Directory Server Console, click the Configuration tab, expand the Replication folder and the database nodes until you select the replication agreement corresponding to the replica that you must update.

  2. Right click the replication agreement, and choose Send Updates Now from the drop-down list.

    This initiates replication toward the server that holds the information that needs to be updated.


Forcing Replication Updates from the Command Line

From the consumer that requires updating, you can run a script that prompts the supplier to send replication updates immediately. This script is shown in Code Example 8-1.

You can copy this example and give it a meaningful name, for example, replicate_now.sh. You must provide actual values for the variables listed in Code Example 8-1.


Note The administrator must run this script as it cannot be configured to run automatically as soon as the server which was off line comes back on line again.


#!/bin/sh
SUP_HOST=supplier_hostname
SUP_PORT=supplier_portnumber
SUP_MGRDN=supplier_directoryManager
SUP_MGRPW=supplier_directoryManager_passwd
MY_HOST=consumer_hostname
MY_PORT=consumer_portnumber

ldapsearch -1 -h ${SUP_HOST} -p ${SUP_PORT} -D "${SUP_MGRDN}" \
-w ${SUP_MGRPW} -b "cn=mapping tree, cn=config" \
"(&(objectclass=nsds5replicationagreement) \
(nsDS5ReplicaHost=${MY_HOST})(nsDS5ReplicaPort=${MY_PORT}))" \
dn nsds5ReplicaUpdateSchedule > /tmp/$$

cat /tmp/$$ |
awk '
BEGIN { s = 0 }
/^dn: / { print $0;
print "changetype: modify";
print "replace: nsds5ReplicaUpdateSchedule";
print "nsds5ReplicaUpdateSchedule: 0000-2359 0123456";
print "-";
print "";
print $0;
print "changetype: modify";
print "replace: nsds5ReplicaUpdateSchedule";
}

/^nsds5ReplicaUpdateSchedule: / { s = 1; print $0; }

/^$/ {
if ( $s == 1 )
{ print "-" ; print ""; }
else
{ print "nsds5ReplicaUpdateSchedule: 0000-2359 0123456";
print "-" ; print ""; };
s = 0; }

' > /tmp/ldif.$$

echo "Ldif is in /tmp/ldif.$$"
echo

ldapmodify -c -h ${SUP_HOST} -p ${SUP_PORT} -D "${SUP_MGRDN}" \
-w ${SUP_MGRPW} -f /tmp/ldif.$$
"> Code Example 8-1    Replicate_Now Script Example
#!/bin/sh
SUP_HOST=supplier_hostname
SUP_PORT=supplier_portnumber
SUP_MGRDN=supplier_directoryManager
SUP_MGRPW=supplier_directoryManager_passwd
MY_HOST=consumer_hostname
MY_PORT=consumer_portnumber

ldapsearch -1 -h ${SUP_HOST} -p ${SUP_PORT} -D "${SUP_MGRDN}" \
-w ${SUP_MGRPW} -b "cn=mapping tree, cn=config" \
"(&(objectclass=nsds5replicationagreement) \
(nsDS5ReplicaHost=${MY_HOST})(nsDS5ReplicaPort=${MY_PORT}))" \
dn nsds5ReplicaUpdateSchedule > /tmp/$$

cat /tmp/$$ |
awk '
BEGIN { s = 0 }
/^dn: / { print $0;
print "changetype: modify";
print "replace: nsds5ReplicaUpdateSchedule";
print "nsds5ReplicaUpdateSchedule: 0000-2359 0123456";
print "-";
print "";
print $0;
print "changetype: modify";
print "replace: nsds5ReplicaUpdateSchedule";
}

/^nsds5ReplicaUpdateSchedule: / { s = 1; print $0; }

/^$/ {
if ( $s == 1 )
{ print "-" ; print ""; }
else
{ print "nsds5ReplicaUpdateSchedule: 0000-2359 0123456";
print "-" ; print ""; };
s = 0; }

' > /tmp/ldif.$$

echo "Ldif is in /tmp/ldif.$$"
echo

ldapmodify -c -h ${SUP_HOST} -p ${SUP_PORT} -D "${SUP_MGRDN}" \
-w ${SUP_MGRPW} -f /tmp/ldif.$$
If you intend to use this script, you must replace the variables with actual values in your replication environment.


Table 8-1    Replicate_Now Variables

Variable

Definition

supplier_hostname  

Hostname of the supplier to contact for information on replication agreements with the current consumer.  

supplier_portnumber  

LDAP port in use on the supplier.  

supplier_directoryManager  

DN of the privileged Directory Manager user on the supplier.  

supplier_directoryManager_passwd  

Password of the privileged Directory Manager user on the supplier.  

consumer_hostname  

Hostname of the current consumer.  

consumer_portnumber  

LDAP port in use on the consumer.  

If you want the update operation to occur over an SSL connection, you must modify the ldapmodify command in the script with the appropriate parameters and values. For more information on the ldapmodify command, refer to "Managing Entries From the Command Line," on page 52 and iPlanet Directory Server Configuration, Command, and File Reference.



Replication over SSL


You can configure Directory Servers involved in replication so that all replication operations occur over an SSL connection.

To use replication over SSL, you must first do the following:

  • Configure both your supplier and consumer servers to use SSL.

  • Configure your consumer server to recognize your supplier server's certificate as the supplier DN. You do this only if you want to use SSL client authentication rather than simple authentication.

These procedures are described in Chapter 11, "Managing SSL."


Note Replication over SSL will fail in the following cases:

  • If the supplier's certificate is a self-signed certificate

  • If the supplier's certificate is an SSL server-only certificate; that is, it cannot act as a client during an SSL handshake.


When your servers are configured to use SSL, you can ensure replication operations occur over SSL connections by using the:

  • Replication Wizard, when you set up the replication agreement between two Directory Servers.

  • Directory Server Console, at any time after the initial replication agreement was configured.


Configuring Replication Over SSL Using the Replication Wizard

  1. On the Directory Server Console of the supplier server, click the Configuration tab, expand the Replication folder and select the database that you want to replicate.

  2. Right-click the database, and choose New Replication Agreement from the drop-down menu.

    The Replication Agreement Wizard is displayed.

  3. Go through each step in the Replication Agreement Wizard until you reach the Source and Destination window.

  4. In the Connection section, check "Using Encrypted SSL Connnection."

  5. Select "SSL Client Authentication" or "Simple Authentication."

    If you select SSL Client Authentication, the supplier and consumer servers will use certificates to authenticate to each other.

    If you select Simple Authentication, the supplier and consumer servers will use a bind DN and password to authenticate to each other. You must specify this information in the text fields provided. When you specify this option, simple authentication takes place over a secure channel but without certificates.

  6. Click Next, and proceed with the replication setup.


Configuring Replication Over SSL Using the Console

  1. On the Directory Server Console of the supplier server, click the Configuration tab, expand the Replication folder and select the replication agreement that you want to modify to enable replication over SSL.

  2. Click the Connection tab in the right navigation window.

    This displays the replication connection settings.

  3. In the Connection section, check "Using Encrypted SSL Connnection."

  4. Select "SSL Client Authentication" or "Simple Authentication."

    If you select SSL Client Authentication, the supplier and consumer servers will use certificates to authenticate to each other.

    If you select Simple Authentication, the supplier and consumer servers will use a bind DN and password to authenticate to each other. You must specify this information in the text fields provided. When you specify this option, simple authentication takes place over a secure channel but without certificates.

  5. Click Save.



Replication with Earlier Releases

This section provides information on how to optimize replication with earlier releases of iPlanet Directory Server. iPlanet Directory Server 5.1 can be involved in replication scenarios with earlier releases of Directory Server, providing the following conditions are met:

  • Directory Server 5.1 is defined as a consumer in the replication agreement.

  • The legacy suppliers can be Directory Server 4.0, or 4.1x.

The following restrictions apply:

  • A legacy Directory Server and a 5.1 Directory Server cannot update the same replica. However, a 5.1 Directory Server can have different replicas, where one is supplied by a legacy Directory Server, and the other is supplied by a 5.1 Directory Server.

  • Directory Server 5.1 cannot be a supplier for other replicas.

The main advantage of being able to use a Directory Server 5.1 as a consumer of a legacy Directory Server is to ease the migration of a replicated environment. For more information on the steps to follow to migrate a replicated environment, refer to the iPlanet Directory Server Installation Guide.


Configuring Directory Server 5.1 as a Consumer of a Legacy Directory Server

If you intend to use your Directory Server 5.1 as a consumer of an earlier release of Directory Server, you must configure it as follows:

  1. On the Directory Server Console, click the Configuration tab.

  2. On the Configuration tab, select the Replication node and click the Legacy Consumer Settings tab in the right pane.

  3. Check the Enable Legacy Consumer checkbox.

    This activates the fields in the Authentication box.

  4. Specify the Supplier DN that the legacy supplier server will use to bind.

    Optionally, you can specify a password for the supplier. The password must contain at least 8 characters.

  5. Click Save.

    You must now configure consumer settings for each replica that will receive updates from a legacy supplier.

  6. In the navigation tree, expand the Replication node and select a replica that will receive updates from the legacy supplier.

  7. On the Replica Settings tab in the right pane, check the Enable Replica and the "Updatable by a 4.x Replica" checkboxes in the Common Settings box.

    These options are the only ones required for replication to work. It is not necessary to specify a Supplier DN, because the one you specified in Step 4 will be used.

  8. Click Save.

    Repeat Step 7 and Step 8 for each consumer replica that will receive updates from a legacy supplier.

    To complete your legacy replication setup, you must now configure the legacy supplier to replicate to the 5.1 Directory Server. For instructions on configuring a replication agreement on a 4.x Directory Server, refer to the documentation for your legacy Directory Server.


    Note Directory Server Console will not prevent you from configuring a database as a supplier replica and enabling legacy consumer settings. This makes migration easier because you can configure your 5.1 Directory Server as you want it to be after the migration, and activate legacy consumer settings just for the duration of the transition.




Using the Retro Change Log Plug-In

The retro change log plug-in enables you to configure iPlanet Directory Server 5.1 to maintain a change log that is compatible with the change log implemented in Directory Server 4.x. Maintaining a retro change log is essential in deployments where iPlanet Directory Server 5.1 coexists with iPlanet Meta Directory. You might also need to maintain a retro change log if you have directory clients that depend on a Directory Server 4.x style change log.

To use the retro change log plug-in, iPlanet Directory Server 5.1 must be configured as a supplier server in a single-master replication scenario.

When you have configured iPlanet Directory Server 5.1 to maintain a retro change log, this change log is stored in a separate database under a special suffix cn=changelog.

The retro change log consists of a single level of entries. Each entry in the change log has the object class changeLogEntry, and can include the attributes listed in Table 8-2.


Table 8-2    Attributes of a Retro Change Log Entry 

Attribute

Definition

changeNumber  

This single-valued atttribute is always present. It contains an integer that uniquely identifies each change. This number is related to the order in which the change occurred. The higher the number, the later the change.  

targetDN  

This attribute contains the DN of the entry that was affected by the LDAP operation. The the case of a modrdn operation, the targetDN attribute contains the DN of the entry before it was modified or moved.  

changeTime  

This attribute specifies the time at which the change operation occurred.  

changeType  

Specifies the type of LDAP operation. This attribute can have one of the following values: add, delete, modify, or modrdn.  

changes  

For add and modify operations, contains the changes made to the entry, in LDIF format.  

newRDN  

In the case of modrdn operations, specifies the new RDN of the entry.  

deleteOldRdn  

In the case of modrdn operations, specifies whether the old RDN was deleted.  

newSuperior  

In the case of modrdn operations, specifies the newSuperior attribute of the entry.  

This section contains information on the following retro change log items:


Enabling the Retro Change Log Plug-In

The retro change log plug-in configuration information is stored in the cn=Retro Changelog Plugin,cn=plugins,cn=config entry in dse.ldif.

The procedure for enabling the retro change log plug-in from Directory Server Console is the same as for all Directory Server plug-ins. For information, refer to "Enabling and Disabling Plug-Ins From the Server Console," on page 459.

To enable the retro change log plug-in from the command line:

  1. Create an LDIF file that contains the following LDIF update statements:

    dn: cn=Retro Changelog Plugin,cn=plugins,cn=config
    changetype: modify
    replace: nsslapd-pluginenabled
    nsslapd-pluginenabled: on

  2. Use the ldapmodify command to import the LDIF file into the directory.

    For more information on the ldapmodify command, refer to "Managing Entries From the Command Line," on page 52 and iPlanet Directory Server Configuration, Command, and File Reference.

  3. Restart the server.

    For information on restarting the server, refer to "Starting and Stopping the Directory Server," on page 35.

The retro change log is created in the directory tree under a special suffix cn=changelog.


Trimming the Retro Change Log

The entries in the change log can be removed automatically after a specified period of time. To configure the period of time after which entries are deleted automatically from the change log, you must set the nsslapd-changelogmaxage configuration attribute in the cn=Retro Changelog Plugin, cn=plugins, cn=config entry.

The nsslapd-changelogmaxage attribute is a single-valued attribute of the form:

nsslapd-changelogmaxage: Integer timeUnit

where integer represents a number, and timeUnit can be one of the following: s for seconds, m for minutes, h for hours, d for days, or w for weeks.


Note There should be no space between the Integer and timeUnit variables. The space in the syntax above is intended to show that the attribute value is composed of two variable parts, not just one.


Example of nsslapd-changelogmaxage value:

nsslapd-changelogmaxage: 2d


Searching and Modifying the Retro Change Log

The change log supports search operations. It is optimized for searches that include filters of the form:

(&(changeNumber>=X)(changeNumber<=Y))

As a general rule, you should not perform add or modify operations on the retro change log entries, although you can delete entries to trim the size of the change log. The only time you will need to perform a modify operation on the retro change log is to modify the default access control policy.


Retro Change Log and the Access Control Policy

When the retro change log is created, by default, the following access control rules apply:

  • Read, search, and compare rights are granted to all authenticated users (userdn=anyone, not to be confused with anonymous access where userdn=all) to the retro change log top entry cn=changelog.

  • Write and delete access are not granted, except implicitly to the Directory Manager.

You should not grant read access to anonymous users, because the change log entries can contain modifications to sensitive information, such as passwords. Only authenticated applications and users should be allowed to access this information.

To modify the default access control policy that applies to the retro change log, you can modify the aci attribute of the cn=changelog entry.



Monitoring Replication Status


You can monitor replication status using the Directory Server Console.

To view a summary of replication status:

  1. On the Directory Server Console, select the Status tab and then select Replication Status in the left navigation tree.

    In the right pane, a table appears that contains information about each of the replication agreements configured for this server.

  2. Click Refresh to update the contents of the tab.

The status information displayed is described in Table 8-3.


Table 8-3    Directory Server Console - Status Tab 

Table Header

Description

Agreement  

Contains the name you provided when you set up the replication agreement.  

Replica suffix  

Contains the suffix that is replicated.  

Supplier  

Specifies the supplier server in the agreement.  

Consumer  

Specifies the consumer server in the agreement.  

Number of changes  

Indicates the number of changes sent to this replica since the server started.  

Last replica update began  

Indicates when the most recent replication update started.  

Last replica update ended  

Indicates when the most recent replication update ended.  

Last update message  

Provides the status for the most recent replication updates.  

Consumer initialization  

Provides current status on consumer initialization (in progress or not).  

Last consumer initialization update message  

Provides status on the last initialization of the consumer.  

Last consumer initialization began  

States when the initialization of the consumer replica started.  

Last consumer initialization ended  

States when the initialization of the consumer replica ended.  



Solving Common Replication Conflicts


Multi-master replication uses a loose consistency replication model. This means that the same entries can be changed on different servers. When replication occurs between the two servers, the conflicting changes need to be resolved. Mostly, resolution occurs automatically, based on the timestamp associated with the change on each server. The most recent change takes precedence.

However, there are some cases where change conflicts require manual intervention in order to reach a resolution. Entries that have a change conflict that cannot be resolved automatically by the replication process contain a conflict marker attribute nsds5ReplConflict. The nsdsReplConflict attribute is an operational attribute. Therefore, it is simple to search for entries that contain this attribute.

For example, you could use the following ldapsearch command:

% ldapsearch -D adminDN -w passwd \
-b "dc=siroe,dc=com" "nsds5ReplConflict=*"

Note that the nsds5ReplConflict attribute is indexed by default.

This section contains the procedures for the following conflict resolution procedures:


Solving Naming Conflicts

When two entries are created with the same DN on different servers, during replication, the automatic conflict resolution procedure renames the last entry created by including the entry's unique identifier in the DN. Every directory entry includes a unique identifier given by the operational attribute nsuniqueid. When a naming conflict occurs, this unique ID is appended to the non-unique DN.

For example, the entry uid=adamss,ou=people,dc=siroe,dc=com is created on Server A at time t1, and on Server B at time t2, where t2 is greater (or later) than t1. After replication, Server A and Server B both hold the following entries:

  • uid=adamss,ou=people,dc=siroe,dc=com (created at time t1)

  • nsuniqueid=66446001-1dd211b2+uid=adamss,dc=siroe,dc=com (created at time t2)

The second entry needs to be renamed in such a way that it has a unique DN. The renaming procedure depends on whether the naming attribute is single-valued or multi-valued. Each procedure is described below.


Renaming an Entry with a Multi-Valued Naming Attribute

To rename an entry that has a multi-valued naming attribute:

  1. Rename the entry using a new value for the naming attribute, and keep the old RDN. For example:

    prompt% ldapmodify -D adminDN -w passwd

    >dn: nsuniqueid=66446001-1dd211b2+uid=adamss,dc=siroe,dc=com
    >changetype: modrdn
    >newrdn: uid=NewValue
    >deleteoldrdn: 0

  2. Remove the old RDN value of the naming attribute, and the conflict marker attribute. For example:

    prompt% ldapmodify -D adminDN -w passwd

    >dn: uid=NewValue,dc=siroe,dc=com
    >changetype: modify
    >delete: uid
    >uid: adamss
    >-
    >delete: nsds5ReplConflict
    >-


    Note This is a two-step procedure because you cannot delete the unique identifier attribute nsuniqueid.


For more information on the ldapmodify command, refer to "Managing Entries From the Command Line," on page 52 and iPlanet Directory Server Configuration, Command, and File Reference.


Renaming an Entry with a Single-Valued Naming Attribute

To rename an entry that has a single-valued naming attribute:

  1. Rename the entry using a different naming attribute, and keep the old RDN. For example:

    prompt% ldapmodify -D adminDN -w passwd

    >dn: nsuniqueid=66446001-1dd211b2+dc=pubs,dc=siroe,dc=com
    >changetype: modrdn
    >newrdn: cn=TempValue
    >deleteoldrdn: 0

  2. Remove the old RDN value of the naming attribute, and the conflict marker attribute. For example:

    prompt% ldapmodify -D adminDN -w passwd

    >dn: cn=TempValue,dc=siroe,dc=com
    >changetype: modify
    >delete: dc
    >dc: pubs
    >-
    >delete: nsds5ReplConflict
    >-


    Note This is a two-step procedure because you cannot delete the unique identifier attribute nsuniqueid.


  3. Rename the entry with the intended attribute-value pair. For example:

    prompt% ldapmodify -D adminDN -w passwd

>dn: cn=TempValue,dc=siroe,dc=com
>changetype: modrdn
>newrdn: dc=NewValue
>deleteoldrdn: 1


By setting the value of the deleteoldrdn attribute to 1, you delete the temporary attribute-value pair cn=TempValue. If you want to keep this attribute, you can set the value of the deleteoldrdn attribute to 0.

For more information on the ldapmodify command, refer to "Managing Entries From the Command Line," on page 52 and iPlanet Directory Server Configuration, Command, and File Reference.


Solving Orphan Entry Conflicts

When a delete operation is replicated, and the consumer server finds that the entry to be deleted has child entries, the conflict resolution procedure creates a glue entry to avoid having orphaned entries in the directory.

In the same way, when an add operation is replicated, and the consumer server cannot find the parent entry, the conflict resolution procedure creates a glue entry representing the parent so that the new entry is not an orphan entry.

Glue entries are temporary entries that include the object classes glue and extensibleObject. Glue entries can be created in several ways:

  • If the conflict resolution procedure finds a deleted entry with a matching unique identifier, the glue entry is a resurrection of that entry, with the addition of the glue object class, and the nsds5ReplConflict attribute.

    In such cases, you can either modify the glue entry to remove the glue object class and the nsds5ReplConflict attribute, to keep the entry as a normal entry, or you can delete the glue entry and its child entries.

  • The server creates a minimalistic entry with the glue and extensibleObject object classes.

    In such cases, you must modify the entry to turn it into a meaningful entry, or delete it and all of its child entries.


Solving Potential Interoperability Problems

For reasons of interoperability with applications that rely on attribute uniqueness such as a mail server, you might need to restrict access to the entries that contain the nsds5ReplConflict attribute. If you do not restrict access to these entries, then the applications requiring one attribute only will pick up both the original entry and the conflict resolution entry containing the nsds5ReplConflict and operations will fail.

To restrict access you need to modify the default ACI that grants anonymous read access, using the following command:

ldapmodify -h hostname -D "cn=Directory Manager" -w passwd

> dn: dc=siroe,dc=com
> changetype: modify
> delete: aci
> aci: (target ="ldap:///dc=siroe,dc=com")(targetattr !="userPassword")(version 3.0;acl "Anonymous read-search access";allow (read, search, compare)(userdn = "ldap:///anyone");)
> -
> add: aci

> aci: (target="ldap:///dc=siroe,dc=com")(targetattr!="userPassword") (targetfilter="(!(nsds5ReplConflict=*))")(version 3.0;acl "Anonymous read-search access";allow (read, search, compare) (userdn="ldap:///anyone");)

> -

The new ACI filters out all entries that contain the nsds5ReplConflict attribute from search results.

For more information on the ldapmodify command, refer to "Managing Entries From the Command Line," on page 52 and iPlanet Directory Server Configuration, Command, and File Reference.


Previous     Contents     Index     Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated October 29, 2001