DACS.INSTALL(7) DACS Miscellaneous Information DACS.INSTALL(7)
NAME
dacs.install - DACS installation guide
DESCRIPTION
This document describes how to configure and install this release of DACS. Please read it carefully.
Important
o Installation requires the GNU make command (gmake[1]) and GCC[2].
o The examples here and in other DACS documentation assume that DACS is installed in its default location, /usr/local/dacs. If you
specify a different location at build time, please keep this in mind as you read the documentation. This also applies to
third-party packages, which you may install where convenient, provided you are careful not to mix different versions of the same
package; in this document's examples we install them under /usr/local and unpack their source code under /local/src.
o In some command line examples, long lines have been split to improve readability.
o Whenever you upgrade to a more recent version of DACS, please do not forget to install the mod_auth_dacs module that comes with
your new version of DACS.
o Please pay careful attention to the descriptions of the third-party packages below. Our philosophy is that DACS should be used with
the most recent versions of third-party packages available at the time DACS is released. This helps to ensure that a DACS
deployment has the latest security features and bug fixes.
You should build third-party packages in the order in which they are discussed below because packages that are discussed earlier
may require some that appear later.
For a few third-party packages, it is important that you use the exact version that is mentioned. Do not use anything newer or
older.
For some third-party packages, a particular release is recommended. It is less critical that you use the recommended release, but
older releases may have important bugs, including security problems. A release newer than the one(s) specified will not have been
tested with DACS - and a release older than the one(s) specified may not have been tested with DACS - so if you choose to use such
a release you are on your own.
You may save yourself time and headaches if you just use the recommended releases.
Sometimes the recommended version of a third-party package will be fine on some platforms but will not build or is buggy on another
platform. Whenever possible, the DACS installation instructions suggest an alternative version, and you may proceed with that
version, or a recent version of your choice - but keep the preceding comments regarding older releases in mind and ensure that a
"gmake test" of DACS completes successfully.
o On some systems it will be necessary to use ldconfig(8)[3] (or equivalent) so that your system finds the correct shared libraries
for programs that are executed by the web server, including the DACS web services.
Trying DACS
If at this time you only want to try DACS rather than doing a full install, review the information below regarding third-party packages and
then proceed to follow the instructions you will find in dacs.quick(7)[4], which is a step-by-step tutorial for installing and configuring
DACS.
Upgrading DACS
If DACS 1.4 is already installed on your system and you are not changing any third-party packages or installation options, for a "quick and
dirty" upgrade you can often install a new release on top of a previous release. While this will leave your existing DACS configuration
files alone, it will also leave files that are no longer needed by the new DACS. Be sure to check the new distribution's release notes and
the rest of this manual page for any notable differences and incompatibilities - you may need to make some adjustments to your pre-existing
installation.
It is possible for minor, incompatible changes introduced by a new release to cause temporary, user-visible problems. For example, changes
to the format of credentials might invalidate sessions (i.e., DACS HTTP cookies) issued by the earlier release, requiring users to
reauthenticate.
1. Make a backup copy of the previous install, just in case. It is especially important to make copies of all data files (such as DACS
password files, other kinds of account files, encryption keys) and any custom configuration (such as access control rules).
2. Obtain and unpack the new distribution and chdir to it;
3. Review dacs.readme(7)[5] and the instructions in this document;
4. Copy src/config.nice from your installed version to the new src directory, make any updates and corrections that are necessary, and
configure DACS:
% cd src; sh ./config.nice
5. Build DACS:
% gmake
6. We recommend that you remove some of the files from the previous release in case they are no longer required or have been renamed.
Unless you have put non-standard files in them or made non-standard customizations, it is safe to simply delete these directories and
their contents:
% rm -f -r /usr/local/dacs/{acls,bin,include,lib,man,www}
7. Stop httpd:
% apachectl stop
8. Install DACS:
% gmake install
9. Make and install the latest mod_auth_dacs module:
% cd ../apache; gmake tag install
10. Restart httpd:
% apachectl start
or
% apachectl startssl
11. Check that DACS appears to be working correctly. You may find it handy to construct a set of links or bookmarks that you can use after
installing or configuring DACS to invoke various DACS web services with appropriate arguments; for instance, try
dacs_authenticate(8)[6] dacs_current_credentials(8)[7], dacs_prenv(8)[8], dacs_list_jurisdictions(8)[9], dacs_conf(8)[10],
dacs_signout(8)[11], and dacs_version(8)[12]. Review the DACS log file for any error messages or warnings.
DACS on Windows
DACS is not currently supported on Microsoft Windows platforms. Cygwin[13], which provides a GNU/Linux-like environment for Windows, is
not an officially-supported platform, but DACS releases usually build on it.
To run DACS utilities and commands on Windows (such as dacscheck), it appears to be sufficient to install the binaries along with the
Cygwin run-time libraries that they require, such as /bin/cygwin1.dll and /bin/cygcrypt-0.dll.
Installing DACS
The following describes how to install DACS.
Important
o If another release of DACS is present, rename your previous release, install the new release, and then copy any site-specific
configuration files from the previous release to the new release.
o Be careful not to mix DACS binaries and support files from different releases; this can lead to strange behaviour that is often
hard to resolve.
o If you are installing or upgrading a third-party package, make sure that you are building against the include files and libraries
from the correct version (i.e., that the DACS build is not finding an old version, or using include files from one version and
library files from a different version). This can also cause strange problems.
1. Unpack the DACS distribution and move to its root directory.
2. Familiarize yourself with the system by:
o reading this document;
o running:
% src/configure --help
o browsing through the documentation (easily done by loading man/index.html[14] into your browser);
o deciding where you want the various components to be installed; and
o considering which optional features you may want (you can easily make changes at any time, so do not be too concerned about this).
3. A few third-party packages are required by DACS and must be built before DACS can be configured and built. Please note carefully if any
special exceptions apply to your particular platform and third-party package needs. Although you may have better luck, sometimes we
experienced problems building the recommended packages (or combinations of packages) on certain platforms; whenever possible, we try to
provide a workable alternative. Late-breaking updates are sometimes available in the release's Post-Release Notes[15].
Important
It is not necessary to actually install these packages, you only have to build them so that the DACS build can use their libraries,
include files, and so on, directly from where you build the packages. You may chose to do this if you do not want to upgrade an
existing version of the package, or if you are unable to do so.
Build these packages in the order in which they are listed below. If you install a package, you may need to be root or use
sudo(8)[16].
These packages are not distributed with DACS and have licensing terms completely separate from those of DACS that are your
responsibility.
1. Install the Expat XML parser
This release of DACS has been tested with Expat[17] 2.0.1 and we recommend that you use that release.
For use with DACS, Expat can either be built with -prefix=/usr/local or something like -prefix=/usr/local/expat-2.0.1, whichever
you prefer. In the former case, you can omit the --with-expat when configuring DACS or use --with-expat=/usr/local, and in the
latter case you must use --with-expat=/usr/local/expat-2.0.1. For the record, here is an example of how we build Expat after
unpacking it:
% cd expat-2.0.1
% ./configure --prefix=/usr/local/expat-2.0.1
% make
(All should go well.)
% make install
(All should go well here, too.)
Note
On Win2K/Cygwin, only a static library is needed. From the root of the expat distribution directory:
% cd lib; ar rv libexpat.a *.o; ranlib libexpat.a
If the build fails, reconfigure using --enable-shared=no and --enable-static=yes and try to build it again.
2. Install OpenSSL
DACS uses cryptographic functionality provided by OpenSSL[18]. This release of DACS has been tested with openssl-1.0.0h and we
recommend that you use that release with DACS. Apache should be built using the version of OpenSSL recommended by the particular
Apache release - using a more recent version of OpenSSL may introduce build problems or run-time bugs in Apache. It is not
necessary for Apache and DACS to use the same release of OpenSSL.
Notes
o Releases of Apache prior to 2.0.55 do not work (as shipped) with OpenSSL 0.9.8 or newer.
o DACS will work with openssl-1.0.0 but not with openssl-0.9.8[mno] ("gmake test" fails); openssl-0.9.8l is the last of the
pre-openssl-1.0.0 releases known to work correctly with DACS.
o If you need InfoCard support and you have upgraded to openssl-1.0.0 or newer, it may be necessary to rebuild xmlsec1[19]
against the new library (if you need to rebuild, "gmake test" will fail).
o When building openssl-0.9.8j on FreeBSD 7.0, problems were encountered that caused "make install" to fail; corrections to
Makefiles under the fips subdirectory solved the problem.
o On OpenSolaris, more serious problems building openssl-0.9.8j and openssl-0.9.8k were found and neither could be
successfully completed; with the same options and environment, openssl-0.9.8i and openssl-0.9.8l built without incident,
however, and the latter was used for testing on that platform. There were also problems forcing the runtime linker to use
OpenSSL libraries other than the default system versions, despite the guidance of the relevant manual pages; it was
necessary to set LD_LIBRARY_PATH appropriately (use dacsversion -v to verify that the expected libraries are being used at
runtime).
o If you are enabling DACS support for Java, add the -fPIC flag to config when you are building OpenSSL.
o In some configurations you may want or require shared OpenSSL libraries; if so, add the shared command line flag to config
when building OpenSSL.
o Solaris 8 (and perhaps other platforms) may require a patch[20] before OpenSSL will work properly. Please consult the
latest OpenSSL documentation.
o For Solaris 10 x86, review OpenSSL's PROBLEMS file to see if you must apply a patch before OpenSSL will compile correctly
with GCC.
o For the record, here is an example of how we build OpenSSL:
% ./config --prefix=/usr/local/openssl-1.0.0h --openssldir=/usr/local/openssl-1.0.0h -fPIC shared
o On Mac OS X, however, it was necessary to explicitly request a 64-bit build of OpenSSL:
% ./Configure darwin64-x86_64-cc --prefix=/usr/local/openssl-1.0.0h --openssldir=/usr/local/openssl-1.0.0h -fPIC shared
3. Install Apache 2.2.22 or 2.0.64
You will need an SSL-capable Apache[21] server (build Apache with --enable-ssl) that uses a recent version of OpenSSL (build Apache
using --with-ssl=path, see above[22]).
Tip
You can install a subset of DACS that does not require Apache and does not require any DACS configuration. These stand-alone,
general-purpose utility commands, such as http and sslclient, might be of interest to you even if you are not interested in any
other parts of DACS. Look for BASIC_PROGS in Makefile.in to see which commands will be installed.
To build this subset, use --with-apache=omit when running configure. Please continue to review the information about
third-party packages in this document, but you can ignore anything that follows that is related to Apache and mod_auth_dacs.
If you want to use mod_auth_dacs as a dynamic module, which is the recommended configuration, make sure that mod_so is built-in to
your httpd ("httpd -l" displays a list).
Important
o This release of DACS has been tested with both Apache 2.0.64 and Apache 2.2.22. We strongly recommend that you use either
of those versions. If necessary, DACS will probably also work with 2.0.51 and newer, or 2.2.2 and newer, but not with
releases older than that.
o When building Apache 2.2, we first build and install APR (srclib/apr) and APR-UTIL (srclib/apr-util), and then build httpd
using the --with-apr and --with-apr-util flags. This may be helpful to know if you run into problems. Also, if you
encounter problems building dacsversion, it may be necessary for you to go back and build APR with the --disable-lfs flag
to disable large file support on your platform. When you build DACS in an upcoming step, you will probably need to use the
--with-apache and --with-apache-apr flags (see Third-party support options[23]). If you are going to use the
--with-berkeley-db flag when building APR-UTIL, you may want to temporarily skip ahead to build Berkeley DB[24] before
returning here to continue your Apache build.
o For the record, here is an example of how we built Apache 2.2 after unpacking it:
% cd httpd-2.2.22
% cd srclib/apr
% ./configure --prefix=/usr/local/apache2-2.2.22/apr-httpd --disable-lfs CFLAGS=-fPIC
% make install
% cd ../apr-util
# See notes below for adding LDFLAGS
% ./configure --prefix=/usr/local/apache2-2.2.22/apr-util-httpd
--with-apr=/usr/local/apache2-2.2.22/apr-httpd
--with-expat=/usr/local/expat-2.0.1
--with-berkeley-db=/usr/local/BerkeleyDB.5.3
--with-dbm=db50
% make install
% cd ../..
# See notes below for adding LDFLAGS
% ./configure --prefix=/usr/local/apache2-2.2.22 --enable-ssl
--with-ssl=/usr/local/openssl-1.0.0h
--with-apr=/usr/local/apache2-2.2.22/apr-httpd
--with-apr-util=/usr/local/apache2-2.2.22/apr-util-httpd
LDFLAGS="-rpath /usr/local/BerkeleyDB.5.3/lib -rpath /usr/local/openssl-1.0.0h/lib"
% make install
This builds a very basic server; you can enable other options if you want.
Because we deal with multiple versions of third-party packages, each release is installed separately, hence the version
numbers in the pathnames.
Your mileage may vary, but when doing the top level Apache configuration above on FreeBSD it was necessary to add "-rpath
/usr/local/BerkeleyDB.5.3/lib -rpath /usr/local/openssl-1.0.0h/lib" to LDFLAGS so that Apache commands could find the
shared library at run time. On Linux, it was necessary to add "-Wl,-rpath /usr/local/BerkeleyDB.5.3/lib -Wl,-rpath
/usr/local/openssl-1.0.0h/lib" to LDFLAGS when building apr-util and at the top level. Alternatively, on either platform
the ldconfig command or LD_LIBRARY_PATH might be used. It does not appear necessary to specify additional linker flags on
Mac OS X.
o One difference between the Apache 2.0 and 2.2 releases to be aware of is that the default Apache configuration with 2.2 may
deny all access by default; some DACS files should be publicly accessible, however, so you may need to explicitly allow
this. For example, in httpd.conf:
<Directory /usr/local/dacs/www>
Satisfy Any
Allow from all
Options Indexes FollowSymLinks
</Directory>
o Apache 1.3 is not supported; please consult the FAQ[25]. DACS has not been tested with Apache 2.3 or 2.4.
o We do not support using mod_auth_dacs with a non-source install of Apache; we have received feedback that it can be done
manually without much effort, however. In this case, we believe that the install may go more smoothly if you use the
configure flag --disable-shared.
Tip
Check that Apache is working properly and that it is actually using the version of OpenSSL that you are expecting. It is
important to confirm that your server is working correctly with your web resources before DACS gets involved - doing so can
save you time and frustration.
You can see your httpd's Server response-header by connecting to your server (e.g., using telnet) and engaging in an
interaction with it similar to the following (note the last line of output):
% telnet localhost 80
Trying 127.0.0.1...
Connected to localhost
Escape character is '^]'.
GET / HTTP/1.0
HTTP/1.1 200 OK
Date: Tue, 30 Aug 2011 21:27:17 GMT
Server: Apache/2.2.22 (Unix) mod_auth_dacs/1.4.27(Release date w16-Feb-2012 00:00:01) mod_ssl/2.2.22 OpenSSL/1.0.0g
4. A few third-party packages are optional and whether you need them depends on which optional features of DACS you require. These
packages must be built before DACS can be configured and built. If you decide you want to add or remove optional capabilities after
building DACS, it is easy to do so later.
Tip
If you are new to DACS, it may be a good idea to first build it without any optional packages. After you have gotten the basic
system working to your satisfaction, rebuild DACS with the optional components you need. Or, if you are not sure at this time which
optional packages you need, return to this step later.
1. Berkeley DB, gdbm, ndbm DB (dbm-type databases)
If you want to be able to store DACS configuration information in a database or need to access files managed by Apache's
mod_auth_dbm, you may use Berkeley DB[26] from Oracle Corporation[27] (Sleepy Cat Software was acquired by Oracle in February,
2006). A suitable version may already be installed on your system. Version db-5.3.15 is being used for testing, but somewhat older
or newer versions should be fine. See the DACS configure arguments: --enable-bdb[28], --disable-bdb[29], and --with-bdb[30].
The default is to use Berkeley DB if it is available, but if you do not want to use Berkeley DB you can disable it
(--disable-bdb[29]) and get similar functionality from the NDBM library, or from GNU GDBM (version 1.8.3 or 1.9.1) in its NDBM
compatibility mode. These libraries may already be installed on your system. Get GDBM from ftp://ftp.gnu.org/gnu/gdbm[31]. See the
--enable-ndbm[32] and --enable-gdbm[33] configure flags.
Notes
o It may be necessary to create (or update) links to the Berkeley DB installation directory to avoid problems when building
other packages. For example, if you install it in /usr/local/bdb-5.3.15:
% ln -s /usr/local/bdb-5.3.15 /usr/local/BerkeleyDB.5.3
% ln -s /usr/local/bdb-5.3.15 /usr/local/db53
o For the record, here is an example of how we build Berkeley DB after unpacking it:
% cd build_unix
% ../dist/configure --prefix=/usr/local/bdb-5.3.15
% make
(All should go well.)
% make install
(All should go well here, too.)
o You cannot use both --enable-ndbm and --enable-gdbm, but you can use either one along with --enable-bdb.
o GNU GDBM 1.9.1 may not interoperate correctly with databases created by earlier versions of GNU GDBM; consult its source
code and documentation for details.
o A deficiency in configuration processing is that the locations of the GNU GDBM and NDBM libraries cannot be specified; the
standard configuration search path is used. A future version should provide --with-gdbm and --with-ndbm flags.
o The NDBM-workalike, sdbm[34], is not currently supported. It may be added to a future release, however, particularly if it
is requested.
2. SQLite
The SQLite[35] database, which can be used together with the dbm-type databases[24], is another option for storing DACS
configuration information. Version 3.7.10 is being used for testing (we use the "autoconf" tarball). See the DACS configure
arguments: --enable-sqlite[36], --disable-sqlite[37], and --with-sqlite[38].
3. Microsoft NTLM
If you want to be able to authenticate against NTLM (see local_ntlm_authenticate[39]), you must obtain Samba[40]. This release of
DACS has been tested with samba-3.6.3, and we strongly recommend that you use that version. It is not known whether this release of
DACS will work with any other version of Samba - we do not officially support them.
DACS NTLM authentication has been tested against Windows 2000 Server SP4.
Note
DACS requires the Samba source distribution to be built but it does not matter if Samba is installed. The DACS build procedure
looks for include files and libraries relative to the Samba distribution's root directory.
To build Samba for DACS, from your Samba distribution's ./source3 directory do:
% ./configure --enable-static=yes --with-ads=no --with-ldap=no --disable-swat --disable-cups --disable-pie
--enable-external-libtalloc=no --enable-external-libtdb=no
% make
Then, when configuring DACS, specify the directory where Samba was unpacked, for example:
--with-samba=/local/src/samba-3.6.3
See the DACS configure arguments: --enable-ntlm-auth[41] and --with-samba[42].
4. libxml2 and xmlsec1
If you need InfoCard support (see local_infocard_authenticate[43]), libxml2[44] and xmlsec1[19] are required. Build libxml2 and
OpenSSL first, because xmlsec1[19] depends on both of them. This release of DACS has been tested with libxml2-2.7.8 and
xmlsec1-1.2.18, and we strongly recommend that you use those versions. It is not known whether this release of DACS will work with
any other versions - we do not officially support them.
Notes
o For the record, here is an example of how we build xmlsec1:
% ./configure --prefix=/usr/local/xmlsec1-1.2.18
--with-libxml=/usr/local/libxml2-2.7.8
--with-openssl=/usr/local/openssl-1.0.0h --with-gnu-ld
--enable-static-linking --disable-crypto-dl --disable-apps-crypto-dl
Except on Mac OS X:
% ./configure --prefix=/usr/local/xmlsec1-1.2.18
--with-libxml=/usr/local/libxml2-2.7.8 --with-gnu-ld --enable-static=yes
--enable-shared=yes --with-nss=/Applications/Firefox.app/Contents/MacOS
--with-nspr=/Applications/Firefox.app/Contents/MacOS
--with-openssl=/usr/local/openssl-1.0.0h
o Due to an apparent error in its build procedure, we sometimes encountered the following error message:
*** Warning: Linking the shared library libxmlsec1-openssl.la against the
*** static library /local/openssl-1.0.0h/lib/libcrypto.a is not portable!
After ensuring that libcrypto.so (or libcrypto.dylib) had been installed when building OpenSSL, to correct the xmlsec1
build problem we did "make clean", re-ran configure as above, and edited src/openssl/Makefile under the root of the xmlsec1
distribution directory to change all occurrences of "libcrypto.a" to "libcrypto.so". It was sometimes also necessary to
delete the -ldl flag on those same lines, and in other Makefile files in the distribution (and making sure the flag was not
specified by xmlsec1-config). After those changes, we ran make again. Additionally, it was sometimes necessary to specify
CFLAGS="-I/usr/local/include -L/usr/local/lib".
o Another problem related to this library on a CentOS platform resulted in an error message similar to this:
Cannot restore segment prot after reloc: Permission denied
The solution was to issue the command (adjust the path as necessary):
% chcon -t texrel_shlib_t /usr/local/xmlsec1-1.2.18/lib/libxmlsec1-openssl.so
o When including InfoCard support on Mac OS X, it was necessary to tell the dynamic linker where to find the xmlsec1 library
(despite using the -rpath flag during the build). To work around this, do something like the following (or equivalent):
% setenv DYLD_LIBRARY_PATH /usr/local/xmlsec1-1.2.18/lib
Ensure that "gmake test" does not fail.
o Due to an apparent bug in configure.in, on FreeBSD configure may incorrectly use the -ldl flag in generated Makefiles.
Either edit all Makefiles to remove all occurrences of the -ldl flag, or edit configure.in, add a "*-*-freebsd*" case like
the others in the "OpenSSL" section, run autoconf to regenerate configure, and then "make clean" and re-run configure.
o Your experience may differ, but we found xmlsec1 to not cooperate when we wanted to work with multiple installations of
libxml2 - apparently if a libxml2 directory or link has been installed, its build procedure seems to use that version,
regardless of what is specified on the command line, requiring manual editing of its Makefiles. Check that the correct
instance of xml2-config is being used.
The DACS build procedure uses xmlsec1-config, a program that comes with xmlsec1. If InfoCard support is enabled, the build
procedure will look in some standard places for this command. You can specify its location with the --with-xmlsec1-config[45] flag.
See the DACS configure arguments: --enable-infocard-auth[46] and --with-xmlsec1-config[45]
5. LDAP or Microsoft Active Directory
Authentication through LDAP (see local_ldap_authenticate[47]) is implemented using OpenLDAP[48]. This release of DACS has been
tested only with openldap-2.4.29 and we strongly recommend that you use that version.
It is not known whether this release of DACS will work with any other version of OpenLDAP - we do not support them. DACS may work
properly with OpenLDAP versions at least as old as 2.2.24, if you really must use one of them.
DACS has been tested against Windows 2000 Server SP4.
If the --with-ldap flag is not given (in which case LDAP authentication must be enabled; e.g., via --enable-ldap-auth), configure
will search for OpenLDAP headers and libraries; if found, it will assume they are a suitable version and use them.
If --with-ldap is given (either because OpenLDAP is not installed or an unsuitable version is installed), headers and libraries
relative to the root of the specified directory will be used rather than any installed OpenLDAP files; it is not necessary to
install OpenLDAP, you only need to build it - so you do not need to be concerned about hassles associated with upgrading or any
other versions that might already be installed on your system.
To build OpenLDAP for DACS, from the root of your OpenLDAP distribution do:
% ./configure --disable-slapd --enable-static
% make
If so instructed, do a "make depend" before the make.
See the DACS configure arguments: --enable-ldap-auth[49] and --with-ldap[50]
6. Readline
The history and editing functionality provided by the GNU Readline Library[51] can be nice to have when using dacsexpr(1)[52]
interactively. This release of DACS has been tested with version 6.2, although we have used readline-6.0 and readline-6.1 with
recent releases of DACS. Note that you may need to compile Readline with the -fPIC flag ("make CFLAGS=-fPIC").
It is not necessary for you to install readline, you only need to build it - so you do not need to be concerned about hassles
associated with upgrading or any other versions that might already be installed on your system.
Notes
o When building on Mac OS X, it was necessary to fix a bug by editing shlib/Makefile and making this change:
#SHOBJ_LDFLAGS = -dynamic
SHOBJ_LDFLAGS = -dynamiclib
See the DACS configure arguments: --with-readline[53]
5. Configure and build DACS libraries, services, commands, and utilities
See Build Options[54] for build alternatives and options to configure.
% cd src
% ./configure
% gmake
To confirm that DACS has been built with the third-party packages that you intended, from the run:
% ./version -v
You should ensure that the sslclient utility is working correctly. From the src directory, you can test it using the following command:
% perl -e 'printf "GET / HTTP/1.0
";' | ./sslclient dacs.dss.ca:443
which should print the contents of https://dacs.dss.ca to the standard output. You should repeat this test substituting the name of
your server and port.
Tip
After building DACS, it is strongly recommended that you run the self-tests (expression evaluation, crypto code, string handling,
and so on) from the src directory:
% gmake test
If any error occurs during testing, testing will stop immediately and a message will be displayed. In this event, first check that
you are using the recommended software packages and that your build flags are correct. Most often, problems are the result of
mixing header files or library files from different versions of a third-party package (e.g., OpenSSL) or incorrect file
permissions. If you cannot find anything wrong with your configuration, please submit a bug report that includes the self test
output and describes your platform (you can include the output of "./version -v").
6. If all looks good, install DACS
% gmake install
Notes
o If gmake complains about not being able to find xsltproc, docbook.xsl, or something that might be related to installing the
documentation, try:
% (cd ../man; gmake touch)
% gmake install
o This will install the rules for the standard DACS web services and run dacsacl(1)[55] to create and install an index for them.
o You can specify DESTDIR[56] to gmake when installing or uninstalling:
% gmake DESTDIR=/tmp/mydacs install
The installation process may prompt you for the owner name and group name to use for files and directories; it will guess at reasonable
defaults for your platform. The appropriate responses will depend on local conventions, but to start with you might set the owner to
your login name or root, and the group name to the same name that is used by Apache (specified by the Group[57] directive in
httpd.conf).
Tip
While running "gmake install", important instructions regarding manual installation steps may be displayed. A copy is written to
.build_notes, truncating any previous contents.
7. As part of the installation procedure, the DACS manual pages are copied into the DACS man directory (default: /usr/local/dacs/man). If
you adjust your MANPATH environment variable to include that directory, try:
% man dacs
While it is occasionally handy to view the manual pages using the man command, the HTML documentation is far superior.
8. Build a DACS-enabled httpd
Please consult apache/README in the DACS distribution for details and, from the apache directory, do:
% gmake help
Security
You can build the module with a full version tag ("gmake tag"), with a simple tag ("gmake smalltag"), or without a tag ("gmake
notag" or "gmake module"). We recommend that you compile mod_auth_dacs with a tag so that Apache's SERVER_SIGNATURE includes a DACS
version identifier stamp; this makes it easy to tell which version of DACS the server is running and helps to detect mismatches.
For servers that are subject to attack, however, identifying exactly which modules are in your Apache server is considered a
security weakness - you may reasonably choose not to include the stamp.
If you want mod_auth_dacs to be a dynamic module, which is recommended, do:
% cd apache
% gmake tag
% gmake install
Check that your httpd.conf has the appropriate LoadModule directive.
If you want mod_auth_dacs to be a static module:
1. Copy apache/mod_auth_dacs.c to Apache's modules/aaa directory
2. Re-run Apache's configure, adding mod_auth_dacs (--with-module=aaa:auth_dacs)
3. Reinstall Apache:
% make install
4. Verify that mod_auth_dacs appears in the list of Apache modules:
% httpd -l
Tip
Because mod_auth_dacs references symbols in mod_ssl, apparently those symbols must be loaded before mod_auth_dacs is loaded. This
can be ensured by statically compiling mod_ssl into httpd (configure httpd with --enable-ssl and verify with "httpd -l") and using
the following directive in httpd.conf to dynamically load the mod_auth_dacs module:
LoadModule auth_dacs_module modules/mod_auth_dacs.so
Alternatively, it may be sufficient to dynamically load mod_ssl before mod_auth_dacs.
If mod_ssl symbols are unavailable when they are needed, you'll probably see a message like the following when you try to start
httpd:
mod_auth_dacs.so: undefined symbol: ssl_hook_Fixup
After you've installed mod_auth_dacs, restart httpd.
If you built the module with a tag, verify that the DACS version identifier appears in SERVER_SIGNATURE. You can do this by hitting
Apache's printenv CGI program from your browser or using a command like:
% http "http://myserver:myserverport/cgi-bin/printenv"
(first making sure that Apache's printenv CGI is executable) and examining the SERVER_SIGNATURE environment variable, or by running:
% telnet myserver myserverport
and typing:
OPTIONS * HTTP/1.0
followed by a blank line and examining the Server response header.
Note
o The URLs that follow will use http and omit myserverport. Substitute https and/or include myserverport as necessary for your
configuration.
o If you install a new version of DACS, please make sure that you use the mod_auth_dacs module that comes with it. Follow the
instructions above.
9. An assortment of DACS files, including HTML documentation and CSS files, are copied into the DACS www directory (default:
/usr/local/dacs/www).
While you can view the documentation simply by pointing your web browser at the DACS www directory, it is recommended that you make it
available through Apache using its Alias[58] directive because the default site configuration (site.conf-std) expects handlers and DTDs
to be available using certain URLs.
Add lines like the following to your httpd.conf:
Alias /dacs "/usr/local/dacs/www/"
Alias /css "/usr/local/dacs/www/css/"
Alias /dtd-xsd "/usr/local/dacs/www/dtd-xsd/"
Alias /examples "/usr/local/dacs/www/examples/"
Alias /handlers "/usr/local/dacs/www/handlers/"
Alias /infocards "/usr/local/dacs/www/infocards/"
Alias /man "/usr/local/dacs/www/man/"
Alias /misc "/usr/local/dacs/www/misc/"
Alias /mod "/usr/local/dacs/www/mod/"
To see the DACS DTD files from your browser, you can also add:
AddType text/plain .dtd
These .dtd files are only used to document XML structures and messages used by DACS and are cited in the documentation.
You should also uncomment these two directives in your site.conf file:
XSD_BASE_URL "/dacs/dtd-xsd"
DTD_BASE_URL "/dacs/dtd-xsd"
Tip
After restarting httpd, you can view the documentation using a URL that looks like http://myserver/dacs/man or simply
http://myserver/man.
10. Access to all DACS web services (everything installed in the .../cgi-bin/dacs directory) must be controlled by DACS; that is, they must
be "DACS-wrapped". Assuming you are following the defaults for installing DACS, these are the only files that are required to be
DACS-wrapped.
DACS-wrapping a resource or set of related resources involves:
o Configuring Apache so that it uses DACS to manage access to the contents of a directory or portion of URL space and
o Configuring one or more DACS access control rules for the jurisdiction responsible for the resources (this is done for the DACS web
services by the default ACLs).
Configuring Apache involves, at minimum, adding directives like the following to the appropriate VirtualHost section of httpd.conf:
AddDACSAuth dacs-acs /usr/local/dacs/bin/dacs_acs "-t -v"
SetDACSAuthMethod dacs-acs external
SetDACSAuthConf dacs-acs "/usr/local/dacs/dacs.conf"
<Location /cgi-bin/dacs>
AuthType DACS
AuthDACS dacs-acs
Require valid-user
Options ExecCGI
</Location>
Tip
Remember to restart Apache after making changes to httpd.conf.
Some administrators may choose to make all content or all CGIs DACS-wrapped. That is probably a more secure approach, although of
course it can be somewhat less efficient than segmenting the server's URL space into "secure" and "insecure" areas. Content that is not
DACS-wrapped is totally oblivious to DACS and incurs no overhead due to DACS. Also, this approach may necessitate making "holes" in the
URL space for non-access controlled resources, which must be done with care.
Tip
If you decide to DACS-wrap everything, you will likely want to add rules to grant access to various public resources, such as CSS
files, robots.txt, favicon.ico, and various public DACS resources, such as its man, dtd-xsd, etc. directories (see the instructions
for the Alias directive above). The default ACL acl-stddocs.0 does this for some resources, but you may need to extend the list to
grant access to additional public resources.
Initial Configuration
Tip
At this point, reviewing dacs.quick(7)[4] is strongly recommended. It provides a detailed example of what needs to be done to make your
DACS operational and how to do some basic testing.
Tip
The interactive dacsinit utility can perform the steps described below quickly. You will find dacsinit in the distribution's src
directory. It can be run anytime after DACS has been built and installed. It produces a directory structure for the federation, copies
the distribution's site configuration file, creates a minimal dacs.conf for the federation and one jurisdiction, makes federation and
jurisdiction encryption keys, and generates metadata for the jurisdiction. The resulting configuration can be used immediately by DACS
commands and by DACS web services after Apache has been configured for DACS.
Passing the -d flag to dacsinit causes it to append a string to certain paths and filenames so that, for debugging or test purposes, it
is unlikely to overwrite any "real" configuration files. Passing it the -n flag causes it to display what it would do without
performing any of the actions.
Having installed DACS, the next major step is to do some initial configuration of your federation and jurisdiction(s). At each jurisdiction
in your federation you will need to do the following:
1. Install the default site configuration file. The distribution comes with a default site configuration file found in the distribution's
conf/site.conf-std file. The installation procedure copies this file into the DACS federations directory. After making a backup copy of
any federations/site.conf file that is already there, copy federations/site.conf-std to federations/site.conf, applying any
customizations you require (customizations are usually done in dacs.conf though, so that you can simply copy on top of the previous
site.conf). Note that conf/site.conf-std may well change in a new release and you should use the latest version.
2. As part of the installation procedure, a default set of access control rules is copied into the DACS acls directory (default:
/usr/local/dacs/acls). The default site.conf file (site.conf-std) configures DACS to look in that directory for the default rules.
These rules control access to DACS web services and are sufficient for proper operation.
Tip
If your installed DACS web services have a filename suffix (e.g., .cgi, you should probably build DACS with an appropriate
--with-cgi-suffix flag or customize the rules manually. If it is necessary to change the default rules, consider overriding them at
the jurisdiction level instead of editing a default ACL file - this will make it easier for you to upgrade because you will not
have to carry these changes forward to future releases of DACS.
Security
Access to some administrative and experimental DACS web services is completely disabled or restricted by default; change these with
care and at your own risk, particularly if your web server is reachable from the Internet.
3. Configure your dacs.conf file at each jurisdiction. At the very least, you must provide FEDERATION_DOMAIN[59], FEDERATION_NAME[60], and
JURISDICTION_NAME[61] directives; all other required directives will come from the site.conf file installed in an earlier step if you
do not specify them.
4. Use dacskey(1)[62] to make encryption keys for the federation (if you are creating a new federation) or obtain a copy of the
federation's encryption keys for each new jurisdiction (if you are joining an existing federation). Each jurisdiction in a federation
must have a copy of the same federation keys.
5. Use dacskey(1)[62] to make encryption keys for each new jurisdiction (each jurisdiction will have different keys).
6. Create a group definition that describes your jurisdictions - see dacs.groups(5)[63] - and install an identical copy at each
jurisdiction.
7. Check ownership and permissions on DACS executables and data files.
Security
All access to DACS configuration files (dacs.conf, site.conf) and keys must be limited to the DACS administrator and the DACS CGI
programs called by Apache. The installation process tries to set this reasonably, but you should re-check now and after making
changes because it is vital to maintain a secure system (e.g., ls -lR /usr/local/dacs).
Initial Testing
Having configured Apache and DACS, you should try some basic DACS web services to make sure that they are working properly before you go on
to make customizations.
For example, invoke dacs_version(8)[12] from your browser to check that it is properly DACS-wrapped (adjust the URL for your environment):
% http "http://myserver/cgi-bin/dacs/dacs_version"
Review the DACS log files (default: /usr/local/dacs/logs/*) to see what happened. You can also try dacsversion(1)[64] from the command
line.
You should verify that dacs_list_jurisdictions(8)[9] works properly.
The next step is to configure an authentication method - see dacs_authenticate(8)[6] and try to authenticate. Once that appears to be
working, you can try dacs_current_credentials(8)[7], dacs_prenv(8)[8], dacs_conf(8)[10], and dacs_signout(8)[11].
Build Options
Running configure generates config.nice (over-writing any previous contents), which can be executed at some later time if you want to
re-run configure with the same arguments.
Tip
After you are happy with your configuration, consider squirrelling away a copy of config.nice in case you want to reconfigure DACS or
for use with later releases of DACS.
It is possible to "bundle" several of the DACS utility programs together into a single binary called dacs. This is similar to what OpenSSL
does with its openssl command. Instead of running:
% dacsacl ...
you would run:
% dacs dacsacl ...
Running dacs without arguments displays the list of built-in utilities. Some utilities have multiple names that are equivalent; these
appear in a comma-separated list. To build this combined command, add the flag bundle=yes to command lines when building and installing:
% gmake bundle=yes
% gmake bundle=yes install
The commands that are bundled into the dacs command won't be built as separate programs. To build and install both bundled and unbundled
commands:
% gmake bundle=both
% gmake bundle=both install
Command: gmake or "gmake build"
This will build libraries, services, and utilities in the source directory. By default, the build process will create shared libraries
and binaries if they are supported on your platform.
Tip
If you encounter problems while building DACS with shared libraries, use --disabled-shared and --enable-static with configure and
try building it again.
Command: "gmake install"
This will install all DACS components. We recommend that everything other than CGI binaries be put under /usr/local/dacs, which is the
default. The CGI binaries are by default installed in .../your-apache-dir/cgi-bin/dacs. By default, DACS utilities will be installed in
/usr/local/dacs/bin, which you may want to put on your PATH for convenience.
Command: "gmake clean"
Removes binaries, object files, and other junk in the build directory
Command: "gmake distclean"
Does a "gmake clean" and cleans up so that configure can be re-done.
Command: "gmake extraclean"
Does a "gmake distclean" and removes configure. After this, do:
% autoconf -I../include
and then run configure.
Command: "gmake uninstall"
Removes installed binaries, include files, and libraries
Other useful build commands (these should be self-explanatory):
% gmake build-services
% gmake build-progs
% gmake build-static
% gmake build-shared
% gmake build-static-services
% gmake build-shared-services
% gmake build-static-progs
% gmake build-shared-progs
% gmake build-shared-lib
% gmake install-libs
% gmake install-shared-lib
% gmake install-static-lib
% gmake install-progs
% gmake install-services
Configure Options
To verify that this documentation is up-to-date, please run:
% configure --help
This will also tell you which features are enabled (or disabled) by default. Standard build and install options.PP
--prefix=PREFIX
The root for the installation hierarchy [/usr/local/dacs], which is referred to as the symbol and variable DACS_HOME[65]
--exec-prefix=EPREFIX
The root for the architecture-dependent hierarchy [PREFIX]
--bindir=DIR
Where DACS utilities are installed [EPREFIX/bin]
--libdir=DIR
Where DACS libraries are installed [EPREFIX/lib]
--includedir=DIR
Where DACS include files are installed [EPREFIX/include]
--mandir=DIR
Where DACS manual pages are installed [EPREFIX/man]
--enable-shared
Generate shared libraries
--enable-static
Generate static libraries
--disable-prefix-check
Disable prefix path check. The prefix path check does some sanity tests on PREFIX.
Feature selection options.PP
--enable-access-tokens
Compile with the authorization caching feature
--enable-all-auth
Enable all authentication methods; you can use this flag and then individually disable methods (e.g., --enable-all-auth
--disable-apache-auth would enable all methods except Apache password authentication
--enable-apache-auth
Enable Apache password authentication directly through DACS
--enable-bdb
Enable Berkeley DB support (default is yes). If you don't want it, use --disable-bdb
--enable-cas-auth
Enable CAS authentication
--enable-cert-auth
Enable X.509 client certificate authentication
--enable-dacs-conf
Specify default DACS config file
--enable-dacs-log
Specify initial DACS log file
--enable-debug
Compile with debugging
--enable-developer
Compile with development flags
--enable-fts
Use included fts(3)[66] library
--enable-gdbm
Enable ndbm support using gdbm's compatibility API (gdbm(3)[67])
--enable-grid-auth
Enable one-time password grid authentication
--enable-infocard-auth
Enable InfoCard authentication and support
--enable-java
Enable Java support
--enable-ldap-auth
Enable LDAP authentication and roles
--enable-local-roles
Enable private DACS roles module (enabled by default)
--enable-native-auth
Enable authentication via Apache modules
--enable-ndbm
Enable native Unix ndbm API support
--enable-ntlm-auth
Enable NTLM authentication
--enable-pam-auth
Enable PAM authentication
Important
The PAM module should be considered experimental. Test it carefully before production use.
--enable-passwd-auth
Enable DACS password-protected account authentication
--enable-simple-auth
Enable simple DACS account authentication
--enable-sqlite
Enable SQLite support (default is no). If you don't want it, use --disable-sqlite
--enable-token-auth
Enable one-time password token authentication
--enable-unix-roles
Enable Unix groups roles module (enabled by default on Unix platforms)
--enable-user-info
Compile with the user information reporting feature
Third-party support options.PP
--with-apache=DIR
Root Apache install directory; if DIR is "omit", however, a basic subset of DACS will be installed (also see above[68]) (example:
if Apache files have been installed in /usr/local/apache2.2/include, /usr/local/apache2.2/conf, etc., use
--with-apache=/usr/local/apache2.2)
--with-apache-apr=DIR
Root Apache APR install directory; required only when Apache 2.2 is used (example:
--with-apache-apr=/usr/local/apache2.2/apr-httpd)
--with-apache-apr-config=PATH
Apache APR configuration program; required only when Apache 2.2 is used and the correct program is not on the search path; this
flag may be required if the build system has more than one instance of Apache installed or if you have installed Apache in a
non-standard location (example: --with-apache-apr-config=/usr/local/apache2.2/apr-httpd/bin/apr-1-config)
--with-apache-apr-cpp-defs=FLAGS
Preprocessor flags required when compiling files that include Apache APR code; may be required with some "non-standard" cases when
Apache 2.2 is used and "apr-1-config --cppflags" is unavailable or does not report the correct flags (example:
--with-apache-apr-cpp-defs=-D_LARGEFILE64_SOURCE)
Note
It has been reported that on some GNU/Linux platforms, such as Ubuntu, it is necessary to define these symbols when building
DACS code that includes APR header files (such as dacsversion):
#define LINUX 2
#define _REENTRANT
#define _GNU_SOURCE
#define _LARGEFILE64_SOURCE
--with-apache-apr-includes=DIR
Apache APR include files directory; required with some "non-standard" cases when Apache 2.2 is used and apr-1-config is unavailable
or does not report the correct directory (example: --with-apache-apr-includes=/usr/bin/include/apr-1.0)
--with-apxs=PATH
By default, the build procedure expects the Apache apxs utility to be bin/apxs, relative to Apache's installation directory. On
systems where this is incorrect, you must specifically configure the path for apxs. (example: --with-apxs=/usr/sbin/apxs2)
--with-bdb=DIR
Location of the root of the installed Berkeley DB libraries, include files, etc.; for example --with-bdb=/usr/local/BerkeleyDB.5.3.
This implies --enable-bdb.
--with-cgi-bin=DIR
Location of Apache CGI files for DACS web services. This will resolve to DIR/cgi-bin/dacs if it exists, or DIR/dacs if that exists,
or DIR if its last component is "dacs".
--with-cgi-suffix=SUFFIX
When installing CGI executables, add SUFFIX as the file extension. A typical value for SUFFIX is ".cgi". The default access control
rules for DACS web services (via the VFS item type dacs_acls) respect this suffix. On Windows platforms, where ".exe" is the
standard extension for programs, SUFFIX is set to that by default. Using a SUFFIX of "no" sets the extension to the null string.
--with-dacs-conf=PATH
Specify default DACS config file (default: PREFIX/federations/dacs.conf)
--with-dacs-log=PATH
Specify initial DACS log file (default: PREFIX/logs/error_log)
--with-expat=DIR
Root directory of installed Expat libraries and include files. If Expat files have been installed in /usr/local/expat/include,
/usr/local/expat/lib, etc., use --with-expat=/usr/local/expat.
--with-federations-root=DIR
Location of DACS federations root directory (default: PREFIX/federations)
--with-htdocs=DIR
Location of Apache DACS files if not the htdocs subdirectory of the Apache install directory.
--with-iconv=DIR
Path to parent of iconv installation. This flag may be required if you are enabling Samba support.
--with-jdk-bin
If Java support is enabled, this identifies the directory containing the java, javac, javah, and jar commands. If this flag is
absent, configure will look for those programs using the current PATH variable. (Example: --with-jdk-bin=/usr/local/java/bin)
--with-jdk-includes
If Java support is enabled, this is a list of one or more GCC include flags for JDK include directories (Example:
--with-jdk-includes=-I/usr/local/jdk/include -I/usr/local/jdk/include/freebsd)
--with-ldap=DIR
Location of OpenLDAP source files. This is the root directory for the OpenLDAP source distribution (Example:
/local/src/openldap-2.2.28). This implies --enable-ldap-auth.
--with-mailer-prog=PATH
Location of a mailer program to use instead of sendmail. This is only needed if email support is required. If --with-mailer-args is
also specified, it will be used as the command line arguments. See dacsemail(1)[69] for a description of how the mailer is expected
to behave.
--with-mailer-args=STRING
Command line arguments to use with the selected mailer program. This is only required if email support is required. See
dacsemail(1)[69] for a description of how the mailer is expected to behave.
--with-readline=LIB
Use GNU Readline[51] when available. If LIB is given, it is the link flag to use or the pathname for the library (other flags may
also be specified). (Example: --with-readline=-Wl,-rpath,/local/src/readline-6.2/lib -L/local/src/readline-6.2/lib
-I/local/src/readline-6.2/include)
--with-samba=DIR
Location of Samba source files. This is the root directory for the Samba source distribution (Example: /local/src/samba-3.6.3).
This implies --enable-ntlm-auth.
--with-sendmail=PATH
Location of sendmail(8)[70]. This is only needed if email support is required and the location of the sendmail command found at
configuration time must be overridden. If --with-mailer-args is also specified, it will be used instead of the default sendmail
command line arguments. See dacsemail(1)[69] for additional details.
--with-sqlite=DIR
Location of the root of the installed SQLite libraries, include files, etc.; for example --with-sqlite=/usr/local/sqlite-3.7.10.
This implies --enable-sqlite.
--with-ssl=DIR
Location of the root of the installed OpenSSL libraries and include files. If OpenSSL files have been installed in
/usr/local/openssl/include, /usr/local/openssl/lib, etc., use --with-expat=/usr/local/openssl.
--with-xmlsec1-config=PATH
If the build procedure cannot find xmlsec1-config, or if it finds the wrong one, you can specify its location as PATH. This may
only be required if InfoCard authentication has been enabled.
To specify additional flags for compiling or linking DACS, set CFLAGS or LDFLAGS, respectively.
To specify additional flags for compiling or linking mod_auth_dacs, set APACHE_CFLAGS or APACHE_LDFLAGS, respectively. For example,
this command will cause mod_auth_dacs to be built with the -m64 flag and DACS to be built with both the -m64 flag and the -O3 flag:
% ./configure "APACHE_CFLAGS=-m64" "CFLAGS=-O3 -m64" ...
SEE ALSO
dacs(1)[71], dacs.readme(7)[5], dacs.quick(7)[4]
AUTHOR
Distributed Systems Software (www.dss.ca[72])
COPYING
Copyright2003-2012 Distributed Systems Software. See the LICENSE[73] file that accompanies the distribution for licensing information.
NOTES
1. gmake
http://directory.fsf.org/project/make
2. GCC
http://gcc.gnu.org
3. ldconfig(8)
http://www.freebsd.org/cgi/man.cgi?query=ldconfig&apropos=0&sektion=8&manpath=FreeBSD+9.0-RELEASE&format=html
4. dacs.quick(7)
http://dacs.dss.ca/man/dacs.quick.7.html
5. dacs.readme(7)
http://dacs.dss.ca/man/dacs.readme.7.html
6. dacs_authenticate(8)
http://dacs.dss.ca/man/dacs_authenticate.8.html
7. dacs_current_credentials(8)
http://dacs.dss.ca/man/dacs_current_credentials.8.html
8. dacs_prenv(8)
http://dacs.dss.ca/man/dacs_prenv.8.html
9. dacs_list_jurisdictions(8)
http://dacs.dss.ca/man/dacs_list_jurisdictions.8.html
10. dacs_conf(8)
http://dacs.dss.ca/man/dacs_conf.8.html
11. dacs_signout(8)
http://dacs.dss.ca/man/dacs_signout.8.html
12. dacs_version(8)
http://dacs.dss.ca/man/dacs_version.8.html
13. Cygwin
http://cygwin.com
14. man/index.html
http://dacs.dss.ca/man/index.html
15. Post-Release Notes
http://dacs.dss.ca/download.html
16. sudo(8)
http://www.freebsd.org/cgi/man.cgi?query=sudo&apropos=0&sektion=8&manpath=FreeBSD+9.0-RELEASE&format=html
17. Expat
http://expat.sourceforge.net
18. OpenSSL
http://www.openssl.org
19. xmlsec1
http://www.aleksey.com/xmlsec
20. a patch
http://www.openssl.org/support/faq.html#USER1
21. Apache
http://httpd.apache.org
22. above
http://dacs.dss.ca/man/#install_openssl
23. Third-party support options
http://dacs.dss.ca/man/#third-party-support-options
24. build Berkeley DB
http://dacs.dss.ca/man/#dbm-databases
25. FAQ
http://dacs.dss.ca/man//faq.html
26. Berkeley DB
http://www.oracle.com/technology/software/products/berkeley-db/index.html
27. Oracle Corporation
http://www.oracle.com
28. --enable-bdb
http://dacs.dss.ca/man/#build_flag_--enable-bdb
29. --disable-bdb
http://dacs.dss.ca/man/#build_flag_--disable-bdb
30. --with-bdb
http://dacs.dss.ca/man/#build_flag_--with-bdb
31. ftp://ftp.gnu.org/gnu/gdbm
ftp://ftp.gnu.org/gnu/gdbm/
32. --enable-ndbm
http://dacs.dss.ca/man/#build_flag_--enable-ndbm
33. --enable-gdbm
http://dacs.dss.ca/man/#build_flag_--enable-gdbm
34. sdbm
http://search.cpan.org/src/NWCLARK/perl-5.8.8/ext/SDBM_File/sdbm/README
35. SQLite
http://www.sqlite.org
36. --enable-sqlite
http://dacs.dss.ca/man/#build_flag_--enable-sqlite
37. --disable-sqlite
http://dacs.dss.ca/man/#build_flag_--disable-sqlite
38. --with-sqlite
http://dacs.dss.ca/man/#build_flag_--with-sqlite
39. local_ntlm_authenticate
http://dacs.dss.ca/man/dacs_authenticate.8.html#local_ntlm_authenticate
40. Samba
http://www.samba.org
41. --enable-ntlm-auth
http://dacs.dss.ca/man/#build_flag_--enable-ntlm-auth
42. --with-samba
http://dacs.dss.ca/man/#build_flag_--with-samba
43. local_infocard_authenticate
http://dacs.dss.ca/man/dacs_authenticate.8.html#local_infocard_authenticate
44. libxml2
http://xmlsoft.org
45. --with-xmlsec1-config
http://dacs.dss.ca/man/#build_flag_--with-xmlsec1-config
46. --enable-infocard-auth
http://dacs.dss.ca/man/#build_flag_--enable-infocard-auth
47. local_ldap_authenticate
http://dacs.dss.ca/man/dacs_authenticate.8.html#local_ldap_authenticate
48. OpenLDAP
http://www.openldap.org
49. --enable-ldap-auth
http://dacs.dss.ca/man/#build_flag_--enable-ldap-auth
50. --with-ldap
http://dacs.dss.ca/man/#build_flag_--with-ldap
51. GNU Readline Library
http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html
52. dacsexpr(1)
http://dacs.dss.ca/man/dacsexpr.1.html
53. --with-readline
http://dacs.dss.ca/man/#build_flag_--with-readline
54. Build Options
http://dacs.dss.ca/man/#build_options
55. dacsacl(1)
http://dacs.dss.ca/man/dacsacl.1.html
56. DESTDIR
http://www.gnu.org/prep/standards/standards.html#DESTDIR
57. Group
http://httpd.apache.org/docs/2.2/mod/mpm_common.html#group
58. Alias
http://httpd.apache.org/docs/2.2/mod/mod_alias.html#alias
59. FEDERATION_DOMAIN
http://dacs.dss.ca/man/dacs.conf.5.html#FEDERATION_DOMAIN
60. FEDERATION_NAME
http://dacs.dss.ca/man/dacs.conf.5.html#FEDERATION_NAME
61. JURISDICTION_NAME
http://dacs.dss.ca/man/dacs.conf.5.html#JURISDICTION_NAME
62. dacskey(1)
http://dacs.dss.ca/man/dacskey.1.html
63. dacs.groups(5)
http://dacs.dss.ca/man/dacs.groups.5.html#dacs_metadata
64. dacsversion(1)
http://dacs.dss.ca/man/dacsversion.1.html
65. DACS_HOME
http://dacs.dss.ca/man/dacs.conf.5.html#var_dacs_home
66. fts(3)
http://www.freebsd.org/cgi/man.cgi?query=fts&apropos=0&sektion=3&manpath=FreeBSD+9.0-RELEASE&format=html
67. gdbm(3)
http://directory.fsf.org/gdbm.html
68. also see above
http://dacs.dss.ca/man/#building_subset
69. dacsemail(1)
http://dacs.dss.ca/man/dacsemail.1.html
70. sendmail(8)
http://www.freebsd.org/cgi/man.cgi?query=sendmail&apropos=0&sektion=8&manpath=FreeBSD+9.0-RELEASE&format=html
71. dacs(1)
http://dacs.dss.ca/man/dacs.1.html
72. www.dss.ca
http://www.dss.ca
73. LICENSE
http://dacs.dss.ca/man/../misc/LICENSE
DACS 1.4.27b 10/22/2012 DACS.INSTALL(7)