Continuing from Gentoo - Apache Virtual Hosts #1, we'll look in detail at some of the additional settings available to us in Apache's virtual host configuration files.
Familiarity with these settings will allow us to exercise better control over the domains we're serving.
Some of the settings we'll discuss were introduced in the previous article, but some are new.
Take the time to read through these explanations, and you'll soon appreciate the flexibility and power of "vhosts" (virtual hosts).
Already Mentioned Settings
Lets start by taking a closer look at some of the settings we saw previously in "domain1.com.include":
Sets the email address for the server administrator. If we've setup Apache to contact us when it throws errors, it uses this address. It's also shown in the server's "signature", if that directive is set to "Email" — see below.
ServerName and ServerAlias
ServerName domain1.com ServerAlias www.domain1.com
These settings determine which vhost configuration Apache will use when it receives an HTTP request for a domain name that resolves to our slice's IP.
The first directive sets the domain name for the virtual host; and then we can have as many aliases as required. For example, we can have "domain1.com" and "domain1.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 their DNS records resolve to our slice's IP.
Defines the index file — the "home" page that is shown when loading the domain name into a browser. Useful if we want visitors to be directed to an alternate page or to a non-standard home page.
Do note this is not a good way of redirecting visitors, as they may go directly to a page they manually specify or have stored in a bookmark — such as "http://domain1.com/index.php" — while "DirectoryIndex" will only be applied for visitors requesting "http://domain1.com/".
The location of the domain's public files. We need to use an absolute path.
ErrorLog and CustomLog
LogLevel warn ErrorLog /home/demo/public_html/domain1.com/log/error.log CustomLog /home/demo/public_html/domain1.com/log/access.log combined
Sets the log levels and the location for the virtual host's log files. Very useful for analysis of our domain's traffic.
Here are some of the settings we haven't seen before, but they could be added to our virtual host configurations.
ErrorDocument 404 /errors/404.html ErrorDocument 403 /errors/403.html
Used for all the standard error messages.
In this example I have an 'errors' folder in my public directory, i.e. the directory specified by "DocumentRoot". Note that paths for the error documents are relative to "DocumentRoot".
I created the error documents and placed them in the 'errors' folder. I'll leave their creation and placement as an exercise for the reader.
If "ErrorDocument" isn't defined, Apache will generate its own error pages. Consider, though, that custom error pages are more user friendly and can be tailored as much or as little as we'd like.
Sets whether the server details are displayed in any server-generated error pages or index lists.
Valid settings are: On, Off, Email.
If set to "Email", the value from our "ServerAdmin" directive will be displayed.
NOTE: the level of detail in the signature is configured via the "ServerTokens" directive, which cannot be set in our vhost files.
For Gentoo's Apache layout, "ServerTokens" is properly set in '/etc/apache2/modules.d/00_default_settings.conf'. See Apache configuration #2 for more details.
ScriptAlias /cgi-bin/ /home/demo/public_html/domain1.com/cgi-bin/ <Location /cgi-bin> Options +ExecCGI </Location>
Enables a custom '/cgi-bin' location per virtual host. We can leave cgi-bin in the "DocumentRoot" location if we wish.
Now we'll look at some options that can be applied to different directories.
<Directory /home/demo/public_html/domain1.com/public> Options FollowSymLinks </Directory>
Sets the "Options" for a specified directory. This example shows the "FollowSymLinks" option enabled for the root directory of domain1.com.
Here are some further Options we could set:
To disable directory browsing we would use "-Indexes" or "None". To enable it use "+Indexes".
This example disables "server side includes" (SSI). More information on SSI can be found in the Apache docs.
Enable or disable this option to have HTTP requests follow symlinks. We need to be careful with this option as it can involve security risks, e.g. inadvertently linking our website's visitors to our configuration folders.
One thing we can consider is using the "SymLinksIfOwnerMatch" directive instead of "FollowSymLinks".
The "SymLinksIfOwnerMatch" directive 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 file system ownership-permissions. That approach prevents many of the security risks that a simple "FollowSymlinks" directive can create, though we still need to be careful.
Setting "AllowOverride" to "none" disables support for .htaccess files in this particular directory. We would use the "All" setting to allow them.
We can also specify which .htaccess features to enable such as:
AllowOverride AuthConfig Indexes
We need to specifically protect our .htaccess files. This can be done in two ways:
First, by renaming them to something obscure. Second, by denying access to those files from external sources.
To this effect, we would place the following directives and options in our vhost config, and would use the filename ".myobscurefilename" in place of ".htaccess".
AccessFileName .myobscurefilename <Files ~ "^\.my"> Order allow,deny Deny from all Satisfy All </Files>
This will turn off all available options for our "Directory" directive.
Remember that Options directives can be set per directory:
<Directory /> AllowOverride None Options None </Directory> <Directory /home/demo/public_html/domain1.com/public> AllowOverride All </Directory>
This will turn of all Options and disable .htaccess support for all directories in our slice's filesystem.
However, the second "Directory" directive will override the first and allow .htaccess support for our 'domain1.com/public' directory.
Virtual host configuration files are both easy to use and very powerful tools! My advice is to enter one setting at a time, and then test it. Then enter the next setting, and so on.
Once we're familiar with the settings and their effects, we'll have much finer control over all our domains.