1.9.1. Apache Executables for Unix

The fairly painless business of compiling Apache, which is described later, can now be circumvented by downloading a precompiled binary for the Unix of your choice. When we went to press, the following operating systems (mostly versions of Unix) were suported, but check before you decide. (See http://httpd.apache.org/dist/httpd/binaries.)

aix	aux	beos	bs2000-osd	bsdi
darwin	dgux	digitalunix	freebsd	hpux
irix	linux	macosx	macosxserver	netbsd
netware	openbsd	os2	os390	osf1
qnx	reliantunix	rhapsody	sinix	solaris
sunos	unixware	win32

Although this route is easier, you do forfeit the opportunity to configure the modules of your Apache, and you lose the chance to carry out quite a complex Unix operation, which is in itself interesting and confidence-inspiring if you are not very familiar with this operating system.

1.9.2. Making Apache 1.3.X Under Unix

Download the most recent Apache source code from a suitable mirror site: a list can be found at http://www.apache.org/[11]. You will get a compressed file — with the extension .gz if it has been gzipped or .Z if it has been compressed. Most Unix software available on the Web (including the Apache source code) is zipped using gzip, a GNU compression tool.

[11]It is best to download it, so you get the latest version with all its bug fixes and security patches.

When expanded, the Apache .tar file creates a tree of subdirectories. Each new release does the same, so you need to create a directory on your FreeBSD machine where all this can live sensibly. We put all our source directories in /usr/src/apache. Go there, copy the <apachename>.tar.gz or <apachename>.tar.Z file, and uncompress the .Z version or gunzip (or gzip -d ) the .gz version:

uncompress <apachename>.tar.Z

or:

gzip -d <apachename>.tar.gz

Make sure that the resulting file is called <apachename>.tar, or tar may turn up its nose. If not, type:

mv <apachename> <apachename>.tar

Now unpack it:

% tar xvf <apachename>.tar

Incidentally, modern versions of tar will unzip as well:

% tar xvfz <apachename>.tar.gz

Keep the .tar file because you will need to start fresh to make the SSL version later on (see Chapter 11). The file will make itself a subdirectory, such as apache_1.3.14.

Under Red Hat Linux you install the .rpmfile and type:

rpm -i apache

Under Debian:

aptget install apache

The next task is to turn the source files you have just downloaded into the executable httpd. But before we can discuss that that, we need to talk about Apache modules.

1.9.3. Modules Under Unix

Apache can do a wide range of things, not all of which are needed on every web site. Those that are needed are often not all needed all the time. The more capability the executable, httpd, has, the bigger it is. Even though RAM is cheap, it isn't so cheap that the size of the executable has no effect. Apache handles user requests by starting up a new version of itself for each one that comes in. All the versions share the same static executable code, but each one has to have its own dynamic RAM. In most cases this is not much, but in some — as in mod_perl (see Chapter 17) — it can be huge.

The problem is handled by dividing Apache's functionality into modules and allowing the webmaster to choose which modules to include into the executable. A sensible choice can markedly reduce the size of the program.

There are two ways of doing this. One is to choose which modules you want and then to compile them in permanently. The other is to load them when Apache is run, using the Dynamic Shared Object (DSO) mechanism — which is somewhat like Dynamic Link Libraries (DLL) under Windows. In the two previous editions of this book, we deprecated DSO because:

• It was experimental and not very reliable.

• The underlying mechanism varies strongly from Unix to Unix so it was, to begin with, not available on many platforms.

However, things have moved on, the list of supported platforms is much longer, and the bugs have been ironed out. When we went to press, the following operating systems were supported:

Linux	SunOS	UnixWare
Darwin/Mac OS	FreeBSD	AIX
OpenStep/Mach	OpenBSD	IRIX
SCO	DYNIX/ptx	NetBSD
HPUX	ReliantUNIX	BSDI
Digital Unix	DGUX

Ultrix was entirely unsupported. If you use an operating system that is not mentioned here, consult the notes in INSTALL.

More reasons for using DSOs are:

• Web sites are also getting more complicated so they often positively need DSOs.

• Some distributions of Apache, like Red Hat's, are supplied without any compiled-in modules at all.

• Some useful packages, such as Tomcat (see Chapter 17), are only available as shared objects.

Having said all this, it is also true that using DSOs makes the novice webmaster's life more complicated than it need be. You need to create the DSOs at compile time and invoke them at runtime. The list of them clogs up the Config file (which is tricky enough to get right even when it is small), offers plenty of opportunity for typing mistakes, and, if you are using Apache v1.3.X, must be in the correct order (under Apache v2.0 the DSO list can be in any order).

Our advice on DSOs is not to use them unless:

• You have a precompiled version of Apache (e.g., from Red Hat) that only handles modules as DSOs.

• You need to invoke the DSO mechanism to use a package such as Tomcat (see Chapter 17).

• Your web site is so busy that executable size is really hurting performance. In practice, this is extremely unlikely, since the code is shared across all instances on every platform we know of.

If none of these apply, note that DSOs exist and leave them alone.

1.9.3.1. Compiled in modules

This method is simple. You select the modules you want, or take the default list in either of the following methods, and compile away. We will discuss this in detail here.

1.9.3.2. DSO modules

To create an Apache that can use the DSO mechanism as a specific shared object, the compile process has to create a detached chunk of executable code — the shared object. This will be a file like (in our layout) /usr/src/apache/apache_1.3.26/src/modules/standard/mod_alias.so.

If all the modules are defined to be DSOs, Apache ends up with only two compiled-in modules: core and mod_so. The first is the real Apache; the second handles DSO loading and running.

You can, of course, mix the two methods and have the standard modules compiled in with DSO for things like Tomcat.