DACS.INSTALL(7) | DACS Miscellaneous Information | DACS.INSTALL(7) |
NAME¶
dacs.install - DACS installation guideDESCRIPTION¶
This document describes how to configure and install this release of DACS. Please read it carefully.•Installation requires the GNU make command
( gmake[1]) and GCC[2].
•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 confuse or combine 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.
•In some command line examples, long lines have
been split to improve readability; copying and pasting may not work.
•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.
•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 stable 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.
•On Mac OS X you will probably need to install the
Xcode[3] development environment.
•On some systems it will be necessary to use
ldconfig(8)[4] (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)[5], 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)[6] 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[7]:
% cd ../apache; gmake tag install
10.Restart httpd:
or
% apachectl start
% 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)[8] dacs_current_credentials(8)[9],
dacs_prenv(8)[10], dacs_list_jurisdictions(8)[11],
dacs_conf(8)[12], dacs_signout(8)[13], and
dacs_version(8)[14]. Review the DACS log file for any error
messages or warnings.
DACS on Windows¶
DACS is not currently supported on Microsoft Windows platforms. Cygwin[15], 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.•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.
•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.
•If you are installing or upgrading a third-party
package, make sure that you are building it against the correct include files
and libraries (e.g., that the DACS build is not finding an old version,
or using include files from one version and library files from a different
version, or that httpd is trying to use the wrong version of an
OpenSSL library). This is frequently the cause of build and run-time
problems.
1.Unpack the DACS distribution and move to its
root directory.
2.Familiarize yourself with the system by:
•reading this document;
•running:
% src/configure --help
•browsing through the documentation (best done by
loading man/index.html[16] into your browser);
•deciding where you want the various components to
be installed; and
•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[17].
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)[18]
(e.g., " sudo make install").
These packages are not distributed with DACS and have licensing terms
completely separate from those of DACS that are your responsibility.
Third-Party Package Index:
•Expat: XML parser
•OpenSSL: Crytographic toolkit
•Apache: Web server
•Berkeley DB, gdbm, ndbm: dbm-type database
libraries
•SQLite: SQL database engine
•Samba: Microsoft Windows interoperability
suite
•libxml2, xmlsec1: XML toolkit and security
libraries
•OpenLDAP: Lightweight Directory Access
Protocol software
•Readline: Command line history and editing
1.Install the Expat XML parser
This release of DACS has been tested with Expat[19]2.1.0 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.1.0, 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.1.0. Here is how we usually build
Expat after unpacking it:
Note
On Win2K/Cygwin, only a static library is needed. From the root of the
expat distribution directory:
If the build fails, reconfigure using --enable-shared=no and
--enable-static=yes and try to build it again.
% cd expat-2.1.0 % ./configure --prefix=/usr/local/expat-2.1.0 % make (All should go well.) % make install (All should go well here, too.)
% cd lib; ar rv libexpat.a *.o; ranlib libexpat.a
2.Install OpenSSL
DACS uses cryptographic functionality provided by OpenSSL[20].
This release of DACS has been tested with openssl-1.0.1e 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
•Releases of Apache prior to 2.0.55 do not
work (as shipped) with OpenSSL0.9.8 or newer.
•DACS will probably work with
openssl-1.0.0x, although those versions are no longer officially supported.
DACS will not work with openssl-0.9.8[mno] (" gmake
test" fails); openssl-0.9.8l is the last of the pre-openssl-1.0.0x
releases at one time known to work correctly with DACS.
•If you need InfoCard support and you have
upgraded to openssl-1.0.0 or newer, it may be necessary to rebuild
xmlsec1[21] against the new library (if you need to rebuild, "
gmake test" will fail).
•When building openssl-0.9.8j on FreeBSD7.0,
problems were encountered that caused " make install" to
fail; corrections to Makefiles under the fips subdirectory solved the
problem.
•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). Note that
OpenSolaris is no longer a supported platform.
•If you are enabling DACS support for Java,
add the -fPIC flag to config when you are building
OpenSSL.
•In some configurations you may want or require
shared OpenSSL libraries; if so, add the shared command line
flag to config when building OpenSSL.
•Solaris 8 (and perhaps other platforms) may
require a patch[22] before OpenSSL will work properly. Please
consult the latest OpenSSL documentation.
•For Solaris 10 x86, review
OpenSSL'sPROBLEMS file to see if you must apply a patch before
OpenSSL will compile correctly with GCC.
•Here is how we built OpenSSL:
% ./config --prefix=/usr/local/openssl-1.0.1e --openssldir=/usr/local/openssl-1.0.1e -fPIC shared
•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.1e --openssldir=/usr/local/openssl-1.0.1e -fPIC shared
3.Install Apache2.4.3 or 2.2.23
You will need an SSL-capable Apache[23] server (build Apache with
--enable-ssl) that uses a recent version of OpenSSL (build
Apache using --with-ssl=path, see
above[24]).
Tip
You can install a subset of DACS that does not require Apache and
does not require anyDACS configuration. These stand-alone,
general-purpose utility commands, such as dacshttp 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[7] 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
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
beforeDACS gets involved - doing so can save you time and
frustration.
You can see your httpd'sServer 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):
•This release of DACS has been tested with
both Apache2.2.23 and Apache2.4.3. 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.
•If suitable APR, APR-UTIL, and other support
libraries have already been installed on your system, you may be able to
perform a basic build and install of Apache2.4 with a command like:
Detailed instructions for building Apache2.4.3 can be found in Apache's
INSTALL file. For the testing platforms, we get the APR and APR-UTIL libraries
from apr.apache.org[25] and unpack them in the Apache distribution's
srclib directory, then rename them srclib/apr and srclib/apr-util,
respectively, as it says in INSTALL. We currently use apr-1.4.6 and
apr-util-1.5.1. When building httpd, run configure with the
--with-included-apr flag.
On CentOS5.9, the Apache build initially failed with a complaint about
not finding pcre-config. To solve this, we did:
When configuring for the DACS build it was not necessary to use the
--with-apache-apr flag.
% cd httpd-2.4.3 % ./configure --prefix=/usr/local/apache2-2.4.3 --enable-ssl \ --with-ssl=/usr/local/openssl-1.0.1e % make install
yum install pcre-devel.x86_64
•When building Apache2.2, running
configure as shown above will work in some cases (distributions of the
2.2 branch include the APR and APR-UTIL libraries). Nevertheless, we usually
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[26]).
If you are going to use the --with-berkeley-db flag when building
APR-UTIL (e.g., --with-berkeley-db=/usr/local/BerkeleyDB.5.1), you may
want to temporarily skip ahead to build Berkeley DB[27] before
returning here to continue your Apache build. (Note: it appears that
apr-util2.2.23 will not work with versions of Berkeley DB newer than 5.1;
refer to documentation for its --with-dbm flag).
•Here is how we built Apache2.2 after
unpacking it:
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/db-5.1.29/lib
-rpath /usr/local/openssl-1.0.1e/lib" to LDFLAGS so that Apache
commands could find shared libraries at run time.
On Linux, it was necessary to add "-Wl,-rpath /usr/local/db-5.1.29/lib
-Wl,-rpath /usr/local/openssl-1.0.1e/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 appears that the LDFLAGS above should be omitted on Mac OS X.
% cd httpd-2.2.23 % cd srclib/apr % ./configure --prefix=/usr/local/apache2-2.2.23/apr-httpd --disable-lfs CFLAGS=-fPIC % make install % cd ../apr-util # See notes below for adding LDFLAGS % ./configure --prefix=/usr/local/apache2-2.2.23/apr-util-httpd --with-apr=/usr/local/apache2-2.2.23/apr-httpd --with-expat=/usr/local/expat-2.0.1 --with-dbm=db51 % make install % cd ../.. # See notes below for adding LDFLAGS % ./configure --prefix=/usr/local/apache2-2.2.23 --enable-ssl --with-ssl=/usr/local/openssl-1.0.1e --with-apr=/usr/local/apache2-2.2.23/apr-httpd --with-apr-util=/usr/local/apache2-2.2.23/apr-util-httpd LDFLAGS="-rpath /usr/local/db-5.1.29/lib -rpath /usr/local/openssl-1.0.1e/lib" % make install
•In some configurations an "undefined
ssl_hook_Fixup symbol" error or "Cannot load modules/mod_ssl.so into
server" error is produced by httpd when it starts up. This was
also seen in earlier releases of Apache. These errors can be due to an
apparent bug in the Apache build procedure that results in the
mod_ssl module not knowing where libssl.so and libcrypto.so are, even
though the correct path was specified at Apache build time through the
--with-ssl flag to configure.
One solution is to make mod_ssl a built-in module instead of a
dynamically loaded module. Build Apache using something similar to this
(using the --enable-ssl=static flag is the important change):
Then do a " make install". Note that you will need to comment
out the httpd.conf directive that loads mod_ssl:
Now, from the Apache installation directory, try:
If httpd cannot find your OpenSSL libraries, you will see an error
message like this:
Tell the linker where the OpenSSL libraries are by setting the
LD_LIBRARY_PATH environment variable for httpd; for example:
You may also be able to resolve the problem using the ldconfig command,
but we don't know if that could possibly break other programs that expect a
different version of the OpenSSL library. You will need to always set
LD_LIBRARY_PATH before running httpd, maybe using an alias or
script. If you use apachectl to manage Apache, you could simply
have it set LD_LIBRARY_PATH (also see the Apacheenvvars
script, which is sourced by apachectl).
% ./configure --prefix=/usr/local/apache2-2.4.3 --with-ssl=/usr/local/openssl-1.0.1e --enable-ssl=static
# LoadModule ssl_module modules/mod_ssl.so
% bin/httpd -l
error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
% sh -c "export LD_LIBRARY_PATH=/usr/local/openssl-1.0.1e/lib; bin/httpd -M"
•One difference to be aware of between the
Apache2.0 branch and subsequent branches is that the default
Apache configuration of the newer branches 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>
•Apache1.3 is not supported; please
consult the FAQ[28]. DACS has not been tested with
Apache2.3 or 2.4.
•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.
% 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.23 (Unix) mod_auth_dacs/1.4.27(Release date 17-Oct-2012 00:00:01) mod_ssl/2.2.23 OpenSSL/1.0.1c
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'smod_auth_dbm, you may use Berkeley DB[29] from
Oracle Corporation[30] (Sleepy Cat Software was acquired by Oracle in
February, 2006). A suitable version may already be installed on your system.
Version db-5.3.21 is being used for testing, but somewhat older or newer
versions should be fine. See the DACS configure arguments:
--enable-bdb[31], --disable-bdb[32], and --with-bdb[33].
Tip
You may find that you must sign on to the Oracle site before it allows you to
download Berkeley DB. You may be able to avoid this by using a URL such as
http://download.oracle.com/berkeley-db/db-5.3.21.tar.gz, or you may be able to
obtain BDB elsewhere (such as at linux.softpedia.com, pkgs.fedoraproject.org,
or fossies.org). Consider validating the downloaded file using a checksum
published on a different site, however.
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[32]) and get similar
functionality from the NDBM library, or from GNU GDBM (version 1.8.3, 1.9.1,
or 1.10) in its NDBM compatibility mode. These libraries may already be
installed on your system. Get GDBM from ftp://ftp.gnu.org/gnu/gdbm[34].
See the --enable-ndbm[35] and --enable-gdbm[36] configure flags.
Notes
•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.21:
% ln -sf /usr/local/bdb-5.3.21 /usr/local/BerkeleyDB.5.3 % ln -sf /usr/local/bdb-5.3.21 /usr/local/db53
•Here is how we built Berkeley DB for DACS
after unpacking it:
% cd build_unix % ../dist/configure --prefix=/usr/local/bdb-5.3.21 % make (All should go well.) % make install (All should go well here, too.)
•You cannot use both
--enable-ndbmand --enable-gdbm, but you can use either
one along with --enable-bdb.
•GNU GDBM1.9.1 and newer may not interoperate
correctly with databases created by older versions of GNU GDBM; consult its
source code and documentation for details.
•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.
•The NDBM-workalike, sdbm[37], is not
currently supported. It may be added to a future release, however,
particularly if it is requested.
2.SQLite
The SQLite[38] database, which can be used together with the dbm-type
databases[27], is another option for storing DACS configuration
information. Version 3.7.14.1 is being used for testing (we use the
"autoconf" tarball). See the DACS configure arguments:
--enable-sqlite[39], --disable-sqlite[40], and
--with-sqlite[41].
Notes
•Here is how we built SQlite:
% ./configure --prefix=/usr/local/sqlite-3.7.14.1
3.Samba
If you want to be able to authenticate against Microsoft NTLM (see
local_ntlm_authenticate[42]), you must obtain Samba[43]. This
release of DACS has been tested with samba-3.6.12, 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 Server 2012.
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:
Then, when configuring DACS, specify the directory where Samba was
unpacked, for example:
See the DACS configure arguments: --enable-ntlm-auth[44] and
--with-samba[45].
% ./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
--with-samba=/local/src/samba-3.6.12
4.libxml2 and xmlsec1
If you need InfoCard support (see local_infocard_authenticate[46]),
libxml2[47] and xmlsec1[21] are required. Build libxml2 and
OpenSSL first, because xmlsec1[21] depends on both of them. This
release of DACS has been tested with libxml2-2.9.0 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
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[48] flag.
See the DACS configure arguments: --enable-infocard-auth[49] and
--with-xmlsec1-config[48]
•Here is how we built libxml2:
Due to an apparent bug in the code (in threads.c) that results in a syntax
error, it was necessary to add --with-threads=no on some platforms,
such as Mac OS X.
% ./configure --prefix=/usr/local/libxml2-2.9.0
•Here is how we built xmlsec1:
Except on Mac OS X:
% ./configure --prefix=/usr/local/xmlsec1-1.2.18 --with-libxml=/usr/local/libxml2-2.9.0 --with-openssl=/usr/local/openssl-1.0.1e --with-gnu-ld --enable-static-linking --disable-crypto-dl --disable-apps-crypto-dl
% ./configure --prefix=/usr/local/xmlsec1-1.2.18 \ --with-libxml=/usr/local/libxml2-2.9.0 --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.1e \ --disable-crypto-dl
•Due to an apparent error in its build procedure,
we sometimes encountered the following error message:
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".
*** Warning: Linking the shared library libxmlsec1-openssl.la against the *** static library /local/openssl-1.0.1e/lib/libcrypto.a is not portable!
•Another problem related to this library on a
CentOS platform resulted in an error message similar to this:
The solution was to issue the command (adjust the path as necessary):
Cannot restore segment prot after reloc: Permission denied
% chcon -t texrel_shlib_t /usr/local/xmlsec1-1.2.18/lib/libxmlsec1-openssl.so
•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):
Ensure that " gmake test" does not fail.
% setenv DYLD_LIBRARY_PATH /usr/local/xmlsec1-1.2.18/lib
•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.
•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.
5.OpenLDAP
Authentication through LDAP or Microsoft Active Directory (see
local_ldap_authenticate[50]) is implemented using OpenLDAP[51].
This release of DACS has been tested only with openldap-2.4.33 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 installOpenLDAP,
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:
If so instructed, do a " make depend" before the make.
See the DACS configure arguments: --enable-ldap-auth[52] and
--with-ldap[53]
% ./configure --disable-slapd --enable-static % make
6.Readline
The history and editing functionality provided by the GNU Readline
Library[54] can be nice to have when using dacsexpr(1)[55]
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 installreadline, 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
See the DACS configure arguments: --with-readline[56]
•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
5.Configure and build DACS libraries, services,
commands, and utilities
See Build Options[57] for build alternatives and options to
configure.
To confirm that DACS has been built with the third-party packages that
you intended, from the run:
You should ensure that the sslclient utility is working correctly. From
the src directory, you can test it using the following command:
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:
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").
% cd src % ./configure % gmake
% ./version -v
% perl -e 'printf "GET / HTTP/1.0\n\n";' | ./sslclient dacs.dss.ca:443
% gmake test
6.If all looks good, install DACS
Notes
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[60] 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.
% gmake install
•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
•This will install the rules for the standard
DACS web services and run dacsacl(1)[58] to create and install
an index for them.
•You can specify DESTDIR[59] to
gmake when installing or uninstalling:
% gmake DESTDIR=/tmp/mydacs install
7.As part of the installation procedure, the DACS
manual pages are copied into the DACSman directory (default:
/usr/local/dacs/man). If you adjust your MANPATH environment variable
to include that directory, try:
While it is occasionally handy to view the manual pages using the man
command, the HTML documentation is far superior.
% man dacs
8.Build a DACS-enabled httpd
Please consult apache/README in the DACS distribution for details and,
from the apache directory, do:
Security
You can build the mod_auth_dacs module[7] with a module identification
string (a "version tag") with varying amounts of detail, or without
a tag. For a full-length tag, use " gmake tag", for a simple
tag use " gmake smalltag", or to disable the tag use
"gmake notag" or "gmake module". We suggest
that you compile mod_auth_dacs with a tag so that
Apache'sSERVER_SIGNATURE and Server response header field can
include DACS version identification; this makes it easy to tell which
version of DACS the server is running and helps to detect mismatches.
If mod_auth_dacs is compiled with debugging enabled or if the
SetDACSAuthDebug[61] directive enables debugging, additional version
information is added to the tag. For production use, identifying the modules
in your Apache server is considered by some to be a potential security
weakness - you may reasonably choose not to include the version tag. For some
versions of Apache, module identification can be suppressed at runtime
through its ServerTokens[62] directive.
If you want mod_auth_dacs[7] to be a dynamic module, which is
recommended, do:
Check that your httpd.conf has the appropriate LoadModule directive.
If you want mod_auth_dacs module[7] to be a static module:
Tip
Because mod_auth_dacs[7] references symbols in mod_ssl, apparently
those symbols must be loaded beforemod_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:
Alternatively, it may be sufficient to dynamically load
mod_sslbefore 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:
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:
(first making sure that Apache'sprintenv CGI is executable) and
examining the SERVER_SIGNATURE environment variable, or by running:
and typing:
followed by a blank line and examining the Server response header.
Note
% gmake help
% cd apache % gmake tag % gmake install
1.Copy apache/mod_auth_dacs.c to
Apache'smodules/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
LoadModule auth_dacs_module modules/mod_auth_dacs.so
mod_auth_dacs.so: undefined symbol: ssl_hook_Fixup
% http "http:// myserver:myserverport/cgi-bin/printenv"
% telnet myserver myserverport
OPTIONS * HTTP/1.0
•The URLs that follow will use http and omit
myserverport. Substitute https and/or include myserverport as
necessary for your configuration.
•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 DACSwww directory
(default: /usr/local/dacs/www).
While you can view the documentation simply by pointing your web browser at the
DACSwww directory, it is recommended that you make it available through
Apache using its Alias[63] 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:
To see the DACS DTD files from your browser, you can also add:
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:
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/"
AddType text/plain .dtd
XSD_BASE_URL "/dacs/dtd-xsd" DTD_BASE_URL "/dacs/dtd-xsd"
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:
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.
•Configuring Apache so that it uses
DACS to manage access to the contents of a directory or portion of URL
space and
•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 # Note: For Apache 2.4, instead use: # Require dacs-authz Options ExecCGI </Location>
Initial Configuration¶
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 DACSfederations 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 DACSacls 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[64],
FEDERATION_NAME[65], and JURISDICTION_NAME[66] 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)[67] 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)[67] 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)[68] - 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)[14] 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"
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.% dacsacl ...
% dacs dacsacl ...
% gmake bundle=yes % gmake bundle=yes install
% gmake bundle=both % gmake bundle=both install
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:
and then run configure.
Command: " gmake uninstall"
% autoconf -I../include
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
To verify that this documentation is up-to-date, please run:
This will also tell you which features are enabled (or disabled) by default.
Standard build and install options.PP
--prefix=PREFIX
% configure --help
The root for the installation hierarchy
[/usr/local/dacs], which is referred to as the symbol and variable
DACS_HOME[70]
--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)[71] library
--enable-gdbm
Enable ndbm support using gdbm's compatibility API
(gdbm(3)[72])
--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-rule-patterns
Enable extended URL patterns when matching a request
against ACLs (this is an add-on feature)
--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[73]) (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 ApacheAPR install directory; required only
when Apache2.2 or 2.4 are used (example:
--with-apache-apr=/usr/local/apache2.2/apr-httpd)
--with-apache-apr-config=PATH
ApacheAPR configuration program; required only
when Apache2.2 or 2.4 are 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 ApacheAPR code; may be required with some
"non-standard" cases when Apache2.2 or 2.4 are 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):
--with-apache-apr-includes=DIR
#define LINUX 2 #define _REENTRANT #define _GNU_SOURCE #define _LARGEFILE64_SOURCE
ApacheAPR include files directory; required with
some "non-standard" cases when Apache2.2 or 2.4 are 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
Apacheapxs 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/db-5.3.21. 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 ApacheDACS 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 OpenLDAPsource 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)[74] 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)[74] for a description of how the mailer is expected to
behave.
--with-readline=LIB
Use GNU Readline[54] 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.12). This implies --enable-ntlm-auth.
--with-sendmail=PATH
Location of sendmail(8)[75]. 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)[74] 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 the mod_auth_dacs
module[7], 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)[76], dacs.readme(7)[6], dacs.quick(7)[5]AUTHOR¶
Distributed Systems Software ( www.dss.ca[77])COPYING¶
Copyright2003-2013 Distributed Systems Software. See the LICENSE[78] file that accompanies the distribution for licensing information.NOTES¶
- 1.
- gmake
- 2.
- GCC
- 3.
- Xcode
- 4.
- ldconfig(8)
- 7.
- mod_auth_dacs module
- 10.
- dacs_prenv(8)
- 12.
- dacs_conf(8)
- 13.
- dacs_signout(8)
- 14.
- dacs_version(8)
- 15.
- Cygwin
- 16.
- man/index.html
- 17.
- Post-Release Notes
- 18.
- sudo(8)
- 19.
- Expat
- 20.
- OpenSSL
- 21.
- xmlsec1
- 22.
- a patch
- 23.
- Apache
- 24.
- above
- 25.
- apr.apache.org
- 26.
- Third-party support options
- 27.
- build Berkeley DB
- 28.
- FAQ
- 29.
- Berkeley DB
- 30.
- Oracle Corporation
- 31.
- --enable-bdb
- 32.
- --disable-bdb
- 33.
- --with-bdb
- 35.
- --enable-ndbm
- 36.
- --enable-gdbm
- 37.
- sdbm
- 38.
- SQLite
- 39.
- --enable-sqlite
- 40.
- --disable-sqlite
- 41.
- --with-sqlite
- 42.
- local_ntlm_authenticate
- 43.
- Samba
- 44.
- --enable-ntlm-auth
- 45.
- --with-samba
- 46.
- local_infocard_authenticate
- 47.
- libxml2
- 48.
- --with-xmlsec1-config
- 49.
- --enable-infocard-auth
- 50.
- local_ldap_authenticate
- 51.
- OpenLDAP
- 52.
- --enable-ldap-auth
- 53.
- --with-ldap
- 54.
- GNU Readline Library
- 55.
- dacsexpr(1)
- 56.
- --with-readline
- 57.
- Build Options
- 58.
- dacsacl(1)
- 59.
- DESTDIR
- 60.
- Group
- 61.
- SetDACSAuthDebug
- 62.
- ServerTokens
- 63.
- Alias
- 64.
- FEDERATION_DOMAIN
- 65.
- FEDERATION_NAME
- 66.
- JURISDICTION_NAME
- 67.
- dacskey(1)
- 68.
- dacs.groups(5)
- 69.
- dacsversion(1)
- 70.
- DACS_HOME
- 71.
- fts(3)
- 72.
- gdbm(3)
- 73.
- also see above
- 74.
- dacsemail(1)
- 75.
- sendmail(8)
- 76.
- dacs(1)
- 77.
- www.dss.ca
- 78.
- LICENSE
07/17/2013 | DACS 1.4.28b |