Introduction to Dynamic Configuration (cn=config)

1 TODO
2 Preamble
3 Introduction
4 Configuration ObjectClasses
- 4.1 OlcConfig Abstract ObjectClass
- 4.2 OlcGlobal ObjectClass
- 4.3 olcSchemaConfig ObjectClass
- 4.4 olcFrontendConfig ObjectClass
- 4.5 olcModuleList ObjectClass
- 4.6 olcDatabaseConfig ObjectClass
  - 4.6.1 olcBdbConfig/olcHdbConfig database ObjectClasses
  - 4.6.2 olcDbPerlConfig database ObjectClass
  - 4.6.3 olcDbSocketConfig database ObjectClass
  - 4.6.4 olcLdapConfig database ObjectClass
  - 4.6.5 olcLdifConfig database ObjectClass
  - 4.6.6 olcMdbConfig database ObjectClass
  - 4.6.7 olcMetaConfig database ObjectClass
  - 4.6.8 olcMonitorConfig database ObjectClass
  - 4.6.9 olcNdbConfig database ObjectClass
  - 4.6.10 olcNullConfig database ObjectClass
  - 4.6.11 olcPasswdConfig database ObjectClass
  - 4.6.12 olcRelayConfig database ObjectClass
  - 4.6.13 olcShellConfig database ObjectClass
  - 4.6.14 olcSqlConfig database ObjectClass

TODO

olcBdbConfig/olcHdbConfig : add attribute list description
olcLdapConfig : add attribute list description
olcMetaConfig : add attribute list description
olcNdbConfig : add attribute list descriptionn
olcSqlConfig : add attribute list description

Preamble

This documentation has been established using various existing documents , mainly [[The OpenLDAP 2.4 admin guide|http://www.openldap.org/doc/admin24/guide]] and the various man pages got from the latest build (2.4.41).

Introduction

OpenLDAP dynamic configuration relies on a special naming context named cn=config, backed by an LDIF database.

An example of what could contain the cn=config backend is given by this picture :

Here, we have a standard layout for a LDAP server having one user data stored into a MDB backend, and both the config and MDB database are providers for other LDAP servers that are going to be replicas. We also have declared 7 schemas, one of them being specific, the 6 others being standard OpenLDAP schemas.

We have 4 database declared in this configuration :

frontend : a generic configuration which is used by all the other databases, unless each specific database override the configuration set there.
config : <To be completed. Here, I have found no info about what does this database, my understanding is that this database exists for the sake of replication>
monitor : it’s a fake database, which provides information about the running operations
mdb : A MDB type database. We may use many other database types. This is where we will store the user’s data

Note that we could have added as many database as needed.

Each database can be associated with _overlays_. Here, we have just declared the syncprov overlay.

It says nothing about the exact configuration, which will be described in the following document.

I have not mentioned the backend elements in this introduction. Backends are supposed to be related to a type of database as a whole, and this should be the place global configuration about a specific type of database would be stored. AFAICT, there is no parameter that can be configured atm, so this sounds like a unused configuration element so far.

Configuration ObjectClasses

As the configuration is stored using LDIF, the element stored are pure LDAP entries. As such, they are defined by ObjectClasses. This paragraph will give an overview of each of the existing configuration ObjectClasses.

This picture lists the existing ObjectClasses and their inheritence relation :

Most of thoe ObjectClasses are Structural (bold boxes), one is Auxiliary (bold dotted box), and one is Abstract (doted box).

Each entry present in the cn=config backend will use one of those ObjectClasses.

OlcConfig Abstract ObjectClass

This ObjectClass is just a placeholder, containing no Attribute. It’s just used as the root of the hierarchy.

OlcGlobal ObjectClass

This ObjectClass contains the global configuration parameters, that apply to the whole server.

Here is the content of this ObjectClass :

Here is the list of attributes for the olcGlobal ObjectClass :

[TABLE]

Changing these settings will generally require deleting any indices that depend on these parameters and recreating them with slapindex.

Here is the list of attributes that are related to TLS for the olcGlobal ObjectClass :

[TABLE]

Here is the list of attributes that are to be used by every database used in the server :

[TABLE]

There are a few attributes that are not covered by the existing documentation :

[TABLE]

The olcAccess attribute which is described as part of the Frontend database belongs to the olcDatabaseConfig ObjectClass in the slapd-config man page.

The olcSchemaDNattribute belongs to the olcDatabaseConfig ObjectClass.

olcSchemaConfig ObjectClass

This ObjectClass contains the description of a schema. Here is its content :

Each entry will contain the list of Syntaxes, AttributeTypes, ObjectClasses and DitContentRules for a given schema, which name is stored in the mandatory cn attribute. The added olcObjectIdentifier attribute is used to define the OID of each elements in a more user-readable way.

Each cn is prefixed by a number as in : {2}nis. This is used to order the various schema, which will be loaded following this order.

Here is an example of content :

dn: cn={2}nis,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: {2}nis
olcAttributeTypes: {0}( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; th
 e common name' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatc
 h SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
...
olcObjectClasses: {0}( 1.3.6.1.1.1.2.0 NAME 'posixAccount' DESC 'Abstraction o
 f an account with POSIX attributes' SUP top AUXILIARY MUST ( cn $ uid $ uidNu
 mber $ gidNumber $ homeDirectory ) MAY ( userPassword $ loginShell $ gecos $ 
 description ) )
...

olcFrontendConfig ObjectClass

This ObjectClass contains common configuration for any other database. Here is its description :

Here are the attribute for this ObjectClass :

Attribute	Params	Description
olcDefaultSearchBase	<dn>	Specify a default search base to use when client submits a non-base search request with an empty base DN.
olcPasswordHash		???
olcSortVals	<attr> […]	Specify a list of multi-valued attributes whose values will always be maintained in sorted order.

olcModuleList ObjectClass

This ObjectClass contains the list of loaded modules (overlays). Here is its description :

Here are the attribute for this ObjectClass :

Attribute	Params	Description	Default
cn	<dn>	The module instance	module{0}
olcModulePath	<pathSpec>	The path on disk where the modules are stored	/usr/local/openldap/libexec/openldap
olcModuleLoad	<fileName>	The list of loaded modules

olcDatabaseConfig ObjectClass

Shouldn’t this ObjectClass be ABSTRACT, instead of STRUCTURAL ? Nowhere we will ever have an entry having this ObjectClass alone, it’s always associated with one of the various type of database ObjectClass ( olcMdbConfig, etc)

This ObjectClass is the root of all the Database ObjectClasses. Here is its content :

Here are the Database ObjectClass attributes :

[TABLE]

We will now describe the various database type.

olcBdbConfig/olcHdbConfig database ObjectClasses

This are the BerkeleyDB configuration ObjectClasses. There is no difference between those two ObjectClasses, except their name ( olcBdbConfig and olcHdbConfig ). Here is the description of the classes :