Sync 2.4 guide with HEAD for 2.4.5

doc/guide/COPYRIGHT

@@ -36,9 +36,11 @@ Public License.
 
 ---
 
-Portions Copyright 1999-2005 Howard Y.H. Chu.
-Portions Copyright 1999-2005 Symas Corporation.
+Portions Copyright 1999-2007 Howard Y.H. Chu.
+Portions Copyright 1999-2007 Symas Corporation.
 Portions Copyright 1998-2003 Hallvard B. Furuseth.
+Portions Copyright 2007 Gavin Henry
+Portions Copyright 2007 Suretec Systems
 All rights reserved.
 
 Redistribution and use in source and binary forms, with or without

doc/guide/admin/Makefile

@@ -18,16 +18,19 @@ sdf-src: \
 	../plain.sdf \
 	../preamble.sdf \
 	abstract.sdf \
+	appendix-configs.sdf \
+	backends.sdf \
 	config.sdf \
 	dbtools.sdf \
 	glossary.sdf \
 	guide.sdf \
 	install.sdf \
 	intro.sdf \
+	maintenance.sdf \
 	master.sdf \
 	monitoringslapd.sdf \
+	overlays.sdf \
 	preface.sdf \
-	proxycache.sdf \
 	quickstart.sdf \
 	referrals.sdf \
 	replication.sdf \
@@ -36,21 +39,19 @@ sdf-src: \
 	schema.sdf \
 	security.sdf \
 	slapdconfig.sdf \
-	syncrepl.sdf \
 	title.sdf \
 	tls.sdf \
+	troubleshooting.sdf \
 	tuning.sdf
 
 sdf-img: \
 	../images/LDAPlogo.gif \
-	config_local.gif \
-	config_ref.gif \
+	config_dit.png \
+	config_local.png \
+	config_ref.png \
 	config_repl.gif \
-	config_x500fe.gif \
-	config_x500ref.gif \
-	intro_dctree.gif \
-	intro_tree.gif \
-	replication.gif
+	intro_dctree.png \
+	intro_tree.png \
 
 guide.html: guide.sdf sdf-src sdf-img
 	sdf -2html guide.sdf
@@ -62,6 +63,7 @@ admin.html: admin.sdf sdf-src sdf-img
 	sdf -DPDF -2html admin.sdf
 
 guide.pdf: admin.html
-	htmldoc --book --duplex --bottom 36 --top 36 \
-		--toclevels 2 \
-		-f guide.pdf admin.html
+	htmldoc --batch guide.book
+
+clean: 
+	rm -f *.pdf *.html *~

doc/guide/admin/README.spellcheck

+# $OpenLDAP$
+# Copyright 2007 The OpenLDAP Foundation, All Rights Reserved.
+# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
+#
+# README.spellcheck 
+#
+
+aspell.en.pws
+	We use aspell to spell check the Admin Guide and Man Pages.
+	
+	Please move aspell.en.pws to ~/.aspell.en.pws and run:
+	
+	aspell --lang=en_US -c <filename>
+	
+	If you add additional words and terms, please add
+	them or copy them to aspell.en.pws and commit.

doc/guide/admin/appendix-changes.sdf

