Tuning and Customizing a Linux System

This section discusses the installation of the Apache HTTP Server from source code. Most Linux distributions contain a preconfigured version of Apache. However, Apache is a very sophisticated and complex product, and so it frequently happens that a user or an administrator needs a custom installation of Apache with options and functionality not included in the distribution's default configuration. In such cases, the administrator will have to build a custom Apache from source code, which is the topic of this section.

Apache really is a very complex product—so complex, in fact, that entire books have been written on it. There is no way that this section can pretend to be a comprehensive coverage of the Apache HTTP Server. Instead, this section has two less ambitious goals:

• Demonstrate a real-world installation of a highly complicated server

• Provide the basics of configuring Apache

Apache is one of the most sophisticated software packages around, and so in completing this chapter you will take a major step in your understanding of software installations.

Depending on your role and reason for reading this book, this chapter will probably be useful to you in one of two ways. Perhaps you're just an average user who doesn't have much more than a passing interest in Apache, or maybe you're a system administrator who may actually be responsible for a production deployment of Apache in a real web site. In the first case, reading this chapter will be a great academic tutorial on how to install a complex piece of software. In the second case, this chapter will be a good primer on Apache installation, but it probably isn't going to be comprehensive enough to bet your job on. If you need more information, you should definitely consult Apache's documentation at httpd.apache.org or get a copy of one of the excellent Apache reference books.

Compile-Time Options

Even though Apache is a very complex package, it is a straightforward GNU autoconf installation. Part Three of this book has already covered several other examples of autoconf installations, so by now this should be old hat. As with all autoconf installations, though, the devil is in the compile-time options. This section covers compile-time options for the Apache HTTP Server.

At the risk of being repetitive, remember that Apache is a very complicated product. A quick ./configure –help command shows that it has a very long list of compile-time options, and many of these are interrelated and even mutually exclusive. In other words, figuring out Apache's compile-time options can be a bear.

However, remember that the Apache developers are not out to make life needlessly complicated, and so all the options are actually necessary. Because of this, unfortunately, there's no easy way out, and there's no magic trick to configuring Apache. To install Apache, you have to understand its compile-time options, and the only way to do so is to consult the documentation for the software. Fortunately, Apache's documentation is outstanding and comprehensive; the web site at httpd.apache.org contains all there is to know about installing (and running) Apache, and a copy of the manual is actually included with the source code and installations.

That said, you can draw a few generalizations about the types of options that Apache supports. The remainder of this section discusses the following compiletime options:

• Installation directory

• Support for Dynamically Loadable Objects

• Selection of a Multi-Processing Module (MPM)

• Other important options

With these options, you can create a basic, reasonable Apache configuration. Almost any production environment will have to customize these options, but they'll be a good starting point. (Actually, the configuration as discussed will be very similar to Apache's default configuration, but it's worthwhile to see it broken down a little.)

Choosing an Installation Directory

As you've probably come to expect by now, the first step in installing a software package is to decide where to install it. In Chapter 7, two general options were discussed: the /usr/local directory and the /opt directory. The /usr/local directory is a good place to put software needed by many users that is upgraded infrequently, while /opt is a good place to put software that needs to be self-contained or that needs to be frequently or systematically updated.

The other example software installations covered by this book include samples of both possibilities; the OpenSSH package, for instance, is needed by many users and was installed into /usr/local. The Java environment (which is discussed later in this book) was installed into /opt/java, since it can be a fairly complicated package and it helps to have it organized into its own location.

So, where should Apache be installed? Well, the answer to that depends on the type of system that Apache's being installed on. If the target is an actual production machine, then chances are the system is going to be very closely monitored and upgrades are going to be done infrequently at best; in this case, you'll probably never need more than one copy installed at once, and it's probably just fine to install Apache into /usr/local. Most distributions that include Apache typically assume that the machine is going to be more or less a production server, or perhaps just someone's personal web server, and that upgrades can be handled via the package mechanism (such as RPM). Thus, most distributions install Apache into /usr; therefore, if you're installing a custom Apache from source code for such a system, you should probably use /usr/local.

