Apache Virtual Hosts on Fedora - part 2

With the base apache virtual host configs in place on your Fedora server, let's look at other settings you may want to apply to them.

More fun with virtual hosts

Now that we have basic configs in place for our virtual hosts, let's look at how you can customize them further for your purposes. Some of the settings we'll look at were introduced in the previous article, and some were discussed in the articles about the basic apache config, but some are new.

It's worth keeping in mind that some directives can be set both in apache's main config and in a virtual host's config. If there's a conflict, the setting within the relevant "VirtualHost" config block will take priority.

Take the time to read through the explanations and you will soon have an understanding of how powerful vhosts actually are.


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)

ServerName and ServerAlias

ServerName www.domain.com
ServerAlias domain.com

The ServerName sets the domain name for the virtual host. You can have as many domain aliases as required, all set with ServerAlias directives. For example, you can have domain.com and domain.net point to the same content.

Note this is not a rewrite rule (those are handled by the rewrite module, which we won't cover here), but the domains defined here will serve the same content (assuming you have set the domains' DNS to point to your server IP address).


DirectoryIndex index.html

Defines the index file, which is the page the server will default to if a visitor doesn't specify the file they want to view. Useful if you want the user to be directed to an alternate page or to a non-standard home page (like "index.php"). You can list more than one file in this directive, and apache will serve up the first one it finds:

DirectoryIndex index.php index.html

This setting is checked if someone just goes to your domain address, but can be overridden by someone entering a filename as part of the URL (like "http://www.example.com/index.html").


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

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

If someone goes to just your domain as an address, the server uses the DocumentRoot setting to determine where to look for the files to serve up, then checks the DirectoryIndex setting to decide which of those files to show the visitor.

When a URL specifies subdirectories or files, the location where the server will look for them will be relative to the DocumentRoot. So for the URL:


The server will look for the file here:

{the DocumentRoot for that virtual host}/main/sub/waffles.html

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 host's log files. Very useful for easy analysis of the domain statistics. The ErrorLog setting tells apache where to put errors it logs for the virtual host (determined by the LogLevel directive), and the CustomLog setting is where apache will log everything else.

The "combined" log type is good for most people's needs, but if you poke around the main config files you'll find where other custom log types are defined as well. Using a different custom log type will change what apache logs when a client accesses the server as well as how the recorded data is ordered.


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 vhost's public directory. I created each error document and placed it in the "errors" folder. The paths shown are relative to the DocumentRoot folder defined above.

If not defined, Apache will generate its own error pages. Custom error pages can provide a more consistent user experience if an error is encountered, and can present any other information you would want the lost user to see (like a link to your site map or back to the site's home page).


ServerSignature On

Sets whether the server details are displayed in any server generated error pages or index lists. Options are On, Off and Email. Back in the apache config articles we looked at this directive in detail as well as the ServerTokens directive that controls how much information is reported in the ServerSignature.

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

ScriptAlias and cgi-bin

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

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 /home/demo/public_html/domain.com/public>
  Options FollowSymLinks

Set the Options for the specified directory - the example shown above enables FollowSymLinks for the public directory of domain.com.

Let's take a look at a few of the features you can set or disable through the Options part of a Directory block. A feature is explicitly disabled if it's listed with a minus ("-") in front of it, and is enabled if it is listed without a modifier or with a plus ("+") in front of it.


Options -Indexes

To turn off directory browsing use '-Indexes' or 'None'. To turn them on, use '+Indexes'. Directory browsing will present a web client with a list of files in a directory if one of the DirectoryIndex files was not found there.


Options -Includes

The Includes Option enables or disables Server Side Includes. If you don't know what those are, odds are good you won't want them enabled.

FollowSymLinks and SymLinksIfOwnerMatch

Options -FollowSymLinks

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

You can, consider using the SymLinksIfOwnerMatch directive instead of FollowSymLinks. The SymLinksIfOwnerMatch option 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 and permissions). This approach can bypass several of the more common security risks a simple FollowSymlinks directive can create.


AllowOverride None

Setting AllowOverride to none disables .htaccess support. Set to All to allow them. The .htaccess file can provide a means of controlling directory options outside of apache configuration files. This is most useful when you want a user to be able to change some of those options but don't want them to have access to the main config files, but it's also commonly used to password-protect a directory.

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

AllowOverride AuthConfig Indexes

The Apache htaccess and AllowOverride docs have more information on what features are available and how to use them.

It's a good idea to obscure your .htaccess file by, well, not calling it .htaccess. You can also explicitly prevent web browsers from being able to view the contents of the .htaccess file. For example:

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


Options None

This will turn off all available options, including those that might normally be enabled by default or are enabled for a parent directory.


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

<Directory />
  AllowOverride None
  Options None

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

The first Directory block will turn off all Options and disable .htaccess support for all directories.

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


The virtual host is at once an easy tool to use and a very powerful one. It can be tricky to troubleshoot though, so it's often best to make only one change at a time to a virtual host configuration, moving on to the next change after each is tested.

Once you've mastered the art of virtual host configuration, you'll have fine-grained control over all your web folders and files. You have the web server ready to go, but you might consider one more step: Setting up logrotate so your virtual host logs don't get out of hand.

  • -- Jered
Want to comment?

(not made public)


(use plain text or Markdown syntax)