12.3. Configuring and Testing the OpenLDAP Server

Problem

Installing your OpenLDAP server went fine; now what do you do to start and test it?

Solution

Debian users don't need to follow this recipe because the Debian installer does all this, but it might be useful to review it anyway.

Fedora users, copy this example: /etc/openldap/slapd.conf. Substitute your own domain name (any one will do, even example.com) in the brackets, and invent your own rootpw:

	#######################################################################
	# Global Directives:

	# 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

	pidfile         /var/run/slapd/slapd.pid
	argsfile        /var/run/slapd/slapd.args

	# Read slapd.conf(5) for possible values
	loglevel         -1

	# Where the dynamically loaded modules are stored
	modulepath    /usr/lib/ldap
	moduleload    back_bdb

	# The maximum number of entries that is returned for a search operation
	sizelimit 500

	# The tool-threads parameter sets the actual amount of cpus that is used
	# for indexing.
	tool-threads 1

	#######################################################################
	# Specific Backend Directives for bdb:
	# Backend specific directives apply to this backend until another
	# 'backend' directive occurs
	backend        bdb
	checkpoint  512 30

	#######################################################################
	# Specific Directives for database #1
	database        bdb
	suffix "dc=[alrac],dc=[net]"
	rootdn "cn=admin,dc=[alrac],dc=[net]"
	rootpw [password]

	# Where the database file are physically stored for database #1
	directory       "/var/lib/ldap"

	# Indexing options for database #1
	index objectClass eq

	# Save the time that the entry gets modified, for database #1
	lastmod         on

	# admin can read/write all passwords
	# users can change their own passwords
	access to attrs=userPassword,shadowLastChange
	        by dn="cn=admin,dc=alrac,dc=net" write
   	        by anonymous auth
	        by self write
	        by * none

	# many applications need read access to the rootDSE
	# especially to read supported SASL mechanisms
	# this restricts them to the rootDSE; they cannot read past this level
	access to dn.base="" by * read

	# admin gets unlimited read/write access to database
	# everyone else read-only
	access to *
	        by dn="cn=admin,dc=alrac,dc=net" write
	        by * read
	#######################################################################

Then, make sure that the files in /var/lib/ldap are owned by the ldap user:

	# chown -R ldap:ldap /var/lib/ldap

If there is no /var/lib/ldap/DB_CONFIG file, create an empty one:

	# touch /var/lib/ldap/DB_CONFIG

Next, run the slaptest command to check /etc/ldap/slapd.conf:

	# slaptestu
	config file testing succeeded

Now, start it up:

	# /etc/init.d/ldap start
	Checking configuration files for slapd: config file testing succeeded 
	                                                           [ OK ]
	Started slapd:                                             [ OK ]

Finally, run this simple search to make sure the server is running and responding to requests:

	# ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
	[...]
	dn:
	namingContexts: dc=alrac,dc=net
	[...]

Very good! This shows success. Now, you are ready to move on to the next steps.

Discussion

Debian users don't need rootpw or rootdn; these will go away in the next recipe anyway.

loglevel -1 means log everything, and this can add up to megabytes dumped into the syslog in a hurry. See Recipe 12.12 for more information.

See the Discussion in Recipe 12.1 for an explanation of the ldapsearch options.

When you run slaptest, you may see warnings. slapd should run anyway, but you should always fix whatever is causing the warnings .Some common errors on Fedora are caused by:

Following the steps in this recipe should prevent any errors. For example, if the files in /var/lib/ldap are not owned by the ldap user, you'll get "permission denied" errors. If DB_CONFIG is missing, you'll get a warning, but slapd will still run.

DB_CONFIG contains options to tune the Berkeley DB backend. See Recipe 12.11 to learn how to configure it.

This is a bare setup just to test the basics; having a rootpw password in slapd.conf isn't the best thing to do from a security perspective, and we haven't really built a directory yet. But we are getting there.

See Also