Ubuntu - Apache Virtual Hosts


Now we have Apache installed and running, we can configure it to serve multiple domains using Virtual Hosts.


Contents

//

Create the layout

In this example we'll be using two domains: domain1.com and domain2.com.

In your home directory create a 'public_html' folder:

cd ~
mkdir public_html

Now for each domain we want to host create a folder with a standard set of sub-folders:

mkdir -p public_html/domain1.com/{public,private,log,cgi-bin,backup}

and

mkdir -p public_html/domain2.com/{public,private,log,cgi-bin,backup}

That will create the folders public, private, log, cgi-bin and backup for each of our domains (domain1.com and domain2.com).

index.html

The content of the public folder is, naturally, up to you but for this example I am going to use a very simple html file so we can check the virtual hosts work.

So for each domain create an index.html file:

nano public_html/domain1.com/public/index.html

add the following to the index.html file:

<html>
  <head>
    <title>domain1.com</title>
  </head>
  <body>

    <h1>domain1.com</h1>
  </body>
</html>

Repeat the process so you have a similar file for domain2.com (simply replace all instances of 'domain1.com' with 'domain2.com).

OK. Now we have a basic structure for our two domains we can look at defining two virtual hosts.

Virtual Hosts

NameVirtualHost

With virtual hosts, one thing that often confuses people is the NameVirtualHost setting.

For each interface and port on which Apache is set to listen on, we need a NameVirtualHost directive. Something to keep in mind is you can only define it once per port.

In the Apache layout for Ubuntu there is a default NameVirtualHost directive in the 'ports.conf' file. If you've worked through the Ubuntu - Apache configuration article, you may remember it being noted previously.

Let's take another look at the contents of 'ports.conf':

cat /etc/apache2/ports.conf

You should get the following output (unless you've previously modified the file):

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default

NameVirtualHost *:80
Listen 80

<IfModule mod_ssl.c>
    # SSL name based virtual hosts are not yet supported, therefore no
    # NameVirtualHost statement here
    Listen 443
</IfModule>

The default NameVirtualHost setting satisfies our requirements at present — Apache will apply named based virtual host logic and settings for HTTP requests made on any available interface (*) at port 80.

NOTE: the placement of the default NameVirtualHost directive in 'ports.conf' is new to Ubuntu's Apache layout; prior Ubuntu releases placed a similar setting in the default vhost.

Custom Virtual Hosts

We've set up the basics and now we're ready to add our own virtual hosts so we can start to serve our domains.

Let's go ahead and create the vhost file for domain1:

sudo nano /etc/apache2/sites-available/domain1.com

The contents look like this:

# Place any notes or comments you have here
# It will make any customisation easier to understand in the weeks to come

# domain: domain1.com
# public: /home/demo/public_html/domain1.com/

<VirtualHost *:80>

  # Admin email, Server Name (domain name) and any aliases
  ServerAdmin webmaster@domain1.com
  ServerName  domain1.com
  ServerAlias www.domain1.com


  # Index file and Document Root (where the public files are located)
  DirectoryIndex index.html
  DocumentRoot /home/demo/public_html/domain1.com/public


  # Custom log file locations
  LogLevel warn
  ErrorLog  /home/demo/public_html/domain1.com/log/error.log
  CustomLog /home/demo/public_html/domain1.com/log/access.log combined

</VirtualHost>

a2ensite

Now we have the site available, we need to enable it:

sudo a2ensite domain1.com

The output of the command is:

Site domain1.com installed; run /etc/init.d/apache2 reload to enable.

Seems like good advice:

sudo /etc/init.d/apache2 reload

Navigate

To test the domain without creating a DNS zone and record(s) on some Internet namserver(s), I've modified the '/etc/hosts' file on my local computer to include some entries mapping 'domain1.com', etc. to the demo Cloud Server's public IP:

127.0.0.1    localhost
...

# entries related to the demo Cloud Server
123.45.67.890   domain1.com
123.45.67.890   www.domain1.com
123.45.67.890   domain2.com
...

You can add similar entries in your own 'hosts' file, though it's location will vary depending on what OS is loaded on your local computer (try a Google search).

NOTE: entries in the 'hosts' file will need to be removed prior to testing and using live DNS zones and records created on Internet nameservers. Failure to remove them will likely lead to confusion on your part and inaccurate tests of new or modified public DNS records.

With such changes made for testing purposes, you can navigate to your site in a web browser on your local computer:

apache-vhostworking-domain1.jpg

Tada! You now have the contents of public/index.html being shown:

ServerAlias

Note that in the vhost file, we set a ServerAlias. Providing you have the DNS set up correctly you can also use that address - for quick testing purposes you can place another entry in your 'hosts' file (I've already done so in the example code given above):

apache-vhostworking-wwwdomain1.jpg

We'll talk about forcing one address or the other in a later article about rewrite rules.

Repeat as necessary

To create and enable domain2.com simply go through the process again:

sudo nano /etc/apache2/sites-available/domain2.com
...
# Enter the details for domain2.com as per the example shown above

Then enable the site and restart Apache:

sudo a2ensite domain2.com
...
sudo /etc/init.d/apache2 reload

Finally navigate to your second domain:

http://domain2.com
or
http://www.domain2.com

All being well, you will see the 'domain2.com' index file.

Log Files

As defined in the vhosts file, each domain has its own log files. Let's take a quick look:

ls /home/demo/public_html/domain1.com/log/

The output is exactly as expected:

access.log  error.log

This makes for much easier analysis as each set of logs is self contained.

Default

Remember that although we changed the default virtual host, we did leave it in place.

Now, if someone enters the IP address of the Cloud Server they are served the contents of that default vhosts file (providing, of course, you have not set up a separate vhost for the IP address).

Why are they served from that vhost file?

Apache searches the enabled vhosts in alphabetical order and if it can't find one for the requested IP address or domain name, it serves the first one (alphabetically).

If we had disabled or deleted the default vhost, then the contents of domain1.com would be displayed (being before domain2.com alphabetically).

This is something to keep in mind when planning your websites. Do you want a particular domain to be the default? Do you want the IP address to have completely different content?

Email

ServerAdmin

ServerAdmin webmaster@domain.com

Sets the email address for the server administrator - this will be used if you have setup the server to contact you on errors. It is also shown in the ServerSignature (if set to 'Email' - see below)

Domain Name

ServerName and ServerAlias

ServerName domain.com
ServerAlias www.domain.com

Sets the domain name for the virtual host. You can have as many aliases as required. For example, you can have domain.com and domain.net point to the same content.

Note this is not a rewrite rule (we'll look at those later) but the domains defined here will serve the same content (assuming you have set the DNS to point to your Cloud Server IP).

Index Files

DirectoryIndex

DirectoryIndex index.html

Defines the index file (the 'home' page that is shown on entering the domain address). Useful if you have want the user to be directed to an alternate page or to a non-standard home page.

Do note this is not a good way of redirecting users as they may go directly to a non specified page such as domain.com/index.php whilst the DirectoryIndex will only work for those entering domain.com.

Documents

DocumentRoot

DocumentRoot /home/demo/public_html/domain.com/public

The location of the domain's public files. Use an absolute path name.

Log Files

ErrorLog and CustomLog

LogLevel warn
ErrorLog  /home/demo/public_html/domain.com/log/error.log
CustomLog /home/demo/public_html/domain.com/log/access.log combined

Set the Log levels and the location for the Virtual Hosts log files. Very useful for easy analysis of the domain statistics.

Error Documents

ErrorDocument

ErrorDocument 404 /errors/404.html
ErrorDocument 403 /errors/403.html

Used for all the standard error messages.

In these examples I have an 'errors' folder in my public directory. I created each error document and place them in the 'errors' folder. The paths shown are relative to the DocumentRoot folder defined above.

If not defined, Apache will generated its own error pages. Custom error pages are more user friendly and can be customised as much, or as little, as you want.

Apache Footers

ServerSignature

ServerSignature On

Sets whether the server details are displayed in any server generated error pages or index lists. Options are On, Off and Email.

Note the level of detail in the signature is configured via ServerTokens which cannot be set in the Virtual Hosts file - for Ubuntu's Apache layout this is properly set in '/etc/apache2/conf.d/security'. See the Apache configuration #2 article for more details.

If set to Email, the ServerAdmin email will be displayed.

cgi-bin

ScriptAlias

ScriptAlias /cgi-bin/ /home/demo/public_html/domain.com/cgi-bin/
<Location /cgi-bin>
  Options +ExecCGI
</Location>

Enables the cgi-bin location as defined by the custom virtual hosts layout. You can, of course, leave the cgi-bin in the DocumentRoot location if you so wish.

Directory

<Directory xxx/xxx>

<Directory /home/demo/public_html/domain.com/public>
  Options FollowSymLinks
</Directory>

Set the Options for the specified directory - the example shown allows the Option FollowSymLinks to be enable for the public directory of domain.com

Listed below are further Options that can be set:

Directory Browsing

Options

Options -Indexes

To turn off directory browsing use '-Indexes' or 'None'. To turn them on, use '+Indexes'.

SSI

Options

Options -Includes

This Option disables Server Side Inlcudes.

Symlinks

Options

Options -FollowSymLinks

Enable or disable the option to follow symlinks. Be careful with this option as it can lead to security risks (inadvertently linking to configuration folders).

You can consider using the SymLinksIfOwnerMatch directive instead of FollowSymLinks. The SymLinksIfOwnerMatch allows symbolic links to be followed only if the owner of the link is identical to the owner of the target file or directory (in terms of Linux filesystem ownership/permissions). Thus preventing many of the security risks that a simple FollowSymlinks directive can create.

.htaccess

AllowOverride

AllowOverride None

Setting AllowOverride to none disables .htaccess support. Set to All to allow them.

You can also specify which .htaccess features to enable such as:

AllowOverride AuthConfig Indexes

The Apache htaccess and AllowOverride docs have more information on the different features.

Remember to specifically protect your .htaccess file. This can be done in two ways:

Firstly rename it to something obscure and, secondly, deny access to the file from external sources:

AccessFileName .myobscurefilename
<Files ~ "^\.my">
    Order allow,deny
    Deny from all
    Satisfy All

</Files>

No Options

Options

Options None

This will turn off all the available options.

Hierarchy

Remember that the Options directives can be set per directory like this:

<Directory />
  AllowOverride None
  Options None
</Directory>

<Directory /home/demo/public_html/domain.com/public>
  AllowOverride All
</directory>

This will turn of all Options and disable .htaccess support for all directories.

However, the second Directory setting will override the first and allow .htaccess support for the domain.com/public directory.

Summary

The Virtual Hosts file is at once an easy tool to use and a very powerful one. My advice is to enter one setting and test it. Then enter the next setting and so on.

Once familiar you will see you have fine control over all of your web folders and files.



Was this content helpful?




© 2014 Rackspace US, Inc.

Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License


See license specifics and DISCLAIMER