---- START access-control.html ---- ---- END access-control.html ---- ---- START appendix-changes.html ---- ---- END appendix-changes.html ---- ---- START appendix-common-errors.html ---- ---- END appendix-common-errors.html ---- ---- START appendix-configs.html ---- ---- END appendix-configs.html ---- ---- START appendix-contrib.html ---- ---- END appendix-contrib.html ---- ---- START appendix-deployments.html ---- ---- END appendix-deployments.html ---- ---- START appendix-ldap-result-codes.html ---- ---- END appendix-ldap-result-codes.html ---- ---- START appendix-recommended-versions.html ---- ---- END appendix-recommended-versions.html ---- ---- START appendix-upgrading.html ---- ---- END appendix-upgrading.html ---- ---- START autoconf.html ---- ---- END autoconf.html ---- ---- START backends.html ---- ---- END backends.html ---- ---- START config.html ---- ---- END config.html ---- ---- START copyright.html ---- 27c27 <

--- >

37c37 <

--- >

39c39 <

Portions Copyright 1999-2007 Howard Y.H. Chu.
Portions Copyright 1999-2007 Symas Corporation.
Portions Copyright 1998-2003 Hallvard B. Furuseth.
Portions Copyright 2007-2011 Gavin Henry.
Portions Copyright 2007-2011 Suretec Systems Limited.
All rights reserved.

--- >

Portions Copyright 1999-2008 Howard Y.H. Chu.
Portions Copyright 1999-2008 Symas Corporation.
Portions Copyright 1998-2003 Hallvard B. Furuseth.
Portions Copyright 2007-2011 Gavin Henry.
Portions Copyright 2007-2011 Suretec Systems Limited.
All rights reserved.

---- END copyright.html ---- ---- START dbtools.html ---- ---- END dbtools.html ---- ---- START glossary.html ---- ---- END glossary.html ---- ---- START index.html ---- 26c26 <

25 March 2011

--- >

28 March 2011

---- END index.html ---- ---- START install.html ---- 128c128 <

As an example, let's assume that we want to install OpenLDAP with BDB backend and TCP Wrappers support. By default, BDB is enabled and TCP Wrappers is not. So, we just need to specify --with-wrappers to include TCP Wrappers support:

--- >

130c130 < ./configure --with-wrappers --- > ./configure --enable-wrappers 135c135 < ./configure --with-wrappers --- > ./configure --enable-wrappers ---- END install.html ---- ---- START intro.html ---- ---- END intro.html ---- ---- START license.html ---- ---- END license.html ---- ---- START limits.html ---- ---- END limits.html ---- ---- START maintenance.html ---- ---- END maintenance.html ---- ---- START monitoringslapd.html ---- ---- END monitoringslapd.html ---- ---- START overlays.html ---- ---- END overlays.html ---- ---- START preface.html ---- ---- END preface.html ---- ---- START quickstart.html ---- ---- END quickstart.html ---- ---- START referrals.html ---- ---- END referrals.html ---- ---- START replication.html ---- 109,110c109 <

To ensure that both databases are consistent, each database might have to be put in read-only mode while performing a slapcat. --- >

If backing up the Berkeley database itself and periodically backing up the transaction log files, then the same member of the mirror pair needs to be used to collect logfiles until the next database backup is taken ---- END replication.html ---- ---- START runningslapd.html ---- ---- END runningslapd.html ---- ---- START sasl.html ---- ---- END sasl.html ---- ---- START schema.html ---- ---- END schema.html ---- ---- START security.html ---- ---- END security.html ---- ---- START slapdconf2.html ---- 26,28c26,37 <

Unlike previous OpenLDAP releases, the slapd(8) runtime configuration in 2.3 (and later) is fully LDAP-enabled and can be managed using the standard LDAP operations with data in 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-config(5) format to allow runtime changes to be saved. While the old style configuration uses a single file, normally installed as /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 /usr/local/etc/openldap/slapd.d directory. An alternate configuration directory (or file) can be specified via a command-line option to slapd(8).

This chapter describes the general format of the configuration system, followed by a detailed description of commonly used config settings.

--- >

OpenLDAP 2.3 and later have transitioned to using a dynamic runtime configuration engine, slapd-config(5). slapd-config(5)

is fully LDAP-enabled >
is managed using the standard LDAP operations >
stores its configuration data in an LDIF database, generally in the /usr/local/etc/openldap/slapd.d directory. >
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.

