Reme Le Hane

In a previous tutorial, we took a look at some of the most basic, but important, Apache configuration directives – what they are for, and how to edit them to fit our needs. For a very basic website (perhaps one with just a few static HTML pages), those simple directives might be all you need to know. Chances are, however, you need a more complex website; today we will look at some advanced directives and configuration settings.

Apache’s behavior is controlled through settings and directives applied in plain-text configuration files that usually end with the extension “.conf”.

The most important .conf file is httpd.conf, although that depends on your particular installation and Linux distribution (for example, it might be called apache2.conf instead). These configuration files generally apply to the server as a whole, even if the server is hosting multiple websites.

Per-directory configuration files are called “.htaccess” files by default, and are located within the web server’s public document directory. These allow certain directives to be applied to certain directories and their sub-directories, rather than the entire server and all its hosted websites. Though not advised, you can change the name of the .htaccess file to something else using the AccessFileName directive, which can be set in httpd.conf: # # AccessFileName: The name of the file to look for in each directory # for additional configuration directives. # AccessFileName .htaccess

Please note that htaccess is not an extension; it is the file’s name. On UNIX-like operating systems, the dot (.) preceding a file name signifies that the file is hidden.

Considering their location in the file system, not all directives can be applied in .htaccess files, as some might simply not be valid. Every line in a configuration file must begin with one of the following:

* a #, indicating a comment
* a valid directive
* a space
* an empty line

If a line does not begin with one of the above options, Apache will issue an error message instead of starting its HTTP service. So, it is important for you to ensure that the server configuration is valid. If a directive spans over multiple lines, end each line with a back slash (\) before proceeding to the next directive.
—-

Maintaining Flexibility

The most important .conf file is httpd.conf.

While making your own changes to the default configuration files, it is best to break those changes out into external files (with meaningful names, of course), and include them in the main configuration file, using the include directive. If separating your settings from the server’s default settings is not possible, at least make a habit to comment out old settings before introducing new ones. This will make it easier to roll back to any file version if the need arises, and it also allows you to upgrade to a newer version of the httpd.conf file with minimum hassle. All you need to do is copy the new version in place of the old, and re-insert your includes at the end of the new file (or at least re-apply your old changes after commenting out the default ones in the new file). For example: … # End of default apache configuration #Beginning of your new configuration and settings # Include ports listing Include /etc/apache2/ports.conf # Include generic snippets of statements Include /etc/apache2/conf.d/ # Include module configuration: Include /etc/apache2/mods-enabled/*.load Include /etc/apache2/mods-enabled/*.conf

As you can see from the example above, you can include a specific file by name, a directory (and all files and sub-directories therein), or multiple files by using wildcards.
—-

Advanced Setup

In my previous tutorial on Apache, you learned some basic directives that control Apache’s behavior. In this tutorial, we’ll look at a few advanced directives, starting with .

The Directive

The directive allows you to specify settings and directives to apply to directories and sub-directories. This gives you the ability to do all sorts of things, such as limiting access to certain directories and files, and turning on or off certain options to certain directories, among other things.

The tags take a path and enclose a block of options to be applied to that directory and its sub-directories. Here is an example: Options None AllowOverride None Order Deny,Allow Deny from all

The opening tag in this example specifies a path of /, which means the root directory and all its sub-directories and files. The settings defined inside the tags apply to the / path (essentially everything in the root).

Note that htaccess is not an extension; it is the file’s name.

The Options directive declares which server features are valid for the specified directory. In this example, no options are valid for the / path. But you could specify any number of options, like allowing symbolic links, allowing the execution of CGI scripts, allowing server-side includes, and many more.

The AllowOverride directive tells the server which settings declared within the tags to override if they are reset in the .htaccess file. When the server finds an .htaccess file, it needs to know which directives declared in that file can override earlier configuration directives. If AllowOverride is set to None, as shown in the example above, then no directives are overridden and any re-declarations in the .htaccess files are completely ignored.

If the AllowOverride directive is set to All, then any directive re-declared in the .htaccess file will override earlier configuration directives. AllowOverride can take specific directive types that can be overridden while the rest will be ignored.

Deny and Allow control access to the directory specified within the opening tag, and are prioritized through the Order directive.

In the above example, Order Deny, Allow means all connecting hosts or IP addresses are denied access to the root directory, except those declared as good hosts. Order Allow, Deny on the other hand would mean that all hosts and IPs are to be allowed access to the root directory except those declared as bad or black-listed.

The Deny from all setting declares that access needs to be denied from all hosts. Since it is not followed by a whitelist, no hosts or IPs have access to the root directory (and this is how it should be for security reasons). For demonstration purposes ONLY, the below example demonstrates how to deny access from all hosts except www.goodhost1.com and www.goodhost2.com: Order Deny,Allow Deny from all Allow from www.goodhost1.com www.goodhost2.com http://goo.gl/D82cMwww.goodhost1.com and www.goodhost2.com: Order Deny,Allow Deny from all Allow from www.goodhost1.com www.goodhost2.com http://goo.gl/D82cM Reme Le Hane