In this Daily Drill Down, we are going to take a look at installing one of the most popular server packages for Linux: the Apache Web Server. Apache is an open source Web server that is found with almost every single Linux distribution, and it is perhaps one of the most popular Web servers on the Internet today. It has excellent portability as it can run on Linux, *BSD, *NIX, Windows, OS/2, and even BeOS.
Because most Linux distributions come with Apache, you will only need to build it from scratch very rarely. More often than not, you will use RPM or DEB packages to upgrade your system, but sometimes the occasion may warrant a system administrator building and installing Apache from scratch. This is often the case on older systems with dependency issues on new packages designed for newer versions of the same distribution. Because installing Apache via RPM and DEB packages is extremely simple and straightforward, we aren’t going to bother taking a look at that method of installation, but instead we’ll deal directly with the source.
Obtaining Apache source
The first thing you need to do is obtain a copy of the Apache source code. You can choose the latest stable version of Apache, which is currently 1.3.20, or you can choose the most recent development version, which is 2.0.16 beta (as of this writing). Let’s download the latest stable version as the file apache_1.3.20.tar.gz. Save this file to your /usr/local/src directory.
The next step is to unpack the source archive. This is accomplished using, as root:
tar xvzf apache_1.3.20.tar.gz
You will now have an apache_1.3.20/ subdirectory located beneath your /usr/local/src tree. Now change to that directory. It’s time to run the configure script, which will set up our Apache options.
Configuring Apache is done via the configure script. This is not the same configuration you will do in your actual configuration files. This is where you configure some of the runtime defaults for Apache, such as the location to install files, support for extra features and modules, and so forth.
Let’s assume that you already have Apache installed and you simply want to give the new version of Apache a test run before you move your entire system over to it. This is handy to ensure that you have no difficulties with the new Apache prior to switching, and it will minimize any downtime should you encounter problems.
To do this, we will install Apache into /usr/local/apache instead of the default /usr directory tree. This means that the Web server itself will be installed into /usr/local/apache/bin instead of /usr/sbin. To do so, we run configure, like this:
But that isn’t how we’re going to install Apache because it won’t give us the functionality that we might be looking for. Instead, we will run configure like this.
This does a few more things than the previous example, some of which may be essential to your site. We tell configure that we want the end installation to be in /usr/local/apache, and we also tell it to enable all modules. By default, Apache enables most modules, but not all of them, and there are some useful modules, such as mod_rewrite, that are not enabled by default. The next thing we are doing is enabling Dynamic Shared Object (DSO) support for the maximum number of modules, which in our case is all of them. Enabling DSO support is important because it allows you to load and unload modules in Apache by simply reconfiguring and restarting it, without requiring you to recompile if you wish to remove support for a particular module or add support for another one.
The next thing we do is disable two modules: auth_dbm and auth_digest. The auth_dbm module is used for providing HTTP Basic Authentication, where usernames and passwords are stored in a DBM database file instead of a plain text password file. I personally find using plain text .htpasswd files to be a little easier, which is why I’ve selected to disable this module. The auth_digest module is an updated version of the mod_digest module, which allows for user authentication using MD5 Digest Authentication. This module is marked as an experimental module by the Apache team, so we won’t include it here. You can use the mod_digest module if you want to use MD5 Digest Authentication; however, be aware that mod_digest may not work with current browsers. If you’re dead-set on using MD5 Digest Authentication, I would probably try mod_digest first, and if that doesn’t work, build auth_digest and use it instead. Be aware that you can use one or the other only, not both.
Finally, we tell Apache where to find the Perl binary, in this case /usr/bin/perl. We also tell it to enable suEXEC support, which is what allows Apache to execute CGI and SSI scripts with the user and group ID of the owner of the script, instead of running it as the user currently running the Web server. This is a good option to enable. First, we tell Apache which user to call suEXEC with; in this case, we choose “nobody,” a completely safe and unprivileged user. Finally, we define a safe path for the suEXEC feature of /bin, /usr/bin, and /usr/local/bin.
The next step, once you have successfully finished running the configure script with all of the above options, is to actually build and then install Apache. To do this, simply execute:
and sit back, grab a coffee, and let the compiler do its work. It may take some time, depending on the speed of your machine. You may run into a few difficulties with the build, though. One that I ran into was when Apache tried to compile the mod_rewrite module, it could not find the file nbdm.h to include in the build. Because Apache looks only in src/include, and not in the system-wide /usr/include directory and all its subdirectories, I simply manually created a symlink to /usr/include/gdbm/nbdm.h. (You must have the gdbm development libraries installed; on most distributions this will be an RPM or DEB called gdbm-devel or libgdbm-devel.) I created the symlink by doing:
ln -s /usr/include/gdbm/ndbm.h .
and then rerunning the make command. Now make would complete for me. I’m not aware of any other strange conditions of the Apache build; however, I am using a Mandrake Linux 8.0 system to build Apache, so you may encounter some other difficulties that should be just as easy as this to resolve.
Building PHP for Apache
Of course, building Apache would not be complete without PHP to go with it. Any other scripting language you may use for CGIs and such does not deal with Apache on the same level as PHP, so if you’re planning on building Apache from source, you might as well build the latest PHP from source, as well.
As of this writing, the latest version of PHP is 4.0.6. Save the php-4.0.6.tar.gz file into /usr/local/src like we did with the Apache source. Now unpack the source code using:
tar xvzf php-4.0.6.tar.gz
You then need to run the configure script in the same manner we did for Apache. In this case, we will use these options to configure PHP.
Of course, there are a whole slew of other options available to build various parts of the whole PHP system. You can include support for MySQL, PostgreSQL, LDAP, IMAP, and so on. To obtain a full list of the different directives you can use with the configure script, execute:
This will pipe the output through the less command (a.k.a. less pager) to help you view all the many configuration options. In this case, we are going for a relatively simple PHP build without getting too fancy.
Here we are telling PHP to install into the /usr/local/apache directory tree to match with our new Apache installation. We are also telling it to use dynamic libraries instead of static libraries, and to compile without debugging symbols. We tell it to enable magic quotes by default, safe mode by default, along with FTP support, GNU gettext support for multilingual applications, and zlib support for compression support. The latter requires you to have the zlib development files installed (typically zlib-devel or zlib1-devel for RPM or DEB packages). Finally, we tell Apache to use the apxs program of Apache to install the PHP modules into the Apache directory tree; we also tell PHP where it can find the Apache configuration files prefix, or the base Apache directory. (The conf/ directory is assumed, so you do not need to include it.)
If you wanted to build in support for other applications, like MySQL or PostgreSQL, you would use some of these options with configure.
There are many other configuration options that you can choose from, but these are perhaps the most commonly used. You will need, for example, to enable the MySQL support if you wish PHP to interact with your MySQL database.
Finally, you will need to build PHP. This is accomplished the same way as with Apache, by running the two magic commands:
And that’s it! You have now installed the Apache Web server and PHP support for it.
Testing Apache and PHP
The next step is to test the server. The configuration files for your new Apache server are located in the /usr/local/apache/conf directory. Change to that directory and edit the httpd.conf file you find there. Find the line that contains the keyword Port, which should be line 314 for those of you using Apache 1.3.20. Change the value of the keyword from the default 80 to 8080. This will tell Apache to bind to port 8080, which is suitable for testing.
You will also need to uncomment support for PHP. In the same file, go to line 843 and uncomment the following two lines:
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
Save your changes. Now we want to start Apache, and to do so, we will use the following command:
You should see something like this if all went well:
./apachectl start: httpd started
Next, we’ll take a look at the process list to see if the httpd service is listed by issuing:
ps aux|grep httpd
You will get an output that looks something like this.
Yes, there it is. As you can see, our older Apache is also running, but you can tell that the processes starting at PID 8068 in the output example belong to our new Apache server.
The next step is to point your Web browser to localhost:8080 or www.yourdomain.com:8080, depending on where you are in relation to the new server. If you see the Apache welcome page, congratulations! Apache is working successfully on your system! But since we are a little paranoid and want to make extra sure, we’ll do the following:
telnet localhost 8080
You will then see:
Connected to localhost.localdomain.
Escape character is ‘^]’
At this point, type the following and press [Enter]:
HEAD / HTTP/1.0
You should then see something very similar to the following:
HTTP/1.1 200 OK
Date: Fri, 22 Jun 2001 01:26:57 GMT
Server: Apache/1.3.20 (Unix) PHP/4.0.6
The rest we can ignore. If you were to do this same test to the Web server running on port 80, you would probably see an older version of Apache and possibly an older PHP, as well. But here, as you can see, it reports the server running Apache 1.3.20 and PHP 4.0.6, both of which we installed just now.
There’s one final test to make sure that PHP works properly. Go to your /usr/local/apache/htdocs directory and, using your favorite editor, create a new file called test.php, which contains:
<? phpinfo(); ?>
Now point your browser to localhost:8080/test.php or a similar URL for your new Apache installation. Do you see a page full of information pertaining to PHP, such as system information, the correct version of PHP, and details on configuration directives? If you do, PHP is working correctly as well. Congratulations!
What we have accomplished today is something many people balk at. We’ve all been spoiled by nicely packaged RPM and DEB packages of some of our favorite software; however, you must keep in mind that the packagers make some rather liberal assumptions about how the server is going to be run, and they try to build it in such a way that it will work for everyone. This sometimes creates extra bloat, takes up more space than it needs to, and may not be quite as efficient as a streamlined self-compiled application. The same can be and has been said for kernels for a long time now, so why not applications such as Apache? While Apache is using DSOs now and this has slimmed down the application itself, some of the generic options used to compile the package may not be to your liking or suit your needs.
Being able to build server applications that you use is a helpful skill. And, if nothing else, you can take these same skills and use them on operating systems that do not prepackage many applications for you, such as OpenBSD and some other UNIX variants.
At any rate, being able to build and streamline both Apache and PHP is something every system administrator should be able to do. As you can see, it can be a little complicated, but with a little work and this Daily Drill Down in front of you, you’ll be able to manage just fine.