This chapter describes the general format of the slapd-config(5) configuration system, followed by a detailed description of commonly used settings.

The older style slapd.conf(5) file is still supported, but its use is deprecated and support for it will be withdrawn in a future OpenLDAP release. Configuring slapd(8) via slapd.conf(5) is described in the next chapter.

Refer to slapd(8) for information on how to have slapd automatically convert from slapd.conf(5) to slapd-config(5).

> Note: Although the slapd-config(5) system stores its configuration as (text-based) LDIF files, you should never edit any of the LDIF files directly. Configuration changes should be performed via LDAP operations, e.g. ldapadd(1), ldapdelete(1), or ldapmodify(1). >

30c39 < Note: some of the backends do not support runtime configuration yet. In those cases, the old style slapd.conf(5) file must be used. --- > Note: You will need to continue to use the older slapd.conf(5) configuration system if your OpenLDAP installation requires the use of one or more backends or overlays that have not been updated to use the slapd-config(5) system. As of OpenLDAP 2.4.25, the only official backends that have not yet been updated to use slapd-config(5) are slapd-meta(5) and slapd-sql(5). There may be additional contributed or experimental overlays that also have not been updated. ---- END slapdconf2.html ---- ---- START slapdconfig.html ---- 25,26c25,26 <

Once the software has been built and installed, you are ready to configure slapd(8) for use at your site. The slapd runtime configuration is primarily accomplished through the slapd.conf(5) file, normally installed in the /usr/local/etc/openldap directory.

An alternate configuration file location can be specified via a command-line option to slapd(8). This chapter describes the general format of the slapd.conf(5) configuration file, followed by a detailed description of commonly used config file directives.

--- >

This chapter describes configuring slapd(8) via the slapd.conf(5) configuration file. slapd.conf(5) has been deprecated and should only be used if your site requires one of the backends that hasn't yet been updated to work with the newer slapd-config(5) system. Configuring slapd(8) via slapd-config(5) is described in the previous chapter.

The slapd.conf(5) file is normally installed in the /usr/local/etc/openldap directory. An alternate configuration file location can be specified via a command-line option to slapd(8).

---- END slapdconfig.html ---- ---- START tls.html ---- ---- END tls.html ---- ---- START troubleshooting.html ---- ---- END troubleshooting.html ---- ---- START tuning.html ---- 121c121 <

Also note that id2entry always uses 16KB per "page", while dn2id uses whatever the underlying filesystem uses, typically 4 or 8KB. To avoid thrashing the, your cache must be at least as large as the number of internal pages in both the dn2id and id2entry databases, plus some extra space to accommodate the actual leaf data pages.

--- >

Also note that id2entry always uses 16KB per "page", while dn2id uses whatever the underlying filesystem uses, typically 4 or 8KB. To avoid thrashing, your cache must be at least as large as the number of internal pages in both the dn2id and id2entry databases, plus some extra space to accommodate the actual leaf data pages.

127,128c127,128 <

This 2.5MB number also doesn't take indexing into account. Each indexed attribute uses another database file of its own, using a Hash structure.

Unlike the B-trees, where you only need to touch one data page to find an entry of interest, doing an index lookup generally touches multiple keys, and the point of a hash structure is that the keys are evenly distributed across the data space. That means there's no convenient compact subset of the database that you can keep in the cache to insure quick operation, you can pretty much expect references to be scattered across the whole thing. My strategy here would be to provide enough cache for at least 50% of all of the hash data.

--- >

This 2.5MB number also doesn't take indexing into account. Each indexed attribute results in another database file. Earlier versions of OpenLDAP kept these index databases in Hash format, but from OpenLDAP 2.2 onward the index databases are in B-tree format so the same procedure can be used to calculate the necessary amount of cache for each index database.

For example, if your only index is for the objectClass attribute and db_stat reveals that objectClass.bdb has 339 internal pages and uses 4096 byte pages, the additional cache needed for just this attribute index is

130,134c130 < (Number of hash buckets + number of overflow pages + number of duplicate pages) * page size / 2. < <

The objectClass index for my example database is 5.9MB and uses 3 hash buckets and 656 duplicate pages. So:

<    ( 3 + 656 ) * 4KB / 2 =~ 1.3MB.
---
>        (339+1) * 4KB =~ 1.3MB.
---- END tuning.html ----