# $OpenLDAP$
-# Copyright 1999-2005, The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 1999-2007 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
H1: The slapd Configuration File
Types Description
bdb Berkeley DB transactional backend
dnssrv DNS SRV backend
+hdb Hierarchical variant of bdb backend
ldap Lightweight Directory Access Protocol (Proxy) backend
ldbm Lightweight DBM backend
meta Meta Directory backend
specification. The search specification includes {{EX:searchbase}},
{{EX:scope}}, {{EX:filter}}, {{EX:attrs}}, {{EX:attrsonly}},
{{EX:sizelimit}}, and {{EX:timelimit}} parameters as in the normal
-search specification. The syncrepl search specification has
-the same value syntax and the same default values as in the
-{{ldapsearch}}(1) client search tool.
+search specification. The {{EX:searchbase}} parameter has no
+default value and must always be specified. The {{EX:scope}} defaults
+to {{EX:sub}}, the {{EX:filter}} defaults to {{EX:(objectclass=*)}},
+{{EX:attrs}} defaults to {{EX:"*,+"}} to replicate all user and operational
+attributes, and {{EX:attrsonly}} is unset by default. Both {{EX:sizelimit}}
+and {{EX:timelimit}} default to "unlimited", and only integers
+or "unlimited" may be specified.
The LDAP Content Synchronization protocol has two operation
types: {{EX:refreshOnly}} and {{EX:refreshAndPersist}}.
If an error occurs during replication, the consumer will attempt to reconnect
according to the retry parameter which is a list of the <retry interval>
-and <# of retries> pairs. For example, retry="60 5 300 3" lets the consumer
+and <# of retries> pairs. For example, retry="60 10 300 3" lets the consumer
retry every 60 seconds for the first 10 times and then retry every 300 seconds
for the next three times before stop retrying. + in <# of retries> means
indefinite number of retries until success.
> updateref ldap://master.example.net
-H3: BDB Database Directives
+H3: BDB and HDB Database Directives
-Directives in this category only apply to a {{TERM:BDB}} database.
-That is, they must follow a "database bdb" line and come before any
+Directives in this category only apply to both the {{TERM:BDB}}
+and the {{TERM:HDB}} database.
+That is, they must follow a "database bdb" or "database hdb" line
+and come before any
subsequent "backend" or "database" line. For a complete reference
-of BDB configuration directives, see {{slapd-bdb}}(5).
+of BDB/HDB configuration directives, see {{slapd-bdb}}(5).
H4: directory <directory>
shows the use of an attribute selector to grant access to a specific
attribute and various {{EX:<who>}} selectors.
-> access to dn.subtree="dc=example,dc=com" attr=homePhone
+> access to dn.subtree="dc=example,dc=com" attrs=homePhone
> by self write
-> by dn.children=dc=example,dc=com" search
+> by dn.children="dc=example,dc=com" search
> by peername.regex=IP:10\..+ read
> access to dn.subtree="dc=example,dc=com"
> by self write
their own DN from the member attribute, you could accomplish
it with an access directive like this:
-> access to attr=member,entry
+> access to attrs=member,entry
> by dnattr=member selfwrite
The dnattr {{EX:<who>}} selector says that the access applies to
E: 21. index cn,sn,uid pres,eq,approx,sub
E: 22. index objectClass eq
E: 23. # database access control definitions
-E: 24. access to attr=userPassword
+E: 24. access to attrs=userPassword
E: 25. by self write
E: 26. by anonymous auth
E: 27. by dn.base="cn=Admin,dc=example,dc=com" write