# $OpenLDAP$
-# Copyright 2005, The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 2005-2007 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
H1: Configuring slapd
describes the general format of the configuration system, followed by a
detailed description of commonly used config settings.
+Note: some of the backends and of the distributed overlays
+do not support runtime configuration yet. In those cases,
+the old style {{slapd.conf}}(5) file must be used.
+
Note: the current version of {{slurpd}} has not been updated for
compatibility with this new configuration engine. If you must use
slurpd for replication at your site, you will have to maintain an
The usual rules for LDIF files apply to the configuration information:
Comment lines beginning with a '{{EX:#}}' character
-are ignored. If a line begins with white space, it is considered a
+are ignored. If a line begins with a single space, it is considered a
continuation of the previous line (even if the previous line is a
-comment). Entries are separated by blank lines.
+comment) and the single leading space is removed. Entries are separated by blank lines.
The general layout of the config LDIF is as follows:
A configuration directive may take arguments. If so, the arguments are
separated by white space. If an argument contains white space,
-the argument should be enclosed in double quotes {{EX:"like this"}}. If
-an argument contains a double quote or a backslash character `{{EX:\}}',
-the character should be preceded by a backslash character `{{EX:\}}'.
+the argument should be enclosed in double quotes {{EX:"like this"}}.
In the descriptions that follow, arguments that should be replaced
by actual text are shown in brackets {{EX:<>}}.
>objectClass: olcSchemaConfig
>cn: test
>olcAttributeTypes: ( 1.1.1
-> NAME 'testAttr'
-> EQUALITY integerMatch
-> SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+> NAME 'testAttr'
+> EQUALITY integerMatch
+> SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
>olcAttributeTypes: ( 1.1.2 NAME 'testTwo' EQUALITY caseIgnoreMatch
-> SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+> SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
>olcObjectClasses: ( 1.1.3 NAME 'testObject'
-> MAY ( testAttr $ testTwo ) AUXILIARY )
+> MAY ( testAttr $ testTwo ) AUXILIARY )
H3: Backend-specific Directives
title="Table 5.2: Database Backends"
Types Description
bdb Berkeley DB transactional backend
+config Slapd configuration backend
dnssrv DNS SRV backend
+hdb Hierarchical variant of bdb backend
ldap Lightweight Directory Access Protocol (Proxy) backend
ldbm Lightweight DBM backend
ldif Lightweight Data Interchange Format backend
> olcBackend: bdb
-There are no other directives defined for this entry, so generally
-it will not be needed. However, specific backend types may define
-additional attributes for their particular use.
+There are no other directives defined for this entry. Specific backend
+types may define additional attributes for their particular use but so
+far none have ever been defined. As such, these directives usually do
+not appear in any actual configurations.
H4: Sample Entry
databases. Subsequent database definitions may also override some
frontend settings.
+The {{EX:config}} database is also special; both the {{EX:config}} and
+the {{EX:frontend}} databases are always created implicitly even if they
+are not explicitly configured, and they are created before any other
+databases.
+
\Example:
> olcDatabase: bdb
> olcSyncrepl: rid=<replica ID>
> provider=ldap[s]://<hostname>[:port]
+> [starttls=yes|critical]
> [type=refreshOnly|refreshAndPersist]
> [interval=dd:hh:mm:ss]
> [retry=[<retry interval> <# of retries>]+]
-> [searchbase=<base DN>]
+> searchbase=<base DN>
> [filter=<filter str>]
> [scope=sub|one|base]
> [attrs=<attr list>]
{{EX:replica}} directives define two independent replication
mechanisms. They do not represent the replication peers of each other.
+The {{EX:starttls}} parameter specifies use of the StartTLS extended
+operation to establish a TLS session before Binding to the provider. If the
+StartTLS request fails and the {{EX:critical}} argument was used, the
+session will be aborted. Otherwise the syncrepl session continues without
+TLS.
+
The content of the syncrepl replica is defined using a search
specification as its result set. The consumer slapd will
send search requests to the provider slapd according to the search
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 positive integers
+or "unlimited" may be specified.
The LDAP Content Synchronization protocol has two operation
types: {{EX:refreshOnly}} and {{EX:refreshAndPersist}}.
> olcUpdateref: ldap://master.example.net
-H4: Sample Entry
+H4: Sample Entries
>dn: olcDatabase=frontend,cn=config
>objectClass: olcDatabaseConfig
+>objectClass: olcFrontendConfig
>olcDatabase: frontend
>olcReadOnly: FALSE
+>
+>dn: olcDatabase=config,cn=config
+>objectClass: olcDatabaseConfig
+>olcDatabase: config
+>olcRootDN: cn=Manager,dc=example,dc=com
+
H3: BDB and HDB Database Directives
and the {{TERM:HDB}} database.
They are used in an olcDatabase entry in addition to the generic
database directives defined above. For a complete reference
-of BDB/HDB configuration directives, see {{slapd-bdb}}(5). BDB and
-HDB database entries must have the {{EX:olcBdbConfig}} objectClass.
+of BDB/HDB configuration directives, see {{slapd-bdb}}(5). In
+addition to the {{EX:olcDatabaseConfig}} objectClass, BDB and HDB
+database entries must have the {{EX:olcBdbConfig}} and
+{{EX:olcHdbConfig}} objectClass, respectively.
H4: olcDbDirectory: <directory>
>dn: olcDatabase=hdb,cn=config
>objectClass: olcDatabaseConfig
->objectClass: olcBdbConfig
+>objectClass: olcHdbConfig
>olcDatabase: hdb
>olcSuffix: "dc=example,dc=com"
>olcDbDirectory: /usr/local/var/openldap-data
shows the use of an attribute selector to grant access to a specific
attribute and various {{EX:<who>}} selectors.
-> olcAccess: to dn.subtree="dc=example,dc=com" attr=homePhone
+> olcAccess: to dn.subtree="dc=example,dc=com" attrs=homePhone
> by self write
> by dn.children=dc=example,dc=com" search
> by peername.regex=IP:10\..+ read
their own DN from the member attribute, you could accomplish
it with an access directive like this:
-> olcAccess: to attr=member,entry
+> olcAccess: to attrs=member,entry
> by dnattr=member selfwrite
The dnattr {{EX:<who>}} selector says that the access applies to
when originally defining the values. For example, when you create the
settings
-> olcAccess: to attr=member,entry
+> olcAccess: to attrs=member,entry
> by dnattr=member selfwrite
> olcAccess: to dn.children="dc=example,dc=com"
> by * search
when you read them back using slapcat or ldapsearch they will contain
-> olcAccess: {0}to attr=member,entry
+> olcAccess: {0}to attrs=member,entry
> by dnattr=member selfwrite
> olcAccess: {1}to dn.children="dc=example,dc=com"
> by * search
attribute (regardless of its value) and adds a new value that is
explicitly inserted as value #1. The result will be
-> olcAccess: {0}to attr=member,entry
+> olcAccess: {0}to attrs=member,entry
> by dnattr=member selfwrite
> olcAccess: {1}to dn.children="dc=example,dc=com"
> by * write
E: 21. # BDB definition for example.com
E: 22. dn: olcDatabase=bdb,cn=config
E: 23. objectClass: olcDatabaseConfig
-E: 24. olcDatabase: bdb
-E: 25. olcSuffix: "dc=example,dc=com"
-E: 26. olcDbDirectory: /usr/local/var/openldap-data
-E: 27. olcRootDN: "cn=Manager,dc=example,dc=com"
-E: 28. olcRootPW: secret
-E: 29. olcDbIndex: uid pres,eq
-E: 30. olcDbIndex: cn,sn,uid pres,eq,approx,sub
-E: 31. olcDbIndex: objectClass eq
-E: 32. olcAccess: to attr=userPassword
-E: 33. by self write
-E: 34. by anonymous auth
-E: 35. by dn.base="cn=Admin,dc=example,dc=com" write
-E: 36. by * none
-E: 37. olcAccess: to *
-E: 38. by self write
-E: 39. by dn.base="cn=Admin,dc=example,dc=com" write
-E: 40. by * read
-E: 41.
-
-Line 21 is a comment. Lines 22-24 identify this entry as a BDB database
-configuration entry. Line 25 specifies the DN suffix
-for queries to pass to this database. Line 26 specifies the directory
+E: 24. objectClass: olcBdbConfig
+E: 25. olcDatabase: bdb
+E: 26. olcSuffix: "dc=example,dc=com"
+E: 27. olcDbDirectory: /usr/local/var/openldap-data
+E: 28. olcRootDN: "cn=Manager,dc=example,dc=com"
+E: 29. olcRootPW: secret
+E: 30. olcDbIndex: uid pres,eq
+E: 31. olcDbIndex: cn,sn,uid pres,eq,approx,sub
+E: 32. olcDbIndex: objectClass eq
+E: 33. olcAccess: to attrs=userPassword
+E: 34. by self write
+E: 35. by anonymous auth
+E: 36. by dn.base="cn=Admin,dc=example,dc=com" write
+E: 37. by * none
+E: 38. olcAccess: to *
+E: 39. by self write
+E: 40. by dn.base="cn=Admin,dc=example,dc=com" write
+E: 41. by * read
+E: 42.
+
+Line 21 is a comment. Lines 22-25 identify this entry as a BDB database
+configuration entry. Line 26 specifies the DN suffix
+for queries to pass to this database. Line 27 specifies the directory
in which the database files will live.
-Lines 27 and 28 identify the database {{super-user}} entry and associated
+Lines 28 and 29 identify the database {{super-user}} entry and associated
password. This entry is not subject to access control or size or
time limit restrictions.
-Lines 29 through 31 indicate the indices to maintain for various
+Lines 30 through 32 indicate the indices to maintain for various
attributes.
-Lines 32 through 40 specify access control for entries in this
+Lines 33 through 41 specify access control for entries in this
database. As this is the first database, the controls also apply
to entries not held in any database (such as the Root DSE). For
all applicable entries, the {{EX:userPassword}} attribute is writable
All other attributes are writable by the entry and the "admin"
entry, but may be read by all users (authenticated or not).
-Line 41 is a blank line, indicating the end of this entry.
+Line 42 is a blank line, indicating the end of this entry.
The next section of the example configuration file defines another
BDB database. This one handles queries involving the
{{EX:dc=example,dc=net}} subtree but is managed by the same entity
-as the first database. Note that without line 50, the read access
+as the first database. Note that without line 51, the read access
would be allowed due to the global access rule at line 19.
E: 42. # BDB definition for example.net
E: 43. dn: olcDatabase=bdb,cn=config
E: 44. objectClass: olcDatabaseConfig
-E: 45. olcDatabase: bdb
-E: 46. olcSuffix: "dc=example,dc=net"
-E: 47. olcDbDirectory: /usr/local/var/openldap-data-net
-E: 48. olcRootDN: "cn=Manager,dc=example,dc=com"
-E: 49. olcDbIndex: objectClass eq
-E: 50. olcAccess: to * by users read
+E: 45. objectClass: olcBdbConfig
+E: 46. olcDatabase: bdb
+E: 47. olcSuffix: "dc=example,dc=net"
+E: 48. olcDbDirectory: /usr/local/var/openldap-data-net
+E: 49. olcRootDN: "cn=Manager,dc=example,dc=com"
+E: 50. olcDbIndex: objectClass eq
+E: 51. olcAccess: to * by users read
projects / openldap / blobdiff