required for each database definition.
If the suffix of one database is "inside" that of another, the database
with the inner suffix must come first in the configuration file.
+.TP
+.B subordinate [advertise]
+Specify that the current backend database is a subordinate of another
+backend database. A subordinate database may have only one suffix. This
+option may be used to glue multiple databases into a single namingContext.
+If the suffix of the current database is within the namingContext of a
+superior database, searches against the superior database will be
+propagated to the subordinate as well. All of the databases
+associated with a single namingContext should have identical rootdns.
+Behavior of other LDAP operations is unaffected by this setting. In
+particular, it is not possible to use moddn to move an entry from
+one subordinate to another subordinate within the namingContext.
+
+If the optional \fBadvertise\fP flag is supplied, the naming context of
+this database is advertised in the root DSE. The default is to hide this
+database context, so that only the superior context is visible.
+
+If the slap tools
+.BR slapcat (8),
+.BR slapadd (8),
+or
+.BR slapindex (8)
+are used on the superior database, any glued subordinates that support
+these tools are opened as well.
+
+Databases that are glued together should usually be configured with the
+same indices (assuming they support indexing), even for attributes that
+only exist in some of these databases. In general, all of the glued
+databases should be configured as similarly as possible, since the intent
+is to provide the appearance of a single directory.
+
+Note that the \fIsubordinate\fP functionality is implemented internally
+by the \fIglue\fP overlay and as such its behavior will interact with other
+overlays in use. By default, the glue overlay is automatically configured as
+the last overlay on the superior backend. Its position on the backend
+can be explicitly configured by setting an \fBoverlay glue\fP directive
+at the desired position. This explicit configuration is necessary e.g.
+when using the \fIsyncprov\fP overlay, which needs to follow \fIglue\fP
+in order to work over all of the glued databases. E.g.
+.RS
+.nf
+ database bdb
+ suffix dc=example,dc=com
+ ...
+ overlay glue
+ overlay syncprov
+.fi
+.RE
.HP
.hy 0
.B syncrepl rid=<replica ID>
.B [credentials=<passwd>]
.B [realm=<realm>]
.B [secprops=<properties>]
+.B [logbase=<base DN>]
+.B [logfilter=<filter str>]
+.B [syncdata=default|accesslog|changelog]
.RS
Specify the current database as a replica which is kept up-to-date with the
master content by establishing the current
option. A non default SASL realm can be set with the
.B realm
option.
+
+Rather than replicating whole entries, the consumer can query logs of
+data modifications. This mode of operation is referred to as \fIdelta
+syncrepl\fP. In addition to the above parameters, the
+.B logbase
+and
+.B logfilter
+parameters must be set appropriately for the log that will be used. The
+.B syncdata
+parameter must be set to either "accesslog" if the log conforms to the
+.BR slapo-accesslog (5)
+log format, or "changelog" if the log conforms
+to the obsolete \fIchangelog\fP format. If the
+.B syncdata
+parameter is omitted or set to "default" then the log parameters are
+ignored.
.RE
.TP
.B updatedn <dn>
.B sql
This backend is experimental.
It services LDAP requests from an SQL database.
+.SH OVERLAYS
+The following overlays can be compiled into slapd.
+They are documented in the
+.BR slapo-<overlay> (5)
+manual pages.
+.TP
+.B accesslog
+Access Logging.
+This overlay can record accesses to a given backend database on another
+database.
+.TP
+.B auditlog
+Audit Logging.
+This overlay records changes on a given backend database to an LDIF log
+file.
+By default it is not built.
+.TP
+.B chain
+Chaining.
+This overlay allows automatic referral chasing when a referral would
+have been returned.
+.TP
+.B denyop
+Deny Operation.
+This overlay allows selected operations to be denied, similar to the
+\fBrestrict\fP option.
+.TP
+.B dyngroup
+Dynamic Group.
+This is a demo overlay which extends the Compare operation to detect
+members of a dynamic group.
+It has no effect on any other operations.
+.TP
+.B dynlist
+Dynamic List.
+This overlay allows expansion of dynamic groups and more.
+.TP
+.B lastmod
+Last Modification.
+This overlay maintains a service entry in the database with the DN,
+modification type, modifiersName and modifyTimestamp of the last write
+operation performed on that database.
+.TP
+.B pcache
+Proxycache.
+This overlay allows caching of LDAP search requests in a local database.
+.TP
+.B ppolicy
+Password Policy.
+This overlay provides a variety of password control mechanisms,
+e.g. password aging, password reuse and duplication control, mandatory
+password resets, etc.
+.TP
+.B refint
+Referential Integrity.
+This overlay can be used with a backend database such as
+.BR slapd-bdb (5)
+to maintain the cohesiveness of a schema which utilizes reference
+attributes.
+.TP
+.B retcode
+Return Code.
+This overlay is useful to test the behavior of clients when
+server-generated erroneous and/or unusual responses occur.
+.TP
+.B rwm
+Rewrite/remap.
+This overlay is experimental.
+It performs basic DN/data rewrite and
+objectClass/attributeType mapping.
+.TP
+.B syncprov
+Syncrepl Provider.
+This overlay implements the provider-side support for
+.B syncrepl
+replication, including persistent search functionality.
+.TP
+.B translucent
+Translucent Proxy.
+This overlay can be used with a backend database such as
+.BR slapd-bdb (5)
+to create a "translucent proxy".
+Content of entries retrieved from a remote LDAP server can be partially
+overridden by the database.
+.TP
+.B unique
+Attribute Uniqueness.
+This overlay can be used with a backend database such as
+.BR slapd-bdb (5)
+to enforce the uniqueness of some or all attributes within a subtree.
.SH EXAMPLES
.LP
Here is a short example of a configuration file:
attributeoptions x-hidden lang-
access to attr=name;x-hidden by * =cs
+# Protect passwords. See \fBslapd.access\fP(5).
+access to attrs=userPassword by * auth
+# Read access to other attributes and entries.
+access to * by * read
+
database bdb
suffix "dc=our-domain,dc=com"
# The database directory MUST exist prior to
"OpenLDAP Administrator's Guide" contains a longer annotated
example of a configuration file.
The original ETCDIR/slapd.conf is another example.
-.SH OBSOLETED DIRECTIVES
-.TP
-.B subordinate
-This directive was used in OpenLDAP 2.1 and 2.2 to glue a database
-with its superior. The same functionality is now provided by the
-.B glue
-overlay; see
-.BR slapo-glue (5)
-for details.
.SH FILES
.TP
ETCDIR/slapd.conf
.BR slapo\-auditlog (5),
.BR slapo\-chain (5),
.BR slapo\-dynlist (5),
-.BR slapo\-glue (5),
.BR slapo\-lastmod (5),
.BR slapo\-pcache (5),
.BR slapo\-ppolicy (5),
projects / openldap / blobdiff