There are other common use cases for Apache, though. For example, you might be a developer installing Apache on your desktop system. In this case, you might need to track the latest and greatest changes to Apache or have different copies installed, each with a different configuration. In this case, you probably want your Apache installation or installations to be more isolated, and so it's better to put them in a subdirectory of /opt; for example, /opt/apache. This is the case assumed by this book.

For the purposes of this chapter, then, the installation directory will be /opt/apache. To actually set this as a compile-time option via the ./configure program, you need to use the –prefix option; to wit, –prefix=/opt/apache. (If you think you'll need to upgrade frequently, another option would be to include the version number in the path, such as –prefix=/opt/apache-2.0.36 for Apache v2.0.36, and create /opt/apache as a symbolic link pointing to your version. This allows you to upgrade Apache more easily, by installing the new version separately and replacing the symbolic link after it's been tested.)

This section advises that "production" installations of Apache be installed into /usr/local and that "development" installations be installed into /opt. That's a good rule of thumb, but there's an additional issue—namely, where to install the actual data files, such as the content on the site that you're using Apache to run. This might actually depend on (or even be dictated by) what language or tools you use to develop your site, but typically there's at least one file that contains your site's contents. By default, Apache will create a directory called htdocs that is supposed to contain such data files, though you can easily change this in the run-time configuration.

However, this htdocs directory will be alongside the other Apache files and directories; for example, it might end up being /opt/apache/htdocs. This means that your data files will be "mixed in" with your program binary and configuration files. This is okay, but it might be a better idea to place your data files on a separate partition, or even disk, that can be easily backed up and restored in case of a hardware failure on your server. This can be done after the installation, of course—check out the "Configuring Apache" section for more information. Just remember to plan ahead!

Enabling Loadable Module Support

Apache has a vast amount of functionality, and this means that if it's all enabled at compile-time, the resulting run-time memory footprint will be very large. Most installations, meanwhile, won't need all that functionality and so it's really a waste of memory. This section discusses how to enable the loadable modules that Apache supports to address this issue.

Apache uses Dynamic Shared Objects (DSOs), which are also referred to as Apache modules or just modules. Each module is a file on disk that contains some specific functionality for the Apache server. For example, there are separate DSO modules for monitoring server status and for spell checking.

Normally, if you want the functionality from a specific module, you have to compile that module into the Apache installation. (For example, you have to compile Apache to include the spell-checking module if you want that functionality.) However, if you later change your mind, you can't get rid of that spell-checking support without recompiling Apache. You can always just leave it in and not use it, of course, but in that case it's wasting memory and perhaps processing time, and it might even be a security risk if an attacker figures out a way to exploit it. For these reasons, you generally don't want Apache to include modules that aren't being used, even if they sit idle.

Apache addresses this issue by allowing each module to be loaded dynamically when the server starts up. This way, removing support for a given module is as easy as editing Apache's configuration file to remove the line that loads the module and then restarting the Apache server process. For example, disabling that spell-checking module is as easy as commenting out or deleting a line in a file, and then the spell-checking module will not only be idle, it won't even be present.

Another major benefit of loadable modules is the inverse case, which is adding a module to include support that you didn't think of or didn't exist when you built Apache. Without DSO support, for example, if you actually did want spell-checking support but forgot to compile it in, you'd have to recompile Apache to get it. If you enabled DSO support, though, you can easily add the module later and turn it on by restarting the server. This technique is also useful for making use of third-party modules that aren't included with Apache proper: You can simply compile such third-party modules as DSOs and load them into Apache at run-time. The alternative without dynamically loadable modules would be to somehow cause Apache to compile these third-party files along with the standard Apache files. Apache actually does support this but it's somewhat more cumbersome, as you'll see later.

Actually using modules (i.e., compiling them, installing them, activating them in the configuration file, and so on) is discussed later in this section. The beauty of DSOs, after all, is that once you've built the core of Apache, you can add and remove modules later at your leisure. For now, all you have to do is enable support for DSOs within Apache. This is accomplished with two options: the –enable-mods-shared and –enable-so options.

