You can get the latest stable source code from the Apache download site at http://httpd.apache.org/download.cgi. This page will point you to a mirror site that changes constantly. You can choose from a tarball, called httpd-<version-number>.tar, compressed with either gzip or bzip2. These archives are a few megabytes each and should not take too long to download, even with a dial-up connection.

After the download is complete, you should extract the archive into a safe temporary directory, such as /tmp. The archive creates a new httpd_<version-number> directory to store its files. This directory will contain a README, a LICENSE, and an INSTALL file.

The README file lists introductory information about the httpd server itself, where to find the latest version and documentation, acknowledgements, and whom to contact if you want to become involved or report a bug. The LICENSE file enumerates the terms and conditions for use and redistribution of the server software. The INSTALL file gives a quick overview at the installation process. Be sure to check out these files before attempting to build Apache.

Apache relies heavily on the use of autoconf and libtool, and although you could compile Apache the old-fashioned way by editing Makefile templates, you’ll find it easier to use the configure script that comes in the tarball. To do this, open a shell (as a regular user), change directories to the location of the extracted tarball (that is, /tmp/httpd_<version-number> if you’re following along), and then type the following command:

./configure --help

The script will output a list of configuration options you can use to fine-tune the compile process and Apache’s setup. After you’ve read through the list and determined which options best suit you, run the configure script again:

./configure --prefix=/usr/local/httpd2 --with-mpm=prefork --enable-so //
     --enable-rewrite

The files will be placed in /usr/include/apache2 by default when the compiled httpd is installed, so you may want to specify a different directory using the prefix option as I did earlier. Keeping Apache’s binary, scripts, configuration files, and modules all together is a good idea and makes things easier if you later need to upgrade or remove the server.

The configure script generates the necessary Makefile to compile the server. Type make to begin compiling the source code. After the code has been compiled, log in as the SuperUser and type make install to complete the installation and install the files under the directory you specified with configure’s prefix option.

You can now configure your server. See the “Runtime Server Configuration Settings” section later in this chapter for ways to do that.

Most important Apache settings can be configured in /etc/sysconfig, but some must be edited in Apache’s own configuration file, /etc/Apache2/httpd.conf. Consult the Apache documentation for a listing of all the settings, also called directives, but you should consider changing the following defaults:

Apache lets you restrict access to your site based on IP addresses or hostnames. This is done through directives in httpd.conf called allow and deny.

Suppose you plan to host an apt package repository at susefan.com/pub/, but you don’t want anyone outside of susefan.com downloading its files with a browser. You would add these lines to httpd.conf:

<Location /pub>
    SetHandler pub
    Order deny, allow
    Deny from all
    Allow from susefan.com
</Location>

Note the four statements. First, we told Apache that when someone tries to access the /pub directory, it needs to check whether the person is allowed. Then we set the order for Apache to check—first process the deny statements and then the allow statements. In this case, the statements are easy to follow: Deny everyone, unless the request originates from a host within the susefan.com domain.

You can describe your limits for either deny or allow in six ways:

Many organizations have a members-only section of their website where information is stored that the rest of the world can’t access. To see the information in such a restricted area, users must prove they are authorized to do so, usually by providing a username and password.

Apache Basic Authentication is the most common authentication method used, probably because it is quite straightforward in its approach. When someone attempts to access a protected page, Apache asks for a username and a password. It then verifies the username and password and if successful, Apache serves the request.

The first step in implementing Basic Authentication is to create a plain-text list of usernames and passwords. This is done using htpasswd2, a script included with the Apache2 package and installed to the same directory as httpd and apachectl. You should store these passwords away from your main Apache installation directory, making it harder for rogue applications to find them, so make a new directory (as the SuperUser) to hold this file, such as /usr/local/httpd2/passwd first.

When you have created this directory, type this command to create a new hidden password file, with the first user included:

./htpasswd -c /usr/local/httpd2/passwd/.htpasswd mikemc

You’ll be prompted twice for this user’s password:

New password:
Re-type new password:
Adding password for user mikemc

To add new users to this file, use the same command without the -c switch (that creates a new file):

./htpasswd /usr/local/httpd2/passwd/.htpasswd newuser

Next, you need to tell Apache to refer to .htpasswd when serving a protected page. You do this in one of two ways: directly through httpd.conf or by creating a new .htaccess file. The .htaccess file should be located in the directory you want to protect; in the example used in the allow/deny section, this would be /pub/.htaccess. In httpd.conf, you would create a new section labeled <Directory /pub>. Either way, the syntax is the same. Use these four directives:

AuthType Basic
AuthName "Members Only"
AuthUserFile /usr/local/httpd2/passwd/.htpasswd
Require user mikemc

