Apache Virtual Hosts on Arch - part 1

Now that apache is running and configured on your Arch server we can add virtual hosts to let it serve more than one domain.

Virtual Hosts

Your apache server should be set up now, and you should have a handle on your basic configuration options. Apache may be answering requests, but if you want to be able to handle more than one domain with one web server, you'll need to set up a virtual host for each. We'll go through setting up a couple sample domains via virtual hosts.

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}


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).


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:


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.

Set the permissions

In order for apache to serve your web pages, the apache process will need to have read permissions for the various files that comprise your sites. We won't go into detail here (you can refer to this series on permissions if you want the details later), but to make sure the permissions are the way we need them run the following two commands:

sudo chmod -R a+rX ~/public_html
sudo chmod a+rx ~

The first command sets everything in your public_html directory to be readable and accessible by all users on the system. The second command sets your home directory to be the same way (though not all the files in it, like we did with public_html). Note that the "X" in the first command is capitalized.

If you add more directories for additional virtual domains later, run that first command again to make sure the new directories are accessible as well.

Custom Virtual Hosts

We've set up the basics and now we're ready to add our own virtual hosts.

First we should set up a new directory to hold our virtual host config files. Putting each virtual host in its own file will make it easier to edit, enable, or disable them in the future:

sudo mkdir /etc/httpd/conf/vhosts

We'll also add a line to the end of the main apache config file (/etc/httpd/conf/httpd.conf) to read files from that directory:

Include conf/vhosts/*.conf

Make sure this Include is placed after the Include for the "custom" directory. It's a bit safer to have the virtual host configurations load after any other configuration changes, like enabling NameVirtualHost.

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

sudo nano /etc/httpd/conf/vhosts/domain1.com.conf

You'll want to tailor this for your own domain, of course, changing the username, directory, and domain name involved. Make sure all the settings relevant to this particular virtual host are inside the "VirtualHost" config block, or those settings will be treated like they're applying to apache's main configuration (because of the way the Include directive we discussed back in the configuration files article works).

As a general template use the following:

# Place any notes or comments you have here
# It will make any customization 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  www.domain1.com
  ServerAlias 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


Reload apache

To have apache use the new virtual domain we'll need it to reload its settings:

sudo /usr/sbin/apachectl graceful


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

# entries related to the demo slice   domain1.com   www.domain1.com   domain2.com

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

NOTE: Remember to remove those hosts entries when you're done with testing. It can get confusing down the line if you forget they're there, and find yourself directed to someplace other than what you've set in the public DNS records for your domain.

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

Domain1 Home Page

Tada! You should now see the index.html file you set up for your virtual host instead of apache's default page.


Note that in the vhost file we set a ServerAlias. Providing you have the DNS set up correctly you can also use that address to reach your site. For quick testing purposes you can place another entry in your "hosts" file (like I did in the example code given above):

Domain1 Home Page (hostname alias)

It is possible to force a browser that came into a site using a ServerAlias to switch to your main domain, but that involves the use of the "rewrite" module. For now we'll let it slide, but if it's important to switch someone to a main domain from an old one (that you would have set as a ServerAlias), you would need to look into using mod_rewrite to do it.

Repeat as necessary

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

sudo nano /etc/httpd/conf/vhosts/domain2.com.conf
# Enter the details for domain2.com as per the example shown above

To enable the site reload Apache:

sudo /usr/sbin/apachectl graceful

Finally add a hosts entry to your local machine and navigate to your second domain:


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

Log Files

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

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

The output should reflect what you set up in the virtual host's config:

access.log  error.log

Keeping the logs for each domain separate means you won't have as many log entries to dig through if you have a problem with just one particular domain.


It's important to note that apache is still set up with its default site configuration - listening to port 80, using a DocumentRoot of /srv/http, and several other details you can dig out of the main apache config file. You might want to change some of those default settings to match your primary site.

Another option is to comment out the following line in the httpd.conf file, changing this:

DocumentRoot "/srv/http"

to this:

#DocumentRoot "/srv/http"

If you use this approach you'll also need to delete the example virtual hosts in the "/etc/httpd/conf/extra/httpd-vhosts.conf" file.

Now apache will treat the first DocumentRoot it finds as the default, and that will be in the vhost config file that comes first alphabetically in your vhosts directory. If your primary domain doesn't come first alphabetically, put a "0" at the start of the file to make sure its config will.

You can then also comment out any other configuration options in the apache config files that you would prefer to have set by your default virtual host instead.


We've gone into some detail here but, overall, setting up a virtual host is relatively straightforward. There are many settings and configurations to take into account but you should have your site up and running in no time.

The next virtual host article will look in more detail at some of the settings that are available and what they mean.

  • -- Jered
Want to comment?

(not made public)


(use plain text or Markdown syntax)