Reinstate subordinate directive, delete references to slapo-glue

This commit is contained in:
Howard Chu 2005-09-01 12:10:26 +00:00
parent 5a9a32e0d7
commit f8ec98588b
2 changed files with 30 additions and 98 deletions

View File

@ -1392,6 +1392,36 @@ backend database. Multiple suffix lines can be given and at least one is
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.
.HP
.hy 0
.B syncrepl rid=<replica ID>
@ -1764,15 +1794,6 @@ lastmod off
"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

View File

@ -1,89 +0,0 @@
.TH SLAPO-GLUE 5 "RELEASEDATE" "OpenLDAP LDVERSION"
.\" Copyright 2004-2005 The OpenLDAP Foundation All Rights Reserved.
.\" Copying restrictions apply. See COPYRIGHT/LICENSE.
.\" $OpenLDAP$
.SH NAME
slapo-glue \- Backend Glue overlay
.SH SYNOPSIS
ETCDIR/slapd.conf
.SH DESCRIPTION
The Backend Glue overlay can be used to glue multiple databases into a
single namingContext. The overlay must be configured on the root database
of the context, and any other databases must be explicitly configured
as subordinates of the root database. All of the participating databases
should have identical rootdns.
All search and write operations will be intercepted by this overlay. Searches
against the root database will be propagated to all the subordinates. Write
operations will pass unaltered to the relevant target database.
If the slap tools
.BR slapcat (8),
.BR slapadd (8)
and
.BR slapindex (8)
are used on the root database, any glued subordinates that support these
tools are opened as well.
Note that
any overlays on the root database configured before this overlay will fail
to execute. As such, the glue overlay should always be the first overlay
configured on the root database.
.SH CONFIGURATION
These
.B slapd.conf
options apply to the Backend Glue overlay.
They should appear after the
.B overlay
directive and before any subsequent
.B database
directive.
.TP
.B glue-sub <suffix-DN> [async] [advertise]
Specify the suffix of a database to attach as a subordinate to the root
database. The specified database must have already been configured. If the
optional \fBasync\fP keyword is supplied, searches against this database may
be spawned in a separate thread to run concurrently with other operations
(currently not implemented). If the optional \fBadvertise\fP flag
is supplied, the naming context is advertised in the root DSE.
.SH EXAMPLE
The following will cause a search from dc=example,dc=com to search
people as well, but it will not search services.
.LP
.RS
.nf
database bdb
suffix "ou=people,dc=example,dc=com"
database bdb
suffix "ou=services,dc=example,dc=com"
database bdb
suffix "dc=example,dc=com"
overlay glue
glue-sub "ou=people,dc=example,dc=com"
.fi
.RE
.SH NOTES
Databases that are glued together should usually be configured with
the same indexes, even for attributes that only exist in some of
these databases.
A search for an attribute which is only indexed in some of the glued
databases must otherwise examine each entry in the search scope in the
other databases, looking for the attribute.
If the extra indexes assist searches one would prefer not to
support, these can be disabled with access controls in some of the
databases.
E.g.:
.RS
access to attrs=cn by * =rcxd
.RE
See
.BR slapd.access (5).
.SH FILES
.TP
ETCDIR/slapd.conf
default slapd configuration file
.SH SEE ALSO
.BR slapd.conf (5).