+# $OpenLDAP$
+# Copyright 2007 The OpenLDAP Foundation, All Rights Reserved.
+# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
+
+H1: Changes Since Previous Release
+
+The following sections attempt to summarize the new features and changes in OpenLDAP
+software since the 2.3.x release and the OpenLDAP Admin Guide.
+
+H2: New Guide Sections
+
+In order to make the Admin Guide more thorough and cover the majority of questions
+asked on the OpenLDAP mailing lists and scenarios discussed there, we have added the following new sections:
+
+* {{SECT:When should I use LDAP?}}
+* {{SECT:When should I not use LDAP?}}
+* {{SECT:LDAP vs RDBMS}}
+* {{SECT:Backends}}
+* {{SECT:Overlays}}
+* {{SECT:Replication}}
+* {{SECT:Maintenance}}
+* {{SECT:Monitoring}}
+* {{SECT:Tuning}}
+* {{SECT:Troubleshooting}}
+* {{SECT:Changes Since Previous Release}}
+* {{SECT:Configuration File Examples}}
+* {{SECT:Glossary}}
+
+Also, the table of contents is now 3 levels deep to ease navigation.
+
+
+H2: New Features and Enhancements in 2.4
+
+H3: Better {{B:cn=config}} functionality
+
+There is a new slapd-config(5) manpage for the {{B:cn=config}} backend. The 
+original design called for auto-renaming of config entries when you insert or 
+delete entries with ordered names, but that was not implemented in 2.3. It is 
+now in 2.4. This means, e.g., if you have
+
+>   olcDatabase={1}bdb,cn=config
+>   olcSuffix: dc=example,dc=com
+
+and you want to add a new subordinate, now you can ldapadd:
+
+>   olcDatabase={1}bdb,cn=config
+>   olcSuffix: dc=foo,dc=example,dc=com
+
+This will insert a new BDB database in slot 1 and bump all following databases
+ down one, so the original BDB database will now be named:
+
+>   olcDatabase={2}bdb,cn=config
+>   olcSuffix: dc=example,dc=com
+
+H3: Better {{B:cn=schema}} functionality
+
+In 2.3 you were only able to add new schema elements, not delete or modify 
+existing elements. In 2.4 you can modify schema at will. (Except for the 
+hardcoded system schema, of course.)
+
+H3: More sophisticated Syncrepl configurations
+
+The original implementation of Syncrepl in OpenLDAP 2.2 was intended to support 
+multiple consumers within the same database, but that feature never worked and 
+was removed from OpenLDAP 2.3; you could only configure a single consumer in 
+any database.
+
+In 2.4 you can configure multiple consumers in a single database. The configuration 
+possibilities here are quite complex and numerous. You can configure consumers 
+over arbitrary subtrees of a database (disjoint or overlapping). Any portion 
+of the database may in turn be provided to other consumers using the Syncprov 
+overlay. The Syncprov overlay works with any number of consumers over a single 
+database or over arbitrarily many glued databases.
+
+H3: N-Way Multimaster Replication
+
+As a consequence of the work to support multiple consumer contexts, the syncrepl 
+system now supports full N-Way multimaster replication with entry-level conflict 
+resolution. There are some important constraints, of course: In order to maintain 
+consistent results across all servers, you must maintain tightly synchronized 
+clocks across all participating servers (e.g., you must use NTP on all servers). 
+
+The entryCSNs used for replication now record timestamps with microsecond resolution, 
+instead of just seconds. The delta-syncrepl code has not been updated to support 
+multimaster usage yet, that will come later in the 2.4 cycle.
+
+H3: Replicating {{slapd}} Configuration (syncrepl and {{B:cn=config}})
+
+Syncrepl was explicitly disabled on cn=config in 2.3. It is now fully supported 
+in 2.4; you can use syncrepl to replicate an entire server configuration from 
+one server to arbitrarily many other servers. It's possible to clone an entire 
+running slapd using just a small (less than 10 lines) seed configuration, or 
+you can just replicate the schema subtrees, etc. Tests 049 and 050 in the test 
+suite provide working examples of these capabilities.
+
+
+H3: Push-Mode Replication
+
+In 2.3 you could configure syncrepl as a full push-mode replicator by using it 
+in conjunction with a back-ldap pointed at the target server. But because the 
+back-ldap database needs to have a suffix corresponding to the target's suffix, 
+you could only configure one instance per slapd.
+
+In 2.4 you can define a database to be "hidden", which means that its suffix is 
+ignored when checking for name collisions, and the database will never be used 
+to answer requests received by the frontend. Using this "hidden" database feature 
+allows you to configure multiple databases with the same suffix, allowing you to 
+set up multiple back-ldap instances for pushing replication of a single database 
+to multiple targets. There may be other uses for hidden databases as well (e.g., 
+using a syncrepl consumer to maintain a *local* mirror of a database on a separate filesystem).
+
+
+H3: More extensive TLS configuration control
+
+In 2.3, the TLS configuration in slapd was only used by the slapd listeners. For 
+outbound connections used by e.g. back-ldap or syncrepl their TLS parameters came 
+from the system's ldap.conf file.
+
+In 2.4 all of these sessions inherit their settings from the main slapd configuration, 
+but settings can be individually overridden on a per-config-item basis. This is 
+particularly helpful if you use certificate-based authentication and need to use a 
+different client certificate for different destinations.
+
+
+H3: Performance enhancements
+
+Too many to list. Some notable changes - ldapadd used to be a couple of orders 
+of magnitude slower than "slapadd -q". It's now at worst only about half the 
+speed of slapadd -q. Some comparisons of all the 2.x OpenLDAP releases are available 
+at {{URL:http://www.openldap.org/pub/hyc/scale2007.pdf}}
+
+That compared 2.0.27, 2.1.30, 2.2.30, 2.3.33, and HEAD). Toward the latter end 
+of the "Cached Search Performance" chart it gets hard to see the difference 
+because the run times are so small, but the new code is about 25% faster than 2.3, 
+which was about 20% faster than 2.2, which was about 100% faster than 2.1, which 
+was about 100% faster than 2.0, in that particular search scenario. That test 
+basically searched a 1.3GB DB of 380836 entries (all in the slapd entry cache) 
+in under 1 second. i.e., on a 2.4GHz CPU with DDR400 ECC/Registered RAM we can 
+search over 500 thousand entries per second. The search was on an unindexed 
+attribute using a filter that would not match any entry, forcing slapd to examine 
+every entry in the DB, testing the filter for a match.
+
+Essentially the slapd entry cache in back-bdb/back-hdb is so efficient the search 
+processing time is almost invisible; the runtime is limited only by the memory 
+bandwidth of the machine. (The search data rate corresponds to about 3.5GB/sec; 
+the memory bandwidth on the machine is only about 4GB/sec due to ECC and register latency.)
+
+H3: New overlays
+
+* slapo-constraint (Attribute value constraints)
+* slapo-dds (Dynamic Directory Services, RFC 2589)
+* slapo-memberof (reverse group membership maintenance)
+
+H3: New features in existing Overlays
+
+* slapo-pcache
+  - Inspection/Maintenance 
+    -- the cache database can be directly accessed via
+       LDAP by adding a specific control to each LDAP request; a specific
+       extended operation allows to consistently remove cached entries and entire
+       cached queries
+  - Hot Restart
+    -- cached queries are saved on disk at shutdown, and reloaded if
+      not expired yet at subsequent restart
+
+* slapo-rwm can safely interoperate with other overlays
+* Dyngroup/Dynlist merge, plus security enhancements
+  - added dgIdentity support (draft-haripriya-dynamicgroup)
+
+H3: New features in slapd
+
+* monitoring of back-{b,h}db: cache fill-in, non-indexed searches,
+* session tracking control (draft-wahl-ldap-session)
+* subtree delete in back-sql (draft-armijo-ldap-treedelete)
+
+H3: New features in libldap
+
+* ldap_sync client API (LDAP Content Sync Operation, RFC 4533)
+
+H3: New clients, tools and tool enhancements
+
+* ldapexop for arbitrary extended operations
+* Complete support of controls in request/response for all clients
+* LDAP Client tools now honor SRV records 
+
+H3: New build options
+
+* Support for building against GnuTLS
+
+
+H2: Obsolete Features Removed From 2.4
+
+These features were strongly deprecated in 2.3 and removed in 2.4.
+
+H3: Slurpd
+
+Please read the {{SECT:Replication}} section as to why this is no longer in
+OpenLDAP
+
+H3: back-ldbm
+
+back-ldbm was both slow and unreliable. Its byzantine indexing code was
+prone to spontaneous corruption, as were the underlying database libraries
+that were commonly used (e.g. GDBM or NDBM). back-bdb and back-hdb are
+superior in every aspect, with simplified indexing to avoid index corruption,
+fine-grained locking for greater concurrency, hierarchical caching for
+greater performance, streamlined on-disk format for greater efficiency
+and portability, and full transaction support for greater reliability.

doc/guide/admin/appendix-configs.sdf

+# $OpenLDAP$
+# Copyright 2007 The OpenLDAP Foundation, All Rights Reserved.
+# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
+
+H1: Configuration File Examples
+
+
+H2: slapd.conf
+
+
+H2: ldap.conf
+
+
+H2: a-n-other.conf

doc/guide/admin/aspell.en.pws

+personal_ws-1.1 en 1405 
+nattrsets
+inappropriateAuthentication
+api
+olcAttributeTypes
+BhY
+reqEnd
+olcOverlayConfig
+shoesize
+olcTLSCACertificateFile
+CGI
+cdx
+DCE
+DAP
+attributename
+lsei
+dbconfig
+arg
+kurt
+authzID
+authzid
+authzId
+DAs
+ddd
+userApplications
+BNF
+attrs
+mixin
+wholeSubtree
+chainingRequired
+ldapport
+hallvard
+ASN
+acknowledgements
+Chu
+ava
+monitorCounter
+del
+DDR
+testObject
+OrgPerson
+IGJlZ
+olcUpdateref
+ECC
+deleteDN
+cli
+ltdl
+CAPI
+dev
+serverctrls
+olcDbDirectory
+xvfB
+BSI
+modv
+nonleaf
+errCode
+PhotoURI
+buf
+cdef
+monitorConnectionLocalAddress
+dir
+EGD
+dit
+retoidp
+ando
+edu
+caseExactSubstringsMatch
+bvstrdup
+AUTHNAME
+memrealloc
+auditExtended
+replog
+ludp
+metainformation
+CRL
+CRP
+olcReferral
+XLDFLAGS
+metadirectory
+csn
+siiiib
+stateful
+olcModulePath
+maxentries
+authc
+seeAlso
+searchbase
+searchBase
+realnamingcontext
+dn's
+DNs
+DN's
+dns
+dereference
+sortKey
+authzTo
+lossy
+gcc
+CWD
+lssl
+organizationalRole
+DSA
+derefInSearching
+pwdGraceUseTime
+DSE
+groupOfURLs
+modrdn
+ModRDN
+modrDN
+pwdFailureCountInterval
+homePhone
+eng
+paramName
+errUnsolicitedData
+Heimdal
+EOF
+authz
+XINCPATH
+LTFINISH
+plaintext
+indices
+reqAssertion
+olcDbUri
+dst
+env
+oplist
+MirrorMode
+mirrormode
+objclass
+Bint
+dup
+hdb
+gid
+stderr
+caseIgnoreOrderingMatch
+moduledir
+gif
+jpegPhoto
+lsasl
+judgmentday
+prepend
+subentry
+dbcache
+mkversion
+objectClasses
+objectclasses
+searchResultReference
+fmt
+qdescrs
+olcSuffix
+supportedControl
+GHz
+libpath
+INADDR
+compareDN
+sizelimit
+unixODBC
+APIs
+blen
+attrsOnly
+attrsonly
+slappasswd
+referralsPreferred
+oids
+OIDs
+wBDARESEhgVG
+syncIdSet
+olcTLSCipherSuite
+username
+sizeLimitExceeded
+subst
+idl
+chroot
+iff
+auditDelete
+numbits
+ZKKuqbEKJfKSXhUbHG
+reqRespControls
+TLSCertificateKeyFile
+olcAccess
+proxyTemplates
+neverDerefaliases
+RootDN
+rootdn
+loglevel
+args
+caseExactOrderingMatch
+olcDbQuarantine
+RELEASEDATE
+baseDN
+basedn
+argv
+GSS
+schemachecking
+whoami
+WhoAmI
+syslogd
+dataflow
+subentries
+attrpair
+BerkeleyDB's
+singleLevel
+entryDN
+dSAOperation
+includedir
+inplace
+LDAPAPIFeatureInfo
+logbase
+ing
+moduleload
+IPC
+Makefile
+getpid
+GETREALM
+numericString
+MANSECT
+XXXX
+domainstyle
+bvarray
+Choi
+iscritical
+subschema
+slapindex
+plugin
+distinguishedNameMatch
+derefAliases
+baseObject
+kdz
+reqMod
+ldb
+srcdir
+pwdExpireWarning
+localstatedir
+sockbuf
+PENs
+ipv
+IPv
+ghenry
+hyc
+multimaster
+noop
+DEFS
+joe
+testAttr
+syncrepl
+pwdFailureTime
+timestamp
+whitespaces
+ISP
+ldp
+monitorInfo
+bjensen
+newPasswd
+irresponsive
+len
+perl
+dynlist
+browseable
+attrvalue
+pers
+retcode
+rootpw
+matchedDN
+auditReadObject
+idletimeout
+intermediateResponse
+myOID
+structuralObjectClass
+integerMatch
+openldap
+OpenLDAP
+moddn
+rewriteEngine
+AVAs
+accesslog
+searchDN
+reqOld
+MDn
+aspell
+TLSCACertificateFile
+mem
+peername
+syncUUIDs
+database's
+krb
+bool
+logins
+jts
+memberAttr
+newpasswdfile
+newPasswdFile
+ucdata
+LLL
+confdir
+BerValues
+olcDbLinearIndex
+Elfrink
+AUTOREMOVE
+countp
+realloc
+bsize
+CThreads
+structs
+desc
+LTCOMPILE
+bindmethod
+olcDbCheckpoint
+modme
+refreshOnly
+PIII
+pwdPolicySubentry
+FIXME
+realanonymous
+caseExactMatch
+olcSizeLimit
+Bourne
+attr
+objectidentifier
+objectIdentifier
+refint
+msgtype
+OBJEXT
+LRL
+subtrees
+realdnattr
+entrymods
+admittable
+libtool's
+dupbv
+searchResultEntry
+lud
+modifyTimestamp
+TLSEphemeralDHParamFile
+LRU
+syncprov
+strvals
+preread
+auth
+nis
+regexec
+adamsom
+objclasses
+deallocation
+strdup
+gsMatch
+adamson
+UniqueName
+ppErrStr
+DESTDIR
+oid
+saslpasswd
+interoperate
+bindwhen
+Solaris
+oOjM
+msg
+submatch
+refreshAndPersist
+monitorServer
+attributeUsage
+soelim
+objectIdentiferMatch
+olc
+PEM
+Autoconf
+alloc
+PDU
+OLF
+inetorgperson
+inetOrgPerson
+deleteoldrdn
+monitorCounterObject
+pid
+CPAN
+sharedstatedir
+OLP
+LDFLAGS
+dereferencing
+errcodep
+xeXBkeFxlZ
+accessor's
+extendedop
+ple
+NTP
+reqSizeLimit
+ORed
+NUL
+namingContexts
+num
+reqAttrsOnly
+ldappasswd
+online
+libdir
+unindexed
+ObjectClassDescription
+attrdesc
+efgh
+exopPasswdDN
+ranlib
+olcAttributeOptions
+lineno
+storages
+nameAndOptionalUID
+png
+INCPATH
+organizationalPerson
+integerOrderingMatch
+OSI
+subschemaSubentry
+cond
+conf
+bvec
+rdn
+ECHOPROMPT
+RDBM
+subany
+runningslapd
+configs
+datagram
+crlcheck
+conn
+builddir
+OTP
+entrylimit
+attrdescN
+logold
+pos
+sbi
+PRD
+reqEntries
+pre
+bvals
+unixusers
+olcReadonly
+olcReadOnly
+pwdChangedTime
+mySQL
+sdf
+suffixmassage
+referralDN
+sed
+statslog
+perror
+ldapexop
+bvecadd
+distributedOperation
+sel
+versa
+TBC
+telephonenumber
+telephoneNumber
+DLDAP
+peernamestyle
+SHA
+filename
+rpath
+argsfile
+ptr
+INCDIR
+pwd
+dctree
+rnd
+quanah
+lastmod
+TCL
+sprintf
+shm
+logops
+dnattr
+subdir
+searchAttrDN
+cctrls
+tcp
+strlen
+spellcheck
+ludpp
+typedef
+olcDbIDLcacheSize
+ostring
+mwrscdx
+SMD
+UCD
+cancelled
+crit
+lucyB
+slp
+rdns
+CPUs
+TGT
+modulepath
+quickstart
+mySNMP
+tgz
+UDP
+RDBMs
+rdbms
+Matic
+qdstring
+gunzip
+librewrite
+UFl
+src
+lastName
+ufn
+cron
+sql
+pwdPolicyChecker
+uid
+olcDbConfig
+refreshDone
+ssf
+replogfile
+rwm
+TOC
+vec
+LDAPDN
+compareAttrDN
+endmacro
+tls
+repl
+monitoringslapd
+referralsp
+tmp
+SRP
+olcDbNosync
+conns
+SSL
+PDkzODdASFxOQ
+SRV
+rwx
+sss
+deallocators
+Contribware
+URLlist
+str
+subinitial
+CSNs
+sbin
+dbtools
+datasource
+sbio
+posp
+errText
+prepended
+labeledURI
+scdx
+startup
+const
+wBDABALD
+octetStringSubstringsStringMatch
+ttl
+bvalue
+bvdup
+stringa
+stringb
+hasSubordinates
+oldPasswd
+sys
+pwdPolicy
+slapd
+sasl
+slapauth
+MANCOMPRESS
+octetStringOrderingStringMatch
+updatedn
+UpdateDN
+slapdindex
+searchFilter
+uri
+slapi
+tty
+liblunicode
+url
+entryExpireTimestamp
+priv
+slapo
+UTF
+vlv
+ctrl
+TXN
+virtualnamingcontext
+eatBlanks
+slimit
+ldaprc
+usr
+txt
+proc
+generalizedTime
+loopback
+unmassaged
+mechs
+freemods
+initgroups
+auditCompare
+GDBM
+DSA's
+compareFalse
+resultCode
+resultcode
+noSuchObject
+params
+groupnummer
+searchEntryDN
+negttl
+chainingPreferred
+TABs
+retdatap
+errAuxObject
+postoperation
+realself
+olcPasswordHash
+concat
+debuglevel
+addAttrDN
+credp
+ldaphost
+pwdMaxFailure
+octetStringMatch
+extparam
+auditWriteObject
+colaligns
+Diffie
+attributevalue
+AttributeValue
+SIGTERM
+MyCompany
+al
+AAQSkZJRgABAAAAAQABAAD
+cd
+contextCSN
+ar
+pthreads
+monitorTimestamp
+de
+reqAuthzID
+backend's
+backends
+cn
+lcrypto
+infodir
+groupstyle
+ldapsearch
+cp
+displayName
+eg
+bv
+olcBackendConfig
+dn
+fd
+LDAPSync
+fG
+fi
+eq
+FIPS
+dx
+et
+eu
+hh
+olcLogLevel
+slurpd
+logevels
+IG
+addDN
+tbls
+ldapmodify
+kb
+syslog
+io
+ip
+dynacl
+aXRoIGEgc
+enum
+slapdconf
+reqFilter
+ld
+xyz
+TLSCertificateFile
+idassert
+failover
+kerberos
+lookups
+md
+iZ
+SysNet
+BerValue
+idlcachesize
+struct
+UCASE
+errno
+syslogged
+mk
+ng
+oc
+errOp
+pwdMaxAge
+truelies
+NL
+mr
+reindex
+newentry
+ok
+mv
+preinstalled
+regex
+saslmech
+rc
+config
+ou
+policyDN
+sb
+olcSyncrepl
+QN
+strtol
+runtime
+NOSYNC
+slapover
+RL
+sockname
+MANCOMPRESSSUFFIX
+makeinfo
+coltags
+ro
+rp
+EXEEXT
+sockurl
+th
+sn
+ru
+UG
+ss
+su
+TP
+reqMethod
+XLIBS
+PhotoObject
+tt
+keycol
+namingContext
+rlookups
+searchstack
+NOECHOPROMPT
+sldb
+wi
+AlmostASearchRequest
+xf
+param
+MChAODQ
+caseExactIA
+Vu
+Za
+idlecachesize
+ws
+errSleepTime
+INSTALLFLAGS
+pthread
+pwdHistory
+slen
+errUnsolicitedOID
+dyngroup
+filtertype
+rewriteRules
+criticality
+preoperation
+smbk
+subord
+reqVersion
+errp
+ZZ
+entryCSNs
+dlopen
+continuated
+newsuperior
+newSuperior
+Preprocessor
+XXLIBS
+deallocate
+reqScope
+llber
+bitstringa
+sbindir
+apache's
+noidlen
+monitorContext
+resync
+fqdn
+authPassword
+LDAPMatchingRule
+olcIdleTimeout
+treedelete
+auditAdd
+reqSession
+derated
+LDVERSION
+IANA
+olcDbSearchStack
+bitstrings
+rscdx
+schemas
+minssf
+ldapadd
+pseudorootdn
+lldap
+gssapi
+applicatio
+nelems
+liblutil
+wrscdx
+scherr
+internet
+logfilter
+lutil
+themself
+libexec
+dnpattern
+proxying
+reqType
+Kartik
+libexecdir
+inetd
+pwdSafeModify
+contrib
+FQDNs
+bjorn
+myLDAP
+SNMP
+myObjectClass
+thru
+olcLastMod
+commonName
+testTwo
+olcFrontendConfig
+LDAPObjectClass
+attributeTypes
+LTINSTALL
+hostname
+Symas
+numattrsets
+msgid
+ldapmodrdn
+ldapbis
+attributeoptions
+serverID
+memberof
+pseudorootpw
+CFLAGS
+substr
+pwdAllowUserChange
+rewriteRule
+XXXXXXXXXX
+credlen
+departmentNumber
+rewriteMap
+logfile
+vals
+LDAPAVA
+modifyAttrDN
+dcedn
+olcOverlay
+exop
+berelement
+BerElement
+olcRootDN
+octetString
+SampleLDAP
+expr
+PostgreSQL
+bvstr
+filesystem
+pathtest
+objectClass
+objectclass
+submatches
+newrdn
+armijo
+addBlanks
+reqMessage
+exts
+SSHA
+func
+filterlist
+modifyDN
+syncuser
+Masarati
+LDAPSyntax
+oldpasswdfile
+oldPasswdFile
+reqDN
+SSFs
+ietf
+unwillingToPerform
+oidlen
+searchFilterAttrDN
+CPPFLAGS
+slapadd
+Clatworthy
+urldesc
+substrings
+Apurva
+slapacl
+multiclassing
+monitoredInfo
+LTLINK
+ETCDIR
+reqId
+setspec
+scanf
+TLSv
+distinguishedname
+distinguishedName
+BerVarray
+caseIgnoreSubstrin
+ldapwhoami
+URLattr
+generalizedTimeOrderingMatch
+requestdata
+timelimit
+subr
+cachesize
+olcRootPW
+SSLv
+domainScope
+LDAPMessage
+LTVERSION
+memalloc
+refreshDeletes
+BerkeleyDB
+pathspec
+uint
+Poitou
+whitespace
+dynstyle
+slaptest
+zeilenga
+WebUpdate
+numericoid
+changelog
+ChangeLog
+creatorsName
+ascii
+wahl
+uniqueMember
+slapcat
+lwrap
+ldapfilter
+errDisconnect
+sermersheim
+rootdns
+searchResult
+libtool
+servercredp
+AttributeTypeDescription
+LTFLAGS
+authcDN
+TLSCipherSuite
+supportedSASLMechanisms
+rootDSE
+dsaparam
+cachefree
+UMich's
+schemadir
+attribute's
+extern
+varchar
+olcDbCacheSize
+olcDbCachesize
+authcid
+authcID
+POSIX
+hnPk
+ldapext
+authzFrom
+Google
+olcSchemaConfig
+newsup
+sbiod
+XXXLIBS
+LDAPBASE
+Supr
+olcDatabaseConfig
+rwxrwxrwx
+aeeiib
+reqStart
+sasldb
+somevalue
+LIBRELEASE
+starttls
+StartTLS
+LDAPSchemaExtensionItem
+reqReferral
+shtool
+Pierangelo
+attrstyle
+backend
+portnumber
+subjectAltName
+errObject
+valsort
+bervals
+berval's
+derefFindingBaseObj
+checkpointed
+keytab
+groupnaam
+frontend
+sctrls
+dbnum
+olcLdapConfig
+sessionlog
+attrset
+entryCSN
+strcast
+kbyte
+modifiersName
+keytbl
+olcHdbConfig
+README
+memcalloc
+inet
+saslargs
+givenname
+givenName
+olcDbMode
+pidfile
+olcLimits
+memvfree
+tuple
+superset
+directoryString
+proxyTemplate
+proxytemplate
+wildcards
+monitoredObject
+TTLs
+LxsdLy
+olcTimeLimit
+stringal
+init
+Locators
+bvalues
+reqResult
+impl
+outvalue
+returnCode
+returncode
+attributeDescription
+attrval
+dnssrv
+ciphersuite
+auditlog
+reqControls
+notypes
+myAttributeType
+stringbv
+keyval
+calloc
+chmod
+Subbarao
+setstyle
+subdirectories
+errlist
+slapdn
+uncached
+ldapapiinfo
+groupOfUniqueNames
+dhparam
+slapd's
+slapds
+inputfile
+RDBMSes
+wildcard
+Locator
+errAbsObject
+errABsObject
+SASL's
+html
+searchResultDone
+olcBdbConfig
+ldapmod
+LDAPMod
+olcHidden
+userPassword
+TLSRandFile
+use'd
+auditBind
+requestDN
+lockdetect
+selfstyle
+liblber
+ERXRTc
+printf
+AutoConfig
+localhost
+lber
+noprompt
+databasenumber
+hasSubordintes
+URIs
+lang
+auditSearch
+ldapdelete
+reqTimeLimit
+cacertdir
+queryid
+Warper
+XDEFS
+urls
+URL's
+postalAddress
+postaladdress
+passwd
+plugins
+george
+http
+uppercased
+Poobah
+libldap
+ldap
+ldbm
+ursula
+LDAPModifying
+slapdconfig
+dnSubtreeMatch
+olcSaslSecProps
+olcSaslSecprops
+auditModify
+groupOfNames
+jensen
+reloadHint
+prepending
+olcGlobal
+matchingRule
+matchingrule
+SmVuc
+MSSQL
+hostnames
+ctrlp
+lltdl
+ctrls
+rewriter
+secprops
+namespace
+whsp
+realusers
+dnstyle
+suffixalias
+proxyAttrset
+proxyAttrSet
+proxyattrset
+pwdMustChange
+ldif
+bvfree
+sleeptime
+pwdCheckQuality
+msgidp
+pwdAttribute
+PRNGD
+LDAPRDN
+entryUUIDs
+proxycache
+proxyCache
+SERATGCgaGBYWGDEjJR
+noanonymous
+accessee
+createTimestamp
+nretries
+auditAbandon
+LDAPAttributeType
+logdb
+procs
+realdn
+alwaysDerefAliases
+ppolicy
+jpeg
+functionalities
+pcache
+caseIgnoreMatch
+sysconfdir
+checkpointing
+rebindproc
+dryrun
+noplain
+exattrs
+Jong
+proxied
+firstName
+accesslevel
+login
+rewriteContext
+dcObject
+newparent
+numericStringMatch
+TLSVerifyClient
+subtree
+multi
+immSupr
+manpage
+assciated
+wZFQrDD
+serverctrlsp
+onelevel
+abcd
+reqcert
+referralsRequired
+Hyuk
+olcServerID
+reqDerefAliases
+newSuperiorDN
+passwdfile
+errMatchedDN
+everytime
+mkdep
+olcDbindex
+olcDbIndex
+syntaxOID
+reqData
+databasetype
+woid
+numericStringOrderingMatch
+clientctrls
+RetCodes
+pwdAccountLockedTime
+attrtype
+LIBVERSION
+proto
+endif
+reqNewRDN
+ldapi
+notoc
+matcheddnp
+mkdir
+mech
+pwdMinAge
+ldaps
+userCertificate
+LDAPv
+IPsec
+tokenization
+olcModuleList
+robert
+generalizedTimeMatch
+UMLDAP
+OpenLDAP's
+lookup
+ABNF
+olcDbShmKey
+pwdLockoutDuration
+TLSCACertificatePath
+ldapuri
+ldapurl
+ACIs
+behera
+olcObjectIdentifier
+endblock
+proxyAuthz
+pagedResults
+bitstring
+ACLs
+berptr
+olcModuleLoad
+attributetype
+attributeType
+auditModRDN
+cacert
+freebuf
+IDSET
+pwdGraceAuthnLimit
+invalue
+XKYnrjvGT
+srvtab
+referralAttrDN
+requestoid
+basename
+substring
+booleanMatch
+babs
+pPasswd
+msgfree
+slapdconfigfile
+olcDatabase
+builtin
+hardcoded
+SIGINT
+MAXLEN
+xpasswd
+cleartext
+extensibleObject
+pwdLockout
+SIGHUP
+reqDeleteOldRDN
+reqAttr
+subfinal
+berval
+octothorpe
+LTONLY
+filesystems
+urandom
+NDBM
+abcdefgh
+olcBackend
+errmsgp
+boolean
+updateref
+regcomp
+contextp
+filtercomp
+LDAPNOINIT
+deref
+preallocated
+syntaxes
+memberURL
+monitorRuntimeConfig
+bindDn
+bindDN
+binddn
+methodp
+timelimitExceeded
+pwdInHistory
+LTSTATIC
+requestors
+requestor's
+LDAPCONF
+saslauthd
+MKDEPFLAG
+gecos
+entryUUID
+gnutls
+GNUtls
+GnuTLS
+postread
+timeval
+DHAVE
+caseIgnoreSubstringsMatch
+monitorIsShadow
+syncdata
+olcPidFile
+hostport
+backload
+bindir
+olcObjectClasses
+auditObject
+LDIFv
+strcasecmp
+LTHREAD
+dereferenced
+entryTtl
+LDAPControl
+pwdMinLength
+ldapcompare
+readonly
+readOnly
+RANDFILE
+attrlist
+aci
+directoryOperation
+selfwrite
+pwdReset
+acl
+attrname
+ADH
+searchable
+bindmethods
+logpurge
+reqNewSuperior
+multiproxy
+dereferences
+datadir
+malloc
+UUIDs
+veryclean
+userid
+Kumar
+AES
+bdb
+manageDSAit
+ManageDsaIT
+bindpw
+monitorContainer
+pEntry
+baz
+memfree
+lresolv
+objectIdentifierMatch
+Blowfish
+mkln
+numericStringSubstringsMatch
+openssl
+OpenSSL
+ModName
+cacheable
+freeit
+pathname
+ber
+ali
+mandir
+changetype
+CAs
+CA's
+typeA
+bvecfree
+ODBC
+typeB
+unescaped
+devel
+pwdCheckModule
+LDAPURLDesc
+authzDN

doc/guide/admin/backends.sdf

+# $OpenLDAP$
+# Copyright 2007 The OpenLDAP Foundation, All Rights Reserved.
+# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
+
+H1: 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 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}}
+ behavior, and all the same configuration options apply.
+
+Note: An {{hdb}} database needs a large {{idlcachesize}} for good search performance, 
+typically three times the {{cachesize}} (entry cache size) or larger.
+
+H3: back-bdb/back-hdb Configuration
+
+MORE LATER
+
+H3: Further Information
+
+{{slapd-bdb}}(5)
+
+H2: LDAP
+
+
+H3: Overview
+
+The LDAP backend to {{slapd}}(8) is not an actual database; instead it acts 
+as a proxy to forward incoming requests to another LDAP server. While 
+processing requests it will also chase referrals, so that referrals are fully
+processed instead of being returned to the {{slapd}} client.
+
+Sessions that explicitly {{Bind}} to the {{back-ldap}} database always create 
+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 
+efficiency by reducing the overhead of repeatedly making/breaking multiple 
+connections.
+
+The ldap database can also act as an information service, i.e. the identity 
+of locally authenticated clients is asserted to the remote server, possibly 
+in some modified form. For this purpose, the proxy binds to the remote server 
+with some administrative identity, and, if required, authorizes the asserted 
+identity. 
+
+H3: back-ldap Configuration
+
+LATER
+
+H3: Further Information
+
+{{slapd-ldap}}(5)
+
+H2: LDIF
+
+
+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.
+
+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
+
+LATER
+
+H3: Further Information
+
+{{slapd-ldif}}(5)
+
+H2: Metadirectory
+
+
+H3: Overview
+
+The meta backend to {{slapd}}(8) performs basic LDAP proxying with respect 
+to a set of remote LDAP servers, called "targets". The information contained 
+in these servers can be presented as belonging to a single Directory Information 
+Tree ({{TERM:DIT}}).
+
+A basic knowledge of the functionality of the {{slapd-ldap}}(5) backend is 
+recommended. This backend has been designed as an enhancement of the ldap 
+backend. The two backends share many features (actually they also share portions
+ of code). While the ldap backend is intended to proxy operations directed 
+ to a single server, the meta backend is mainly intended for proxying of 
+ multiple servers and possibly naming context  masquerading.
+
+These features, although useful in many scenarios, may result in excessive 
+overhead for some applications, so its use should be carefully considered.
+
+
+H3: back-meta Configuration
+
+LATER
+
+H3: Further Information
+
+{{slapd-meta}}(5)
+
+H2: Monitor
+
+
+H3: Overview
+
+The monitor backend to {{slapd}}(8) is not an actual database; if enabled, 
+it is automatically generated and dynamically maintained by slapd with 
+information about the running status of the daemon.
+
+To inspect all monitor information, issue a subtree search with base {{cn=Monitor}}, 
+requesting that attributes "+" and "*" are returned. The monitor backend produces 
+mostly operational attributes, and LDAP only returns operational attributes 
+that are explicitly requested.  Requesting attribute "+" is an extension which 
+requests all operational attributes.
+
+See the {{SECT:Monitoring}} section.
+
+H3: back-monitor Configuration
+
+LATER
+
+H3: Further Information
+
+{{slapd-monitor}}(5)
+
+H2: Null
+
+
+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.
+
+Inspired by the {{F:/dev/null}} device.
+
+H3: back-null Configuration
+
+LATER
+
+H3: Further Information
+
+{{slapd-null}}(5)
+
+H2: Passwd
+
+
+H3: Overview
+
+The PASSWD backend to {{slapd}}(8) serves up the user account information 
+listed in the system {{passwd}}(5) file.
+
+This backend is provided for demonstration purposes only. The DN of each entry 
+is "uid=<username>,<suffix>".
+
+H3: back-passwd Configuration
+
+LATER
+
+H3: Further Information
+
+{{slapd-passwd}}(5)
+
+H2: Perl/Shell
+
+H3: Overview
+
+The Perl backend to {{slapd}}(8) works by embedding a {{perl}}(1) interpreter 
+into {{slapd}}(8). Any perl database section of the configuration file 
+{{slapd.conf}}(5) must then specify what Perl module to use. Slapd then creates 
+a new Perl object that handles all the requests for that particular instance of the backend.
+
+The Shell backend to {{slapd}}(8) executes external programs to implement 
+operations, and is designed to make it easy to tie an existing database to the 
+slapd front-end. This backend is is primarily intended to be used in prototypes.
+
+H3: back-perl/back-shell Configuration
+
+LATER
+
+H3: Further Information
+
+{{slapd-shell}}(5) and {{slapd-perl}}(5)
+
+H2: Relay
+
+
+H3: Overview
+
+The primary purpose of this {{slapd}}(8) backend is to map a naming context 
+defined in a database running in the same {{slapd}}(8) instance into a 
+virtual naming context, with attributeType and objectClass manipulation, if
+required. It requires the rwm overlay.
+
+This backend and the above mentioned overlay are experimental.
+
+H3: back-relay Configuration
+
+LATER
+
+H3: Further Information
+
+{{slapd-relay}}(5)
+
+H2: SQL
+
+
+H3: Overview
+
+The primary purpose of this {{slapd}}(8) backend is to PRESENT information 
+stored in some RDBMS as an LDAP subtree without any programming (some SQL and 
+maybe stored procedures can’t be considered programming, anyway ;).
+
+That is, for example, when you (some ISP) have account information you use in 
+an RDBMS, and want to use modern solutions that expect such information in LDAP 
+(to authenticate users, make email lookups etc.). Or you want to synchronize or 
+distribute information between different sites/applications that use RDBMSes 
+and/or LDAP. Or whatever else...
+
+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. 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 
+it without any modifications. This allows SQL and LDAP applications to interoperate 
+without replication, and exchange data as needed.
+
+The SQL backend is designed to be tunable to virtually any relational schema without 
+having to change source (through that meta-information mentioned). Also, it uses 
+ODBC to connect to RDBMSes, and is highly configurable for SQL dialects RDBMSes 
+may use, so it may be used for integration and distribution of data on different 
+RDBMSes, OSes, hosts etc., in other words, in highly heterogeneous environment.
+
+This backend is experimental.
+
+H3: back-sql Configuration
+
+LATER
+
+H3: Further Information
+
+{{slapd-sql}}(5)

