How to install Apache on Linux

SAN FRANCISCO– The installation, care, and feeding of an Apache Web server is not terribly difficult, but can seem so if you haven’t ventured into those particular waters before. This quick-start guide will help you get your feet wet with Apache on a Linux server. You’ll find it’s relatively simple to get the Web server set up and running on your Linux of choice. We’ll also install PHP and MySQL, though we won’t be digging into MySQL configurations, as that deserves a quick start all its own.

The method of installing the Apache packages on a Linux server varies from distribution to distribution. We’ll cover how to do this on Fedora and CentOS, as well as on Ubuntu. This is a server-centric walkthrough, so we’ll use the command line exclusively. Naturally, you’ll need root-level privileges. Open the terminal window and type:

su –

Then enter the root password. Now we can get started.

First we’ll install the packages themselves. For Fedora and CentOS, this is a simple step involving Yum, the package installer and updater. To install the basic Apache and PHP packages, run the following command:

yum install httpd php mysql mysql-server

Follow the prompts, as this tool will locate and install a base set of Apache and PHP packages.

For Ubuntu 10.04 servers and newer, you can install the whole LAMP (Apache, MySQL, and PHP) stack with two commands:
 
sudo apt-get install tasksel
sudo tasksel install lamp-server

While this guide does not cover MySQL, the above commands are a quick way to get all the necessary packages required for LAMP applications. Once the installation is complete, we can begin configuring the server.

For all file editing, on Fedora, CentOS, or Ubuntu, you may want to use nano:

nano /etc/httpd/conf/httpd.conf

This command will open the Apache configuration file in a basic editor. You can save the file with Ctrl-O and exit the editor with Ctrl-X.

Apache on Linux: Initial configuration
While the Apache and PHP packages are essentially the same across the different distributions, there are differences in how they are actually installed on the file system. We’ll start with Fedora and CentOS.

Fedora and CentOS. After installation, you’ll find a new directory: /etc/httpd. Within this directory are all the Apache configuration files. The important subdirectories for our purposes are /etc/httpd/conf and /etc/httpd/conf.d. Within /etc/httpd you’ll find the main Apache configuration file, httpd.conf. In /etc/httpd/conf.d you will find includes, or supplemental files that are included in the main configuration file.

Includes are a way to break out complex configurations into separate files for easy organization and management. For instance, if you have an Apache server that has 20 virtual hosts, then each virtual host should have a separate file in /etc/httpd/conf.d/ that contains its specific configuration parameters. In this way, you can easily add or remove virtual hosts without editing the main Apache configuration file.

In order for files to be included in the Apache configuration, they must have a filename that ends with .conf. If we have a virtual host named www.test.com, all the configuration elements for that virtual host would reside in a file named test.conf or test.com.conf.

You can see how these files are included in the main configuration file by looking at /etc/httpd/conf/httpd.conf. Press Ctrl-W to search for “Include conf.d” and you’ll find this line:

