# $OpenLDAP$
-# Copyright 2005, The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 2005-2006 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
H1: Configuring slapd
Once the software has been built and installed, you are ready
to configure {{slapd}}(8) for use at your site. Unlike previous
-OpenLDAP releases, the slapd runtime configuration in 2.3 is
-fully LDAP-enabled and can be managed using the standard LDAP
+OpenLDAP releases, the slapd(8) runtime configuration in 2.3 (and later)
+is fully LDAP-enabled and can be managed using the standard LDAP
operations with data in {{TERM:LDIF}}. The LDAP configuration engine
allows all of slapd's configuration options to be changed on the fly,
generally without requiring a server restart for the changes
to take effect. The old style {{slapd.conf}}(5) file is still
-supported, but must be converted to the new {{slapd.d}}(5) format
+supported, but must be converted to the new {{slapd-config}}(5) format
to allow runtime changes to be saved. While the old style
configuration uses a single file, normally installed as
{{F:/usr/local/etc/openldap/slapd.conf}}, the new style
configuration database normally resides in the
{{F:/usr/local/etc/openldap/slapd.d}} directory.
-An alternate configuration directory (or file) can be specified via a
-command-line option to {{slapd}}(8) or {{slurpd}}(8). This chapter
-describes the general format of the configuration system, followed by a
-detailed description of commonly used config settings.
+An alternate configuration directory (or file) can be specified via
+a command-line option to {{slapd}}(8). This chapter 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
+old-style {{slapd.conf}} file for slurpd to use.
H2: Configuration Layout
Other objects may be part of the configuration but were omitted from
the illustration for clarity.
-The {{slapd.d}} configuration tree has a very specific structure. The
+The {{slapd-config}} configuration tree has a very specific structure. The
root of the tree is named {{EX:cn=config}} and contains global configuration
settings. Additional settings are contained in separate child entries:
* Include files
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:<>}}.
H2: Configuration Directives
This section details commonly used configuration directives. For
-a complete list, see the {{slapd.d}}(5) manual page. This section
+a complete list, see the {{slapd-config}}(5) manual page. This section
will treat the configuration directives in a top-down order, starting
with the global directives in the {{EX:cn=config}} entry. Each
directive will be described along with its default value (if any) and
>olcInclude: ./schema/cosine.schema
+H3: cn=module
+
+If support for dynamically loaded modules was enabled when configuring
+slapd, {{EX:cn=module}} entries may be used to specify sets of modules to load.
+Module entries must have the {{EX:olcModuleList}} objectClass.
+
+
+H4: olcModuleLoad: <filename>
+
+Specify the name of a dynamically loadable module to load. The filename
+may be an absolute path name or a simple filename. Non-absolute names
+are searched for in the directories specified by the {{EX:olcModulePath}}
+directive.
+
+
+H4: olcModulePath: <pathspec>
+
+Specify a list of directories to search for loadable modules. Typically the
+path is colon-separated but this depends on the operating system.
+
+
+H4: Sample Entries
+
+>dn: cn=module{0},cn=config
+>objectClass: olcModuleList
+>cn: module{0}
+>olcModuleLoad: /usr/local/lib/smbk5pwd.la
+>
+>dn: cn=module{1},cn=config
+>objectClass: olcModuleList
+>cn: module{1}
+>olcModulePath: /usr/local/lib:/usr/local/lib/slapd
+>olcModuleLoad: accesslog.la
+>olcModuleLoad: pcache.la
+
+
H3: cn=schema
The cn=schema entry holds all of the schema definitions that are hard-coded
objectClass.
-H4: olcAttributeTypes: <{{REF:RFC2252}} Attribute Type Description>
+H4: olcAttributeTypes: <{{REF:RFC4512}} Attribute Type Description>
This directive defines an attribute type.
Please see the {{SECT:Schema Specification}} chapter
for information regarding how to use this directive.
-H4: olcObjectClasses: <{{REF:RFC2252}} Object Class Description>
+H4: olcObjectClasses: <{{REF:RFC4512}} Object Class Description>
This directive defines an object class.
Please see the {{SECT:Schema Specification}} chapter for
>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
meta Meta Directory backend
monitor Monitor 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
This marks the beginning of a new {{TERM:BDB}} database instance.
-H4: olcAccess: to <what> [ by <who> <accesslevel> <control> ]+
+H4: olcAccess: to <what> [ by <who> [<accesslevel>] [<control>] ]+
This directive grants access (specified by <accesslevel>) to a
set of entries and/or attributes (specified by <what>) by one or
Simple authentication should not be used unless adequate data
integrity and confidentiality protections are in place (e.g. TLS
-or IPSEC). Simple authentication requires specification of
-{{EX:binddn}} and {{EX:credentials}} parameters.
+or {{TERM:IPsec}}). Simple authentication requires specification
+of {{EX:binddn}} and {{EX:credentials}} parameters.
SASL authentication is generally recommended. SASL authentication
requires specification of a mechanism using the {{EX:saslmech}} parameter.
This directive specifies the name of the replication log file to
which slapd will log changes. The replication log is typically
-written by slapd and read by slurpd. Normally, this directive is
-only used if slurpd is being used to replicate the database.
-However, you can also use it to generate a transaction log, if
-slurpd is not running. In this case, you will need to periodically
-truncate the file, since it will grow indefinitely otherwise.
+written by {{slapd}}(8) and read by {{slurpd}}(8). Normally, this
+directive is only used if {{slurpd}}(8) is being used to replicate
+the database. However, you can also use it to generate a transaction
+log, if {{slurpd}}(8) is not running. In this case, you will need to
+periodically truncate the file, since it will grow indefinitely
+otherwise.
See the chapter entitled {{SECT:Replication with slurpd}} for more
information on how to use this directive.
> olcRootPW: secret
-It is also permissible to provide a hash of the password in RFC 2307
-form. {{slappasswd}}(8) may be used to generate the password hash.
+It is also permissible to provide a hash of the password in
+{{REF:RFC2307}} form. {{slappasswd}}(8) may be used to generate
+the password hash.
\Example:
The master database is located at the replication provider site
specified by the {{EX:provider}} parameter. The replica database is
kept up-to-date with the master content using the LDAP Content
-Synchronization protocol. See {{EX:draft-zeilenga-ldup-sync-xx.txt}}
-({{a work in progress}}) for more information on the protocol.
+Synchronization protocol. See {{REF:RFC4533}}
+for more information on the protocol.
The {{EX:rid}} parameter is used for identification of the current
{{EX:syncrepl}} directive within the replication consumer server,
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}}.
Simple authentication should not be used unless adequate data
integrity and confidentiality protections are in place (e.g. TLS
-or IPSEC). Simple authentication requires specification of {{EX:binddn}}
+or IPsec). Simple authentication requires specification of {{EX:binddn}}
and {{EX:credentials}} parameters.
SASL authentication is generally recommended. SASL authentication
parameter specifies Cyrus SASL security properties.
The syncrepl replication mechanism is supported by the
-three native backends: back-bdb, back-hdb, and back-ldbm.
+two native backends: back-bdb and back-hdb.
See the {{SECT:LDAP Sync Replication}} chapter of the admin guide
for more information on how to use this directive.
> 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>
documentation for more details.
-H4: olcDbNosync: <TRUE|FALSE>
+H4: olcDbNosync: { TRUE | FALSE }
This option causes on-disk database contents to not be immediately
synchronized with in memory changes upon change. Setting this option
-to TRUE may improve performance at the expense of data integrity. This
+to {{EX:TRUE}} may improve performance at the expense of data integrity. This
directive has the same effect as using
> olcDbConfig: set_flags DB_TXN_NOSYNC
manually completed using the slapindex tool.
-H4: olcDbLinearIndex: <TRUE|FALSE>
+H4: olcDbLinearIndex: { TRUE | FALSE }
If this setting is {{EX:TRUE}} slapindex will index one attribute
at a time. The default settings is {{EX:FALSE}} in which case all
>dn: olcDatabase=hdb,cn=config
>objectClass: olcDatabaseConfig
->objectClass: olcBdbConfig
+>objectClass: olcHdbConfig
>olcDatabase: hdb
>olcSuffix: "dc=example,dc=com"
>olcDbDirectory: /usr/local/var/openldap-data
> olcAccess: <access directive>
> <access directive> ::= to <what>
-> [by <who> <access> <control>]+
+> [by <who> [<access>] [<control>] ]+
> <what> ::= * |
> [dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
> [filter=<ldapfilter>] [attrs=<attrlist>]
> [set=<setspec>]
> [aci=<attrname>]
> <access> ::= [self]{<level>|<priv>}
-> <level> ::= none | auth | compare | search | read | write
-> <priv> ::= {=|+|-}{w|r|s|c|x|0}+
+> <level> ::= none | disclose | auth | compare | search | read | write | manage
+> <priv> ::= {=|+|-}{m|w|r|s|c|x|d|0}+
> <control> ::= [stop | continue | break]
where the <what> part selects the entries and/or attributes to which
discussed further in this document.) The third form is used to
select entries which are within the requested scope of DN. The
<DN> is a string representation of the Distinguished Name, as
-described in {{REF:RFC2253}}.
+described in {{REF:RFC4514}}.
The scope can be either {{EX:base}}, {{EX:one}}, {{EX:subtree}},
or {{EX:children}}. Where {{EX:base}} matches only the entry with
> to filter=<ldap filter>
where <ldap filter> is a string representation of an LDAP
-search filter, as described in {{REF:RFC2254}}. For example:
+search filter, as described in {{REF:RFC4515}}. For example:
> to filter=(objectClass=person)
H3: The access to grant
-
The kind of <access> granted can be one of the following:
-
!block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
title="Table 5.4: Access Levels"
-Level Privileges Description
-none =0 no access
-auth =x needed to bind
-compare =cx needed to compare
-search =scx needed to apply search filters
-read =rscx needed to read search results
-write =wrscx needed to modify/rename
+Level Privileges Description
+none =0 no access
+disclose =d needed for information disclosure on error
+auth =dx needed to authenticate (bind)
+compare =cdx needed to compare
+search =scdx needed to apply search filters
+read =rscdx needed to read search results
+write =wrscdx needed to modify/rename
+manage =mwrscdx needed to manage
!endblock
-Each level implies all lower levels of access. So, for
-example, granting someone {{EX:write}} access to an entry also
-grants them {{EX:read}}, {{EX:search}}, {{EX:compare}}, and
-{{EX:auth}} access. However, one may use the privileges specifier
+Each level implies all lower levels of access. So, for example,
+granting someone {{EX:write}} access to an entry also grants them
+{{EX:read}}, {{EX:search}}, {{EX:compare}}, {{EX:auth}} and
+{{EX:disclose}} access. However, one may use the privileges specifier
to grant specific permissions.
When evaluating whether some requester should be given access to
an entry and/or attribute, slapd compares the entry and/or attribute
-to the {{EX:<what>}} selectors given in the configuration.
-For each entry, access controls provided in the database which holds
+to the {{EX:<what>}} selectors given in the configuration. For
+each entry, access controls provided in the database which holds
the entry (or the first database if not held in any database) apply
first, followed by the global access directives (which are held in
-the {{EX:frontend}} database definition). Within this
-priority, access directives are examined in the order in which they
-appear in the configuration attribute. Slapd stops with the first {{EX:<what>}}
-selector that matches the entry and/or attribute. The corresponding
-access directive is the one slapd will use to evaluate access.
+the {{EX:frontend}} database definition). Within this priority,
+access directives are examined in the order in which they appear
+in the configuration attribute. Slapd stops with the first
+{{EX:<what>}} selector that matches the entry and/or attribute. The
+corresponding access directive is the one slapd will use to evaluate
+access.
Next, slapd compares the entity requesting access to the {{EX:<who>}}
selectors within the access directive selected above in the order
!endif
-Note: the remainder of this chapter has not yet been updated to reflect
-the new cn=config mechanisms.
-
H2: Configuration Example
The following is an example configuration, interspersed
reference only and are not included in the actual file. First, the
global configuration section:
-E: 1. # example config file - global configuration section
-E: 2. include /usr/local/etc/schema/core.schema
-E: 3. referral ldap://root.openldap.org
-E: 4. access to * by * read
-
-Line 1 is a comment. Line 2 includes another config file
-which contains {{core}} schema definitions.
-The {{EX:referral}} directive on line 3
+E: 1. # example config file - global configuration entry
+E: 2. dn: cn=config
+E: 3. objectClass: olcGlobal
+E: 4. cn: config
+E: 5. olcReferral: ldap://root.openldap.org
+E: 6.
+
+Line 1 is a comment. Lines 2-4 identify this as the global
+configuration entry.
+The {{EX:olcReferral:}} directive on line 5
means that queries not local to one of the databases defined
below will be referred to the LDAP server running on the
standard port (389) at the host {{EX:root.openldap.org}}.
-
-Line 4 is a global access control. It applies to all
-entries (after any applicable database-specific access
-controls).
-
-The next section of the configuration file defines a BDB
-backend that will handle queries for things in the
-"dc=example,dc=com" portion of the tree. The
-database is to be replicated to two slave slapds, one on
-truelies, the other on judgmentday. Indices are to be
-maintained for several attributes, and the {{EX:userPassword}}
-attribute is to be protected from unauthorized access.
-
-E: 5. # BDB definition for the example.com
-E: 6. database bdb
-E: 7. suffix "dc=example,dc=com"
-E: 8. directory /usr/local/var/openldap-data
-E: 9. rootdn "cn=Manager,dc=example,dc=com"
-E: 10. rootpw secret
-E: 11. # replication directives
-E: 12. replogfile /usr/local/var/openldap/slapd.replog
-E: 13. replica uri=ldap://slave1.example.com:389
-E: 14. binddn="cn=Replicator,dc=example,dc=com"
-E: 15. bindmethod=simple credentials=secret
-E: 16. replica uri=ldaps://slave2.example.com:636
-E: 17. binddn="cn=Replicator,dc=example,dc=com"
-E: 18. bindmethod=simple credentials=secret
-E: 19. # indexed attribute definitions
-E: 20. index uid pres,eq
-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: 25. by self write
-E: 26. by anonymous auth
-E: 27. by dn.base="cn=Admin,dc=example,dc=com" write
-E: 28. by * none
-E: 29. access to *
-E: 30. by self write
-E: 31. by dn.base="cn=Admin,dc=example,dc=com" write
-E: 32. by * read
-
-Line 5 is a comment. The start of the database definition is marked
-by the database keyword on line 6. Line 7 specifies the DN suffix
-for queries to pass to this database. Line 8 specifies the directory
+Line 6 is a blank line, indicating the end of this entry.
+
+E: 7. # internal schema
+E: 8. dn: cn=schema,cn=config
+E: 9. objectClass: olcSchemaConfig
+E: 10. cn: schema
+E: 11.
+
+Line 7 is a comment. Lines 8-10 identify this as the root of
+the schema subtree. The actual schema definitions in this entry
+are hardcoded into slapd so no additional attributes are specified here.
+Line 11 is a blank line, indicating the end of this entry.
+
+E: 12. # include the core schema
+E: 13. include: file:///usr/local/etc/openldap/schema/core.ldif
+E: 14.
+
+Line 12 is a comment. Line 13 is an LDIF include directive which
+accesses the {{core}} schema definitions in LDIF format. Line 14
+is a blank line.
+
+Next comes the database definitions. The first database is the
+special {{EX:frontend}} database whose settings are applied globally
+to all the other databases.
+
+E: 15. # global database parameters
+E: 16. dn: olcDatabase=frontend,cn=config
+E: 17. objectClass: olcDatabaseConfig
+E: 18. olcDatabase: frontend
+E: 19. olcAccess: to * by * read
+E: 20.
+
+Line 15 is a comment. Lines 16-18 identify this entry as the global
+database entry. Line 19 is a global access control. It applies to all
+entries (after any applicable database-specific access controls).
+
+The next entry defines a BDB backend that will handle queries for things
+in the "dc=example,dc=com" portion of the tree. Indices are to be maintained
+for several attributes, and the {{EX:userPassword}} attribute is to be
+protected from unauthorized access.
+
+E: 21. # BDB definition for example.com
+E: 22. dn: olcDatabase=bdb,cn=config
+E: 23. objectClass: olcDatabaseConfig
+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 attr=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 9 and 10 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 11 through 18 are for replication. Line 12 specifies the
-replication log file (where changes to the database are logged -
-this file is written by slapd and read by slurpd). Lines 13 through
-15 specify the hostname and port for a replicated host, the DN to
-bind as when performing updates, the bind method (simple) and the
-credentials (password) for the binddn. Lines 16 through 18 specify
-a second replication site. See the {{SECT:Replication with slurpd}}
-chapter for more information on these directives.
-
-Lines 20 through 22 indicate the indices to maintain for various
+Lines 30 through 32 indicate the indices to maintain for various
attributes.
-Lines 24 through 32 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 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 39, the read access
-would be allowed due to the global access rule at line 4.
-
-E: 33. # BDB definition for example.net
-E: 34. database bdb
-E: 35. suffix "dc=example,dc=net"
-E: 36. directory /usr/local/var/openldap-data-net
-E: 37. rootdn "cn=Manager,dc=example,dc=com"
-E: 38. index objectClass eq
-E: 39. access to * by users read
+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. 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