IN THIS CHAPTER
Everything that Mr. Smallweed's grandfather ever put away in his mind was a grub at first, and is a grub at last. In all his life he has never bred a single butterfly. | ||
| --Bleak House—Charles Dickens | ||
Apache is an Open Source product. This means that the source code is freely available for you to download and tinker with. This also means that most people will install Apache by downloading that source and compiling Apache their own particular way. This chapter walks you through that process. By the end of this chapter, you should have Apache installed and ready to start using.
For those of you who want to get something installed immediately, and don't care about all the details, this is for you. This is labeled “Overview for the Impatient” in the INSTALL file that comes with Apache. After you have unpacked the archive file, do the following:
./configure —prefix=PREFIX make make install PREFIX/bin/apachectl start
There, you're done. Note that PREFIX should be replaced with the base directory under which you want everything else installed. For example, throughout this book we will be making the assumption most of the time that you have installed Apache in the directory /usr/local/apache, so in the above code example you would use the commands:
./configure —prefix=/usr/local/apache make make install /usr/local/apache/bin apachectl start
OK, now some of the details.
The Apache Software Foundation (ASF) Web site is http://www.apache.org/. The part of the Web site specific to the Apache Web server is http://httpd.apache.org/. The Web site contains comprehensive documentation about the server software, information about the ASF, and, of course, the software itself.
Additionally, there are a number of mirrors around the world, so you can usually find a server that is near to you, particularly if you live outside of the United States. To find the mirror closest to you, go to http://www.apache.org/dyn/closer.cgi, which will dynamically figure out your closest mirror and send you there. After you click the Download link, you'll find yourself in the directory of downloadable files, http://httpd.apache.org/dist/httpd/, where you can select a file to download. Which file you choose depends on what format you're most comfortable with, and what version you want. Several versions are usually available for download—usually the most recent, and one or two versions back, in each of the various branches that are currently being supported. At the time of this writing, for example, 1.3.19, 1.3.20, and 1.3.22 are available for the 1.3 branch, whereas 2.0.16 and 2.0.18 are available for the 2.0 branch.
For each version there are usually six different files. The software is available in three different compression formats, and a .asc file accompanies each format, which is a PGP signature that verifies the authenticity of the file.
The three compression formats are .tar.Z (compressed tar archive), .tar.gz (gzipped tar archive), and .zip (pkzipped or Windows zip). The different compression formats are purely for the convenience of people that like the different formats, or might be more familiar with tools for extracting a particular format. All of the files contain the identical contents.
If you're not sure what you want, you should get the file labeled Current release in whatever compression format you're familiar with.
The .asc files enable you to verify that the files you are downloading are actually the same files that the Apache developers put on the site for you to download, and have not been tampered with by a third party. This is particularly important if you are downloading the files from a mirror of the Apache site, rather than the main download site.
You can check the validity of the signature files using PGP, which you can acquire at http://web.mit.edu/network/pgp.html. If the signature on the file matches, then you can be certain that the file has not been tampered with.
The method used to extract the archive will, of course, depend on which compression format you download.
Move the archive to a convenient location for unpacking. /usr/local/src is a good place.[1]
To extract a .tar.Z file, type the following command:[2]
tar -vZxf httpd-2_0_xx.tar.Z
To extract a .tar.gz file, type the following command:
tar -vzxf httpd-2_0_xx.tar.gz
Or, if you are using a version of tar that does not accept the -z argument, try:
gunzip < httpd-2_0_xx.tar.gz | tar -zx
To extract a .zip file, type the following command:
unzip httpd-2_0_xx.zip
Or, if you are uncompressing this file on a platform other than Unix, there are a variety of decompression utilities available, such as WinZip, which simplify the process of extracting compressed files.
After you have unpacked the source code, a directory listing will show you several files in the top-level directory—most of them documentation—and several subdirectories. Although it is not essential that you know everything about the source code to be a good system administrator, it's a good idea to understand something about the code that you're installing on your server.
There are six subdirectories created when you unpack the source archive.
The cgi-bin directory contains two very simple CGI programs, one in shell, and the other in Perl. They both perform the same function—displaying the contents of your CGI environment. They are not particularly useful, but we'll refer to them again when we get to the chapter on CGI (15). A number of other CGI programs used to be distributed with Apache, but most were removed because of security concerns. If everyone on the planet knows what CGI programs are preinstalled on a default installation of Apache it gives them an upper hand when trying to compromise your server through Apache.
The conf directory contains the default configuration files that will be installed on your server. During the configuration process variables in this file will be filled in with values that you provide to the configure script, or with default values if none are provided. These configuration files enable you to get a default Apache installation up and running in just a few minutes.
See Chapter 4 “Configuration Directives,” for more information on these configuration files.
htdocs contains a default index page for the server, with the Apache logo and some text explaining that this is a new installation of the server, and providing links to the ASF Web site for more information about the Apache server. This page is available in a number of languages and a variety of character sets. Apache's content negotiation ensures that (correctly configured) browsers will get the document in their own language.
The htdocs directory also contains the Apache users' manual in a subdirectory called manual, which contains exhaustive documentation on the server, as well as a number of “how to” style tutorials on a variety of topics. You need to be aware that although the documentation contained in this directory was the best thing available when that version of Apache was released, the Apache documentation gets updated almost on a daily basis, and the online docs (at http://httpd.apache.org/docs-project/) will be more up-to-date than what you have installed.
icons contains a number of images that are used in directory listings and other automatically generated documents, as well as some you can use for your own documents.
The logs directory is empty. This is where your log files will be put when you start up your server.
The most fun, of course, is in the src directory. src contains the source code for the server. This directory is subdivided into a number of subdirectories, but we won't talk about them all right now. If you are going to hack on the Apache server code, it is in this directory that you will be working. However, modifying the Apache server code is beyond the scope of this book.
Later in the book we'll talk more about modules (Chapter 26, “Modules Included with Apache”) and at that time we'll refer to the modules directory inside src.
Before we proceed with what happens next, we need to address binary distributions. If you are using some non-Unix operating system, such as Windows, Mac OS, or OS/2, it is very likely that you don't have a compiler installed, or even available to you. Outside of the Unix world, a compiler is typically a software package that you'll have to pay a good amount of money for, therefore, relatively few people are going to have them.
For these folks, the ASF provides binary distributions, which means that someone else has gone to the trouble of compiling the source code for you, and all you have to do is download the files and install them on your system.
Binaries are provided for an impressive list of platforms. Most of them are there either because compilers for those platforms are expensive or difficult to use. Some are just there for the convenience of people who don't want to spend the time building it themselves. In any case, the user will just need to download the package, and run the installation program, to have a fully functional installation of Apache server.
On Windows, the provided installation file is a familiar InstallShield file, which will ask you for some information such as where you want to install the server. It will then place the various files for you.
If you are installing on an NT operating system[3] you will further want to install Apache as a service, which can be done by selecting “Install as a service” from the Start menu.
See Chapter 12, “Apache on Microsoft Windows,” for more detail on installing Apache on Windows.
Some folks will wonder why they would want to go to all the trouble to build their own installation when someone has already provided binary installations for their specific operating system. There are a number of reasons that you might want to build it yourself. Some of them are philosophical, but most of them are very pragmatic.
The spirit of the Open Source movement is that you have the source code, and can do whatever you want with it. This necessitates, in many cases, a large degree of understanding of what's going on behind the scenes, even to the point of hacking on the source code to get it to work. As more and more Open Source projects spring up, and as the quality of the source code improves, it becomes less and less necessary to work directly with the source code. This is definitely a good thing. But, for the present at least, it has left behind it a strong sentiment that to be a responsible system administrator, you should really understand the code that you are running on your system. Security reasons are hidden somewhere in there—someone could hide something malicious in code that you blindly install on your servers—but most of it is a philosophical belief that as a system admin, you should know as much as possible about what is on your servers.
Although I personally believe these sentiments, it might ring a little hollow to the sysadmin who has about 12 free minutes on a good day, and really doesn't have the time to mess with the source code of everything she installs. If it works, that's sufficient.
However, a number of more practical reasons exist to build Apache from source yourself.
If you install binaries, you trust someone else to make the decisions about what the best configuration is for your server. Although this person has tried to make those decisions in the best interests of the majority of installations, he did not know the particulars of your server—what sort of load it will be under, what sort of content it will be serving, or what expectations your users have about performance. And, necessarily, when trying to make everyone happy, decisions are made that are not the best for everyone.
By building the source yourself, you can make decisions in the configure process that will accurately reflect how you want your servers to work. During the configure process, you can decide where files are put, what modules are installed and which ones are left off, and a variety of other things. This way, Apache is built in such a way that is most fitted to your system, the way that you work, and what you expect the server to do. It won't leave out modules that you will want, and perhaps as importantly, it will not be weighted down by a bunch of modules that you will never use.
The next step in the installation process, if you have chosen to install from source, is to configure the build process. This is done with a script called configure, which is in the main directory where you unpacked the source archive file. configure enables you to specify a large number of options about how your server will be compiled and installed.[4]
To run the configure program, change into the directory where the archive has been unpacked, and type
./configure
Running configure without any arguments at all causes it to get ready for a default installation, taking all the default arguments to all options.
Upon typing this command, you'll see a large number of messages scroll by that will say “checking for,” “checking if,” and “checking whether” various things are available, installed, or working. You'll then see a lot of messages stating that it is creating various files for your particular configuration. This means that by the time you get around to compiling the code, it already knows all about your system, and it can do the right thing for your particular situation.
However, it will also make a lot of decisions for you that you might want to make for yourself.
By typing ./configure —help, you can see a complete list of the things that you are able to configure. Most of them you'll just want to leave as the default, and in each case the default is specified in square brackets [].
Rather than wasting two pages reproducing this here, I encourage you to run this command on your own system while you read along, so that you can see what we're talking about. Or, you can look in Appendix B, “configure Command-Line Options,” for the complete listing.
Configuration options are divided into four main sections: configuration options, directory and filenames, host type, and features and packages.
The Configuration options are those that affect the configuration itself, and apart from the —help option, it is probable that you will not want any of these options, at least the first few times you build Apache.
These options enable you to do things such as suppress the rather verbose output of the configuration process; run the configuration, but not create any of the resultant files after it is done; and cache the test results (where it is checking for various files and utilities) in a cache file for later use.
The next set of options deals with directories and filenames. The bulk of this is specifying where particular files are put. In a default installation, all the files are put in /usr/local/apache, but you can change this, and you can change where particular parts of the installation are put.
Some people have very strongly held beliefs that certain files should go in certain places, regardless of their origin. For example, these people would hold that configuration files should go in /etc, log files in /var/log, and man files (documentation) in /usr/man or /var/man.
Other people feel that one application (such as Apache) should keep all its files in one place, so that they can be easily located.
This portion of the configuration process is there to keep everyone happy. Although the default is to keep everything together by specifying such arguments as —prefix (The directory which, by default, everything else will go under), —bindir (where the compiled binary executables will be placed), and —mandir (where the man pages will be placed), you can specify where each type of files in the installation will be placed.
You are unlikely to have to change these options in a normal installation. They enable you to specify a few options about the host on which you are building Apache. If you do not specify these options, the configure process will automatically look up your hostname and type, and fill in these values for you.
This is where things get really interesting. In this portion of the configuration you can specify which packages get installed, what features are enabled or disabled, and a variety of other options.
The most commonly used aspect of this section is turning various modules on or off, so they are built into the server, or not. Once again, see Appendix B for the complete list of modules that you can enable or disable in this step.
Note again that if you don't specify any options, Apache will be built with a sensible default list of modules, or some definition of sensible, and with files in some sensible place, so you can run a normal Web site without too much difficulty. Consequently, the first few times you build Apache, at least until you think you have a good idea of what is happening, it is recommended that you accept the defaults to learn the ropes.
The technique for a default installation is covered at the beginning of the chapter in the “Overview for the Impatient.”
The final step of this process is very simple. You type the following command:
make && make install
And then you wait. This can take a while, but the time will vary depending on your processor, the amount of memory you have, and what you consider to be a long time.
During this time, the C source code that comprises the Apache server will be compiled into executable binary files, which it will then put in the locations that you specified during the configuration process.
These are actually two commands. make does the compilation, and make install puts the various files in their correct locations. The && between the two commands means that upon the completion of the first command it should proceed immediately to the second. If there is a problem of some kind during the build process, execution will be aborted, and the installation process will not be run.
If you want to see where the installation will put all the various files, type the following:
./configure —show-layout
This will show you a full listing of the various directories that the installation will create and put things into:
root@rhiannon:/usr/src/apache_1.3.17# ./configure —show-layout
Configuring for Apache, Version 1.3.17
+ using installation path layout: Apache (config.layout)
Installation paths:
prefix: /usr/local/apache
exec_prefix: /usr/local/apache
bindir: /usr/local/apache/bin
sbindir: /usr/local/apache/bin
libexecdir: /usr/local/apache/libexec
mandir: /usr/local/apache/man
sysconfdir: /usr/local/apache/conf
datadir: /usr/local/apache
iconsdir: /usr/local/apache/icons
htdocsdir: /usr/local/apache/htdocs
cgidir: /usr/local/apache/cgi-bin
includedir: /usr/local/apache/include
localstatedir: /usr/local/apache
runtimedir: /usr/local/apache/logs
logfiledir: /usr/local/apache/logs
proxycachedir: /usr/local/apache/proxy
Compilation paths:
HTTPD_ROOT: /usr/local/apache
SHARED_CORE_DIR: /usr/local/apache/libexec
DEFAULT_PIDLOG: logs/httpd.pid
DEFAULT_SCOREBOARD: logs/httpd.scoreboard
DEFAULT_LOCKFILE: logs/httpd.lock
DEFAULT_XFERLOG: logs/access_log
DEFAULT_ERRORLOG: logs/error_log
TYPES_CONFIG_FILE: conf/mime.types
SERVER_CONFIG_FILE: conf/httpd.conf
ACCESS_CONFIG_FILE: conf/access.conf
RESOURCE_CONFIG_FILE: conf/srm.conf
This option is not available in Apache 2.0 as of this writing.
By this point, you should have Apache successfully installed. It's OK if you have done a default installation the first time through. You can move on with that for a while, and then when you understand things better, you can come back to this chapter and customize your installation a little more.
[1] You don't have to move the archive if you don't want to. Just change to the directory where you want to unpack the file, and provide the full path to the file when you type the following commands.
[2] In each of these command lines, xx will be replaced with the particular version of the code you have downloaded.
[3] “NT” is used here, and throughout the book, to refer to Microsoft's server operating systems, including NT and Windows 2000. The desktop operating systems are referred to generically as “Win9x”, which includes Windows 95, Windows 98, and Windows ME.
[4] Please note, going into this section, that there is another way to configure your installation, with the deceptively similar name of Configure (uppercase C, rather than lowercase c), which does much the same thing, in much the same way. This might seems a little silly, but there are some historical reasons that we'll touch on very briefly later.