There are many ways of installing this package; one of the features of open software like Apache is that anyone may make an installation kit. This allows vendors (such as Debian, FreeBSD, Red Hat, Mandrake, Hewlett-Packard, and so on) to customize the Apache file locations and default configuration settings so that these settings fit with the rest of their software. Unfortunately, one of the consequences of customization is that the various prepackaged installation kits are almost all different from one another.
In addition to installing it from a prepackaged kit, of which the variations are legion, there’s always the option of building and installing it from the source yourself. This has both advantages and disadvantages; on the one hand you know exactly what you installed and where you put it, but on the other hand, it’s likely that binary add-on packages will expect files to be in locations different than those you have chosen.
If setting up the web server is something you’re going to do once and never again, using a packaged solution prepared by your system vendor is probably the way to go. However, if you anticipate applying source patches, adding or removing modules, or just fiddling with the server in general, building it yourself from the ground up is probably the preferred method. (The authors of this book, being confirmed bit-twiddlers, always build from source.)
This chapter covers some of the more common prepackaged installation varieties and also how to build them from the source yourself.
Throughout the chapter, we assume that you will be using dynamic shared objects (DSOs) rather than building modules statically into the server. The DSO approach is highly recommended; it not only makes it easy to update individual modules without having to rebuild the entire server, but it also makes adding or removing modules from the server’s configuration a simple matter of editing the configuration file.
DSOs on Unixish systems typically have a .so extension; on Windows they end with a .dll suffix.
up2date -ui apache apache-devel apache-manual
If you’re running a more recent version:
up2date -ui httpd httpd-devel httpd-manual
If you aren’t a member of RHN, you can still download the packages from one of Red Hat’s servers (either ftp://ftp.redhat.com/ or ftp://updates.redhat.com/), and install it with the following command:
rpm -Uvh apache
-Uvh option to the rpm
command tells it to:
Upgrade any existing version of the package already on the system or install it for the first time if it isn’t.
Explain the process, so you can receive positive feedback that the installation is proceeding smoothly.
Display a pretty line of octothorpes (
the screen, marking the progress of the installation.
If you use the packages Red Hat maintains for its own platform, you will benefit from a simple and relatively standard installation. However, you can only update versions that Red Hat has put together an RPM package for, which typically means that you may be lagging weeks to months behind the latest stable version.
There is also the issue of platform compatibility; for instance, at some point the version of Apache provided for Red Hat Linux changed from 1.3 to 2.0, and newer versions of the operating system will probably only have the 2.0 packages available. Similarly, if you run an older version of Red Hat Linux, the newer packages will probably not install properly on your system.
It’s a good idea to install the apache-devel package as well. It’s quite small, so it won’t have much impact on your disk usage; however, it includes files and features that a lot of third-party modules will need to install properly.
If you already have Apache installed on your Windows system, remove it before installing a new version. Failure to do this results in unpredictable behavior. See Recipe 1.7.
Primarily, Windows is a graphically oriented environment, so the Apache install for Windows is correspondingly graphical in nature.
The simplest way to install Apache is to download and execute the Microsoft Software Installer (MSI) package from the Apache web site at http://httpd.apache.org/download. The following screenshots come from an actual installation made using this method.
Each step of the installation process is distinct in the process and you can revise earlier decisions, until the files are installed. The first screen (Figure 1-1) simply confirms what you’re about to do and the version of the package you’re installing.
The second screen (Figure 1-2) presents the Apache license. Its basic tenets boil down to the following: do what you want with the software, don’t use the Apache marks (trademarks like the feather or the name Apache) without permission, and provide proper attribution for anything you build based on Apache software. (This only applies if you plan to distribute your package; if you use it strictly on an internal network, this isn’t required.) You can’t proceed past this screen until you agree to the license terms.
Figure 1-3 shows the recommended reading for all new users of the Apache software. This describes special actions you should take, such as making configuration changes to close security exposures, so read it closely.
If you are installing Apache for the first time, the installation process asks for some information so it can make an initial configuration for your server (Figure 1-4). If you already have a version of Apache installed, anything you enter on this screen will not override your existing configuration.
The Server Name in the figure is filled with the same value as the Network Domain field; this is a nod to the growing tendency to omit the “www” prefix of web sites and use the domain name (e.g., http://oreilly.com/ instead of http://www.oreilly.com/). What name you specify for the server is just advisory, allowing the installation process to configure some initial values; you can change them later by editing the configuration file. The important thing is that the Server Name value be resolvable into an IP address.
Next comes a screen asking what portions of the package you want to install, as shown in Figure 1-5. Just go with Complete unless you’re an advanced user. The Custom option allows you to choose whether to install the Apache documentation.
Figure 1-6 asks where you want the software installed. The screen shot shows the default location, which will become the ServerRoot.
Once you’ve answered all the questions, a screen similar to Figure 1-7 will come up. This is your last chance to go back and change anything; once you click the Install button on this screen, the installation puts the pieces of the package in place on your system.
Figure 1-8 and Figure 1-9 show the last screens for the Windows MSI install; they show the progress of the installation. When they’re finished, Apache has been installed (and started, if you have chosen the Start as a service option shown in Figure 1-4).
A lot of effort has been put into making the Apache server run well on Windows and be managed like other Windows applications. As a consequence, the primary installation method (InstallShield or MSI) should be familiar to Windows users.
If you’ve never run Apache before, accept the defaults the first time you install it. This makes it easier for others to provide assistance if you need help, because the files will be in predictable locations.
If you chose to start the Apache server as a service (see Figure 1-4), then you can modify the conditions for it to start, such as the user it should run as or whether it should start automatically, just as you would any other service. Figure 1-10 shows one way to do this; bring up the window by right-clicking on the My Computer icon on the desktop and choose Manage from the pop-up menu.
You want to build the Apache web server yourself from the sources directly (see Recipe 1.4), but don’t know how to obtain them.
There are a number of ways to obtain the sources. You can access the latest version in close to real-time by using CVS, the tool used by the Apache developers for source control, you can download a release tarball, or you can install a source package prepared by a distributor, among others.
From a prepackaged tarball, download the tarball from http://httpd.apache.org/dist/, and then:
If your version of
z option for processing zipped
archives, use this command instead:
gunzip -c <
apache_1.3.27.tar.gz| tar xvf -
From the very latest up-to-the-minute Apache 1.3 source repository (not guaranteed to be completely functional), use:
cvs -d :pserver:anoncvs@CVS.Apache.Org:/home/cvspublic loginPassword:
cvs -d :pserver:anoncvs@CVS.Apache.Org:/home/cvspublic checkout apache-1.3
You can fetch a particular release version instead of the bleeding edge code if you know the name the developers gave it. For example, this will pull the sources of the 1.3.27 release, which is expected to be stable, unlike the up-to-the-minute version:
cvs -d :pserver:anoncvs@CVS.Apache.Org:/home/cvspublic checkout -r APACHE_1_3_27 apache-1.3
From the very latest up-to-the-minute Apache 2.0 source repository (not guaranteed to be completely functional), use:
cvs -d :pserver:anoncvs@CVS.Apache.Org:/home/cvspublic loginPassword:
cvs -d :pserver:anoncvs@CVS.Apache.Org:/home/cvspublic checkout -r APACHE_2_0_BRANCH httpd-2.0%
cvs checkout apr apr-util
As with the method for the 1.3 version of the server, you can fetch a particular release of the 2.0 code if you know the name assigned to it in CVS.
You can find the names of the tags used in the source tree by visiting either http://cvs.apache.org/viewcvs.cgi/apache-1.3/ or http://cvs.apache.org/viewcvs.cgi/httpd-2.0/ and pulling down the Show files using tag list at the bottom of the page.
No matter how you install the source, the directory tree will be ready for configuration and building. Once the source is in place, you should be able to move directly to building the package (see Recipe 1.4).
If you chose to install the sources using the CVS method, you can keep your sources up-to-date by simply executing the following command from the top level of the source directory:
cvs update -Pd
This will update or fetch any files that have been changed or added by the developers since the last time you downloaded or updated.
If you update to the latest version of the sources, you’re getting whatever the developers are currently working on, which may be only partially finished. If you want reliability, stick with the released versions, which have been extensively tested.
Assuming that you already have the Apache source tree, whether you installed it from a tarball, CVS, or some distribution package, the following commands, executed in the top directory of the tree, builds the server package with most of the standard modules as DSOs:
/usr/local/apache--with-layout=Apache --enable-shared=max--enable-module=most %
For Apache 2.0:
/usr/local/apache--with-layout=Apache --enable- modules=most --enable-mods-shared=all %
If you want more detailed information about the various options and their meanings, you can use the following command:
Building the server from the sources can be complex and time-consuming, but it’s required if you intend to make any changes to the source code. It gives you much more control over things, such as the use of shareable object libraries and the database routines available to modules. Building from source is also de rigeur if you’re developing your own Apache modules.
The options to the configure script are many and varied; if you haven’t used it before to build Apache, locate some online tutorials (such as those at http://Apache-Server.Com/tutorials/ or http://httpd.apache.org/docs-2.0/install.html) when you want to change the defaults. The default options generally produce a working server, although the filesystem locations and module choices may not be what you’d like; they may include modules you don’t want or omit some you do. (See Chapter 2 for some examples.)
Download ApacheToolbox from http://www.apachetoolbox.com/. (Note that the version numbers will probably be different than these, which were the latest available when this section was written.) Unpack the file:
(Depending on your version of
tar, you may be able
to combine these operations into a single tar
Then run the installation script:
ApacheToolbox is developed and maintained by Bryan Andrews. It is a shell script that assists in the configuration and installation of Apache. It includes support for over 100 commonly used or standard modules.
When you run the script, you select modules from lists appearing on various screens. Once you have decided on your list of modules, ApacheToolbox downloads the third-party modules you have selected and the tools that you don’t have installed, and then runs the Apache configure script with any arguments needed to create the combination you have requested.
The main screen (see Figure 1-11) lists the most popular third-party modules that ApacheToolbox can install. Select or deselect a particular module by typing the number next to that module’s name.
apache moves you to the second screen
(see Figure 1-12), which lists the standard Apache
modules. Add or remove individual modules by typing the number next
to their module names.
You can choose options for configuring the modules on additional menus, and you can build an RPM on your installation configuration, which you can then install on multiple machines without requiring that ApacheToolbox be installed.
Once you have made all your module selections, type
go to tell ApacheToolbox to start the
Your preferences are saved to a file (etc/config.cache) so that if you want to reinstall Apache with the same configuration, you merely need to run ApacheToolbox again, and it will start up with the selections from the last run. To upgrade to a new version of Apache, get the latest version of ApacheToolbox, and ask it to run the installation script with your last selections (without going through the menu process), by typing the following commands:
Once ApacheToolbox has completed its work, you can edit the configuration script to insert or modify arguments. Once you are satisfied and ApacheToolbox has run the configuration script, go into the Apache source subdirectory and run make and make install to compile and install Apache:
The basic Apache package includes tools to make it easy to control the server. For Unixish systems, this is usually a script called apachectl , but prepackaged distributions may replace or rename it. It can only perform one action at a time, and the action is specified by the argument on the command line. The options of interest are:
This will start the server if it isn’t already running. If it is running, this option has no effect and may produce a warning message.
This option causes the server to reload its configuration files and gracefully restart its operation. Any current connections in progress are allowed to complete. The server will be started if it isn’t running.
Like the graceful option, this one makes the server reload its configuration files. However, existing connections are terminated immediately. If the server isn’t running, this command will try to start it.
This shuts the server down immediately. Any existing connections are terminated at once.
For Windows, the MSI installation of Apache includes menu items for controlling the server, as shown in Figure 1-13.
Both of the solutions shown (for Unixish and Windows systems) illustrate the basic server control operations: start, stop, and restart. The purpose of the start and stop functions should be self-evident. Any time you modify the server-wide configuration files (such as httpd.conf), you must restart the server for the changes to take effect.
On Red Hat Linux, to remove an Apache version installed with the RPM tool, use:
rpm -ev apache
Other packaging systems may provide some similar mechanism.
On Windows, Apache can be typically removed like any other MSI-installed software (see Figure 1-14).
Unfortunately, there is no generic works-for-all removal method for Apache installations on Unixish systems. Some packages, such as Red Hat’s RPM, do remember what they installed so they can remove all the pieces, as shown in the solution. However, if the software was installed by building from the sources (see Recipe 1.4), the burden of knowing where files were put rests with the person who did the build and install. The same applies if the software was installed from source on a Windows system; it’s only the MSI or InstallShield packages that make the appropriate connections to allow the use of the Add/Remove Software control panel.