cd (directory it was untarred into) ./configure make make install ln -s /usr/local/lib/sasl2 /usr/lib/sasl2
If you're checking this directly out of GIT, you'll need to run "sh ./autogen.sh" to build the configure script first.
Read the System Administrator's Guide to learn how to configure libsasl in depth. There is also a document that covers migrating from libsasl v1 to libsasl v2 applications.
You may also be interested in the contents of configure --help which can reveal the many possible configure options that can be used to build Cyrus SASL.
Note that the library looks for plugins in /usr/lib/sasl2, but installs them into ${prefix}/lib/sasl2, where ${prefix} is usually something like /usr/local. This is intentional - we want the plugins installed with the rest of the package (wherever things get installed at your site), but we want the library to always be able to find its plugins under /usr/lib/sasl2, no matter where you install things, so that the SASL plugin ABI on all platforms is roughly the same.
If you don't want to do this for some reason, you can set the location where the library will look for plugins by setting the environment variable SASL_PATH to the path the library should use.
You will want to have answered the following questions about your intended installation:
You'll probably need the GNU make program, available as of this writing here.
If you are using SASLdb, you will need to pick your backend. libsasl2 can use gdbm, Berkeley db, or ndbm to implement its user/password lookup. Most systems come with ndbm these days; as of this writing, gdbm is available here. Berkeley DB is available from: Sleepycat
If you are using SQL, you'll need to properly configure your server/tables, and build the necessary client libraries on the system where you will be building and using SASL. Currently we support PostgreSQL v7.2 (or higher) and MySQL.
If you are using LDAPDB, you'll need SASL enabled OpenLDAP libraries. OpenLDAP 2.1.27 (or higher) or 2.2.6 (or higher) is support.
For Kerberos support, you'll need the kerberos libraries. At CMU, the version we use comes from here.
For GSSAPI support you will need either MIT Kerberos 5 , the Heimdal or CyberSafe implementation.
Once you have ansered all the necessary questions and installed (and tested!) any required packages for your configuration, you are ready to build SASL. Building SASL is done with the aid of an autoconf configure script, which has a lot of options. Be sure to read the outpit of configure --help to be sure you aren't missing any (they are all documented). Note that often times a --enable-foo option has a counterpart like --disable-foo to not enable that feature.
Some of the most important configuration options are those which allow you to turn off the comiplation of modules you do not need. This is often the easiest way to solve compilation problems with Cyrus SASL. If you're not going to need a particular mechanism, don't build it! Not building them can also add performance improvements as it does take system resources to load a given plugin, even if that plugin is otherwise unused (even when it is disabled via the mech_list option).
As of this writing, modules that are enabled by default but may not be applicable to all systems include CRAM-MD5, DIGEST-MD5, OTP, KERBEROS_V4, GSSAPI, PLAIN, and ANONYMOUS. These can be disabled with --disable-cram, --disable-digest, --disable-otp, --disable-krb4, --disable-gssapi, --disable-plain, and --disable-anon respecively.
If you are using an SQL auxprop plugin, you may want to specify one or more of --enable-sql, --with-mysql=PATH, and --with-pgsql=PATH, note that PATH in the later two should be replaced with the path where you installed the necessary client libraries.
If you are using LDAPDB auxprop plugin, you will need to specify --enable-ldapdb and --with-ldap=PATH. Warning: LDAPDB auxprop plugin (and LDAP enabled saslauthd) introduces a circular dependency between OpenLDAP and SASL. I.e., you must have OpenLDAP already built when building LDAPDB in SASL. In order for LDAPDB to work at runtime, you must have OpenLDAP already built with SASL support. One way to solve this issue is to build Cyrus SASL first without ldap support, then build OpenLDAP, and then come back to SASL and build LDAPDB.
Given the myriad of ways that Berkeley DB can be installed on a system, people useing it may want to look at the --with-bdb-libdir and --with-bdb-incdir as alternatives to --with-dbbase for specifying the paths to the Berkeley DB Library and Include directories.
In fact, if you're not planning on using SASLdb at all, it may be worth your time to disable its use entirely with the --with-dblib=none option.
If you are planning on using LDAP with saslauthd, be sure to specify the --with-ldap=PATH option to configure.
To install the library, run make install as root followed by ln -s /usr/local/lib/sasl2 /usr/lib/sasl2 (modified for your installation path as appropriate). Be sure to do this last step or SASL will not be able to locate your plugins!
You may need to play with your CPPFLAGS and LDFLAGS a little if you're using vendor compilers. We use gcc extensively, but you'll probably have more luck if you use the same compiler for the library as you do for your applications. You can see what compilers we use on our platforms by looking at the "SMakefile".
Plesae read about the SASL Options to learn what needs to be configured so that applications can successfully use the SASL library. This is also covered in the Read Me First document.
You will want to ensure that the settings of pwcheck_method and auxprop_plugin match the decisions you made about your authentication infrastructure. (For example, if you are using saslauthd as a password verifier, you'll want to be sure to set pwcheck_method: saslauthd).
If you are using saslauthd, you will want to arrange for saslauthd -a pam (or ldap, or kerberos4, etc) to be run at boot. If you are not going to be using saslauthd, then this is not necessary.
Many of these pieces are covered in more detail in the SASL System Administrator's Guide.
This has been tested under Linux 2.2, Linux 2.4, Solaris 2.7 and Solaris 2.8. It should work under any platform where dynamic objects can be linked against other dynamic objects, and where the dynamic library file extension is ".so", or where libtool creates the .la files correctly. There is also documentation for Win32, MacOS X, and OS/390.