Chapter 18. Using the Attribute Uniqueness Plug-in

dn: cn=mail uniqueness,cn=plugins,cn=config

...

nsslapd-pluginEnabled: on

nsslapd-pluginarg0: mail

nsslapd-pluginarg1: l=Chicago,dc=example,dc=com

nsslapd-pluginarg2: l=Boston,dc=example,dc=com

...

NOTE

The nsslapd-pluginarg0attribute always contains the name of the attribute for which to ensure uniqueness. All other occurrences of the nsslapd-pluginarg, such as nsslapd-pluginarg1, contain DNs.

With this configuration, the plug-in allows an instance of a value for the mail attribute to exist once under the l=Chicago,dc=example,dc=com subtree and once under the l=Boston,dc=example,dc=com subtree. For example, the following two attribute-value settings are allowed:

mail=bjensen,l=Chicago,dc=example,dc=com

mail=bjensen,l=Boston,dc=example,dc=com

To ensure that only one instance of a value exists under both subtrees, configure the plug-in to ensure uniqueness for the entire dc=example,dc=com subtree.

6. Replication and the Attribute Uniqueness Plug-in

When using the Attribute Uniqueness Plug-ins on Directory Servers involved in a replication agreement, carefully consider how to configure the plug-in on each server.

Consider the following cases:

Simple replication with one supplier and one or several consumers.

Complex replication with multiple masters.

Attribute Uniqueness Plug-ins do not perform any checking on attribute values when an update is performed as part of a replication operation.

6.1. Simple Replication Scenario

Because all modifications by client applications are performed on the supplier server, the Attribute Uniqueness Plug-in should be enabled on the supplier. It is unnecessary to enable it on the consumer server.

512

Page 532
Image 532
HP UX Red Hat Direry Server Software manual Replication and the Attribute Uniqueness Plug-in, Simple Replication Scenario