title: Translating slapd.conf into slapd.d link: https://onemoretech.wordpress.com/2011/07/20/translating-slapdconf-into-slapdd/ author: lembobro description: post_id: 18 created: 2011/07/20 00:28:37 created_gmt: 2011/07/20 00:28:37 comment_status: open post_name: translating-slapdconf-into-slapdd status: publish post_type: post

Translating slapd.conf into slapd.d

Just some notes on making the transition from the old slapd.conf to "cn=config" or controlling the configuration of OpenLDAP. For those who have OpenLDAP as their primary directory in production this is probably a big deal. Being able to make changes to things like access controls while the server is running is a real benefit. For home or experimental users like me making the switch can be a real annoyance. Having said that, "cn=config" is here to stay, and like IP v6 is something we're all going to have to learn eventually. The move up to OpenLDAP 2.4 came along as part of my upgrade to Scientific Linux 6 from CentOS 5. While there are ways to continue using slapd.conf (for example, by adding "SLAPD_OPTIONS='-f /etc/openldap/slapd.conf'" to /etc/sysconfig/ldap), the time had come for me to master something new. The process of using "cn=config" starts with converting an existing slapd.conf using:

slaptest -f [name of slapd.conf] -F [directory for slapd.d]

Like this:

[me@mine~]$ slapdtest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d

For now I continue to maintain a slapd.conf with any changes I make in "cn=config", for use to level set things in case I drive myself into a rut. This process will also pull in all the schema files loaded by the slapd.conf, on Red Hat systems typically found under /etc/openldap/schema. Once you've made the conversion you'll have to update the schema by importing into "cn=config". Starting with RHEL 6, Red Hat provides a corresponding .ldif file with each shipping .schema file. One trick you can use to convert any other standard format OpenLDAP .schema files into the new .ldif ones is to use slaptest to build them against a dummy slapd,conf. I created one under $HOME/ldapbuild and added directories for schema, slapd.d, var/lib/ldap and var/log to keep the utility happy. Of course your new schema file will be under your ldapbuild/schema directory and that dummy slapd.conf will contain an "include" line with the path to the new schema file, like "include ldapbuild/schema/mynew.schema". You should find a "cn={5}mynew.ldif" or the like under slapd.d/cn=config/cn=schema. Can you modify or extend your schema "on the fly" while your directory is running? I've experimented with this and got mixed results. For now I'm going to take the coward's way out, shut down the server, make my changes, and fire it back up when done. Some enterprise directories, like Oracle's DSEE (that they inherited from Sun) or Red Hat's 389 Directory, can safely do schema changes, and even database indexing, on the fly. So far I'm wary of even trying with OpenLDAP. If I needed this feature but still wanted to use open source, I'd definitely look into 389 for the job. Here are the contents of my /etc/openldap/slapd.d directory under "cn=config":

-rw------- 1 ldap ldap   403 Jul  6 01:59 cn=module{0}.ldif
drwxr-x--- 2 ldap ldap  4096 Jul  6 01:59 cn=schema
-rw------- 1 ldap ldap 51878 Jul  6 01:59 cn=schema.ldif
-rw------- 1 ldap ldap   561 Jul  6 01:59 olcDatabase={0}config.ldif
-rw------- 1 ldap ldap  1037 Jul 20 00:11 olcDatabase={-1}frontend.ldif
-rw------- 1 ldap ldap   439 Jul  6 01:59 olcDatabase={1}monitor.ldif
drwxr-x--- 2 ldap ldap  4096 Jul  6 01:59 olcDatabase={2}bdb
-rw------- 1 ldap ldap  2666 Jul 19 23:08 olcDatabase={2}bdb.ldif

This is my "oclDatabase={-1}frontend.ldif" file, what we used to call the "global" section of slapd.conf (the access control rules are very basic, but suitable for a home directory):

dn: olcDatabase={-1}frontend
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 0
olcReadOnly: FALSE
olcSchemaDN: cn=Subschema
olcSizeLimit: 2000
olcTimeLimit: 900
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: e7ee9542-3be0-1030-8ad0-bbd4436b36a7
creatorsName: cn=config
createTimestamp: 20110706055950Z
olcAccess: {0}to dn.base=""  by * read
olcAccess: {1}to dn.base="cn=subschema"  by * read
olcAccess: {2}to dn.subtree="cn=monitor"  by * read
olcAccess: {3}to attrs=userpassword by group/groupofuniquenames/uniquemember="c
 n=administrators,ou=groups,dc=casalembo,dc=com" write by self write by * auth
olcAccess: {4}to * by group/groupofuniquenames/uniquemember="cn=administrators
 ,ou=groups,dc=casalembo,dc=com" write by self write by users read by anonymou
 s read

Finally, here's the primary dbd database configuration, which to me looks eerily similar to what you'd find in a Netscape family directory server's dse.ldif -- just more obtuse (are the OpenLDAP developers trying to out-Oracle Oracle in the obfuscation department?):

dn: olcDatabase={2}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {2}bdb
olcSuffix: dc=example,dc=com
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=Manager,dc=example,dc=com
olcRootPW:: e1NTSEF12345678910V1dwTjk3YWRjWUxyKzg=
olcMonitoring: TRUE
olcDbDirectory: /var/lib/ldap
olcDbCacheSize: 1000
olcDbConfig: {0}# $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.1.2.4 2007/1
 2/18 11:51:46 ghenry Exp $
olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databas
 es.
olcDbConfig: {2}#
olcDbConfig: {3}# See the Oracle Berkeley DB documentation
olcDbConfig: {4}#   <http://www.oracle.com/technology/documentation/berkele
 y-db/db/ref/env/db_config.html>
olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics.
olcDbConfig: {6}#
olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ
olcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl
 PTI+
olcDbConfig: {9}# in particular:
olcDbConfig: {10}#   
olcDbConfig: {11}
olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon
 rebuilding
olcDbConfig: {13}# the DB environment.
olcDbConfig: {14}
olcDbConfig: {15}# one 0.25 GB cache
olcDbConfig: {16}set_cachesize 0 268435456 1
olcDbConfig: {17}
olcDbConfig: {18}# Data Directory
olcDbConfig: {19}#set_data_dir db
olcDbConfig: {20}
olcDbConfig: {21}# Transaction Log settings
olcDbConfig: {22}set_lg_regionmax 262144
olcDbConfig: {23}set_lg_bsize 2097152
olcDbConfig: {24}#set_lg_dir logs
olcDbConfig: {25}
olcDbConfig: {26}# Note: special DB_CONFIG flags are no longer needed for
 "quick"
olcDbConfig:: ezI3fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl
 aXIgLXEgb3B0aW9uKS4g
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass pres,eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: uidNumber pres,eq
olcDbIndex: gidNumber pres,eq
olcDbIndex: mail pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbIndex: sn pres,eq,sub
olcDbIndex: loginShell pres,eq
olcDbIndex: ou pres,eq,sub
olcDbIndex: memberUid pres,eq,sub
olcDbIndex: nisMapName pres,eq,sub
olcDbIndex: nisMapEntry pres,eq,sub
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig

Really not looking forward to having to create one of these from scratch. Makes me yearn for the days when I used to roll my own slapd.conf from memory (and reminds me of why we all should dump sendmail for postfix).

Copyright 2004-2019 Phil Lembo