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
-operations with data in LDIF. The LDAP configuration engine
+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
configuration uses a single file, normally installed as
{{F:/usr/local/etc/openldap/slapd.conf}}, the new style
uses a slapd backend database to store the configuration. The
-the configuration database normally resides in the
+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 directives.
+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:
> ...
>
> # backend definitions
-> dn: olcBackend={X}<typeA>,cn=config
+> dn: olcBackend=<typeA>,cn=config
> objectClass: olcBackendConfig
-> olcBackend: {X}<typeA>
+> olcBackend: <typeA>
> <backend-specific settings>
>
> # database definitions
does not have to be provided; it will be automatically generated based
on the order in which entries are created.
-A configuration directive may take arguments. If so, they are
+Configuration directives are specified as values of individual
+attributes.
+Most of the attributes and objectClasses used in the slapd
+configuration have a prefix of {{EX:"olc"}} (OpenLDAP Configuration)
+in their names. Generally there is a one-to-one correspondence
+between the attributes and the old-style {{EX:slapd.conf}} configuration
+keywords, using the keyword as the attribute name, with the "olc"
+prefix attached.
+
+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:<>}}.
The distribution contains an example configuration file that will
be installed in the {{F: /usr/local/etc/openldap}} directory.
This section details commonly used configuration directives. For
a complete list, see the {{slapd.d}}(5) manual page. This section
-separates the configuration directives into global,
-backend-specific and data-specific categories, describing each
-directive and its default value (if any), and giving an example of
-its use.
-
-Most of the attributes and objectClasses used in the slapd
-configuration have a prefix of {{EX:"olc"}} (OpenLDAP Configuration)
-in their names.
-
-
+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
+an example of its use.
-H3: Global Directives
-Directives described in this section apply to all backends
-and databases unless specifically overridden in a backend or
-database definition. Arguments that should be replaced
-by actual text are shown in brackets {{EX:<>}}.
-
-
-H4: access 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
-more requesters (specified by <who>).
-See the {{SECT:Access Control}} section of this chapter for a
-summary of basic usage.
+H3: cn=config
-!if 0
-More details discussion of this directive can be found in the
-{{SECT:Advanced Access Control}} chapter.
-!endif
+Directives contained in this entry generally apply to the server as a whole.
+Most of them are system or connection oriented, not database related. This
+entry must have the {{EX:olcGlobal}} objectClass.
-Note: If no {{EX:access}} directives are specified, the default
-access control policy, {{EX:access to * by * read}}, allows all
-both authenticated and anonymous users read access.
-
-H4: attributetype <{{REF:RFC2252}} 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: idletimeout <integer>
+H4: olcIdleTimeout: <integer>
Specify the number of seconds to wait before forcibly closing
-an idle client connection. An idletimeout of 0, the default,
+an idle client connection. A value of 0, the default,
disables this feature.
-H4: include <filename>
-
-This directive specifies that slapd should read additional
-configuration information from the given file before continuing
-with the next line of the current file. The included file should
-follow the normal slapd config file format. The file is commonly
-used to include files containing schema specifications.
-
-Note: You should be careful when using this directive - there is
-no small limit on the number of nested include directives, and no
-loop detection is done.
-
-H4: loglevel <integer>
+H4: olcLogLevel: <level>
This directive specifies the level at which debugging statements
and operation statistics should be syslogged (currently logged to
the {{syslogd}}(8) {{EX:LOG_LOCAL4}} facility). You must have
configured OpenLDAP {{EX:--enable-debug}} (the default) for this
to work (except for the two statistics levels, which are always
-enabled). Log levels are additive. To display what numbers
+enabled). Log levels may be specified as integers or by keyword.
+Multiple log levels may be used and the levels are additive.
+To display what levels
correspond to what kind of debugging, invoke slapd with {{EX:-?}}
-or consult the table below. The possible values for <integer> are:
+or consult the table below. The possible values for <level> are:
!block table; colaligns="RL"; align=Center; \
title="Table 5.1: Debugging Levels"
-Level Description
--1 enable all debugging
-0 no debugging
-1 trace function calls
-2 debug packet handling
-4 heavy trace debugging
-8 connection management
-16 print out packets sent and received
-32 search filter processing
-64 configuration file processing
-128 access control list processing
-256 stats log connections/operations/results
-512 stats log entries sent
-1024 print communication with shell backends
-2048 print entry parsing debugging
+Level Keyword Description
+-1 Any enable all debugging
+0 no debugging
+1 Trace trace function calls
+2 Packets debug packet handling
+4 Args heavy trace debugging
+8 Conns connection management
+16 BER print out packets sent and received
+32 Filter search filter processing
+64 Config configuration processing
+128 ACL access control list processing
+256 Stats stats log connections/operations/results
+512 Stats2 stats log entries sent
+1024 Shell print communication with shell backends
+2048 Parse print entry parsing debugging
+4096 Cache database cache processing
+8192 Index database indexing
+16384 Sync syncrepl consumer processing
!endblock
\Example:
-E: loglevel -1
+E: olcLogLevel: -1
This will cause lots and lots of debugging information to be
logged.
-\Default:
+E: olcLogLevel: Conns Filter
-E: loglevel 256
+Just log the connection and search filter processing.
+\Default:
-H4: objectclass <{{REF:RFC2252}} Object Class Description>
+E: olcLogLevel: Stats
-This directive defines an object class.
-Please see the {{SECT:Schema Specification}} chapter for
-information regarding how to use this directive.
-
-H4: referral <URI>
+H4: olcReferral <URI>
This directive specifies the referral to pass back when slapd
cannot find a local database to handle a request.
\Example:
-> referral ldap://root.openldap.org
+> olcReferral: ldap://root.openldap.org
This will refer non-local queries to the global root LDAP server
at the OpenLDAP Project. Smart LDAP clients can re-ask their
contain a host part and optionally a distinguished name part.
-H4: sizelimit <integer>
+H4: Sample Entry
-This directive specifies the maximum number of entries to return
-from a search operation.
+>dn: cn=config
+>objectClass: olcGlobal
+>cn: config
+>olcIdleTimeout: 30
+>olcLogLevel: Stats
+>olcReferral: ldap://root.openldap.org
-\Default:
-> sizelimit 500
+H3: cn=include
-H4: timelimit <integer>
+An include entry holds the pathname of one include file. Include files
+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.
-This directive specifies the maximum number of seconds (in real
-time) slapd will spend answering a search request. If a
-request is not finished in this time, a result indicating an
-exceeded timelimit will be returned.
-\Default:
+H4: olcInclude: <filename>
+
+This directive specifies that slapd should read additional
+configuration information from the given file.
+
+Note: You should be careful when using this directive - there is
+no small limit on the number of nested include directives, and no
+loop detection is done.
+
+
+H4: Sample Entries
-> timelimit 3600
+>dn: cn=include{0},cn=config
+>objectClass: olcIncludeFile
+>cn: include{0}
+>olcInclude: ./schema/core.schema
+>
+>dn: cn=include{1},cn=config
+>objectClass: olcIncludeFile
+>cn: include{1}
+>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>
-H3: General Backend Directives
+Specify a list of directories to search for loadable modules. Typically the
+path is colon-separated but this depends on the operating system.
-Directives in this section apply only to the backend in which
-they are defined. They are supported by every type of backend.
-Backend directives apply to all databases instances of the
+
+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. Schema entries must have the {{EX:olcSchemaConfig}}
+objectClass.
+
+
+H4: olcAttributeTypes: <{{REF:RFC2252}} 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>
+
+This directive defines an object class.
+Please see the {{SECT:Schema Specification}} chapter for
+information regarding how to use this directive.
+
+
+H4: Sample Entries
+
+>dn: cn=schema,cn=config
+>objectClass: olcSchemaConfig
+>cn: schema
+>
+>dn: cn=test,cn=schema,cn=config
+>objectClass: olcSchemaConfig
+>cn: test
+>olcAttributeTypes: ( 1.1.1
+> 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 )
+>olcObjectClasses: ( 1.1.3 NAME 'testObject'
+> 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: backend <type>
+H4: olcBackend: <type>
-This directive marks the beginning of a backend declaration.
+This directive names a backend-specific configuration entry.
{{EX:<type>}} should be one of the
supported backend types listed in Table 5.2.
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
passwd Provides read-only access to {{passwd}}(5)
\Example:
-> backend bdb
+> olcBackend: bdb
+
+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.
+
-This marks the beginning of a new {{TERM:BDB}} backend
-definition.
+H4: Sample Entry
+> dn: olcBackend=bdb,cn=config
+> objectClass: olcBackendConfig
+> olcBackend: bdb
-H3: General Database Directives
-Directives in this section apply only to the database in which
-they are defined. They are supported by every type of database.
+H3: Database-specific Directives
-H4: database <type>
+Directives in this section are supported by every type of database.
+Database entries must have the {{EX:olcDatabaseConfig}} objectClass.
-This directive marks the beginning of a database instance
-declaration.
+H4: olcDatabase: [{<index>}]<type>
+
+This directive names a specific database instance. The numeric {<index>} may
+be provided to distinguish multiple databases of the same type. Usually the
+index can be omitted, and slapd will generate it automatically.
{{EX:<type>}} should be one of the
-supported backend types listed in Table 5.2.
+supported backend types listed in Table 5.2 or the {{EX:frontend}} type.
+
+The {{EX:frontend}} is a special database that is used to hold
+database-level options that should be applied to all the other
+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:
-> database bdb
+> olcDatabase: bdb
+
+This marks the beginning of a new {{TERM:BDB}} database instance.
+
+
+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
+more requesters (specified by <who>).
+See the {{SECT:Access Control}} section of this chapter for a
+summary of basic usage.
+
+!if 0
+More detailed discussion of this directive can be found in the
+{{SECT:Advanced Access Control}} chapter.
+!endif
-This marks the beginning of a new {{TERM:BDB}} database instance
-declaration.
+Note: If no {{EX:olcAccess}} directives are specified, the default
+access control policy, {{EX:to * by * read}}, allows all
+users (both authenticated and anonymous) read access.
+Note: Access controls defined in the frontend are appended to all
+other databases' controls.
-H4: readonly { on | off }
+
+H4: olcReadonly { TRUE | FALSE }
This directive puts the database into "read-only" mode. Any
attempts to modify the database will return an "unwilling to
\Default:
-> readonly off
+> olcReadonly: FALSE
+
-H4: replica
+H4: olcReplica
->
replica uri=ldap[s]://<hostname>[:<port>] | host=<hostname>[:<port>]
-> [bindmethod={simple|kerberos|sasl}]
+>
olcReplica: uri=ldap[s]://<hostname>[:<port>] | host=<hostname>[:<port>]
+> [bindmethod={simple|sasl}]
> ["binddn=<DN>"]
> [saslmech=<mech>]
> [authcid=<identity>]
> [authzid=<identity>]
> [credentials=<password>]
-> [srvtab=<filename>]
-This directive specifies a replication site for this database. The
+This directive specifies a replication site for this database for
+use with slurpd. The
{{EX:uri=}} parameter specifies a scheme, a host and optionally a port where
the slave slapd instance can be found. Either a domain name
or IP address may be used for <hostname>. If <port> is not
entire {{EX:"binddn=<DN>"}} string should be enclosed in double
quotes.
-The {{EX:bindmethod}} is {{EX:simple}} or {{EX:kerberos}} or {{EX:sasl}},
-depending on whether simple password-based authentication or Kerberos
-authentication or {{TERM:SASL}} authentication is to be used when connecting
+The {{EX:bindmethod}} is {{EX:simple}} or {{EX:sasl}},
+depending on whether simple password-based authentication
+or {{TERM:SASL}} authentication is to be used when connecting
to the slave slapd.
Simple authentication should not be used unless adequate data
or IPSEC). Simple authentication requires specification of
{{EX:binddn}} and {{EX:credentials}} parameters.
-Kerberos authentication is deprecated in favor of SASL authentication
-mechanisms, in particular the {{EX:KERBEROS_V4}} and {{EX:GSSAPI}}
-mechanisms. Kerberos authentication requires {{EX:binddn}} and
-{{EX:srvtab}} parameters.
-
SASL authentication is generally recommended. SASL authentication
requires specification of a mechanism using the {{EX:saslmech}} parameter.
Depending on the mechanism, an authentication identity and/or
information on how to use this directive.
-H4: replogfile <filename>
+H4: olcReplogfile: <filename>
This directive specifies the name of the replication log file to
which slapd will log changes. The replication log is typically
information on how to use this directive.
-H4: rootdn <DN>
+H4: olcRootDN: <DN>
This directive specifies the DN that is not subject to
access control or administrative limit restrictions for
Entry-based Example:
-> rootdn "cn=Manager,dc=example,dc=com"
+> olcRootDN: "cn=Manager,dc=example,dc=com"
SASL-based Example:
-> rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"
+> olcRootDN: "uid=root,cn=example.com,cn=digest-md5,cn=auth"
See the {{SECT:SASL Authentication}} section for information on
SASL authentication identities.
+H4:
olcRootPW: <password>
-This directive can be used to specifies a password for the DN for
+This directive can be used to specify a password for the DN for
the rootdn (when the rootdn is set to a DN within the database).
\Example:
-> rootpw secret
+> olcRootPW: secret
-It is also permissible to provide hash of the password in RFC 2307
+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.
\Example:
-> rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
+> olcRootPW: {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
The hash was generated using the command {{EX:slappasswd -s secret}}.
-H4: suffix <dn suffix>
+H4: olcSizeLimit: <integer>
+
+This directive specifies the maximum number of entries to return
+from a search operation.
+
+\Default:
+
+> olcSizeLimit: 500
+
+
+
+H4: olcSuffix: <dn suffix>
This directive specifies the DN suffix of queries that will be
passed to this backend database. Multiple suffix lines can be
-given, and at least one is required for each database
-definition.
+given, and usually at least one is required for each database
+definition. (Some backend types, such as {{EX:frontend}} and
+{{EX:monitor}} use a hard-coded suffix which may not be overridden
+in the configuration.)
\Example:
-> suffix "dc=example,dc=com"
+> olcSuffix: "dc=example,dc=com"
Queries with a DN ending in "dc=example,dc=com"
will be passed to this backend.
Note: When the backend to pass a query to is selected, slapd
-looks at the suffix line(s) in each database definition in the
-order they appear in the file. Thus, if one database suffix is a
-prefix of another, it must appear after it in the config file.
+looks at the suffix value(s) in each database definition in the
+order in which they were configured. Thus, if one database suffix is a
+prefix of another, it must appear after it in the configuration.
-H4: syncrepl
+H4: olcSyncrepl
-> syncrepl rid=<replica ID>
+> olcSyncrepl: rid=<replica ID>
> provider=ldap[s]://<hostname>[:port]
> [type=refreshOnly|refreshAndPersist]
> [interval=dd:hh:mm:ss]
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.
for more information on how to use this directive.
-H4: updatedn <DN>
+H4: olcTimeLimit: <integer>
+
+This directive specifies the maximum number of seconds (in real
+time) slapd will spend answering a search request. If a
+request is not finished in this time, a result indicating an
+exceeded timelimit will be returned.
+
+\Default:
+
+> olcTimeLimit: 3600
+
+
+H4: olcUpdateDN: <DN>
This directive is only applicable in a slave slapd. It specifies
the DN allowed to make changes to the replica. This may be the DN
Entry-based Example:
-> updatedn "cn=Update Daemon,dc=example,dc=com"
+> olcUpdateDN: "cn=Update Daemon,dc=example,dc=com"
SASL-based Example:
-> updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"
+> olcUpdateDN: "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"
See the {{SECT:Replication with slurpd}} chapter for more information
on how to use this directive.
-H4: updateref <URL>
+H4: olcUpdateref: <URL>
This directive is only applicable in a slave slapd. It
specifies the URL to return to clients which submit update
\Example:
-> updateref ldap://master.example.net
+> olcUpdateref: ldap://master.example.net
+
+
+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.
-That is, they must follow a "database bdb" line and come before any
-subsequent "backend" or "database" line. For a complete reference
-of BDB configuration directives, see {{slapd-bdb}}(5).
+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. 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: directory <directory>
+H4: olcDbDirectory: <directory>
This directive specifies the directory where the BDB files
containing the database and associated indices live.
\Default:
-> directory /usr/local/var/openldap-data
+> olcDbDirectory: /usr/local/var/openldap-data
-H3: LDBM Database Directives
-
-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).
-
-H4: cachesize <integer>
+H4: olcDbCachesize: <integer>
This directive specifies the size in entries of the in-memory
-cache maintained by the LDBM backend database instance.
+cache maintained by the BDB backend database instance.
\Default:
-> cachesize 1000
+> olcDbCachesize: 1000
-H4: dbcachesize <integer>
+H4: olcDbCheckpoint: <kbyte> <min>
-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.
+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.
-\Default:
+\Example:
-> dbcachesize 100000
+> olcDbCheckpoint: 1024 10
-H4: dbnolocking
+H4: olcDbConfig: <DB_CONFIG setting>
-This option, if present, disables database locking.
-Enabling this option may improve performance at the expense
-of data security.
+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.
+\Example:
-H4: dbnosync
+> 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
+
+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.
+
+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: 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