doc/guide/admin/config.sdf

@@ -15,7 +15,7 @@ directory service for your local domain only. It does not interact
 with other directory servers in any way. This configuration is shown
 in Figure 3.1.
 
-!import "config_local.gif"; align="center"; title="Local service via slapd(8) configuration"
+!import "config_local.png"; align="center"; title="Local service via slapd(8) configuration"
 FT[align="Center"] Figure 3.1: Local service configuration.
 
 Use this configuration if you are just starting out (it's the one the
@@ -32,7 +32,7 @@ referrals to other servers capable of handling requests.  You may
 run this service (or services) yourself or use one provided to you.
 This configuration is shown in Figure 3.2.
 
-!import "config_ref.gif"; align="center"; title="Local service with referrals"
+!import "config_ref.png"; align="center"; title="Local service with referrals"
 FT[align="Center"] Figure 3.2: Local service with referrals 
 
 Use this configuration if you want to provide local service and

doc/guide/admin/dbtools.sdf

@@ -18,7 +18,7 @@ special utilities provided with slapd. This method is best if you
 have many thousands of entries to create, which would take an
 unacceptably long time using the LDAP method, or if you want to
 ensure the database is not accessed while it is being created. Note
-that not all database types support these utilitites.
+that not all database types support these utilities.
 
 
 H2: Creating a database over LDAP

doc/guide/admin/guide.book

+#HTMLDOC 1.8.27
+-t pdf14 -f "OpenLDAP-Admin-Guide.pdf" --book --toclevels 3 --no-numbered --toctitle "Table of Contents" --title --titleimage "../images/LDAPwww.gif" --linkstyle plain --size Universal --left 1.00in --right 0.50in --top 0.50in --bottom 0.50in --header .t. --header1 ... --footer ..1 --nup 1 --tocheader .t. --tocfooter ..i --duplex --portrait --color --no-pscommands --no-xrxcomments --compression=1 --jpeg=0 --fontsize 11.0 --fontspacing 1.2 --headingfont Helvetica --bodyfont Times --headfootsize 11.0 --headfootfont Helvetica --charset iso-8859-1 --links --embedfonts --pagemode outline --pagelayout single --firstpage p1 --pageeffect none --pageduration 10 --effectduration 1.0 --no-encryption --permissions all  --owner-password ""  --user-password "" --browserwidth 680 --no-strict --no-overflow
+admin.html

doc/guide/admin/install.sdf

@@ -21,7 +21,7 @@ directly from the project's {{TERM:FTP}} service at
 
 The project makes available two series of packages for {{general
 use}}.  The project makes {{releases}} as new features and bug fixes
-come available.  Though the project takes steps to improve stablity
+come available.  Though the project takes steps to improve stability
 of these releases, it is common for problems to arise only after
 {{release}}.  The {{stable}} release is the latest {{release}} which
 has demonstrated stability through general use.
@@ -63,16 +63,18 @@ installation instructions provided with it.
 
 H3: {{TERM[expand]TLS}}
 
-OpenLDAP clients and servers require installation of {{PRD:OpenSSL}}
+OpenLDAP clients and servers require installation of either {{PRD:OpenSSL}}
+or {{PRD:GnuTLS}}
 {{TERM:TLS}} libraries to provide {{TERM[expand]TLS}} services.  Though
 some operating systems may provide these libraries as part of the
-base system or as an optional software component, OpenSSL often
-requires separate installation.
+base system or as an optional software component, OpenSSL and GnuTLS often
+require separate installation.
 
 OpenSSL is available from {{URL: http://www.openssl.org/}}.
+GnuTLS is available from {{URL: http://www.gnu.org/software/gnutls/}}.
 
 OpenLDAP Software will not be fully LDAPv3 compliant unless OpenLDAP's
-{{EX:configure}} detects a usable OpenSSL installation.
+{{EX:configure}} detects a usable TLS library.
 
 
 H3: {{TERM[expand]SASL}}

doc/guide/admin/intro.sdf

@@ -57,8 +57,8 @@ support browsing and searching.
 
 While some consider the Internet {{TERM[expand]DNS}} (DNS) is an
 example of a globally distributed directory service, DNS is not
-browsable nor searchable.  It is more properly described as a
-globaly distributed {{lookup}} service.
+browseable nor searchable.  It is more properly described as a
+globally distributed {{lookup}} service.
 
 
 H2: What is LDAP?
@@ -96,7 +96,7 @@ units, people, printers, documents, or just about anything else
 you can think of.  Figure 1.1 shows an example LDAP directory tree
 using traditional naming.
 
-!import "intro_tree.gif"; align="center"; \
+!import "intro_tree.png"; align="center"; \
 	title="LDAP directory tree (traditional naming)"
 FT[align="Center"] Figure 1.1: LDAP directory tree (traditional naming)
 
@@ -106,7 +106,7 @@ for directory services to be located using the {{DNS}}.
 Figure 1.2 shows an example LDAP directory tree using domain-based
 naming.
 
-!import "intro_dctree.gif"; align="center"; \
+!import "intro_dctree.png"; align="center"; \
 	title="LDAP directory tree (Internet naming)"
 FT[align="Center"] Figure 1.2: LDAP directory tree (Internet naming)
 
@@ -154,6 +154,12 @@ LDAP also supports data security (integrity and confidentiality)
 services.
 
 
+H2: When should I use LDAP?
+
+
+H2: When should I not use LDAP?
+
+
 H2: How does LDAP work?
 
 LDAP utilizes a {{client-server model}}. One or more LDAP servers
@@ -205,22 +211,127 @@ H2: What is the difference between LDAPv2 and LDAPv3?
 LDAPv3 was developed in the late 1990's to replace LDAPv2.
 LDAPv3 adds the following features to LDAP:
 
- - Strong authentication and data security services via {{TERM:SASL}}
- - Certificate authentication and data security services via {{TERM:TLS}} (SSL)
- - Internationalization through the use of Unicode
- - Referrals and Continuations
- - Schema Discovery
- - Extensibility (controls, extended operations, and more)
+ * Strong authentication and data security services via {{TERM:SASL}}
+ * Certificate authentication and data security services via {{TERM:TLS}} (SSL)
+ * Internationalization through the use of Unicode
+ * Referrals and Continuations
+ * Schema Discovery
+ * Extensibility (controls, extended operations, and more)
 
 LDAPv2 is historic ({{REF:RFC3494}}).  As most {{so-called}} LDAPv2
 implementations (including {{slapd}}(8)) do not conform to the
-LDAPv2 technical specification, interoperatibility amongst
+LDAPv2 technical specification, interoperability amongst
 implementations claiming LDAPv2 support is limited.  As LDAPv2
 differs significantly from LDAPv3, deploying both LDAPv2 and LDAPv3
 simultaneously is quite problematic.  LDAPv2 should be avoided.
 LDAPv2 is disabled by default.
 
 
+H2: LDAP vs RDBMS
+
+This question is raised many times, in different forms. The most common, 
+however, is: {{Why doesn't OpenLDAP drop Berkeley DB and use a relational 
+database management system (RDBMS) instead?}} In general, expecting that the 
+sophisticated algorithms implemented by commercial-grade RDBMS would make 
+{{OpenLDAP}} be faster or somehow better and, at the same time, permitting 
+sharing of data with other applications.
+
+The short answer is that use of an embedded database and custom indexing system 
+allows OpenLDAP to provide greater performance and scalability without loss of 
+reliability. OpenLDAP, since release 2.1, in its main storage-oriented backends 
+(back-bdb and, since 2.2, back-hdb) uses Berkeley DB concurrent / transactional 
+database software. This is the same software used by leading commercial 
+directory software.
+
+Now for the long answer. We are all confronted all the time with the choice 
+RDBMSes vs. directories. It is a hard choice and no simple answer exists.
+
+It is tempting to think that having a RDBMS backend to the directory solves all 
+problems. However, it is a pig. This is because the data models are very 
+different. Representing directory data with a relational database is going to 
+require splitting data into multiple tables.
+
+Think for a moment about the person objectclass. Its definition requires 
+attribute types objectclass, sn and cn and allows attribute types userPassword, 
+telephoneNumber, seeAlso and description. All of these attributes are multivalued, 
+so a normalization requires putting each attribute type in a separate table.
+
+Now you have to decide on appropriate keys for those tables. The primary key 
+might be a combination of the DN, but this becomes rather inefficient on most 
+database implementations.
+
+The big problem now is that accessing data from one entry requires seeking on 
+different disk areas. On some applications this may be OK but in many 
+applications performance suffers.
+
+The only attribute types that can be put in the main table entry are those that 
+are mandatory and single-value. You may add also the optional single-valued 
+attributes and set them to NULL or something if not present.
+
+But wait, the entry can have multiple objectclasses and they are organized in 
+an inheritance hierarchy. An entry of objectclass organizationalPerson now has 
+the attributes from person plus a few others and some formerly optional attribute 
+types are now mandatory.
+
+What to do? Should we have different tables for the different objectclasses? 
+This way the person would have an entry on the person table, another on 
+organizationalPerson, etc. Or should we get rid of person and put everything on 
+the second table?
+
+But what do we do with a filter like (cn=*) where cn is an attribute type that 
+appears in many, many objectclasses. Should we search all possible tables for 
+matching entries? Not very attractive.
+
+Once this point is reached, three approaches come to mind. One is to do full 
+normalization so that each attribute type, no matter what, has its own separate 
+table. The simplistic approach where the DN is part of the primary key is 
+extremely wasteful, and calls for an approach where the entry has a unique 
+numeric id that is used instead for the keys and a main table that maps DNs to 
+ids. The approach, anyway, is very inefficient when several attribute types from 
+one or more entries are requested. Such a database, though cumbersomely, 
+can be managed from SQL applications.
+
+The second approach is to put the whole entry as a blob in a table shared by all 
+entries regardless of the objectclass and have additional tables that act as 
+indices for the first table. Index tables are not database indices, but are 
+fully managed by the LDAP server-side implementation. However, the database 
+becomes unusable from SQL. And, thus, a fully fledged database system provides 
+little or no advantage. The full generality of the database is unneeded. 
+Much better to use something light and fast, like Berkeley DB. 
+
+A completely different way to see this is to give up any hopes of implementing 
+the directory data model. In this case, LDAP is used as an access protocol to 
+data that provides only superficially the directory data model. For instance, 
+it may be read only or, where updates are allowed, restrictions are applied, 
+such as making single-value attribute types that would allow for multiple values. 
+Or the impossibility to add new objectclasses to an existing entry or remove 
+one of those present. The restrictions span the range from allowed restrictions 
+(that might be elsewhere the result of access control) to outright violations of 
+the data model. It can be, however, a method to provide LDAP access to preexisting 
+data that is used by other applications. But in the understanding that we don't
+really have a "directory".
+
+Existing commercial LDAP server implementations that use a relational database 
+are either from the first kind or the third. I don't know of any implementation 
+that uses a relational database to do inefficiently what BDB does efficiently.
+For those who are interested in "third way" (exposing EXISTING data from RDBMS 
+as LDAP tree, having some limitations compared to classic LDAP model, but making 
+it possible to interoperate between LDAP and SQL applications):
+
+OpenLDAP includes back-sql - the backend that makes it possible. It uses ODBC + 
+additional metainformation about translating LDAP queries to SQL queries in your 
+RDBMS schema, providing different levels of access - from read-only to full 
+access depending on RDBMS you use, and your schema.
+
+For more information on concept and limitations, see {{slapd-sql}}(5) man page, 
+or the {{SECT: Backends}} section. There are also several examples for several 
+RDBMSes in {{F:back-sql/rdbms_depend/*}} subdirectories. 
+
+TO REFERENCE:
+
+http://blogs.sun.com/treydrake/entry/ldap_vs_relational_database
+http://blogs.sun.com/treydrake/entry/ldap_vs_relational_database_part
+
 H2: What is slapd and what can it do?
 
 {{slapd}}(8) is an LDAP directory server that runs on many different
@@ -243,7 +354,7 @@ SASL}} software which supports a number of mechanisms including
 {{B:{{TERM[expand]TLS}}}}: {{slapd}} supports certificate-based
 authentication and data security (integrity and confidentiality)
 services through the use of TLS (or SSL).  {{slapd}}'s TLS
-implementation utilizes {{PRD:OpenSSL}} software.
+implementation can utilize either {{PRD:OpenSSL}} or {{PRD:GnuTLS}} software.
 
 {{B:Topology control}}: {{slapd}} can be configured to restrict
 access at the socket layer based upon network topology information.
@@ -283,8 +394,7 @@ well-defined {{TERM:C}} {{TERM:API}}, you can write your own
 customized modules which extend {{slapd}} in numerous ways.  Also,
 a number of {{programmable database}} modules are provided.  These
 allow you to expose external data sources to {{slapd}} using popular
-programming languages ({{PRD:Perl}}, {{shell}}, {{TERM:SQL}}, and
-{{PRD:TCL}}).
+programming languages ({{PRD:Perl}}, {{shell}}, and {{TERM:SQL}}.
 
 {{B:Threads}}: {{slapd}} is threaded for high performance.  A single
 multi-threaded {{slapd}} process handles all incoming requests using
@@ -294,8 +404,10 @@ required while providing high performance.
 {{B:Replication}}: {{slapd}} can be configured to maintain shadow
 copies of directory information.  This {{single-master/multiple-slave}}
 replication scheme is vital in high-volume environments where a
-single {{slapd}} just doesn't provide the necessary availability
-or reliability.  {{slapd}} includes support for {{LDAP Sync}}-based
+single {{slapd}} installation just doesn't provide the necessary availability
+or reliability.  For extremely demanding environments where a
+single point of failure is not acceptable, {{multi-master}} replication
+is also available.  {{slapd}} includes support for {{LDAP Sync}}-based
 replication.
 
 {{B:Proxy Cache}}: {{slapd}} can be configured as a caching
@@ -304,5 +416,7 @@ LDAP proxy service.
 {{B:Configuration}}: {{slapd}} is highly configurable through a
 single configuration file which allows you to change just about
 everything you'd ever want to change.  Configuration options have
-reasonable defaults, making your job much easier.
+reasonable defaults, making your job much easier. Configuration can
+also be performed dynamically using LDAP itself, which greatly
+improves manageability.