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
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:<>}}.
H3: cn=config
Directives contained in this entry generally apply to the server as a whole.
-Most of them are system or connection oriented, not database related.
+Most of them are system or connection oriented, not database related. This
+entry must have the {{EX:olcGlobal}} objectClass.
H4: olcIdleTimeout: <integer>
are part of the old style slapd.conf configuration system and must be in
slapd.conf format. Include files were commonly used to load schema
specifications. While they are still supported, their use is deprecated.
+Include entries must have the {{EX:olcIncludeFile}} objectClass.
H4: olcInclude: <filename>
>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
in slapd. As such, the values in this entry are generated by slapd so no
schema values need to be provided in the config file. The entry must still
be defined though, to serve as a base for the user-defined schema to add
-in underneath.
+in underneath. Schema entries must have the {{EX:olcSchemaConfig}}
+objectClass.
H4: olcAttributeTypes: <{{REF:RFC2252}} Attribute Type Description>
>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
Backend directives apply to all database instances of the
same type and, depending on the directive, may be overridden
-by database directives.
+by database directives. Backend entries must have the
+{{EX:olcBackendConfig}} objectClass.
H4: olcBackend: <type>
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
H3: Database-specific Directives
Directives in this section are supported by every type of database.
+Database entries must have the {{EX:olcDatabaseConfig}} objectClass.
H4: olcDatabase: [{<index>}]<type>
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
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.
> 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 Database Directives
+H3: BDB and HDB Database Directives
-Directives in this category only apply to a {{TERM:BDB}} database.
+Directives in this category apply to both the {{TERM:BDB}}
+and the {{TERM:HDB}} database.
They are used in an olcDatabase entry in addition to the generic
-database directives defined above. Their use requires the database
-entry to also use the {{EX:olcBdbConfig}} objectClass.
-For a complete reference
-of BDB configuration directives, see {{slapd-bdb}}(5).
+database directives defined above. For a complete reference
+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>
> olcDbDirectory: /usr/local/var/openldap-data
-H4: Sample Entry
+H4: olcDbCachesize: <integer>
->dn: olcDatabase=bdb,cn=config
->objectClass: olcDatabaseConfig
->objectClass: olcBdbConfig
->olcDatabase: bdb
->olcSuffix: "dc=example,dc=com"
->olcDbDirectory: /usr/local/var/openldap-data
+This directive specifies the size in entries of the in-memory
+cache maintained by the BDB backend database instance.
-H3: LDBM Database Directives
+\Default:
-Directives in this category only apply to a {{TERM:LDBM}} database.
-That is, they must follow a "database ldbm" line and come before
-any subsequent "backend" or "database" line. For a complete reference
-of LDBM configuration directives, see {{slapd-ldbm}}(5).
+> olcDbCachesize: 1000
-H4: cachesize <integer>
-This directive specifies the size in entries of the in-memory
-cache maintained by the LDBM backend database instance.
+H4: olcDbCheckpoint: <kbyte> <min>
-\Default:
+This directive specifies how often to checkpoint the BDB transaction log.
+A checkpoint operation flushes the database buffers to disk and writes a
+checkpoint record in the log.
+The checkpoint will occur if either <kbyte> data has been written or
+<min> minutes have passed since the last checkpont. Both arguments default
+to zero, in which case they are ignored. When the <min> argument is
+non-zero, an internal task will run every <min> minutes to perform the
+checkpoint. See the Berkeley DB reference guide for more details.
-> cachesize 1000
+\Example:
+> olcDbCheckpoint: 1024 10
-H4: dbcachesize <integer>
-This directive specifies the size in bytes of the in-memory cache
-associated with each open index file. If not supported by the
-underlying database method, this directive is ignored without
-comment. Increasing this number uses more memory but can
-cause a dramatic performance increase, especially during
-modifies or when building indices.
+H4: olcDbConfig: <DB_CONFIG setting>
-\Default:
+This attribute specifies a configuration directive to be placed in the
+{{EX:DB_CONFIG}} file of the database directory. At server startup time, if
+no such file exists yet, the {{EX:DB_CONFIG}} file will be created and the
+settings in this attribute will be written to it. If the file exists,
+its contents will be read and displayed in this attribute. The attribute
+is multi-valued, to accomodate multiple configuration directives. No default
+is provided, but it is essential to use proper settings here to get the
+best server performance.
-> dbcachesize 100000
+\Example:
+> olcDbConfig: set_cachesize 0 10485760 0
+> olcDbConfig: set_lg_bsize 2097512
+> olcDbConfig: set_lg_dir /var/tmp/bdb-log
+> olcDbConfig: set_flags DB_LOG_AUTOREMOVE
-H4: dbnolocking
+In this example, the BDB cache is set to 10MB, the BDB transaction log
+buffer size is set to 2MB, and the transaction log files are to be stored
+in the /var/tmp/bdb-log directory. Also a flag is set to tell BDB to
+delete transaction log files as soon as their contents have been
+checkpointed and they are no longer needed. Without this setting the
+transaction log files will continue to accumulate until some other
+cleanup procedure removes them. See the SleepyCat documentation for the
+{{EX:db_archive}} command for details.
-This option, if present, disables database locking.
-Enabling this option may improve performance at the expense
-of data security.
+Ideally the BDB cache must be
+at least as large as the working set of the database, the log buffer size
+should be large enough to accomodate most transactions without overflowing,
+and the log directory must be on a separate physical disk from the main
+database files. And both the database directory and the log directory
+should be separate from disks used for regular system activities such as
+the root, boot, or swap filesystems. See the FAQ-o-Matic and the SleepyCat
+documentation for more details.
-H4: dbnosync
+H4: olcDbNosync: { TRUE | FALSE }
This option causes on-disk database contents to not be immediately
-synchronized with in memory changes upon change. Enabling this option
-may improve performance at the expense of data integrity.
+synchronized with in memory changes upon change. Setting this option
+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
-H4: directory <directory>
+H4: olcDbIDLcacheSize: <integer>
-This directive specifies the directory where the LDBM files
-containing the database and associated indices live.
+Specify the size of the in-memory index cache, in index slots. The
+default is zero. A larger value will speed up frequent searches of
+indexed entries. The optimal size will depend on the data and search
+characteristics of the database, but using a number three times
+the entry cache size is a good starting point.
-\Default:
+\Example:
-> directory /usr/local/var/openldap-data
+> olcDbIDLcacheSize: 3000
-H4:
index {<attrlist> | default} [pres,eq,approx,sub,none]
+H4:
olcDbIndex: {<attrlist> | default} [pres,eq,approx,sub,none]
This directive specifies the indices to maintain for the given
attribute. If only an {{EX:<attrlist>}} is given, the default
\Example:
-> index default pres,eq
-> index uid
-> index cn,sn pres,eq,sub
-> index objectClass eq
+> olcDbIndex: default pres,eq
+> olcDbIndex: uid
+> olcDbIndex: cn,sn pres,eq,sub
+> olcDbIndex: objectClass eq
The first line sets the default set of indices to maintain to
present and equality. The second line causes the default (pres,eq)
By default, no indices are maintained. It is generally advised
that minimally an equality index upon objectClass be maintained.
-> index objectClass eq
+> olcDbindex: objectClass eq
+
+If this setting is changed while slapd is running, an internal task
+will be run to generate the changed index data. All server operations
+can continue as normal while the indexer does its work. If slapd is
+stopped before the index task completes, indexing will have to be
+manually completed using the slapindex tool.
+
+
+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
+indexed attributes of an entry are processed at the same time. When
+enabled, each indexed attribute is processed individually, using
+multiple passes through the entire database. This option improves
+slapindex performance when the database size exceeds the BDB cache
+size. When the BDB cache is large enough, this option is not needed
+and will decrease performance. Also by default, slapadd performs
+full indexing and so a separate slapindex run is not needed. With
+this option, slapadd does no indexing and slapindex must be used.
-H4: mode <integer>
+H4: olcDbMode: <integer>
This directive specifies the file protection mode that newly
created database index files should have.
\Default:
-> mode 0600
+> olcDbMode: 0600
+
+
+H4: olcDbSearchStack: <integer>
+
+Specify the depth of the stack used for search filter evaluation.
+Search filters are evaluated on a stack to accomodate nested {{EX:AND}} /
+{{EX:OR}} clauses. An individual stack is allocated for each server thread.
+The depth of the stack determines how complex a filter can be evaluated
+without requiring any additional memory allocation. Filters that are
+nested deeper than the search stack depth will cause a separate stack to
+be allocated for that particular search operation. These separate allocations
+can have a major negative impact on server performance, but specifying
+too much stack will also consume a great deal of memory. Each search
+uses 512K bytes per level on a 32-bit machine, or 1024K bytes per level
+on a 64-bit machine. The default stack depth is 16, thus 8MB or 16MB
+per thread is used on 32 and 64 bit machines, respectively. Also the
+512KB size of a single stack slot is set by a compile-time constant which
+may be changed if needed; the code must be recompiled for the change
+to take effect.
+
+\Default:
+
+> olcDbSearchStack: 16
+
+
+H4: olcDbShmKey: <integer>
+
+Specify a key for a shared memory BDB environment. By default the BDB
+environment uses memory mapped files. If a non-zero value is specified,
+it will be used as the key to identify a shared memory region that will
+house the environment.
+
+\Example:
+
+> olcDbShmKey: 42
+
+
+H4: Sample Entry
+
+>dn: olcDatabase=hdb,cn=config
+>objectClass: olcDatabaseConfig
+>objectClass: olcHdbConfig
+>olcDatabase: hdb
+>olcSuffix: "dc=example,dc=com"
+>olcDbDirectory: /usr/local/var/openldap-data
+>olcDbCacheSize: 1000
+>olcDbCheckpoint: 1024 10
+>olcDbConfig: set_cachesize 0 10485760 0
+>olcDbConfig: set_lg_bsize 2097152
+>olcDbConfig: set_lg_dir /var/tmp/bdb-log
+>olcDbConfig: set_flags DB_LOG_AUTOREMOVE
+>olcDbIDLcacheSize: 3000
+>olcDbIndex: objectClass eq
H2: Access Control
Access to slapd entries and attributes is controlled by the
-access configuration file directive. The general form of an
-access line is:
+olcAccess attribute, whose values are a sequence of access directives.
+The general form of the olcAccess configuration is:
-> <access directive> ::= access to <what>
+> olcAccess: <access directive>
+> <access directive> ::= to <what>
> [by <who> <access> <control>]+
> <what> ::= * |
> [dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
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 file.
+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. Within this
+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 config file. Slapd stops with the first {{EX:<what>}}
+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 order of evaluation of access directives makes their placement
in the configuration file important. If one access directive is
more specific than another in terms of the entries it selects, it
-should appear first in the config file. Similarly, if one {{EX:<who>}}
+should appear first in the configuration. Similarly, if one {{EX:<who>}}
selector is more specific than another it should come first in the
access directive. The access control examples given below should
help make this clear.
A simple example:
-> access to * by * read
+> olcAccess: to * by * read
This access directive grants read access to everyone.
-> access to *
+> olcAccess: to *
> by self write
> by anonymous auth
> by * read
This directive allows the user to modify their entry, allows anonymous
-to authentication against these entries, and allows all others to
+to authenticate against these entries, and allows all others to
read these entries. Note that only the first {{EX:by <who>}} clause
which matches applies. Hence, the anonymous users are granted
{{EX:auth}}, not {{EX:read}}. The last clause could just as well
of protection in place. The following shows how security strength
factors (SSF) can be used.
-> access to *
+> olcAccess: to *
> by ssf=128 self write
> by ssf=64 anonymous auth
> by ssf=64 users read
This directive allows users to modify their own entries if security
-protections have of strength 128 or better have been established,
+protections of strength 128 or better have been established,
allows authentication access to anonymous users, and read access
-when 64 or better security protections have been established. If
-client has not establish sufficient security protections, the
+when strength 64 or better security protections have been established. If
+the client has not establish sufficient security protections, the
implicit {{EX:by * none}} clause would be applied.
-The following example shows the use of a style specifiers to select
+The following example shows the use of style specifiers to select
the entries by DN in two access directives where ordering is
significant.
-> access to dn.children="dc=example,dc=com"
+> olcAccess: to dn.children="dc=example,dc=com"
> by * search
-> access to dn.children="dc=com"
+> olcAccess: to dn.children="dc=com"
> by * read
Read access is granted to entries under the {{EX:dc=com}} subtree,
would never be reached, since all entries under {{EX:dc=example,dc=com}}
are also under {{EX:dc=com}} entries.
-Also note that if no {{EX:access to}} directive matches or no {{EX:by
-<who>}} clause, {{B:access is denied}}. That is, every {{EX:access
+Also note that if no {{EX:olcAccess: to}} directive matches or no {{EX:by
+<who>}} clause, {{B:access is denied}}. That is, every {{EX:olcAccess:
to}} directive ends with an implicit {{EX:by * none}} clause and
-every access list ends with an implicit {{EX:access to * by * none}}
+every access list ends with an implicit {{EX:olcAccess: to * by * none}}
directive.
The next example again shows the importance of ordering, both of
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
+> olcAccess: to dn.subtree="dc=example,dc=com" attr=homePhone
> by self write
> by dn.children=dc=example,dc=com" search
> by peername.regex=IP:10\..+ read
-> access to dn.subtree="dc=example,dc=com"
+> olcAccess: to dn.subtree="dc=example,dc=com"
> by self write
> by dn.children="dc=example,dc=com" search
> by anonymous auth
their own DN from the member attribute, you could accomplish
it with an access directive like this:
-> access to attr=member,entry
+> olcAccess: to attr=member,entry
> by dnattr=member selfwrite
The dnattr {{EX:<who>}} selector says that the access applies to
the entry attribute is required because access to the entry is
required to access any of the entry's attributes.
+
+
+H3: Access Control Ordering
+
+Since the ordering of {{EX:olcAccess}} directives is essential to their
+proper evaluation, but LDAP attributes normally do not preserve the
+ordering of their values, OpenLDAP uses a custom schema extension to
+maintain a fixed ordering of these values. This ordering is maintained
+by prepending a {{EX:"{X}"}} numeric index to each value, similarly to
+the approach used for ordering the configuration entries. These index
+tags are maintained automatically by slapd and do not need to be specified
+when originally defining the values. For example, when you create the
+settings
+
+> olcAccess: to attr=member,entry
+> by dnattr=member selfwrite
+> olcAccess: to dn.children="dc=example,dc=com"
+> by * search
+> olcAccess: to dn.children="dc=com"
+> by * read
+
+when you read them back using slapcat or ldapsearch they will contain
+
+> olcAccess: {0}to attr=member,entry
+> by dnattr=member selfwrite
+> olcAccess: {1}to dn.children="dc=example,dc=com"
+> by * search
+> olcAccess: {2}to dn.children="dc=com"
+> by * read
+
+The numeric index may be used to specify a particular value to change
+when using ldapmodify to edit the access rules. This index can be used
+instead of (or in addition to) the actual access value. Using this
+numeric index is very helpful when multiple access rules are being managed.
+
+For example, if we needed to change the second rule above to grant
+write access instead of search, we could try this LDIF:
+
+> changetype: modify
+> delete: olcAccess
+> olcAccess: to dn.children="dc=example,dc=com" by * search
+> -
+> add: olcAccess
+> olcAccess: to dn.children="dc=example,dc=com" by * write
+> -
+
+But this example {{B:will not}} guarantee that the existing values remain in
+their original order, so it will most likely yield a broken security
+configuration. Instead, the numeric index should be used:
+
+> changetype: modify
+> delete: olcAccess
+> olcAccess: {1}
+> -
+> add: olcAccess
+> olcAccess: {1}to dn.children="dc=example,dc=com" by * write
+> -
+
+This example deletes whatever rule is in value #1 of the {{EX:olcAccess}}
+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
+> by dnattr=member selfwrite
+> olcAccess: {1}to dn.children="dc=example,dc=com"
+> by * write
+> olcAccess: {2}to dn.children="dc=com"
+> by * read
+
+which is exactly what was intended.
+
!if 0
For more details on how to use the {{EX:access}} directive,
consult the {{Advanced Access Control}} chapter.
!endif
-H2: Configuration File Example
+H2: Configuration Example
-The following is an example configuration file, interspersed
+The following is an example configuration, interspersed
with explanatory text. It defines two databases to handle
different parts of the {{TERM:X.500}} tree; both are {{TERM:BDB}}
database instances. The line numbers shown are provided for
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