The Apache Web Server

written by: Tomy Winderfind; article published: year 2008, month 01;



In: Categories » Computers and technology » Servers » The Apache Web Server

There are currently two different versions of Apache: the original 1.3.x series and the newer Apache 2.x series. In this guide, we're going to look at the latest version of the 1.3.x series, which is Apache 1.3.27 at the time of this writing. We're using this version because PHP support for the Apache 2.0 series is still experimental. Also, most web servers you are likely to find offered by hosting companies will still be running Apache 1.3. So, unless you are willing to pay the cost of running your own dedicated server, Apache 1.3 is likely to be what you'll end up using for some time to come.

Apache has a huge following, so there's a wealth of information on the Web about it, and a large number of modules have been written that add new functionality to it. Your first step is to download the package from the Apache web site, which you'll look at now.

Downloading Apache

Apache is free to download from the Apache web site: http://httpd.apache.org/download.cgi/.

Once on the download page, you need to scroll down to the section labeled Apache 1.3.27. The file that you need to download is labeled Unix Source: apache_1.3.27.tar.gz. You don't need to download this file directly onto your Linux machine, however. You could download it onto your desktop computer and then transfer it across.

The file is around only 2.3MB, so it shouldn't take too long to download.

The reason the file is so small is that is has been compressed using an archiving utility called GNU tar, "tar" being short for "tape archive." The utility was originally written back in the mid-1980s for use with magnetic tape devices. Nowadays, it is normally used for combining multiple files and directories into a single file. When combined with the GNU zip utility, gzip, tar has an effect similar to the PKZIP format from PKWARE, Inc., common on Windows platforms, or the StuffIt archives used on Macs, in that it compacts, as well as archives, the files it contains.

Once you have downloaded the file, transfer it onto your Linux machine's /usr/local/ directory for installation.

Installing Apache

This guide assumes that you're installing Apache through a shell prompt, either on the Linux server itself or through a Telnet session from another computer. You'll need to be logged in as the root user. If you're not already the root user, you can change using the Linux su command:

su root  

You'll then need to enter the root user password.

The su command is short for "switch user" and allows you to change to another user without having to log out and log in again. You can become another user only if you have the correct permissions and know the user's password.

Creating the Required Directory Structure

Before you can install Apache, you need to extract the Apache file downloaded from the Apache web site and create the correct directory structure ready for the installation.

In this guide, you're going to install Apache to the following path:

/usr/local/apache  

This directory doesn't exist by default, so you need to create it using the following commands:

cd /usr/local  mkdir apache  cd apache  

The next step is to copy the Apache archive file that you just downloaded (apache_1.3.27.gz, in our case) to this location. You can do this with the following command (inserting your own filename, as necessary):

cp /usr/local/apache_1.3.27.tar.gz /usr/local/apache/  

Now that the file is in the correct place, you need to extract the files it contains. Move to the /usr/local/apache directory:

cd /usr/local/apache  

Enter the following command:

tar -xzvf ./apache_1.3.27.tar.gz  

When the command is run, a new directory is created within usr/local/apache/ called apache_1.3.27, which contains all the necessary files for Apache to run.

The options used with the tar command have the following meaning: x = extract file (rather than archive it), z = unzip the compressed gzip archive, v = use the "verbose" option, which means "show all the file names as each one is extracted", and f = work on the archive file named in the command.

The archive will unpack the files and directories, and output a scrolling list showing each one as it is extracted.

To make life easier, you next create a symbolic link between the apache_1.3.27 directory and a directory called httpd using the following command:

ln -s /usr/local/apache/apache_1.3.27 /usr/local/apache/httpd  

A symbolic link has now been set up so that you can refer to the apache_1.3.27 directory as if it were called httpd. In effect, you've given the directory apache_1.3.27 another name. Either name can now be used to access the directory. Understand, however, that httpd is not a copy of apache_1.3.27; both are names for the same directory. The concept is similar to that of a shortcut in Windows or an alias in OS X.

Creating the symbolic link has several advantages:

  • It's much easier to type httpd in a path than it is to type apache_1.3.27.

  • If in the future you install a later version of Apache, you can just change the symbolic link that httpd uses to the new Apache directory. This keeps each version of Apache separate from any others, and you don't have to change any configuration files (which are set to point to the httpd directory).

    Should you have problems installing the new version, you can just change httpd to point back to the old version, and you'll have a working version of Apache again without losing any development time.

Symbolic links do add slightly to the system overhead, but on a development server this shouldn't be a problem.

The Apache Layout

To keep the installation neat and easy to upgrade, you're going to split the installation into two separate locations. One location will hold dependent files specific to the running of Apache, and the other will hold the configuration and log files, as these are not specific to the Apache version. This means that you can upgrade to later Apache versions without having to change your configuration files.

You need to create these directories in the following location:

