This is used in the Makefile rule to build guide.pdf. Hence the -f is bogus.

[openldap] / doc / guide / admin / backends.sdf

diff --git a/doc/guide/admin/backends.sdf b/doc/guide/admin/backends.sdf
index 5eeb7aebd3ba414e4459035778f5b0b48870f69a..013288f45364afaf95cce4aec248f42226c34218 100644 (file)
--- a/doc/guide/admin/backends.sdf
+++ b/doc/guide/admin/backends.sdf
@@ -5,7 +5,7 @@
 H1: Backends
 
 
-H2: Berkley DB Backends
+H2: Berkeley DB Backends
 
 
 H3: Overview
@@ -70,11 +70,10 @@ H3: Overview
 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
@@ -146,11 +145,11 @@ H3: Overview
 
 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.
 
@@ -237,11 +236,9 @@ an RDBMS, and want to use modern solutions that expect such information in LDAP
 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