The main configuration file for OpenLDAP is /etc/ldap/slapd.conf. This file is almost always stored in /etc/ldap, but you will want to check your software vendor's installation path to be certain. The basic format of this file is very similar to other UNIX configuration files you have seen before: each line contains some sort of setting or directive, and lines beginning with hash (#) are comments.
The general structure of slapd.conf is as follows:
# comment - these options apply to every database
<global configuration options>
# first database definition & configuration options
database <backend 1 type>
<configuration options specific to backend 1>
# subsequent database definitions & configuration options
...
The man page for slapd.conf lists many options and features of this configuration file.
First, we encounter the global settings which will apply to every database.
# Features to permit
#allow bind_v2
This first section is where we enable features to permit. This commented out feature is backwards compatibility with LDAPv2. Note that this is not true v2 support, RFC 1777 and the now historic RFC 3494 specifications for v2 are not implimented. If you do have some more ancient clients that need to connect to this directory, enabling this support may help you, but unless you know for certain you need it I would recommend not enabling. LDAPv2 is not something we will look much at in this class.
Other options which can be enabled with the allow:
bind_anon_cred
Allows anonymous bind when credentials are not empty (e.g. when DN is empty).
bind_anon_dn
Allows unauthenticated (anonymous) bind when DN is not empty.
update_anon
Allow unauthenticated (anonymous) update operations to be processed (subject to access controls and other administrative limits).
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
This is the section where we include various schema and objectClass definitions. The book on page 40 discusses the various schemas available under OpenLDAP. Deciding which schema(s) to use can be a very difficult decision. Additionally, you may wish to design your own schema(s) (be sure to register an OID for your organization), or derive new ones from existing ones. These are all questions you will have to answer as your organization defines what they need from a directory service.
Regardless of which schema(s) you decide to use, chances are you will need to include at least core.schema, as most other shemas are derived from it.
# Schema check allows for forcing entries to
# match schemas for their objectClasses's
schemacheck on
This feature is very helpful in debugging LDIF data coming into the server. Chances are, you will want this enabled unless you have a very well tested and unchanging directory.
# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd/slapd.pid
When slapd starts, it will place it's process ID in this file so that it can then be killed when the system's runlevel changes.
# List of arguments that were passed to the server
argsfile /var/run/slapd.args
Chances are, you will never need to use this, but it is useful to know where it is if the need does arise.
# Read slapd.conf(5) for possible values
loglevel 0
Specify the level at which debugging statements and operation statistics should be syslogged (currently logged to the syslogd(8) LOG_LOCAL4 facility). Log levels are additive, and available levels are:
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 entry parsing
Since the log levels are additive, if you wanted to enable "trace function calls" and "print out packets sent and received" then you would get 1+16=17 for your loglevel setting.
# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_bdb
As you have probable seen, most UNIX applications allow for loadable module support. Apache can load modules on Perl, PHP, Java, etc. XFree86 can load modules for chipset support, accelerated graphics, etc. So it should come as no suprise that OpenLDAP supports loadable modules. We will not really get into these right now, but it should be noted that if you need backend support for some alternative database, you must load it's module here.