Here the AuthType is Basic because we’re using Basic Authentication (the option would be set to Digest if mod_auth-digest was used). The AuthName can be anything and identifies the “realm” or category of that page. In this case, all pages with the AuthName Members Only would have the same password. Thus, when the browser went to another page marked Members Only, it could deliver the same password without forcing the user to retype it in an endless series of pop-up dialog boxes. The AuthUserFile points to the .htpasswd file containing the usernames and passwords. The Require directive specifies the user(s) allowed to access the page.

If, instead of one person having access to a resource, you want to create a group of users with the same level of access, create a group file named .htgroup in any text editor with the Group Name and a list of users. Save it in the same directory as .htpasswd. The entry in .htgroup file should look like this:

Members: mikemc robsh ltorvalds svillinski

The concept of the two files are similar to Linux’s /etc/passwd and /etc/group files; .htpasswd stores each username and password hash, and .htgroup aggregates usernames into logical groups. Each group member needs to have a password listed in .htpasswd before access is allowed.

Now edit your .htaccess file so that your group has access.

AuthType Basic
AuthName "Members Only"
AuthUserFile /usr/local/httpd2/passwd/.htpasswd
AuthGroupFile /usr/local/httpd2/passwd/.htgroups
Require group Members

Everyone in the Members group would now have access to all pages with the “Members Only” realm.

According to the HTTP/1.1 specification, when a client seeks out a document from a server, it includes the expected domain in its request. Although various domains may resolve to the same IP address with a DNS query, the domain names in the HTTP requests will still be different. This is the basic principle of name-based virtual hosting.

This type of virtual hosting (also known as vhosting) is the easiest and most popular way to handle hosting multiple domains. With this method, you need only one IP address to host several domain names. Apache receives a request, examines it to identify the desired domain, and obliges with the proper page.

You’ll need to add VirtualHost sections in the configuration file for each domain name after the NameVirtualHost directive. For example, if you want to host a personal site at www.YourName.com and a second site, www.susefan.com, this is how you would enter them in httpd.conf:

<VirtualHost *>
    ServerName www.YourName.com
    DocumentRoot /srv/www/htdocs/YourName.com
    ServerAdmin [email protected]
    ErrorLog /var/log/apache2/www.YourName.com-error_log
    CustomLog /var/log/apache2/www.YourName.com-access_log common
</VirtualHost>

<VirtualHost *>
    ServerName www.susefan.com
    DocumentRoot /srv/www/htdocs/susefan.com
    ServerAdmin [email protected]
    ScriptAlias /srv/www/htdocs/susefan.com/cgi-bin
    ErrorLog /var/log/apache2/www.susefan.com-error_log
    CustomLog /var/log/apache2/www.susefan.com-access_log common
</VirtualHost>

As the server receives the request, it will scan through the configuration file seeking a virtual host entry’s ServerName or ServerAlias directive that matches the expected domain. If no matching entry can be found, the first virtual host is used. The virtual host first inherits the directives set earlier in the httpd.conf file and then overrides those explicitly set for the host.

In the preceding example, www.YourName.com will use whatever ScriptAlias value is defined in the base configuration, whereas www.susefan.com will use /srv/www/htdocs/susefan.com/cgi-bin.

Hosting multiple IP addresses is a little more complex than hosting multiple names, but it is more widely supported. All but a very few ancient browsers (that is, those browsers that support only HTTP/1.0) support name-based vhosts, but if you want to be universal, this is the way to go.

Setting up IP-based vhosting is a two-step process. First, you must identify the addresses to use. As the SuperUser, run ifconfig to find the Internet address (listed here as inet addr) attached to eth0, your Ethernet connection. It should show up similar to the following:

inet addr:172.26.1.33

Then use ifconfig to bind more addresses to the network interface:

/sbin/ifconfig eth0:0 172.26.1.40
/sbin/ifconfig eth0:1 172.16.1.41

Now you can enter the same VirtualHost statements in httpd.conf as you did when using names, with only the VirtualHost statement changed:

<VirtualHost 172.26.1.40>
    ServerName www.YourName.com
    DocumentRoot /srv/www/htdocs/YourName.com
    ServerAdmin [email protected]
    ErrorLog /var/log/apache2/www.YourName.com-error_log
    CustomLog /var/log/apache2/www.YourName.com-access_log common
</VirtualHost>

<VirtualHost 172.26.1.41>
    ServerName www.susefan.com
    DocumentRoot /srv/www/htdocs/susefan.com
    ServerAdmin [email protected]
    ScriptAlias /srv/www.htdocs/susefan.com/cgi-bin
    ErrorLog /var/log/apache2/www.susefan.com-error_log
    CustomLog /var/log/apache2/www.susefan.com-access_log common
</VirtualHost>

CGI is a specification that allows a web server to execute programs and scripts that reside on the web server and return their output back to the client. CGI programming is the most common method of generating dynamic content for the web. Almost any language can be used, although Perl, Python, and C tend to be the most popular.

The easiest (and most secure) way to activate the CGI capabilities of Apache is to create a special directory that will contain all the scripts, and specify it using the ScriptAlias directive. Traditionally, the name of the directory is cgi-bin. Apache will try to run any file that resides in that directory ll file residing in the directory set with ScriptAlias.

