slapdconf2.sdf

OpenLdap是LDAP的开源项目

# $OpenLDAP: pkg/openldap-guide/admin/slapdconf2.sdf,v 1.1.2.14 2007/04/06 03:59:58 quanah Exp $
# Copyright 2005-2007 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
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
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
uses a slapd backend database to store the configuration. 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 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 slapd configuration is stored as a special LDAP directory with
a predefined schema and DIT. There are specific objectClasses used to
carry global configuration options, schema definitions, backend and
database definitions, and assorted other items. A sample config tree
is shown in Figure 5.1.

!import "config_dit.gif"; align="center"; title="Sample configuration tree"
FT[align="Center"] Figure 5.1: Sample configuration tree.

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
root of the tree is named {{EX:cn=config}} and contains global configuration
settings. Additional settings are contained in separate child entries:
* Include files
.. Usually these are just pathnames left over from a converted
{{EX:slapd.conf}} file.
.. Otherwise use of Include files is deprecated.
* Dynamically loaded modules
.. These may only be used if the {{EX:--enable-modules}} option was
used to configure the software.
* Schema definitions
.. The {{EX:cn=schema,cn=config}} entry contains the system schema (all
the schema that is hard-coded in slapd).
.. Child entries of {{EX:cn=schema,cn=config}} contain user schema as
loaded from config files or added at runtime.
* Backend-specific configuration 
* Database-specific configuration
.. Overlays are defined in children of the Database entry.
.. Databases and Overlays may also have other miscellaneous children.

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 a single space, it is considered a
continuation of the previous line (even if the previous line is a
comment) and the single leading space is removed. Entries are separated by blank lines.

The general layout of the config LDIF is as follows:

>	# global configuration settings
>	dn: cn=config
>	objectClass: olcGlobal
>	cn: config
>	<global config settings>
>
>	# schema definitions
>	dn: cn=schema,cn=config
>	objectClass: olcSchemaConfig
>	cn: schema
>	<system schema>
>
>	dn: cn={X}core,cn=schema,cn=config
>	objectClass: olcSchemaConfig
>	cn: {X}core
>	<core schema>
>
>	# additional user-specified schema
>	...
>
>	# backend definitions
>	dn: olcBackend=<typeA>,cn=config
>	objectClass: olcBackendConfig
>	olcBackend: <typeA>
>	<backend-specific settings>
>
>	# database definitions
>	dn: olcDatabase={X}<typeA>,cn=config
>	objectClass: olcDatabaseConfig
>	olcDatabase: {X}<typeA>
>	<database-specific settings>
>
>	# subsequent definitions and settings
>	...

Some of the entries listed above have a numeric index {{EX:"{X}"}} in
their names. While most configuration settings have an inherent ordering
dependency (i.e., one setting must take effect before a subsequent one
may be set), LDAP databases are inherently unordered. The numeric index
is used to enforce a consistent ordering in the configuration database,
so that all ordering dependencies are preserved. In most cases the index
does not have to be provided; it will be automatically generated based
on the order in which entries are created.

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"}}.
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.
A number of files containing schema definitions (attribute types
and object classes) are also provided in the
{{F: /usr/local/etc/openldap/schema}} directory.


H2: Configuration Directives

This section details commonly used configuration directives.  For
a complete list, see the {{slapd.d}}(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
an example of its use.


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. This
entry must have the {{EX:olcGlobal}} objectClass.


H4: olcIdleTimeout: <integer>

Specify the number of seconds to wait before forcibly closing
an idle client connection.  A value of 0, the default,
disables this feature.


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 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 <level> are:

!block table; colaligns="RL"; align=Center; \
	title="Table 5.1: Debugging Levels"
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: olcLogLevel: -1

This will cause lots and lots of debugging information to be
logged.

E: olcLogLevel: Conns Filter

Just log the connection and search filter processing.

\Default:

E: olcLogLevel: Stats


H4: olcReferral <URI>

This directive specifies the referral to pass back when slapd
cannot find a local database to handle a request.

\Example:

>	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
query at that server, but note that most of these clients are
only going to know how to handle simple LDAP URLs that
contain a host part and optionally a distinguished name part.


H4: Sample Entry

>dn: cn=config
>objectClass: olcGlobal
>cn: config
>olcIdleTimeout: 30
>olcLogLevel: Stats
>olcReferral: ldap://root.openldap.org



H3: cn=include

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.


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

>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>

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. 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. Backend entries must have the
{{EX:olcBackendConfig}} objectClass.

H4: olcBackend: <type>

This directive names a backend-specific configuration entry.
{{EX:<type>}} should be one of the
supported backend types listed in Table 5.2.

!block table; align=Center; coltags="EX,N"; \
	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)
perl	Perl Programmable backend