# $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 in
-addition to the {{EX:olcDatabaseConfig}} class.
+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: 30. olcDbIndex: uid pres,eq
E: 31. olcDbIndex: cn,sn,uid pres,eq,approx,sub
E: 32. olcDbIndex: objectClass eq
-E: 33. olcAccess: to attr=userPassword
+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
projects / openldap / blobdiff