CHAPTER 3:

CONFIGURATION
FILES

Web Administration –FWD 213

 MAIN CONFIGURATION FILES
▪ Apache HTTP Server is configured using the main configuration file [Link] (on Ubuntu [Link]).
▪ The location of this file is set at compile-time, but may be overridden with the -f command line flag.

▪ Other configuration files may be added to the main configuration file [Link] using INCLUDE directive,
and wildcards expressions can be used to include many configuration files.
▪ Example: the following code will include the configuration file “[Link] “and all the “*.conf” files inside the
directory “conf/vhosts”.

▪ Any directive may be placed in any of these configuration files. Changes to the main configuration files are
only recognized by httpd when it is started or restarted.
SYNTAX OF THE
CONFIGURATION FILES
▪ Httpd configuration files managed by placing directives in plain text configuration files, one per line.
▪ The backslash "\" may be used as the last character on a line to indicate that the directive continues
onto the next line. There must be no other characters or white space between the backslash and the
end of the line.
❑ Directives:

▪ Consists of the directive name followed by a series of one or more space-separated arguments. If an
argument contains a space, the argument must be enclosed in double quotes.
- DirectiveName [argument-list]
▪ Directives in the configuration files are case-insensitive, but arguments to directives are often case
sensitive.
▪ Lines that begin with the hash character "#" are considered comments, and are ignored.
Comments may not be included on the same line as a configuration directive.
[Link]
FILE IN
UBUNTU
SYNTAX OF THE
CONFIGURATION FILES
▪ The values of variables defined with the Define directive, and can be used in configuration file lines using
the syntax ${VAR}.
- Define parameter-name [parameter-value]
▪ If "VAR" is the name of a valid variable, the value of that variable is substituted into that spot in the configuration
file line, and processing continues as if that text were found directly in the configuration file.
▪ Variable names may not contain colon ":" characters.

Define servername [Link]

Define SSL
DocumentRoot "/var/www/${servername}/htdocs"

▪ You can check your configuration files for syntax errors without starting the server by using apachectl configtest
or the -t command line option.
 MODULES
▪ The Apache HTTP Server is a modular program where the administrator can choose the functionality to include in
the server by selecting a set of modules. Functions are in the form of modules.
▪ Only the most basic functionality is included in the core server. Extended features are available through external
modules , called Dynamic Shared Objects (DSOs), which can be dynamically loaded into httpd using LoadModule
directive.
▪ The LoadModule directive links in the object file or library (filename) and adds the module structure named
(module) to the list of active modules.
- LoadModule module filename
▪ Example

▪ To see which modules are currently compiled into the server, you can use the apachectl -l command line option. You
can also see what modules are loaded dynamically using the -M command line option.
▪ apachectl -M: list all Apache installed modules.
$APACHECTL -M
▪ Static: modules included in the server at compile-time.
▪ Dynamic: modules loaded using the LoadModule
directive.
 SCOPE OF DIRECTIVES (CONTAINERS)
❑Directives placed in the main configuration files apply to the entire server.
❑Scope of Directives:
▪ Change the configuration for only a part of the server.
▪ You can scope your directives by placing them in <DIRECTORY>,
<DIRECTORYMATCH>, <FILES>, <FILESMATCH>, <LOCATION>, and
<LOCATIONMATCH> sections.
▪ These sections limit the application of the directives which they enclose to
particular filesystem locations or URLs. They can also be nested, allowing for
very fine-grained configuration.
SCOPE OF DIRECTIVES (CONTAINERS)

▪ Httpd has the capability to serve many different websites

simultaneously. This is called Virtual Hosting.
▪ Directives can also be scoped by placing them inside
<VIRTUALHOST> sections, so that they will only apply to requests
for a particular website.
▪ Although most directives can be placed in any of these sections,
some directives do not make sense in some contexts. For example,
directives controlling process creation can only be placed in the
main server context.
 .HTACCESS FILES
▪ Per-directory configuration files
▪ Httpd allows for decentralized management of configuration via special files placed inside
the web tree.
▪ The special files are usually called .htaccess, but any name can be specified in the
AccessFileName directive inside the main configuration file .
▪ Directives placed in .htaccess files apply to the directory where you place the file, and all
sub-directories.
▪ The .htaccess files follow the same syntax as the main configuration files. Since .htaccess
files are read on every request, changes made in these files take immediate effect.
▪ The server administrator further controls what directives may be placed in .htaccess files
by configuring the AllowOverride directive in the main configuration file.
.HTACCESS FILES
 ALLOWOVERRIDE DIRECTIVE