/home  

If you don't already have a home directory, use the following commands to create one in the server's root directory, /.

cd /  mkdir home  cd home  

Now that you're in the /home directory, you're going to create a new subdirectory called www and then three subdirectories under that for different types of files. Type the following commands to make the directories:

mkdir www  cd www  mkdir conf  mkdir logs  mkdir webroot  

www is your base directory and will contain all of the non-version-specific files. conf will contain the Apache configuration files, logs will hold the Apache log files, and webroot will be the directory that web pages are served from.

To recap, you now have two separate directory structures:

  • /usr/local/apache/httpd – For version-dependent files

  • /home/www – For version-independent files

Now that you have the two directory structures set up, you can start the Apache installation.

Starting the Apache DSO Installation

Use the following command to change to the location to which Apache was extracted:

cd /usr/local/apache/httpd  

Installation on Linux systems is very different from Windows systems. You have to actually create the program files themselves. The file that you downloaded from the Apache web site contains the source code for Apache, written in C, rather than a ready-to-run installation package. To turn this source code into a working program, you need to compile it using a C compiler. This isn't as difficult as it sounds, though, since it's largely an automated process.

There are two ways you can build Apache, and which one you use will be determined by how you want it to run:

  • If you choose a static build, then every time you want to install a new module into it, you need to recompile the whole Apache program again from the source code, including the new module into the build.

  • The alternative method, which is the one you are going to use, is to build what is called a DSO installation. This installation allows you to add and remove modules without having to recompile the Apache program. In addtion to the performance advantages this offers, it makes it much easier to install the PHP module. Building a DSO installation also makes it easier to update Apache. You can find a more detailed explanation of the DSO system at http://httpd.apache.org/docs/dso.html.

To build the DSO installation, you first have to use the configure command. You can supply further options as parameters that dictate how Apache will behave. We're only going to cover a basic setup, so the only parameters you'll use are the ones that tell Apache where to place the compiled program files. Type the following command to start the compile process:

./configure -prefix=/usr/local/apache/httpd -sysconfdir=/home/www/conf -  enable-module=so  

The -prefix parameter indicates where to install the Apache program files, and the -sysconfdir option defines the directory where Apache will store its configuration files.

Once you've entered the command, the compile process will start. It may take a minute or two, during which time you'll see various information about the process displayed. When the configure command has completed, you'll be returned to the command prompt. All the relevant pieces of source code needed to build Apache have been pulled together according to the options that were specified.

Next, you need to compile the parts of Apache that the configure command has prepared to make it into an executable file, which you can do by entering the following command:

make  

While the make command is compiling all the code, you'll see the lists of the current files being compiled. The process may take a couple of minutes, especially on an older machine. Don't worry if you're not sure what the output means; you just need to wait for the make command to finish. If the program compiled successfully, then you'll just be returned to the command prompt. Otherwise, an error message indicating what the problem is will be output before returning you to the command prompt.

At some stages of make (and make install, which is the next command we look at), it may appear as if nothing is happening. It's very unlikely that the server has hung, though, so just be patient and wait for the command to finish.

If there is an error, it's usually because the libraries on the server Apache needs to compile are older versions than the ones Apache requires. If this is the case, the error message will show which package is too old and which version Apache needs to compile. You can then download the newer library versions and install them if necessary. If you do update any libraries, you need to execute the following command, so that the newer library versions can be found:

/sbin/ldconfig  

You should then run the Apache configure and make commands again. As long as the correct versions of the libraries it needs are present, Apache will be compiled successfully.

You need to enter one final command:

make install  

This copies all of Apache's files to the correct location and sets the correct file permissions for the files and directories used. Again, everything make install is doing is shown on the screen.

Once everything is complete, you should see a message similar to the following:

+--------------------------------------------------------+  
| You now have successfully built and installed the      |  
| Apache 1.3 HTTP server. To verify that Apache actually |  
| works correctly you now should first check the         | 
| (initially created or preserved) configuration files   |  
|                                                        |  
|   /home/www/conf/httpd.conf  |                                                        
|  
| and then you should be able to immediately fire up     |  
| Apache the first time by running:                      |  
|                                                        |  
|   /usr/local/apache/httpd/bin/apachectl start  |                                                        
|  | Thanks for using Apache.       The Apache Group        
|  |                                http://www.apache.org/  
|  +--------------------------------------------------------+  

Apache has installed successfully, but before you can start it, you need to change a few options in the Apache configuration file.

Configuring Apache

Now that Apache is installed, you need to set some options specific to your server in its main configuration file, which is called httpd.conf. The location of this file will be

/home/www/conf/httpd.conf  

If you're opening the file on a Windows system, you'll need to use a text editor such as Notepad, as a word processor may insert hidden formatting codes that will cause problems when Apache tries to read the file.

