Installation Procedure
This document offers a general overview of installing the SASL library.
Quick and Dirty
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 CVS, you'll need to run "sh
./SMakefile" to build the configure script first.
Read
sysadmin.html
the System Administrator's Guide
to
learn how to configure libsasl in depth.  There is also a
upgrading.html
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.
Details
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.
Slower and Cleaner
Before reading this section, please be sure you are comfortable with
the concepts presented in the
components.html
components discussion
and in the
readme.html
Read Me First
document.
You will want to have answered the following questions about your intended
installation:
What mechanisms do you want to support?  Are they plaintext (LOGIN, PLAIN),
shared secret (DIGEST-MD5, CRAM-MD5), or Kerberos (KERBEROS_V4, GSSAPI)?
Perhaps you will use some combination (generally plaintext with one of
the other two types).
Given the answer to the previous question, how will the mechanisms
perform user verification?
The Kerberos mechanisms just need your existing
Kerberos infroastructure.
The shared secret mechanisms will need an auxprop
plugin backend.
The plaintext mechanisms can make do with saslauthd, Courier authdaemond (not included),
*or* by using an auxprop plugin backend.
To use Kerberos and Plaintext, you'll likely want to use saslauthd
with a kerberos module for plaintext authentication.  To use Shared Secret
and plaintext, you'll want to use the auxprop plugin for password verification.
If you are using an auxprop plugin, will you be using SASLdb (and
if so, Berkeley DB [recommended], GDBM, or NDBM?), LDAP or an SQL backend
(Postgres? MySQL?).
If you are using saslauthd, what module will you be using?  LDAP?
Kerberos?  PAM?
Also if you are using saslauthd, what communication (IPC) method do
you want to use?  On most systems, the correct answer is the default
(unix sockets), but on Solaris you can use IPC doors, which have proven
to be more stable than equivilant Solaris systems using unix sockets.
Once you have answered these questions, properly configuring a working
configuration of Cyrus SASL becomes significantly easier.
Requirements
You'll probably need the GNU make program, available as of this
writing
ftp://ftp.gnu.org/pub/gnu/make/
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
ftp://ftp.gnu.org/pub/gnu/gdbm/
here
.
Berkeley DB is available from:
http://www.sleepycat.com/
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
http://postgresql.org
PostgreSQL
v7.2 (or higher) and
http://mysql.org
MySQL
.
If you are using LDAPDB, you'll need SASL enabled OpenLDAP libraries.
http://www.openldap.org
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
http://www.pdc.kth.se/kth-krb/
here
.
For GSSAPI support you will need either
http://web.mit.edu/kerberos/www/
MIT Kerberos 5
, the
http://www.pdc.kth.se/heimdal
Heimdal
or
http://www.cybersafe.com/
CyberSafe
implementation.
Build Configuration
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
options.html
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
.
Building and Installation
After configure runs, you should be able to build SASL just by
running
make
.  If this runs into problems, be sure that you
have disabled everything that your system doesn't need, and that you have
correctly specified paths to any dependencies you may have.
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!
Compilation Hints
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".
Application Configuration
Plesae read about the
options.html
SASL Options
to learn what
needs to be configured so that applications can successfully use the SASL
library.  This is also covered in the
readme.html
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
sysadmin.html
SASL System Administrator's Guide
.
Supported platforms
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
windows.html
Win32
,
macosx.html
MacOS X
, and
os390.html
OS/390
.
Back to the
index.html
index