▪ Determines the types of directives that are allowed in .htaccess files
▪ When the server finds an .htaccess file (as specified by AccessFilename directive in the main
configuration file), it needs to know which directives declared in that file can override earlier
configuration directives.
Basic directives
▪ When this directive is set to None, .htaccess files are completely ignored. In this case, the server
will not even attempt to read .htaccess files in the filesystem.
▪ Example :
AccessFileName .acl

▪ Before returning the document /usr/local/web/[Link], the server will read

/.acl, /usr/.acl, /usr/local/.acl and /usr/local/web/.acl for directives unless they have
been disabled with: <Directory "/">
AllowOverride None
</Directory>
[Link]
 CONFIGURATION SECTIONS
▪ Directives in the configuration may apply to the entire server, or they may be restricted to apply only to
particular directories, files, hosts, or URLs using the configuration section containers.
❑ Types of Configuration Section Containers:

❖ Containers that evaluated for each request. The enclosed directives are applied only for those requests that
match the containers.
➢ <DIRECTORY>, <DIRECTORYMATCH>.

➢ <FILES>, <FILESMATCH>.

➢ <LOCATION>, <LOCATIONMATCH>.

❖ Containers that evaluated only at server startup and restart. If their conditions are true at startup, then the
enclosed directives will apply to all requests.
➢ <IFDEFINE>

➢ <IFMODULE>

➢ <IFVERSION>
 THE <IFDEFINE> CONTAINER.
▪ It encloses directives that will only be applied if an appropriate parameter is
defined on the httpd command line using –D parameter.
▪ -D parameter:
o Sets a configuration parameter which can be used with <IfDefine> sections in the configuration files to
conditionally skip or process commands at server startup and restart.

▪ For example, with the following configuration, all requests will be redirected to
another site only if the server is started using httpd –DClosedForNow.

<IfDefine ClosedForNow>
Redirect "/" "[Link]
</IfDefine>
 THE <IFMODULE> CONTAINER
▪ It encloses directives that will only be applied if a particular module is available in
the server.
▪ The module must either be statically compiled in the server, or it must be
dynamically compiled and its LoadModule line must be earlier in the
configuration file.
▪ This directive should only be used if you need your configuration file to work
whether or not certain modules are installed. It should not be used to enclose
directives that you want to work all the time, because it can suppress useful error
messages about missing modules.
▪ Example: the MimeMagicFile directive will be applied only if mod_mime_magic is
available. <IfModule mod_mime_magic.c>

MimeMagicFile "conf/magic"
</IfModule>
THE <IFVERSION> CONTAINER
▪ Very similar to <IFDEFINE> and <IFMODULE>, except it encloses
directives that will only be applied if a particular version of the server is
executing.
▪ This module is designed for the use in test suites and large networks
which have to deal with different httpd versions and different
configurations.

<IfVersion >= 2.4>

# this happens only in versions
greater or
# equal 2.4.0.
</IfVersion>
 FILESYSTEM & WEBSPACE
▪ The most commonly used configuration section containers are the ones
that change the configuration of particular places in the filesystem or
webspace.
▪ The filesystem: is the view of your disks as seen by your operating system.
▪ For example, in a default install, Apache httpd resides at /usr/local/apache2 in the Unix
filesystem, "c:/Program Files/Apache Group/Apache2" in the Windows filesystem.
▪ The webspace: is the view of your site as delivered by the web server and
seen by the client. So, the path /dir/ in the webspace corresponds to the
path /usr/local/apache2/htdocs/dir/ in the filesystem of a default Apache
httpd install on Unix.
▪ The webspace need not map directly to the filesystem, since webpages may be
generated dynamically from databases or other locations.
 FILESYSTEM CONTAINERS
▪ The <DIRECTORY> and <FILES> directives, along with their regex counterparts, apply directives to parts of the
filesystem.
▪ Directives enclosed in a <DIRECTORY> section apply to the named filesystem directory and all subdirectories
of that directory (as well as the files in those directories).
▪ The same effect can be obtained using .htaccess files. For example, in the following configuration, directory
indexes will be enabled for the /var/web/dir1 directory and all subdirectories.