The –enable-so option simply activates support for DSOs within Apache; however, it does not actually cause any specific modules to be build as DSOs. The –enable-mods-shared option to ./configure is the one that allows you to add or enable specific modules. For example, if you wanted to add that spell-checking module as a DSO, you would use –enable-mods-shared=mod_speling. However, there's also a convenience form you can use—namely, –enable-mods-share=all— that saves you the trouble of having to type out all the individual modules explicitly. This is the option used by this book, and its result is that all modules that can be enabled as DSOs are so enabled.

It can be argued that enabling DSOs with Apache is a security risk, and therefore, it should not be used on actual production systems. An attacker can conceivably cause Apache to dynamically load a DSO module designed to compromise the Apache server or the system itself. If DSO support is disabled, this would obviously be impossible.

This is a risk. However, in practice the risk is probably rather remote, and it's largely irrelevant anyway. After all, if an attacker can gain access to the file system on which Apache is installed (in order to place his own hostile module for Apache to load), then he can almost certainly do much more damage than just loading a module into Apache.

So, as security risks go, enabling Apache DSOs is quite small. However, it is a risk, and users and administrators always need to compare the risks against the potential impacts. Forewarned is forearmed!

Choosing an MPM

Some Apache modules cannot be loaded as DSOs. These include the core module, which contains things such as the capability to actually load the DSO modules, and the Multi-Processing Module (MPM) to be used for the installation. This section discusses the MPM options available for Apache.

An MPM is a module that handles connections to clients and governs how Apache behaves while fulfilling those clients' requests. Each MPM can use a different technique for this "multiprocessing", and each has a different performance profile. By allowing the MPM to be customized, Apache can use a different technique for each operating system it runs on, allowing the best possible performance on each platform. MPM functionality was added in Apache's 2.0 release.

Because the MPM being used is the foundation for the rest of Apache, the MPM cannot be built as a dynamically loadable module; it has to be hardcompiled into the core Apache program. In other words, once Apache has been compiled and installed, changing to a different MPM requires that Apache itself be recompiled.

Generally, the ./configure program can detect which operating system Apache is being compiled on and it selects the most appropriate MPM for that platform. Some platforms, however, support multiple MPMs from which you can choose. In these cases, the ./configure program selects a reasonable default MPM, which is usually the most stable one.

Switching to a different MPM is not a small matter, since it has major performance implications. If you want to use an alternate MPM, you should consult the Apache documentation on the subject. This section is here just to advise you of the presence of MPMs in Apache; the actual configuration used simply accepted the default MPM that Apache selected for the system. No custom MPM-related options were passed to ./configure.

Other Options

As I've mentioned repeatedly, Apache supports a very wide variety of compiletime options. Exhaustively covering these options is beyond the scope of this section, and indeed, exploring the features offered by Apache is a diversion of several hours just by itself. If you'd truly like to master Apache, you should consult the Apache documentation or another book. However, there are a few fairly common options that users frequently need, some of which are outlined in Table 11-1.

Completing the Installation

Now that you've selected the compile-time options, you can install Apache. This is a very straightforward example of a GNU autoconf installation, meaning that it consists of essentially three commands: ./configure with the appropriate arguments, make, and make install. Here's the actual ./configure command used for this example:

./configure --prefix=/opt/apache --enable-so --enable-mods-shared=all

After the ./configure command and the make commands have completed, Apache will be installed in the /opt/apache directory.

If you've read the other software installation examples in this book, you should be starting to see some patterns. By reading this section on Apache, you'll have seen a real-world installation of a pretty complicated software server.

You'll be able to apply many of the same techniques and modes of thought to installing any other server program, such as the OpenLDAP directory server or Samba file-and print-sharing server. Installing these things is pretty easy—you just read the documentation to find out what options you need, then run ./configure, make, and make install, and voila! You've got your software installed. Of course, even then the work will only be half done—it also has to be configured. That's the topic of the next section.