Remember, these programs must be executable by the system Apache user. When you place your programs there, the permissions must be set to permit this:

chmod 755 program.cgi

Another way to enable CGI is to add +ExecCGI to the directory’s Options directive and then set a handler for files with certain extensions. These changes can be made either in the http.conf or .htaccess file:

Options +ExecCGI
AddHandler cgi-script .cgi .pl

In the preceding code, files in the directory with a .cgi or .pl extension will be handled as CGI scripts. Apache will execute the scripts and return the results to the requesting client.

SSI are specially crafted comments called elements, which are embedded in a web page and interpreted by Apache. They can be used to include the contents of other files, display environment variables (such as the current date and time) or a file’s timestamp, and produce program outputs.

To enable SSI, mod_include must be available to Apache, and you must add +Includes to the directory’s Options directive either in http.conf or in .htaccess:

Options +Includes

There are then two methods for identifying a file for processing as an SSI document. The first is to specify a file extension, traditionally .shtml, and associate a handler to process files that end with that extension:

AddType text/html  .shtml
AddHandler server-parsed  .shtml

The directives may be placed in either the http.conf or a .htaccess file. When set, Apache will process all files with the .shtml extension for SSI elements before returning the results to the requesting client.

The second method for identifying a file is by turning on the XBitHack directive and setting the execute permission bit on any SSI file. Again, they may be set either in .htaccess or httpd.conf.

XBitHack on

With XBitHack turned on, Apache will parse all files that the user has permission to execute, regardless of the file’s extension.

If you find yourself writing a lot of CGI scripts in a particular interpreted language, it might be beneficial to see if a module exists that integrates the language’s interpreter with Apache. For example, you would probably do better in the long run using the mod_perl Apache module instead of processing your Perl-powered pages through CGI. When you call a script from Apache, the Perl interpreter process starts, does its work, and then eventually stops. You can just imagine what that does to your system’s resources if you have 20 scripts running simultaneously, even if just for a few seconds. When you channel those scripts through a module, everything is handled by one native interpreter. This makes everything go faster—and safer.

The downside is that mod_perl is much fussier about errors. Apache doesn’t really mind if you don’t release a resource programmatically, because it shuts down the script before that becomes a problem. In a module, errors accumulate and become real problems. The upside is that you will become a better programmer as a result of fixing all these problems.

Some languages are specifically designed to be run through an Apache module, such as PHP. PHP can be used to process scripts through CGI; the language’s documentation encourages the use of an Apache module over the CGI implementation.

SUSE Linux provides Apache modules for four scripting languages: mod_perl, mod_python, mod_php4, and mod_ruby.

This tiny server (only 129KB), included in SUSE Linux and installable via YaST, aims to be a simple, small, fast, and secure web server. It’s not as feature rich as Apache or other server applications, but it does support CGI, Basic Authentication, virtual hosting, and bandwidth throttling.

The Caudium WebServer is on par with Apache but again with different strengths and weaknesses. It is a nonforking, threaded web server. It offers a web-based configuration interface, templating with the RoXen Macro Language (RXML), Pike code embedding, and the Supports Database, a method through which the requesting browser’s capabilities can be identified without using JavaScript in the web document. Caudium is not distributed with SUSE, but its source code can be downloaded from the project’s home page.

Xitami is a small, multithreaded and modular web server application that can also handle FTP requests. It supports direct support for CGI scripts written in Perl, Awk and Python, Basic Authentication, virtual hosting, on-the-fly server configuration, and server-side XML processing. Xitami is not distributed with SUSE, but the project’s source code can be downloaded from its website.

Zope is an open-source web-application server written mostly in Python. It is included in SUSE Linux and is installable via YaST. (You learned a little about Zope, including how to install it, when you installed ZWiki in Chapter 16, “Collaborating with Others.”)

Zope is an excellent content management framework and is geared toward serving dynamic pages. Zope can do its own web serving and has many of the same modules to do its work that Apache does, but it is often used together with Apache.

The best thing about Zope as a web server is that the simple web-based interface makes configuration much easier than with Apache.

Macromedia’s ColdFusion server bills itself as a fast way to create powerful web-based applications. It can run as a standalone application server, integrate with Apache, or work in conjunction with other J2EE solutions to serve CFML documents. The main benefits of the ColdFusion server is its Java underpinnings, which allow developers to use third-party Java code in their Internet applications, and tight integration with Macromedia’s other technologies. Free trial and developer versions are available from the company’s website.

The TomCat servlet container is part of the Apache Foundation’s open-source Jakarta project and embodies the industry’s standard implementation for the servlets and JSP interfaces. It can be configured as a standalone application server or integrated with Apache to serve JSP pages. TomCat can handle CGI and SSL requests when acting as a standalone server. Other benefits are its Single Sign On feature and web-based configuration interface. TomCat can be downloaded from the project’s website.