Building Apache from Source - Apache

Building Apache from the source is a relatively painless process. However, you need the following:

An ANSI C compiler: You can use the freely available gcc as an alternative if a native compiler doesn’t compile Apache properly. On most Unix platforms, gcc is the preferred choice; most Linux, BSD, and MacOS X servers have it installed as standard and aliased to the normal C compiler command cc. You can find it at http://www.gnu.org/software/gcc/gcc.html as an installable package for innumerable platforms.

Dynamic linking support: For Apache to be built as a dynamic server loading modules at runtime, the platform needs to support it. Some operating systems may need patches for dynamic support to work correctly. Otherwise, Apache must be built statically.

A Perl interpreter: Some of Apache’s support scripts, including apxs and dbmmanage, are written in Perl. For these scripts to work, you need a Perl interpreter. If Perl isn’t already installed, you can find binary downloads at http://www.cpan.org/ports/ for many platforms. The source code is also available for those wanting to build it themselves. Note that mod_perl isn’t required; these are external stand-alone scripts. (For administrators who want to use mod_perl, it’s worth updating Perl to the latest stable release, particularly if you want to use threads in mod_perl 2.)

To build Apache from source and install it with the default settings requires only three commands: one to configure it, one to build it, and one to install it. Both Apache 1.3 and Apache 2 provide the configuration script configure to set up the source for compilation on the server and customize it with command line options to determine the structure and makeup of the eventual installation. You can control almost every aspect of Apache at this time if you want, including experimental code and optional platform-specific features.

The following command scans the server to find out what capabilities the operating system has (or lacks), determines the best way to build Apache, and sets up the source tree to compile based on this information:

$ ./configure

A large part of what the configuration process does is to examine the features and capabilities of the operating system. This information is derived through a series of tests and checks and can take quite some time.

The remainder of the configuration process is concerned with taking your customizations, supplied as command line options, and reconfiguring the source code accordingly. This allows you to enable or disable features, include additional components, or override default server locations and limits. For a list of all available options, you can instead use this:

$ ./configure --help

Once the Apache source is configured, you need to build and install it. The following commands build Apache and then install it in the default location of /usr/local/apache (\apache on Windows, /apache on NetWare, and /os2httpd on OS/2):

$ make
$ make install

For minimalists, you can also combine all three commands:

$ ./configure && make && make install

More usefully, you can change Apache’s installation root to something else, which will change both where the installation process puts it and the internal settings built into Apache. Apache then defaults to looking for the server root and its configuration files in that location. If you change nothing else, this is the one thing you might want to override because all of Apache’s default directory and file locations are based on this value. You can have Apache install into a different location by supplying a parameter to the configure command. For example:

$ ./configure --prefix=/opt/apache2

This command would cause make install to install Apache outside the /usr/local/ directory tree. On a Unix server, you’ll certainly need root permissions for the actual installation to proceed without a permissions error. However, you can still carry out the configure and build process up to the point of installation as an unprivileged user. For Apache 2, you can install Apache into a different directory than the one that it was configured with:

[2.0] $ make install DESTDIR=/opt/apache2

If you don’t have root privileges, and no friendly administrator is available to help you, you can instead use the --prefix parameter to have Apache installed under your own directory, for example:

$ ./configure --prefix=/home/ultraviolet/high-programmer/apache --port=4444

Here you specify an installation directory where you do have write privileges. You also specify a port number above 1023; on a Unix server, ports up to this number are considered privileged and can’t be used by nonprivileged processes. A nonstandard installation root and port number are also handy for installing test versions of new releases of the server without disturbing the current server. You could also use the DESTDIR argument to make install.

In general, almost any aspect of Apache can be configured by specifying one or more parameters to the configure command, as you shall see throughout the rest of the chapter.

Apache 2 vs. Apache 1.3 Configuration Process

One of the many significant changes between Apache 1.3 and Apache 2 is the configuration process. Although on the surface the configure script behaves much the same as it used to, there are several differences, too, including many options that have changed name or altered slightly in behavior.

Apache 2 makes use of autoconf, a general-purpose tool for deriving and creating configuration scripts. The autoconf application creates scripts that are similar in spirit to the way that the configure script of Apache 1.3 worked, but they operate on a more generic and cross-platform basis. They’re also easier to maintain and extend; given Apache’s extensible nature, this is a critical requirement. The older Apache 1.3 script mimics a lot of the behavior of autoconf-generated scripts, which is why the two configure scripts have many similarities. However, the resemblance is skin-deep only.

autoconf implements the --enable and --disable options that switch on and off different packages within a source tree and the --with and --without options to configure features both within packages and external to the source tree:

--enable: In Apache, packages translate as modules. As a result, configuration options now exist to enable and disable each module within Apache. For instance, --enable-rewrite and --enable-rewrite=shared can enable mod_rewrite statically or dynamically. Modules may now be specified in a list rather than individually with options such as --enable-modules="auth_dbm rewrite vhost_alias", which wasn’t possible in Apache 1.3. The --with-layout option has changed to an --enable option, --enable-layout.

--with and --without: Features within modules and outside the source itself are enabled or disabled with --with and --without options. This covers a range of Apache features such as the server user and group, which change from --server-uid and --server-gid to --with-server-uid and --with-server-gid. This includes the suExec options, apart from --enable-suexec itself, for example, with --suexec-caller becomes --with-suexec-caller. Modules that rely on external features now enable them with options such as --with-dbm, --with-expat, --with-ldap, and --with-ssl.

Exceptions are mostly restricted to options that control the build type and base locations. As a result, many options have been renamed to fit with this scheme, and a few have also changed in how they work—for the most part, they become more flexible in the process.

To make it easier to see how options differ between the old and new configuration styles, I’ll present the various ways in which you can configure Apache’s build process and give examples for both Apache 1.3 and Apache 2. As well as making it easier for those wanting to migrate to Apache 2, it’s also friendlier to administrators who want to stick with Apache 1.3 for now but have an eye to the future.

Also, Apache developers can retrieve the current development code base using CVS. Three modules are needed in total: httpd-2.0 (the server itself ), apr (the Apache Portable Runtime), and apr-util (APR support utilities). The following series of commands will retrieve the complete Apache 2 source tree and place it under /home/admin/ apache2:

$ cd /home/admin/apache2
$ CVSROOT=:pserver:anonymous@cvs.apache.org:/home/cvspublic $ export CVSROOT
$ cvs login
CVS password: anoncvs
$ cvs co httpd-2.0
$ cd httpd-2.0/srclib
$ cvs co apr
$ cvs co apr-util

The next step is to configure the configuration process itself. For this to work, you must have current versions of autoconf and libtool installed. Both are projects of the Free Software Foundation and are commonly available as a package for most platforms; see the autoconf home page at http://www.gnu.org/software/autoconf/ for detailed information. Assuming you do have autoconf and libtool,you now execute this:

$ cd httpd-2.0
$ ./buildconf

This should generate the configure script, which you can then use to actually configure the source code for building.

Curious administrators who don’t need to live quite so close to the cutting edge can also retrieve daily snapshots of the CVS source tree from http://cvs.apache.org/snapshots/. As with the CVS repository, you need the snapshots for httpd-2.0, apr, and apr-util.