▪ Directives enclosed in a <FILES> section apply to any file with the specified name, regardless of what
directory it lies in. For example, the following configuration directives will - when placed in the main section
of the configuration file - deny access to any file named [Link] regardless of where it is found.
 FILESYSTEM CONTAINERS
▪ To address files found in a particular part of the filesystem, the <FILES> and
<DIRECTORY> sections can be combined.
▪ For example, the following configuration will deny access to
/var/web/dir1/[Link], /var/web/dir1/subdir2/[Link],
/var/web/dir1/subdir3/[Link], and any other instance of [Link] found
under the /var/web/dir1/ directory.
WEBSPACE CONTAINERS
▪ The <LOCATION> directive and its regex counterpart change
the configuration for content in the webspace.
▪ For example, the following configuration prevents access to
any URL-path that begins in /private.
▪ In particular, it will apply to requests for
[Link]
[Link] and
[Link] as well as any
other requests starting with the /private string.

▪ The <LOCATION> directive need not have anything to do with

the filesystem.
▪ For example, the following example shows how to map a
particular URL to an internal Apache HTTP Server handler
provided by MOD_STATUS. No file called server-status needs
to exist in the filesystem.
WILDCARDS AND REGULAR EXPRESSIONS

▪ The <DIRECTORY>, <FILES>, and <LOCATION> directives can each use shell-
style wildcard characters.
➢"*" matches any sequence of characters (everything).
➢"?" matches any single character.
➢ "[seq]" matches any character in seq.
➢ Note: The "/" character will not be matched by any wildcard; it must be
specified explicitly.
▪ If even more flexible matching is required, each container has a regular
expression (regex) counterpart <DIRECTORYMATCH>, <FILESMATCH>, and
<LOCATIONMATCH> that allow perl-compatible regular expressions to be used
in choosing the matches.
 WILDCARDS AND REGULAR EXPRESSIONS
▪ A non-regex wildcard section that changes the configuration of all
user directories could look as follows:
<Directory "/home/*/public_html">
Options Indexes
</Directory>

▪ Using regex sections, we can deny access to many types of image files (ends with .gif, .png, .jpg )
at once.

<FilesMatch "\.(gif|png|jpg)$">
Require all denied
</FilesMatch>
WHAT TO USE WHEN
▪ When applying directives to objects that reside in the filesystem
always use <DIRECTORY> or <FILES>.
▪ When applying directives to objects that do not reside in the filesystem
(such as a webpage generated from a database), use <LOCATION>.
▪ It is important to never use <LOCATION> when trying to restrict access
to objects in the filesystem.
▪ This is because many different webspace locations (URLs) could map to
the same filesystem location, allowing your restrictions to be avoided.
Directive Description: Example SERVER-WIDE
ServerRoot Base directory for the ServerRoot CONFIGURATION
server files. /usr/local/apache
ServerAdmin Email address that the ServerAdmin www-
server includes in error admin@[Link] The directives provided by
messages sent to the the CORE server which are
client.
used to configure the basic
ServerName Hostname or IP address ServerName operations of the server.
that the server uses to [Link] Or
identify itself. ServerName [Link]
DocumentRoot sets the directory from DocumentRoot "/usr/web"
which httpd will serve Or
files. DocumentRoot
"/var/www"
ErrorLog sets the name of the file ErrorLog
to which the server will "/var/log/httpd/error_log"
log any errors it
encounters.
 ACCESS CONTROL
▪ Apache's Require directive provides a variety of different ways to allow or deny access to resources.
▪ These authorization providers affect which hosts can access an area of the server.
❑Require All Granted: Access is allowed unconditionally.
❑Require All Denied: Access is denied unconditionally.
▪ Access can be controlled by hostname, IP Address, or IP Address range.
❑Require IP
▪ The IP provider allows access to the server to be controlled based on the IP address of the remote
client.
▪ When Require ip ip-address is specified, then the request is allowed access if the IP address matches.
▪ Full IP address:
Require ip [Link]
▪ Partial IP address: the first 1 to 3 bytes of an IP address, for subnet restriction.

Require ip 10.1
ACCESS CONTROL
❑Require host
▪ The host provider allows access to the server to be controlled based on the host name of
the remote client.
▪ When Require host host-name is specified, then the request is allowed access if the host
name matches.
▪ (partial) domain-name

Require host [Link]

Require host .net [Link]

▪ Hosts whose names match, or end in, this string are allowed access.
▪ Only complete components are matched, so the above example will
match [Link] but it will not match [Link].
THANK YOU