slapd.backends - backends for slapd, the stand-alone LDAP daemon
The slapd(8) daemon can use a variety of different backends for serving
LDAP requests. Backends may be compiled statically into slapd, or when module
support is enabled, they may be dynamically loaded. Multiple instances of a
backend can be configured, to serve separate databases from the same slapd
Configuration options for each backend are documented separately
in the corresponding slapd-<backend>(5) manual pages.
- This was the recommended primary backend through OpenLDAP 2.3, but it has
since been superseded by the hdb backend. It takes care to
configure it properly. It uses the transactional database interface of the
Oracle Berkeley DB (BDB) package to store data.
- This backend is used to manage the configuration of slapd at run-time.
Unlike other backends, only a single instance of the config backend
may be defined. It also instantiates itself automatically, so it is always
present even if not explicitly defined in the slapd.conf(5)
- This backend is experimental. It serves up referrals based upon SRV
resource records held in the Domain Name System.
- This is the recommended primary backend for a normal slapd database.
hdb is a variant of the bdb backend that uses a hierarchical
database layout. This layout stores entry DNs more efficiently than the
bdb backend, using less space and requiring less work to create,
delete, and rename entries. It is also one of the few backends to support
- This backend acts as a proxy to forward incoming requests to another LDAP
- This database uses the filesystem to build the tree structure of the
database, using plain ascii files to store data. Its usage should be
limited to very simple databases, where performance is not a requirement.
This backend also supports subtree renames.
- This will soon be the recommended primary backend, superseding hdb.
This backend uses OpenLDAP's own MDB transactional database library. It is
extremely compact and extremely efficient, delivering much higher
performance than the Berkeley DB backends while using significantly less
memory. Also, unlike Berkeley DB, MDB is crash proof, and requires no
special tuning or maintenance. This backend also supports subtree
- This backend performs basic LDAP proxying with respect to a set of remote
LDAP servers. It is an enhancement of the ldap backend.
- This backend provides information about the running status of the slapd
daemon. Only a single instance of the monitor backend may be
- This backend is experimental. It uses the transactional database interface
of the MySQL Cluster Engine (NDB) to store data. Note that Oracle, which
now owns MySQL, has withdrawn support for NDB and this backend is unlikely
to be developed any further.
- Operations in this backend succeed but do nothing.
- This backend is provided for demonstration purposes only. It serves up
user account information from the system passwd(5) file.
- This backend embeds a perl(1) interpreter into slapd. It runs Perl
subroutines to implement LDAP operations.
- This backend is experimental. It redirects LDAP operations to another
database in the same server, based on the naming context of the request.
Its use requires the rwm overlay (see slapo-rwm(5) for
details) to rewrite the naming context of the request. It is primarily
intended to implement virtual views on databases that actually store
- This backend executes external programs to implement LDAP operations. It
is primarily intended to be used in prototypes.
- This backend is experimental. It services LDAP requests from an SQL
- default slapd configuration file
- default slapd configuration directory
ldap(3), slapd-bdb(5), slapd-config(5),
slapd-dnssrv(5), slapd-hdb(5), slapd-ldap(5),
slapd-ldif(5), slapd-mdb(5), slapd-meta(5),
slapd-monitor(5), slapd-ndb(5), slapd-null(5),
slapd-passwd(5), slapd-perl(5), slapd-relay(5),
slapd-shell(5), slapd-sql(5), slapd.conf(5),
slapd.overlays(5), slapd(8). "OpenLDAP Administrator's
OpenLDAP Software is developed and maintained by The OpenLDAP Project
<http://www.openldap.org/>. OpenLDAP Software is derived from the
University of Michigan LDAP 3.3 Release.