Red Hat Directory Server 8.0 Administrator's Guide

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-pluginarg0 attribute 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.
Chapter 18. Using the Attribute Uniqueness Plug-in
512