This tutorial explains how to install and configure the Apache web server on CentOS 6. All configuration will be done through the terminal; make sure you are logged in as root via SSH. If you have not followed the getting started guide, it is recommended that you do so prior to beginning this guide. Also note that if you're looking to install a full LAMP stack, you may want to consider using our LAMP guide for CentOS.
Before you begin installing and configuring the components described in this guide, please make sure you've followed our instructions for setting your hostname. Issue the following commands to make sure it is set properly:
hostname hostname -f
The first command should show your short hostname, and the second should show your fully qualified domain name (FQDN).
Make sure your system is up to date by issuing the following command:
Enter the following command to install the Apache HTTP Server:
yum install httpd
Edit the main Apache configuration file to adjust the resource use settings. The settings shown below are a good starting point for a Linode 1GB.
KeepAlive Off ... <IfModule prefork.c> StartServers 2 MinSpareServers 6 MaxSpareServers 12 MaxClients 80 MaxRequestsPerChild 3000 </IfModule>
Issue the following command to start the web server:
service httpd start
To ensure that Apache starts following the next reboot cycle, issue the following command:
chkconfig httpd on
The following commands are optional, and should be run if you want to have support within Apache for server-side scripting in PHP, Ruby, Python, or Perl.
To install Ruby support, issue the following command:
yum install ruby
Note that this installs support only for the Ruby programing language. Running scripts and applications written in Ruby in web pages will require some sort of CGI handler.
To install Perl support, issue the following command:
yum install mod_perl
To install Python support, issue the following command:
yum install mod_wsgi
If you need support for MySQL in Python, you will also need to install Python MySQL support:
yum install MySQL-python
To install PHP support, including common support bundles, issue the following command:
yum install php php-pear
If you're also hoping to run PHP with MySQL, then also install MySQL support:
yum install php-mysql
All configuration for Apache are contained in the httpd.conf file, which is located at: /etc/httpd/conf/httpd.conf. We advise you to make a backup of this file into your home directory, like so:
cp /etc/httpd/conf/httpd.conf ~/httpd.conf.backup
By default all files ending in the .conf extension in /etc/httpd/conf.d/ are treated as configuration files, and we recommend placing your non-standard configuration options in files in this directory. Regardless how you choose to organize your configuration files, making regular backups of known working states is highly recommended.
Now we'll configure virtual hosting so that we can host multiple domains (or subdomains) with the server. These websites can be controlled by different users, or by a single user, as you prefer.
Before we get started, we suggest that you combine all configuration on virtual hosting into a single file called vhost.conf located in the /etc/httpd/conf.d/ directory. Open this file in your favorite text editor, and we'll begin by setting up virtual hosting.
First we must configure Apache to only "listen" for requests on a specific IP address. By default Apache listens to requests on all IP addresses.
For name based Virtual Hosting, begin with a line that reads:
Now, you will create virtual host entries for each site that you need to host with this server. Here are two examples for sites at "example.org" and "example.net:"
<VirtualHost *:80> ServerAdmin email@example.com ServerName example.org ServerAlias www.example.org DocumentRoot /srv/www/example.org/public_html/ ErrorLog /srv/www/example.org/logs/error.log CustomLog /srv/www/example.org/logs/access.log combined </VirtualHost> <VirtualHost *:80> ServerAdmin firstname.lastname@example.org ServerName example.net ServerAlias www.example.net DocumentRoot /srv/www/example.net/public_html/ ErrorLog /srv/www/example.net/logs/error.log CustomLog /srv/www/example.net/logs/access.log combined </VirtualHost>
Notes regarding this example configuration:
Before you can use the above configuration you'll need to create the specified directories. For the above configuration, you can do this with the following commands:
mkdir -p /srv/www/example.org/public_html mkdir -p /srv/www/example.org/logs mkdir -p /srv/www/example.net/public_html mkdir -p /srv/www/example.net/logs
After you've set up your virtual hosts, issue the following command to load these values into Apache:
service httpd reload
Virtual hosting for your domain should now work -- assuming of course that you have already configured DNS to point your domain to your Linode's IP address. Remember that you can create as many virtual hosts with Apache as you need.
Any time you change an option in your vhost.conf file, or any other Apache configuration remember to reload the configuration with the reload command form above.
One of the strengths, and obstacles, of Apache is the immense amount of flexibility offered in its configuration files. In the default installation of Apache 2 on CentOS 6, the main configuration file is located at /etc/httpd/conf/httpd.conf, but Apache configuration is also loaded from files in a number of different locations, in a specific order. Configuration files are read in the following order, with items specified later taking precedence over earlier and potentially conflicting options:
Remember, later files take precedence over earlier-cited files. Within a directory of included configuration files, files will be read in order based on an alpha-numeric sort of their file names.
Apache will follow symbolic links to read configuration files, so you can create links in these directories and locations to files that are actually located elsewhere in your file system.
In accordance with best practices, we do not recommend modifying the default configuration file in most cases, as most control of Apache can be administered from files included in the conf.d/ directory, which can help administrators avoid unforeseen conflicts. If you do decide to edit httpd.conf, make a backup of the standard configuration file, as well as backups of known-working states. This will help you quickly restore your server to a working state in case your modifications introduce an unforeseen error.
cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd-conf.backup-1
One of Apache's prime strengths is its extreme customizability and flexibility. With its support for a large number of modules, there are few web serving tasks that Apache cannot fulfill. By default, modules are located in the /etc/httpd/modules/ directory. Configuration directives for the default modules are located in /etc/httpd/conf/httpd.conf, while configuration options for optional modules installed with yum are generally placed in .conf files in /etc/httpd/conf.d/.
To see if a module is enabled, look in "conf" files for lines beginning with LoadModule statements. The following two grep commands should generate a list of currently available modules:
grep ^LoadModule /etc/httpd/conf/httpd.conf grep ^LoadModule /etc/httpd/conf.d/*
To disable an existing module (at your own risk) edit the file in question, and comment out the LoadModule statement by prefixing the line with a hash (e.g. #).
To get a list of available Apache modules modules in the CentOS repository use the following commands:
yum search mod_
You can then install one of these modules with the command:
yum install mod_[module-name]
Modules should be enabled and ready to use following installation, though you may have to apply additional configuration options to have access to the modules' functionality. Consult the Apache Module Documentation for more information regarding the configuration of specific modules.
The .htaccess file is the Apache configuration interface that many webmasters and developers have the most experience with. Entering configuration options in these files allow you to control Apache's behavior on a per-directory basis. This allows you to "lock" a directory behind a password wall (for instance) to prevent general access to it. Additionally, directory specific .htaccess files are a common location to specify rules for rewriting URLs.
Remember that options specified in an .htaccess file apply to all directories below the file. Furthermore, note that all options specified in .htaccess files can specify higher level configuration locations. If this kind of configuration organization is desirable for your setup you can specify directory-level options using <Directory > blocks within your virtual host.
By Default, the httpd.conf file is restricted to not allow overrides. You Will need to adjust the following lines to allow them:
<Directory /srv/www> Options FollowSymLinks AllowOverride All </Directory>
In a non web accessible directory, we need to create a .htpasswd file. For example, if the document root for your Virtual Host is /srv/www/example.com/public_html/, use /srv/www/example.com/. Enter this directory:
Using the htpasswd command we'll create a new password entry for a user named cecil:
htpasswd -c .htpasswd cecil
Note, you can specify an alternate name for the password file (eg. .htpasswd), which might be prudent if you wanted to store a number of .htpasswd files for different directories in the same location.
These usernames and passwords need not (and should not) correspond to system usernames and passwords. Also, you can specify how passwords are encrypted/hashed with the -m flag for MD5, or -s for SHA hashes. Furthermore, note that when you're adding additional users to the .htpasswd file you should not use the -c option (which creates a new file).
In the .htaccess file for the directory that you want to protect, add the following lines:
AuthUserFile /srv/www/example.com/.htpasswd AuthType Basic AuthName "Advanced Choreographic Information" Require valid-user
Note, that the AuthName is presented to the user as an explanation in the authentication dialog for what they are requesting access to on the server.
The mod_rewrite engine is very powerful, and is available for your use by default. Although the capabilities of mod_rewrite far exceed the scope of this section, we hope to provide a brief outline and some common use cases.
In a <Directory > block or .htaccess file, enable mod_rewrite with the following line:
File excerpt:Apache Virtual Host Configuration or .htaccess
Now, you may create any number of separate rewrite rules. These rules provide a pattern that the server compares incoming requests against, and if a request matches a rewrite pattern, the server provides an alternate page. Here is an example rewrite rule:
File excerpt:Apache Virtual Host Configuration or .htaccess
RewriteRule ^post-id/([0-9]+)$ /posts/$1.html
Let's parse this rule. First, note that the first string is the pattern for matching against incoming requests. The second string specifies the actual files to be served. Mod_rewrite patterns use regular expression syntax: the ^ matches to the beginning of the string, and the $ matches to the end of the string, meaning that the rewrite engine won't rewrite strings that partially match the pattern.
The string in question rewrites all URLs that specify paths that begin with /post-id/ and contain one or more numbers (eg. [0-9]+), serving a corresponding .html file in the /posts/ directory. The parenthetical term or terms in the pattern specify a variable that is passed to the second string as $1, $2, $3 and so forth.
There are many other possibilities for using mod_rewrite to allow users to see and interact with useful URLs, while maintaining a file structure that makes sense from a development or deployment perspective.
You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.
This guide is licensed under a Creative Commons Attribution-NoDerivs 3.0 United States License.
Last edited by Sharon Campbell on Tuesday, November 19th, 2013 (r3950).