3.2 Software Requirements

[ Team LiB ]

3.2 Software Requirements The examples presented in this book for building the client tools and server components are based on the latest OpenLDAP 2.1 release available at the current time (Version 2.1.8). As with any piece of software, version numbers and dependencies change. Make sure to consult the documentation included with future OpenLDAP releases before building your server. Our OpenLDAP server will require several external software packages: Support for POSIX threads, either by the operating system or an external library. SSL/TLS libraries (such as the OpenSSL package, which is available from http://www.openssl.org/). A database manager library that supports DBM type storage facilities. The current library of choice is the Berkeley DB 4.1 package from Sleepycat Software (http://www.sleepycat.com/). Release 2.1 of the SASL libraries from Carnegie Mellon University (http://asg.web.cmu.edu/sasl/sasl-library.html). 3.2.1 Threads If your server's operating system supports threads, OpenLDAP 2 can take advantage of this feature. This support works fine out of the box on most current Linux systems, Solaris, and several other platforms. If you run into problems related to POSIX thread support, your first option is to check the OpenLDAP.org web site for installation notes specific to your platform. You may also wish to visit http://www.gnu.ai.mit.edu/software/pth/related.html for a list of known POSIX thread libraries for Unix systems. It is possible to disable thread support in the OpenLDAP server, slapd, by specifying the �disable-threads option in the OpenLDAP configure script prior to compiling. However, the replication helper daemon, slurpd, which is covered in Chapter 5, requires thread support. 3.2.2 SSL/TLS Libraries RFC 2246 describes TLS 1.0, which resembles SSL 3.0. The StartTLS extended operation defined in RFC 2830 allows LDAP clients and servers to negotiate a TLS session at any point during a conversation (even prior to authenticating the client). To enable support for this extended operation or the LDAPS protocol, you need to obtain and install the latest version of the OpenSSL libraries. These can be downloaded from the OpenSSL Project at http://www.openssl.org/. Building and installing the OpenSSL libraries is straightforward. Just remember that, as of release 0.9.6g, shared libraries are not built by default. To build shared libraries, pass the shared option to the OpenSSL build script. The �openssldir option is used to define the install directory: $ ./config shared --openssldir=/usr/local Then follow with the obligatory: $ make $ /bin/su -c "make install" to install the development libraries and tools in /usr/local/. 3.2.3 Database Backend Modules In order to build a standalone OpenLDAP server, it is necessary to provide libraries for some type of database manager (DBM). OpenLDAP presently supports two categories of local DB storage. The first, referred to as ldbm, can use either the GNU Database Manager from the Free Software Foundation (http://www.fsf.org/) or the BerkeleyDB package from Sleepycat software (http://www.sleepycat.com/). The second database type introduced in OpenLDAP 2.1, called bdb, has been customized to use only the Berkeley DB 4 libraries. The newer bdb backend type is preferred to the ldbm interface for servers that maintain local copies of data, such as those we will build in this book. To obtain and install the Berkeley DB 4.1 libraries, begin by downloading the source code from http://www.sleepycat.com/download/index.shtml. Next, extract the source code to a temporary directory such as /usr/local/src/. This example uses the release 4.1.24: $ cd /usr/local/src/ $ gzip -dc {path-to-download-directory}/db-4.1.24.tar.gz | tar xvf - The instructions for building the software on Unix-like systems are linked from the beginning page of the software's documentation in db-<version>/docs/index.html. For most purposes, this boils down to: $ cd db-version/build_unix $ ../dist/configure --prefix=/usr/local/ $ make $ /bin/su -c "make install" You can choose an installation directory other than /usr/local/ as long as you remember to take any necessary steps to ensure that the libraries and development files can be found by both the Cyrus SASL libraries and OpenLDAP when compiling these packages. Once the process is completed, verify that the file libdb-4.1.so exists in the lib/ directory below the installation root (e.g., /usr/local/lib/). 3.2.4 SASL Libraries Chapter 2 introduced the concept of pluggable authentication mechanisms. While the SASL libraries are not required to build OpenLDAP 2, the resulting LDAP server will not be completely LDAPv3-compliant if SASL is absent. The Computing Services Department at Carnegie-Mellon University has made a set of SASL libraries available for download under a BSD-like license. The latest version can be found at ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/. The cyrus-sasl libraries v2.1 support several SASL mechanisms, including: ANONYMOUS CRAM-MD5 DIGEST-MD5 GSSAPI (MIT Kerberos 5 or Heimdal Kerberos 5) KERBEROS_V4 PLAIN To support the Kerberos plug-ins, you must obtain libraries from either Heimdal Kerberos (http://www.pdc.kth.se/heimdal/) or the MIT Kerberos distribution (http://web.mit.edu/kerberos/www/). Understanding SASL is somewhat of an undertaking. You don't need to install the SASL libraries if you plan to support only simple (clear-text) binds and simple binds over SSL/TLS. The most common reasons for requiring SASL integration with LDAP are Kerberos authentication and integration with other SASL-enabled applications, such as Sendmail or CMU's Cyrus IMAPD server. For the sake of flexibility, we will build the server with SASL support. I recommend reading the SASL System Administrator's HOWTO (sysadmin.html) included as part of the CMU distribution. This document gives some general setup and configuration information. You may also wish to review the "GSSAPI Tutorial" mentioned in the HOWTO and the Programmer's Guide. All of these are included in the Cyrus SASL distribution under the doc/ directory. You may also wish to refer to RFC 2222 for a general overview of SASL. The sample/ subdirectory also includes a program for testing the SASL libraries. Chapter 9 includes examples of using the GSSAPI SASL mechanism when exploring interoperability with Microsoft's Active Directory. Building the SASL distribution requires only a few familar steps. In most environments, the following commands will install the libraries and development files in /usr/local/: $ gzip -dc cyrus-sasl-2.1.9.tar.gz | tar xf - $ cd cyrus-sasl-2.1.9 $ ./configure $ make $ /bin/su -c "make install && \ ln -s /usr/local/lib/sasl2 /usr/lib/sasl2" The symbolic link is needed because the SASL library will look for installed mechanisms in /usr/lib/sasl2/ (as described in the cyrus-sasl documentation).

[ Team LiB ]