Web Developer's Virtual Library: Encyclopedia of Web Design Tutorials, Articles and Discussions


WDVL Newsletter

Active Server Pages
JSP/Java Servlets
Microsoft SQL Server
Daily Backup
Dedicated Servers
Streaming Audio/Video
24-hour Support    

jobs.webdeveloper.com

Hiermenus


e-commerce
Partner With Us















Developer Channel
FlashKit.com
JavaScript.com
JavaScriptSource
Developer Jobs
ScriptSearch
StreamingMediaWorld
Web Developer's Journal
Web Developer's Virtual Library
WebDeveloper.com
Webreference
Web Hosts
XMLfiles.com

internet.com
IT
Developer
Internet News
Small Business
Personal Technology

Search internet.com
Advertise
Corporate Info
Newsletters
Tech Jobs
E-mail Offers


Installing and Configuring an LDAP Server - Page 8

February 15, 2002

Installing OpenLDAP in a *nix environment is a straightforward task. The software is available for download from http://www.openldap.org/. Here our server of choice is OpenLDAP due to the fact that this is an open source solution and is easily available with no licensing issues when used for non-commercial purposes.

To uncompress and unarchive the distribution:

tar xzvf openldap-stable- xyz.tgz

Change to the LDAP directory:

cd openldap-stable-xyz

To generate configuration information:

./configure --enable-ldbm --with-ldbm- api=gdbm

The --enable-ldbm flag tells that a back-end database has to be used and the --with-ldbm-api=gdbm flag says that this should be GDBM.

If you do not have GDBM, you can get it from a GNU- mirror site: http://www.gnu.org/. Else, you can use the Berkley database or UNIX shell and specify the back-end datastore by the -with-ldbm-api directive while running the configure script.

To cause the source file to compile and generate the executable binaries:

make depend && make

To test that the distribution has been properly compiled:

cd tests; make

To plant the executable in the appropriate locations (make sure to be the root user when you do this):

cd ..
make install

The OpenLDAP Config File

The OpenLDAP server has a configuration file that can be used to set several properties for the server and the directory that it will serve. This file is /usr/local/etc/openldap/slapd.conf by default.

Let's take a look at a sample configuration file that has been tailored to suit our purposes of experimentation. An exhaustive list of configurable parameters is available with the manual that comes along with the OpenLDAP distribution:

include         /usr/local/etc/openldap/slapd.at.conf
include         /usr/local/etc/openldap/slapd.oc.conf

schemacheck off
referral   ldap://ldap.itd.umich.edu

pidfile        /usr/local/var/slapd.pid
argsfile       /usr/local/var/slapd.args

access to * by * write

#########################################################
# ldbm database definitions
#########################################################

database       ldbm
suffix         "o=myorg, c=US"
directory      /home/myhome/test-addr
rootdn         "cn=root,o=myorg, c=US"
rootpw         opensesame

The comments within the file start with a # character and go on to the end of the line.

The include directive causes another file to be included into this file, that is, the files slapd.at.conf and slapd.oc.conf are read and interpreted first before proceeding with the rest of the directives in the slapd.conf file. Incidentally the slapd.oc.conf file contains the object definitions for several generic objects (for example, the inetOrgPerson object that we saw earlier). The file slapd.at.conf contains definitions for generic object classes with pre-defined minimum attributes.

The schemacheck directive takes a value of either on or off and determines whether the objects present in the directory will be checked for conformance with the schema of the directory. While experimenting, we could set this to off.

The referral directive causes the LDAP server to advise the client to redirect the LDAP message to another LDAP server (specified as an ldap:// URL argument) if the server realizes that the client asked for something that it couldn't provide.

The pidsfile and argsfile directives are for the server to maintain certain information about the instances of it that have been started. This is not much of a concern for us, and not adding these directives usually makes little difference as the server defaults to a setting that is acceptable.

The access directive implements the access-control features of the LDAP server by determining who has access to what in the directory. We shall set this to access to * by * write, meaning that everybody should have write access to all entries in the directory (which is probably not a good idea in a production environment).

The database directive tells the server to use a database as the back-end and the directory directive tells the server where the actual database and indexing files can be found.

The argument of the suffix directive is passed on as a suffix to queries made on the directory. This means that the queries need not specify the complete DN for each operation.

The rootdn directive tells the server about the root of the directory. An administrator binds to the directory using this DN to perform various administrative tasks. The rootpw directive sets the password for the administrator.

Advanced Features of LDAP - Page 7
Professional PHP4 Programming
Running the slapd Server - Page 9


Up to => Home / Authoring / Languages / PHP / Pro




Jupiter Online Media: internet.comearthweb.comDevx.commediabistro.comGraphics.com

Search:

Jupitermedia Corporation has two divisions: Jupiterimages and Jupiter Online Media

Jupitermedia Corporate Info


Legal Notices, Licensing, & Permissions, Privacy Policy.

Web Hosting | Newsletters | Tech Jobs | Shopping | E-mail Offers