Include conf.d/*.conf

That tells Apache to include all files matching *.conf in the /etc/httpd/conf.d folder into the main configuration.

There are many configuration elements present in the Apache configuration file, but beginners need to be concerned with only a few. These are the elements that control where our Web root is, how to handle virtual hosting, and a few other minor tweaks. To start with, the default settings present in this file will be fine.

By default, the Web root on Fedora and CentOS is /var/www/html. This means that any files placed under /var/www/html will be served via Apache when a Web browser connects to the server. If a file exists as /var/www/html/test.html, and you open a Web browser and connect to http://<server IP address>/test.html, the server will deliver that file to the browser. If the server will host only a single website, then you can put all of your content under this directory and configure DNS to map a name, such as www.test.com, to the server’s IP address, and then http://www.test.com/ will work.

Controlling the Apache server is very simple. To start the server on Fedora or CentOS, run:

service httpd start

Stopping the server is equally simple:

service httpd stop

To restart the server, you can also use:

service httpd restart

For simply reloading the configuration file without restarting the service, use the following command:

service httpd reload

Another very handy control:

service httpd configtest

This tests the Apache configuration file and all included files for errors without starting or restarting the server. This allows you to make sure your configurations are valid before actually causing Apache to run with that configuration, which makes it easier to add and test configurations without disturbing the running server.

To make sure that Apache starts when the server boots, simply run:

chkconfig httpd on

This will add Apache to the list of services to start at boot time.

Ubuntu. Ubuntu follows the same basic procedure as Fedora and CentOS, but places the files in different directories. The global Apache configurations are found at /etc/apache2/apache2.conf. As in Fedora and CentOS, includes break out different Apache configuration elements to separate files, but go further in Ubuntu, breaking out many more sections of the global configuration to other files (such as ports.conf, which controls the ports Apache listens on). For beginners, these files will not need to be modified.

Unlike Fedora and CentOS, Ubuntu has a specific directory for virtual host configurations, /etc/apache2/sites-available, and a companion directory, /etc/apache2/sites-enabled. Configuration elements specific to individual virtual hosts are placed in sites-available, then symlinked from sites-enabled, making it easy to add and remove active virtual hosts from the configuration without deleting or renaming the files. Just add or remove a symlink to bring them to the configuration.

Ubuntu also has a different default Web root, /var/www, so if a file named test.html exists in /var/www, Apache will deliver that file to a Web browser that requests the URL http://<server IP address>/test.html. If the server will host only a single website, then you can put all content under this directory and configure DNS to map a name, such as www.test.com, to the server’s IP address, and then http://www.test.com/ will work.

Controlling Apache in Ubuntu is as simple as in Fedora and CentOS, but generally relies on a different command-line method. Although some versions of Ubuntu support the service command, you can always count on the following commands.

To start Apache, run:

sudo /etc/init.d/apache2 start

To stop Apache, run:

sudo /etc/init.d/apache2 stop

To restart the server, run:

sudo /etc/init.d/apache2 restart

As in Fedora and CentOS, you can reload the configuration files without restarting the service, by running:

sudo /etc/init.d/apache2 reload

And you can test the configuration file syntax with:

sudo apachectl configtest

There are several different ways to configure Apache to start at boot with Ubuntu, but a general method is to use update-rc.d:

sudo update-rc.d apache2 defaults

This will cause Apache to start when the server boots. You might also look into using Upstart, which is a newer method of starting system services at boot.

Apache on Linux: General configuration
Regardless of the Linux distribution, Apache’s configuration follows standard concepts. A primary element is the use of opening and closing tags, which are patterned after HTML tags. For instance, if you have a <Directory> statement, everything after that statement is within the <Directory> context, which is terminated with a </Directory> tag. If you forget to add a closing tag, the configuration syntax will not be valid and the server will refuse to run.

It’s a good idea to read through the default httpd.conf (Fedora and CentOS) or apache2.conf (Ubuntu) file and included files. While you may not understand everything, these files are well commented, providing context and sometimes even examples on proper usage. They will also give you an idea of how the overall configuration file is constructed and clue you in to different aspects of the configuration that might come in handy later on when you’re attempting more advanced configuration tasks.

For our purposes here, we can leave the default configuration as-is and work on extending that configuration to suit our needs. The default settings for server operation are generally well suited for small and experimental servers, but production servers that are expected to handle heavy loads may require extensive modifications to the default settings. But let’s start simple.

As mentioned above, you can place your content in Apache’s document root directory and it will be served to clients, but in general it’s better to configure virtual hosts. It makes no difference to the server if there’s only one virtual host, and multiple virtual hosts can be easily added later using the same formula.

Configuring a virtual host is distribution-agnostic. Simply create a file in the default virtual host include directory for your distribution as described above.

We’ll create the file test.conf. Within this file we will add all the configuration elements necessary to have the server deliver content for www.test.com.

Note: For Fedora and CentOS, you may have to edit the /etc/httpd/conf/httpd.conf file and remove the # character before NameVirtualHost *:80 near the bottom of the file. This will allow name-based virtual hosts to function. To do this, open the file in nano:

nano /etc/httpd/conf/httpd.conf

Then press Ctrl-W and locate NameVirtualHost by typing in that search string. Remove the # (comment character) from the beginning of the line and save the file.
 
Now we’re ready to create our virtual host. Using Fedora, we’d open a new file in /etc/httpd/conf.d/:

nano /etc/httpd/conf.d/test.conf

For Ubuntu, we would run:

sudo nano /etc/apache2/sites-available/test

We now have an empty file that we need to fill up with the configuration for our virtual host. Here’s an example file for Fedora or CentOS:

<VirtualHost *:80>
    ServerAdmin webmaster@www.test.com
    DocumentRoot /var/www/test
    ServerName www.test.com
    ServerAlias test.com
    ErrorLog logs/www.test.com-error_log
    CustomLog logs/www.test.com-access_log combined
</VirtualHost>

We need a slightly different file for Ubuntu due to different conventions for log file placement:

<VirtualHost *:80>
    ServerAdmin webmaster@www.test.com
    DocumentRoot /var/www/test
    ServerName www.test.com
    ServerAlias test.com
    ErrorLog ${APACHE_LOG_DIR}/www.test.com-error_log
    CustomLog ${APACHE_LOG_DIR}/www.test.com-access_log combined
</VirtualHost>

This configuration snippet tells Apache that we have a virtual host that will be listening on TCP port 80 (the standard HTTP port). It also tells Apache that the document root for this virtual host is /var/www/test, indicates that the server name is www.test.com, and specifies where the logs should be placed. It then ends the configuration snippet with the </VirtualHost> directive.

In order for this virtual host to work, the directory /var/www/test must exist and have some contents, such as an index.html file, and DNS needs to be configured to point the DNS name www.test.com to the server’s IP address. Note the ServerAlias directive in the configuration file. This allows Apache to accept either www.test.com or test.com as a valid name when a browser requests the site. This is important, as many people omit the initial www when manually typing in website URLs. You can also use ServerAlias to allow the server to deliver content for a completely different name, such as www.foo.com, from the same document root.

Once you have modified the virtual host configuration file to your needs, such as changing the server name and the DocumentRoot directory, then press Ctrl-O to save the file and exit the editor.

At this point, you can go on to create other virtual hosts in the same manner. You can create the document root with the mkdir command on Fedora or CentOS:

mkdir /var/www/test

An alternative on Ubuntu:

sudo mkdir /var/www/test

Then place an HTML file in that directory called index.html:

nano /var/www/test/index.html

Next, type this into the file:

<html>
This is a test.
</html>

To test the configuration on Fedora or CentOS, use:

service httpd configtest

If it responds with “Syntax OK,” you’re all set.

For Ubuntu, we first need to enable the site, then test the configuration like so:

sudo a2ensite test

This uses the Ubuntu tool a2ensite to enable the site you configured earlier. We also need to disable the default site if we’re working without DNS, or if we want our test virtual host to be the only content served:

sudo a2dissite default

If we don’t do this, then accessing the server by IP address with a browser will show the default site that was installed with Apache, rather than our test site. If you want to enable the default site at a later time, just run:

sudo a2ensite default

After this, you can run the following to test the configuration in Ubuntu:

sudo apachectl configtest

If all is well, you can now start or restart Apache to load the new configuration. In Fedora and CentOS:

service httpd restart

In Ubuntu:

sudo /etc/init.d/apache2 restart

Once you’ve restarted the server, you can test the site by opening it with a browser, assuming that you’ve configured DNS to translate your site’s name to the server’s IP address. You should see “This is a test” in the browser, as the server delivers the index.html file you created.

 

Apache on Linux: Beyond the basics
What we’ve laid out above is an extremely simple example of an Apache configuration. While most installations will require only minimal modifications to the default configurations, there are a few details to know beyond the basics.

You may recall that we also installed PHP in the initial steps. Because of this, PHP has already been configured for use with Apache. You can test this by creating a file in the document root called test.php and typing in the following PHP code:

<?php
phpinfo();
?>

Save the file, then open your browser and access http://<server ip address>/test.php. You should get a listing of all the PHP environment variables, modules, and versions. This means that PHP is installed and functional.

An important Apache configuration element to know is the <Directory> statement. This allows you to configure specific permissions on directories shared by Apache. For instance, within our VirtualHost directive example, we might add the following:

<Directory /var/www/test>
    AllowOverride All
    Order deny,allow
    Deny from all
    Allow from 192.168.
</Directory>

This directory statement accomplishes a few goals. First and foremost, AllowOverride All permits the use of .htaccess files within the directory /var/www/test to modify the server’s behavior. Through .htaccess files, you can control access to the directory or implement any number of other configuration tweaks without modifying the virtual host configuration file itself. This can be very handy, they allow you to make configuration changes for the virtual host without reloading the server. The downside is that configuration errors within an .htaccess file can cause immediate problems.

(Note that the AllowOverride is subject to several different qualifiers that can grant specific override directives to the .htaccess file. The use of All here allows all of them. You can find a list with descriptions at the Apache Software Foundation.)

Secondly, we have Order deny, allow, and a few Deny and Allow statements. As configured above, the Web server would deny access to any client with an IP address outside the 192.168.0.0/16 range, or 192.168.0.0 through 192.168.255.255. It’s a handy way to deny access to specific IP ranges or to ensure that only internal clients can access that particular resource.

Once you’re comfortable with the basics, you can move on to other advanced configuration elements. For instance, it’s relatively simple to password-protect a site or directory using .htaccess files. To do this, you need to create a file named .htaccess in the document root of the virtual host (or Apache server) and add these lines:

AuthUserFile /etc/httpd/webpasswds
AuthName “My Web Auth”
AuthType basic
<Limit GET POST>
</Limit>

Then create the password file. On Fedora or CentOS:

htpasswd -c /etc/httpd/webpasswds myuser

On Ubuntu:

sudo htpasswd -c /etc/apache2/webpasswds myuser

Make sure you have set AllowOverride All, or at least AllowOverride Limit, in your configuration file as noted above. After you’ve done this and reloaded the server, users will be presented with a login dialog box before they can access the website. You can add more usernames and passwords using the same htpasswd command, though you don’t need to use the -c flag if you’re just adding more users.

To infinity and beyond
With any luck, you’ve just succeeded in getting Apache up and running on a modern Linux server. There’s much more to know about the Apache Web server, and the best way to learn is to experiment with different configurations. You’ll want to bookmark Apache’s documentation for the version you’re running.

It’s unwise to put sensitive information on any Web server until you’re comfortable that the configuration is proper. It’s too easy to make configuration errors that expose information inadvertently. If you’re just starting out with Apache and Linux, take the time to research and educate yourself first, and perhaps find someone more knowledgeable to verify your configurations before placing your server into production.

Would you recommend this article?

Share

Thanks for taking the time to let us know what you think of this article!
We'd love to hear your opinion about this or any other story you read in our publication.


Jim Love, Chief Content Officer, IT World Canada

Featured Download

Featured Articles

Cybersecurity in 2024: Priorities and challenges for Canadian organizations 

By Derek Manky As predictions for 2024 point to the continued expansion...

Survey shows generative AI is a top priority for Canadian corporate leaders.

Leaders are devoting significant budget to generative AI for 2024 Canadian corporate...

Related Tech News

Tech Jobs

Our experienced team of journalists and bloggers bring you engaging in-depth interviews, videos and content targeted to IT professionals and line-of-business executives.

Tech Companies Hiring Right Now