# $OpenLDAP$
-# Copyright 2007 The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 2007-2008 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
H1: Backends
-H2: Berkley DB Backends
+H2: Berkeley DB Backends
H3: Overview
The {{bdb}} backend to {{slapd}}(8) is the recommended primary backend for a
normal {{slapd}} database. It uses the Oracle Berkeley DB ({{TERM:BDB}})
package to store data. It makes extensive use of indexing and caching
-(see {{SECT:Tuning}}) to speed data access.
+(see the {{SECT:Tuning}} section) to speed data access.
{{hdb}} is a variant of the {{bdb}} backend that uses a hierarchical database
layout which supports subtree renames. It is otherwise identical to the {{bdb}}
their own private connection to the remote LDAP server. Anonymous sessions
will share a single anonymous connection to the remote server. For sessions
bound through other mechanisms, all sessions with the same DN will share the
-same connection. This connection pooling strategy can enhance the proxy’s
+same connection. This connection pooling strategy can enhance the proxy's
efficiency by reducing the overhead of repeatedly making/breaking multiple
connections.
The LDIF backend to {{slapd}}(8) is a basic storage backend that stores
entries in text files in LDIF format, and exploits the filesystem to create
the tree structure of the database. It is intended as a cheap, low performance
-easy to use backend, and it is exploited by higher-level internal structures
-to provide a permanent storage.
+easy to use backend.
-When using Dynamic configuration over LDAP via {{cn=config}}, this is where all
-configuration is stored if {{slapd}}(8) if started with {{-F}}. See {{slapd-config.5}](5)
+When using the {{cn=config}} dynamic configuration database with persistent
+storage, the configuration data is stored using this backend. See {{slapd-config}}(5)
for more information
H3: back-ldif Configuration
The Null backend to {{slapd}}(8) is surely the most useful part of slapd:
-- Searches return success but no entries.
-- Compares return compareFalse.
-- Updates return success (unless readonly is on) but do nothing.
-- Binds other than as the rootdn fail unless the database option "bind on" is given.
-- The slapadd(8) and slapcat(8) tools are equally exciting.
+* Searches return success but no entries.
+* Compares return compareFalse.
+* Updates return success (unless readonly is on) but do nothing.
+* Binds other than as the rootdn fail unless the database option "bind on" is given.
+* The slapadd(8) and slapcat(8) tools are equally exciting.
Inspired by the {{F:/dev/null}} device.
distribute information between different sites/applications that use RDBMSes
and/or LDAP. Or whatever else...
-It is NOT designed as a general-purpose backend that uses RDBMS instead of
+It is {{B:NOT}} designed as a general-purpose backend that uses RDBMS instead of
BerkeleyDB (as the standard BDB backend does), though it can be used as such with
-several limitations. You can take a look at {{URL:http://www.openldap.org/faq/index.cgi?file=378}}
- (OpenLDAP FAQ-O-Matic/General LDAP FAQ/Directories vs. conventional databases)
- to find out more on this point.
+several limitations. Please see {{SECT: LDAP vs RDBMS}} for discussion.
The idea is to use some meta-information to translate LDAP queries to SQL queries,
leaving relational schema untouched, so that old applications can continue using
projects / openldap / blobdiff