If you're editing the file on the Linux server itself, you can use the pico or vi editors.

During the install process, most of the correct paths are placed in the httpd.conf file, but it's a good idea to go through and check certain key settings.

ServerRoot

The first setting that is of importance to you is the ServerRoot setting, as this tells Apache where its program and system files are located. The setting should currently read

ServerRoot "/usr/local/apache/httpd"  

This is correct because you specified it in your earlier ./configure call, so it can be left as it is.

Port

The Port setting is in the second section of the httpd.conf file, which is quite a ways down the page. To jump to it quickly, you can use the Find function of your text editor. The default setting is

Port 80  

This governs the port that Apache listens to requests on. Port 80 is the standard port for running a web server, but if you wish, you can change the port to another value, as long as the port number you choose isn't already in use. If you do decide to change the port, then whenever you make a request to the web server you will need to specify the port number in the URL. For example, http://localhost:81/page.php.

DocumentRoot

The DocumentRoot setting defines the directory on the server that web pages are served from the root directory of your web site. By default, this setting should be

DocumentRoot "/home/www/webroot"  

Again, this is correct, so you can leave it as is.

Slightly further down, you'll also see the following line:

<Directory "/home/www/webroot/">  

The paths in these two settings must always match each other, so if you change the DocumentRoot setting in the future, you must also change the path for the Directory setting.

AllowOverride

The AllowOverride option sets whether or not you can override the settings in httpd.conf by using .htaccess files. The default setting for this option is

AllowOverride None  

This means that no settings in httpd.conf can be overridden by an .htaccess file. This isn't very convenient for a development server, and it can be changed to All to allow any setting to be overridden. This is what you would want on a development server. Other options include the following: Options, FileInfo, AuthConfig, Limit, or None. These govern which sections of the httpd.conf file can be overridden, where All means that all options can be overridden, and None means no options can be overridden. The other options allow you to specify that certain parts of the httpd.conf file can be overridden, and you can find a list of the directives they apply to at http://httpd.apache.org/docs/mod/core.html#allowoverride.

ErrorLog

This setting dictates where the file that logs errors is stored. Following installation, it will be set to its default location:

ErrorLog /usr/local/apache/httpd/logs/error_log  

You want the log files to be in your www directory, however, so you need to change this setting to the following:

ErrorLog /home/www/logs/error_log  

CustomLog

This setting governs where the normal Apache log files are stored. By default this will be

CustomLog /usr/local/apache/httpd/logs/access_log common  

Again, this needs changing to

CustomLog /home/www/logs/access_log common  

These options are the main ones that need to be checked, so you can now save the file and close it.

Controlling the Apache Server

To start Apache, you need to use the apachectl (short for "Apache control") control:

/usr/local/apache/httpd/bin/apachectl start  

Similarly, to stop the server, you would use this command:

/usr/local/apache/httpd/bin/apachectl stop  

There is also a restart command, but it can sometimes be unreliable, and it is more useful on a live server. If you want to restart a test server, we recommend that you just stop the server and then start it up again.

It's a good idea for a Linux development server to have Apache start itself during bootup. How you do this will depend on your version and distribution of Linux, but there are many guides on the Web on how to set Apache to run on start-up. Instructions can also usually be found in the manual for your particular Linux distribution.

Note that you can shut down your whole Linux server so that it can be powered off, using the command

/sbin/shutdown -h now  

and you can do this remotely through a Telnet session.

Testing Apache

Once you have Apache started, you can create a test page that you can view in your browser to check that Apache is correctly serving web pages.

If you have followed this guide so far, the root of your web site will be at the location /home/www/webroot.

You can now copy the default Apache index.htm file from the httpd/htdocs directory, using the following command:

cp /usr/local/apache/httpd/htdocs/index.html.en  /home/www/webroot/index.html  

Open a web browser and, if you're working on the server, enter this URL:

http://localhost/index.html  

If you're working remotely, you can use this URL:

http://serveripaddress/index.html  

And if everything is working correctly, you'll see the Apache test page.

Actually, you probably won't see the graphic, apache_pb.gif, at the bottom of the page in your copy of the page, because it's still located in Apache's default webroot folder. If you want to see it, you'll have to copy it across to your new webroot folder by entering the command

cp /usr/local/apache/httpd/htdocs/apache_pb.gif /home/www/webroot/  

Reload the page and the image should appear.

Troubleshooting the Apache Installation

If you get a 404 - Page Not Found error, open up the main Apache configuration file, httpd.conf from

/home/www/conf/httpd.conf  

You then need to check that all the paths you entered are correct. Fix any errors and save the file. You'll then need to restart Apache so it will read the new settings. You can also check that the Apache configuration files do not have any syntax errors using the apachectl command you use to start and stop the web server. You do this by passing it the argument configtest, as follows:

/usr/local/apache/httpd/bin/apachectl configtest  

This will point out any syntax errors it finds in the configuration files.

You can also check the Apache log files, especially error_log, which, in our case, is found at the following location:

/home/www/logs/error_log  

This should provide some helpful information.

Note the error_log file has no file extension. This is perfectly valid on Linux; it's just a normal text file. You can read it and edit it using a text editor such as Notepad or Pico.

Don't forget that Apache needs to be started by the root user.

There are a large number of frequently asked questions and troubleshooting tips that will help you sort out any problems at the Red Hat Apache Knowledgebase (http://www.redhat.com/support/resources/faqs/RH-apache-FAQ/book1.html).

Apache Modules

Apache can be extended by a number of modules that you add when you compile Apache or later. A current list that's divided into groups depending on the module type can be found at http://httpd.apache.org/docs/mod/index-bytype.html. Although you probably won't use any of these modules yet, it's useful to know they exist and can be installed later on if you wish.

legal disclaimer

1) Our website is not responsible for the information contained by this article as well for any and all copyright infringements by authors and writers. E-articles is a free information resource. If you suspect this article for any copyright infringements, please read the Terms of service and contact us to investigate the problem.
2) The E-articles directory team is not responsible for inaccuracies, falsehoods, or any other types of misinformation this tutorial may contain and will not be liable for any loss or damage suffered by a user through the user's reliance on the information gained here. Please read the Terms of service

Useful tools and features

Translate this article to...    Send this article to you or to a friend

Link to this article from your page   
If you like this article (tutorial), please link to it from your web page using the information above. Linking to this page, this is the only way to help us improve our service, the same time providing your visitors with a way to improve their online experience.

related articles

1. Understanding DNS Requirements for Exchange Server 2007
In Active Directory, all client logons and lookups are directed to local domain controllers and GC servers through references to the SRV records in DNS. Each configuration has its DNS and resource requirements. Exchange relies on other servers for client authentication and uses DNS to find those servers. In an Active Directory domain controller configuration, on the other hand, the Exchange server also participates in the authentication process for Active Directory. Using DNS in Exchange Server 2007 As has bee...

2. Securing and Maintaining an Exchange Server 2007 Implementation
One of the greatest advantages of Exchange Server 2007 is its emphasis on security. Along with Windows Server 2003, Exchange Server 2007 was developed during and after the Microsoft Trustworthy Computing initiative, which effectively put a greater emphasis on security over new features in the products. In Exchange Server 2007, this means that the OS and the application were designed with services “Secure by Default.” With Secure by Default, all nonessential functionality in Exchange must be turned on if needed. Thi...

3. Improvements in Exchange Server 2007 Relative to Security and Compliance
One of the improvement goals Microsoft has had with all of their products over the past few years has been to constantly improve the security in the products. More recently with all of the regulatory compliance laws and policies being implemented, Microsoft has focused a lot of security enhancements to address privacy, information archiving, and compliance support. The release of Exchange 2007 was no different—Microsoft added in several new enhancements in the areas of security and compliance support. One of the addition...

4. Designing Exchange Infrastructure
After Active Directory and the physical OS has been chosen and deployed, the Exchange infrastructure can be set up and optimized for the specific needs of the organization. With these needs in mind, you can do several things to optimize an Exchange 2007 setup, as detailed in the following sections. Determining the Exchange Version When installing Exchange, the choice of Exchange version needs to be made. As with Windows Server 2003, there are two versions of Exchange, Standard and Enterprise. The Standard Edit...

5. Synchronizing Exchange Server 2007 with Novell eDirectory
Novell eDirectory and Novell Directory Service (NDS) environments are relatively commonplace in business environments, and there is often a need to integrate them into deployed Exchange infrastructures. Several tools exist that can make this a reality, including the MIIS 2003 tools discussed. In addition, tools in the Microsoft-supplied Services for NetWare can be used to synchronize directory information between the two directory systems. NOTE Exchange 2000 Server and Exchange Server 2003 included a GroupWise ...

6. Integrating Client Access into Exchange Server 2007 Design
Although the Exchange server is a powerful systems component, it is only half the equation for an email platform. The client systems comprise the other half, and are a necessary ingredient that should be carefully determined in advance. Outlining Client Access Methods Great effort has been put into optimizing and streamlining the client access approaches available in Exchange 2007. Not only have traditional approaches such as the Outlook client been enhanced, but support for nontraditional access with POP3 and...

7. Domain Name System and Its Role in Exchange Server 2007
For computer systems to communicate with each other, whether you are talking about a local area network (LAN), a wide area network (WAN), or the Internet, they must have the ability to identify one another using some type of name resolution. Several strategies have been developed over the years, but the most reliable one to date (and the current industry standard) is the use of a DNS. Accurate name resolution is critical in a mail environment as well. For a message to reach its destination, it might pass through several syste...