Ubuntu 15.04 Server with systemd: Administration and Reference (2015)

Part II. Services

Chapter 8. Web Servers

The primary web server for Ubuntu is Apache, which has almost become the standard web server for all Linux distributions. It is a very powerful, stable, and fairly easy-to-configure server. Ubuntu provides default configuration for the Apache, making it usable as soon as it is installed.

Check the Ubuntu Server Guide | Web Servers | HTTPD for basic configuration.

https://help.ubuntu.com/stable/serverguide/httpd.html

Note: The Zope Application server for Web development is also included on the main Ubuntu repository. Zope application server (http://zope.org) is an open source web server with integrated security, web-based administration and development, and database interface features. It was developed by the Zope Corporation, which also developed the Python programming language.

Apache Web Server

The Apache web server is a full-featured, free HTTP (Web) server, developed and maintained by the Apache Server Project. The aim of the project is to provide a reliable, efficient, and easily extensible Web server, with free open source code made available under its own Apache Software License. The server software includes the server daemon, configuration files, management tools, and documentation. The Apache Server Project is maintained by a core group of volunteer programmers and supported by a great many contributors worldwide. The Apache Server Project is one of several projects currently supported by the Apache Software Foundation (formerly known as the Apache Group). This nonprofit organization provides financial, legal, and organizational support for various Apache Open Source software projects, including the Apache HTTPD Server, Java Apache, Jakarta, and XML-Apache. The website for the Apache Software Foundation is http://apache.org. Table 8-1 lists several Apache-related websites.

Apache was originally based on the NCSA web server developed at the National Center for Supercomputing Applications, University of Illinois, Urbana-Champaign. Apache has since emerged as a server in its own right, and become one of the most popular Web servers in use. Although originally developed for Linux and UNIX systems, Apache has become a cross-platform application with Windows and OS/2 versions. Apache provides online support and documentation for its web server at http://httpd.apache.org. An HTML-based manual also is provided with the server installation.

Table 8-1: Apache-Related Websites

Java: Apache Jakarta Project

The Apache Jakarta Project supports the development of Open Source Java software; its website is located at http://jakarta.apache.org. Currently, the Jakarta supports numerous projects, including libraries, tools, frameworks, engines, and server applications. Tomcat is an open source implementation of the Java Servlet and JavaServer Pages specifications. Tomcat is designed for use in Apache servers. JMeter is a Java desktop tool used to test performance of server resources, such as server lets and CGI scripts. Velocity is a template engine that provides easy access to Java objects. Watchdog is a tool that checks the compatibility of servlet containers. Struts, Cactus, and Tapestry are Java frameworks, established methods for developing Java web applications.

LAMP

During installation, you can install the Apache Web server as part of the LAMP collection of packages. LAMP stands for Linux Apache MySQL and PHP. It consists essentially of the Web server (Apache) with database support (MySQL) and programming capability (PHP). For programming, PHP is selected by default, though you could use Python or Perl instead. Together they provide a commercially capable Web site, supporting multiple users and complex data with application support. For a basic informational Web site, you only need the Apache Web server.

The LAMP packages include the following from the Ubuntu main repository.

apache2 The Apache Web server and all supporting packages

mysql-server The MySQL database server

php5-mysql and libapache2-mod-php5 The PHP support for MySQL and Apache

To install the LAMP package after installation, you would use the tasksel command in a terminal window with the install and lamp-server options.

sudo tasksel install lamp-server

To allow other hosts on your network to access your MySQL database, you have to set the MySQL server to accept access from the local network. You do this with the bind-address option in the mysqld section of the /etc/mysql/my.cnf configuration file. Initially, this option is set to the localhost, 127.0.0.1, allowing access only for your local machine. For a local network, you can change this to the IP address of your machine on that network, or the IP address of network device connected to the local network. If the address is allocated dynamically, comment out the bind-address entry. If you want to allow MySQL to use several interfaces, including localhost, you would set the bind-address to 0.0.0.0. This allows MySQL to use all your network interfaces.

Ubuntu Apache Installation

Ubuntu will provide you with the option of installing the Apache web server during the Ubuntu Server CD installation (LAMP package). Alternatively, you can install the Apache web server later as the apache2 package (see the Ubuntu Software Center, the Synaptic Package Manager, or apt-get). All the necessary directories and configuration files are automatically generated for you. Then, whenever you run Linux, your system is already a fully functional website. Every time you start your system, the web server will also start up, running continuously. On Ubuntu, the directory reserved for your website data files is /var/www. Place your web pages in this directory. Your system is already configured to operate as a web server. All you need to do is perform any needed network server configuration, and then designate the files and directories open to remote users. Once your website is connected to a network, remote users can access it.

Table 8-2: Apache Web Server Files and Directories

The web server normally sets up your website in the /var/www directory. A simple index.html test page is installed for you to check if your Web server is working. Your configuration files are located in a different directory, /etc/apache2. Table 8-2 lists the various Apache web server directories and configuration files.

Table 8-3: Apache management tools

The Apache manual is installed from the apacha2-doc package, and is placed in the /usr/share/doc/apache2-doc/manual directory in html format. You can access it with any browser as:

http://localhost/manual/index.html

Apache also installs several management applications, such as apache2ctl for starting and stopping the server, a2ensite for activating a Web site, and a2enmod for enabling particular modules. The /etc/init.d/apache2 script is designed to safely run apache2ctl, and should be used to actually start and stop the server manually. Table 8-3 lists the applications.

The Apache server is managed by systemd using the apache2.service unit file in the /run/systemd/generator.late directory. This file is generated by systemd-sysv-generator using the /etc/init.d/apache2 file. The server is started after the network and file system mounts (After). The/etc/init.d/apache2 script is used to start, stop, and restart the sever (ExecStart, ExecStop, ExecReload). It is run after the multi-user and graphical targets (runlevel targets 2, 3, 4, and 5) (After).

apache2.service

# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/apache2
Description=LSB: Apache2 web server
Before=runlevel2.target runlevel3.target runlevel4.target runlevel5.target shutdown.target
After=local-fs.target remote-fs.target network-online.target systemd-journald-dev-log.socket nss-lookup.target
Wants=network-online.target
Conflicts=shutdown.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
ExecStart=/etc/init.d/apache2 start
ExecStop=/etc/init.d/apache2 stop
ExecReload=/etc/init.d/apache2 reload

Apache Multiprocessing Modules: MPM

Apache now uses architecture with multiprocessing modules (MPMs), which are designed to customize Apache to different operating systems, as well as handle certain multiprocessing operations. For the main MPM, a Linux system uses the prefork, worker, or event MPM, whereas Windows uses the mpm_winnt MPM. The prefork is a standard MPM module designed to be compatible with older UNIX and Linux systems, particularly those that do not support threading. Currently Ubuntu uses the worker modules. You can configure the workload parameters for both in their module configuration files in the mods-available directory: the mpm_prefork.conf, mpm_worker.conf, and mpm_event.conf files.

Starting and Stopping the Web Server

On Ubuntu, Apache is installed as a standalone server, continually running. Your system will use an init script to automatically start up the web server daemon, invoking it whenever you start your system. An init script for the web server called apache2 is in the /etc/init.d directory. This script uses the apache2ctl tool to manage the apache server, allowing you to start, stop, and restart the server from the command line. The apache2 init script takes several arguments: start to start the server, stop to stop it, and restart to shut down and restart the server.

To check your web server, start your web browser on the host that is running the Web server, and use localhost as the domain name. Your Web server will be providing access on port 80. You would enter http://localhost/. You can also just enter your host name, like http://turtle. If you already have an Internet domain name address already supported by DNS servers, you could use that instead. This should display the home page you placed in your web root directory. A test page index.html file is set up for you that will display the words, It Works. Your Web site will be located in the /var/www directory. Here is where you would place the Web pages for your Web site.

As you configure your Web site, you will need to reload your configuration settings and restart the Web server, so that the new settings will take effect. You can do this by running the apache2 service script first with the reload option, and then with the restart option. Use the service command to invoke the apache2 script.

sudo service apache2 reload
sudo service apache2 restart

You also can use the apache2 script to start and stop the Web server using the start and stop options.

sudo service apache2 start

With the status option you can check if your Web server is running already.

The apache2 script also can be used to run the htcacheclean daemon, which will periodically check and clean the disk cache used by the Web server. Use the start-htcacheclean option to start the htcacheclean server, and stop-htcacheclean to stop it.

sudo service apache2 start-htcacheclean

Once you have your server running, you can check its performance with the ab benchmarking tool, also provided by Apache. ab shows you how many requests at a time your server can handle. It takes as its argument the website URL. Options include -v, which enables you to control the level of detail displayed; -n, which specifies the number of requests to handle (default is 1); and -t, which specifies a time limit.

ab -v -n localhost/index.htm.

Apache Configuration

Configuration directives are run from the apache2.conf configuration file. A documented version of the apache2.conf configuration file is installed automatically in /etc/apache2/apache2.conf. It contains detailed descriptions and default entries for global Apache directives. Though the apache2.conf file runs the entire configuration, it does so by including the contents of other configuration files. In effect, Apache configuration is distributed among other configuration files tailored for specific tasks. Configuration files for Apache are listed in Table 8-4 .

Table 8-4: Apache configuration files in the /etc/apache2 directory.

The apache2.conf file is configured to include and run all the directives in the ports.conf, envvars, all the configuration files linked to in the /etc/apache2/conf-enabled and /etc/apache2/mods-enabled directories, and all the configuration files linked to in the /etc/apache2/sites-enabled directory. The /etc/apache2/ports.conf file holds the port directives determining what port Apache will use (normally 80). The /etc/apache2/envvars file holds variable definitions such as APACHE_LOG_DIR, which are used by Apache tools, site configuration files, and scripts like apache2ctl. Currently these include user and group definitions for running Apache.

Any of the directives in the main configuration files can be overridden on a per-directory basis using an .htaccess file located within a directory. Although originally designed only for access directives, the .htaccess file can also hold any resource directives, enabling you to tailor how web pages are displayed in a particular directory. You can configure access to .htaccess files in the apache2.conf file. In addition, default start-up settings for htcacheclean are set up in the /etc/default/apache2 file for managing the Web server cache.

Module configuration files

Many directives that once resided in the apache core are now placed in respective modules and MPMs. With this modular design, several directives have been dropped, such as ServerType. Available modules and their configuration files are located in the /etc/apache2/mods-availabledirectory. The enabled modules are listed in the /etc/apache2/mods-enabled directory as links to their corresponding modules in the mods-available directory. A module is disabled by removing its link. Use the a2enmod command to enable a module, and the a2dismod command to disable a module. These commands work by adding or removing links for available modules in the /etc/apache2/mods-enabled directory...

Modules will have both a .conf and .load configuration file. For example, the SSL module has both an ssl.conf and ssl.load file The .conf file holds directives for configuring the module, and the .load file holds the LoadModule directive for performing the actual load operation, specifying the location and name of the module. Their corresponding links in the mods-enabled directory also have .conf and .load extensions.

Configuration files in conf-available

Additional configuration files, not associated with a particular module, are located in the /etc/apache2/conf-available directory. Sometimes these are links to configuration files set up by other applications. The configuration files have the extension .conf, such as security.conf. The configuration files are not active unless enabled. The enabled configuration files are listed in the /etc/apache2/conf-enabled directory as links to their corresponding modules in the conf-available directory. The links also have the same .conf extension. A configuration file is disabled by removing its link. Use the a2enconf command to enable a module, and the a2disconf command to disable a module. These commands work by adding or removing links for available modules in the /etc/apache2/conf-enabled directory.

Site configuration files

All sites on the Web server are configured as virtual hosts, with a special site called default for the main Web server. Normally you would create your site as a virtual host, reserving the default for administration. Virtual hosts can then be enabled or disabled, letting you turn access to a site on and off. You use the a2dissite and a2ensite commands to enable or disable sites. .

The configuration files for sites you have set up on your server are listed in the /etc/apache2/sites-available directory. Configuration files will contain Directory directives specifying the location of the site and controls and features you have set up for it. The 000-default.conf file holds configuration directives for the default Web server, such as the directory directives locating the default site at /var/www/html. All site configuration files have the extension .conf. To make a site accessible, a link to its configuration file must be created in the /etc/apache2/sites-enableddirectory. Use the ensite command to create such a link. There will already be a link for the default site (000-default.conf). The links also have a .conf extension.

Apache Configuration Directives

Apache configuration takes the form of directives entered into the Apache configuration files (/etc/apache2). With these directives, you can enter basic configuration information, such as your server name, or perform more complex operations, such as implementing virtual hosts. The design is flexible enough to enable you to define configuration features for particular directories and different virtual hosts. Apache has a variety of different directives performing operations as diverse as controlling directory access, assigning file icon formats, and creating log files. Most directives set values such as DirectoryRoot, which holds the root directory for the server’s web pages, or Port, which holds the port on the system that the server listens on for requests. The syntax for a simple directive is shown here:

directive option option ...

Certain directives create blocks able to hold directives that apply to specific server components (also referred to as block directives). For example, the Directory directive is used to define a block within which you place directives that apply only to a particular directory. Block directives are entered in pairs: a beginning directive and a terminating directive. The terminating directive defines the end of the block and consists of the same name beginning with a slash. Block directives take an argument that specifies the particular object to which the directives apply. For theDirectory block directive, you must specify a directory name to which it will apply. The <Directory mydir> block directive creates a block whose directives within it apply to the mydir directory. The block is terminated by a </Directory> directive. The <VirtualHost hostaddress> block directive is used to configure a specific virtual web server, and must include the IP or domain name address used for that server. </VirtualHost> is its terminating directive. Any directives you place within this block are applied to that virtual web server. The <Limit method> directive specifies the kind of access method you want to limit, such as GET or POST. The access control directives located within the block list the controls you are placing on those methods. The syntax for a block directive is as follows:

<block-directive option ... >
directive option ...
directive option ...
</block-directive>

Global directives are placed in one of the main configuration files. Directives for particular sites are located in that site's configuration file in /etc/apache2/sites-available directory. Directory directives in those files can be used to configure a particular directory. However, Apache also makes use of directory-based configuration files. Any Web site directory may have its own .htaccess file that holds directives to configure only that directory. If your site has many directories, or if any directories have special configuration needs, you can place their configuration directives in their .htaccess files, instead of filling the main configuration file with specific Directory directives for each one. You also can control what directives in an .htaccess file take precedence over those in the main configuration files. If your site allows user or client-controlled directories, you may want to monitor or disable the use of .htaccess files in them. It is possible for directives in an .htaccess file to override those in the standard configuration files unless disabled with AllowOverride directives.

You can find a listing of Apache web configuration directives both at the Apache website, http://httpd.apache.org/docs/2.4/mod/quickreference.html and, if you have installed the apache2-doc package, on your own system as http://localhost/manual/en/mod/quickreference.html.

Access controls: require

With access control directive require you can control access to your website by remote users and hosts (see Table 8-5 ) . With Apache 2.4, the require directive replaces the allow, order, deny, and satisfy directives used in Apache 2.2. It is implemented by the mod_authz_hostmodule. Access can be granted or denied. The all term refers to all hosts. The require directive can be used globally to control access to the entire site or placed within Directory directives to control access to individual directives. In the following example, all users are allowed access:

require all granted

The require directive performs authentication on users. Authentication can refer to all users (all), specific users (user), groups (group), the domain name of a host the users are on (host), IP address (ip) of a host, and even an expression (expr), HTTP method (method), or environment variable (env). In most cases it is used to determine access by all users (all), or those from specified hosts (host or ip).

Directory blocks

A Directory block begins with a <Directory pathname> directive, where pathname is the directory to be configured. The ending directive uses the same <> symbols, but with a slash preceding the word “Directory”: </Directory>. Directives placed within this block apply only to the specified directory. The following example denies access to only the mypics directory by requests from www.myvids.com.

<Directory /var/www/mypics>
Require all granted
Require host www.myvids.com denied
</Directory>

With the Options directive, you can enable certain features in a directory, such as the use of symbolic links, automatic indexing, execution of CGI scripts, and content negotiation. The default is the All option, which turns on all features except content negotiation (Multiviews). The following example enables automatic indexing (Indexes), symbolic links (FollowSymLinks), and content negotiation (Multiviews). A simple index.html file has been placed in the /var/www directory to disable automatic indexing (Indexes) for that top level directory (DocumentRoot). The Indexes option can be a security risk.

Options Indexes FollowSymLinks Multiviews

Configurations made by directives in main configuration files or in upper-level directories are inherited by lower-level directories. Directives for a particular directory held in .htaccess files and Directory blocks can be allowed to override those configurations. This capability can be controlled by the AllowOverride directive. With the all argument, .htaccess files can override any previous configurations. The None argument disallows overrides, effectively disabling the .htaccess file. You can further control the override of specific groups of directives. AuthConfigenables use of authorization directives, FileInfo is for type directives, Indexes is for indexing directives, Limit is for access control directives, and Options is for the options directive.

AllowOverride all

Authentication

Your web server can also control access on a per-user or per-group basis to particular directories on your website. You can require various levels for authentication. Access can be limited to particular users and require passwords, or expanded to allow members of a group access. You can dispense with passwords altogether or set up an anonymous type of access, as used with FTP.

To apply authentication directives to a certain directory, you place those directives within either a Directory block or the directory’s .htaccess file. Use the require directive to determine what users can access the directory. You can list particular users or groups. The AuthNamedirective provides the authentication realm to the user, the name used to identify the particular set of resources accessed by this authentication process. The AuthType directive specifies the type of authentication, such as basic or digest. A require directive requires also AuthType,AuthName, and directives specifying the locations of group and user authentication files. In the following example, only the users george, robert, and mark are allowed access to the newpics directory:

<Directory /var/www/newpics
AuthType Basic
AuthName Newpics
AuthUserFile /web/users
AuthGroupFile /web/groups
<Limit GET POST>
require users george robert mark
</Limit>
</Directory>

To set up anonymous access for a directory, place the Anonymous directive with the user anonymous as its argument in the directory’s Directory block or .htaccess file. You can also use the Anonymous directive to provide access to particular users without requiring passwords from them.

Apache maintains its own user and group authentication files, specifying what users and groups are allowed access to which directories. These files are normally simple flat files, such as your system’s password and group files. They can become large, however, possibly slowing down authentication lookups. As an alternative, many sites have used database management files in place of these flat files. Database methods are then used to access the files, providing a faster response time. Apache has directives for specifying the authentication files, depending on the type of file you are using. The AuthUserfile and AuthGroupFile directives are used to specify the locations of authentication files that have a standard flat file format. The AuthDBUserFile and AuthDBGroupFile directives are used for DB database files, and the AuthDBMGUserFile andAuthDBMGGroupFile are used for DBMG database files.

The programs htdigest, htpasswd, and htdbm are tools provided with the Apache software package for creating and maintaining user authentication files, which are user password files listing users who have access to specific directories or resources on your website. The htdigest andhtpasswd programs manage a simple flat file of user authentication records, whereas htdbm uses a more complex database management format. If your user list is extensive, you may want to use a database file for fast lookups. htdigest takes as its arguments the authentication file, the realm, and the username, creating or updating the user entry. htpasswd can also employ encryption on the password. htdbm has an extensive set of options to add, delete, and update user entries. A variety of different database formats are used to set up such files. Three common ones are Berkeley DB2, NDBM, and GNU GBDM. htdbm looks for the system libraries for these formats in that order. Be careful to be consistent in using the same format for your authentication files.

Directory-level Configuration

One of the most flexible aspects of Apache is its ability to configure individual directories. With the Directory directive, you can define a block of directives that apply only to a particular directory (see Table 8-5 ). Such a directive can be placed in a site configuration file. Global default directives are located in the apache2.conf configuration file. You can also use an .htaccess file within a particular directory to hold configuration directives. Those directives are then applied only to that directory. The name .htaccess is set with the AccessFileName directive. You can change this if you want.

AccessFileName .htaccess

Table 8-5: Access Control Directives

A Directory block begins with a <Directory pathname> directive, where pathname is the directory to be configured. The ending directive uses the same <> symbols, but with a slash preceding the word “Directory”: </Directory>. Directives placed within this block apply only to the specified directory.

With the Options directive, you can enable certain features in a directory, such as the use of symbolic links, automatic indexing, execution of CGI scripts, and content negotiation. The default is the All option, which turns on all features except content negotiation (Multiviews). The following example enables automatic indexing (Indexes), symbolic links (FollowSymLinks), and content negotiation (Multiviews).

Options Indexes FollowSymLinks Multiviews

Configurations made by directives in main configuration files or in upper-level directories are inherited by lower-level directories. Directives for a particular directory held in .htaccess files and Directory blocks can be allowed to override those configurations. This capability can be controlled by the AllowOverride directive. With the all argument, .htaccess files can override any previous configurations. The none argument disallows overrides, effectively disabling the .htaccess file. You can further control the override of specific groups of directives. AuthConfigenables use of authorization directives, FileInfo is for type directives, Indexes is for indexing directives, Limit is for access control directives, and Options is for the options directive.

AllowOverride all

When given a URL for a directory instead of an HTML file, and when no default web page is in the directory, Apache creates a page on the fly and displays it. This is usually only a listing of the different files in the directory. In effect, Apache indexes the items in the directory for you. You can set several options for generating and displaying such an index using IndexOptions. With FancyIndexing, web page items are displayed with icons and column headers that can be used to sort the listing. With VersionSort items are sorted alphabetically and numerically.NameWidth sets column width, with the * value setting the width as needed. Charset sets the character set, usually UTF-8. For a complete list of options see http://httpd.apache.org/docs/2.2/mod/mod_autoindex.html#indexoptions

IndexOptions FancyIndexing VersionSort NameWidth=* HTMLTable Charset=UTF-8

Global Configuration: apache2.conf, ports.conf, and envvars

The Apache configuration places global settings in the apache2.conf file, as well as the ports.conf and envvars files. Configuration for particular modules is located in the modules-conf directory. The global settings control the basic operation and performance of the web server. Here is where you set configuration locations, process ID files, timing, ports, environmental variable definitions, and default directory controls.

The ServerRoot directive specifies where your web server configuration files and modules are kept. This server root directory is then used as a prefix to other directory entries.

ServerRoot "/etc/apache2"

The server’s process ID (PID) file is set by PidFile. On Ubuntu, the Process ID file is defined by APACHE_PID_FILE variable in the /etc/apache2/envvars file.

PidFile ${APACHE_PID_FILE}

Connection and request timing is handled by Timeout, KeepAlive, MaxKeepAlive, and KeepAliveTimeout directives. Timeout is the time in seconds that the web server times out a send or receive request. KeepAlive allows persistent connections, several requests from a client on the same connection. This is turned off by default. KeepAliveRequests sets the maximum number of requests on a persistent connection. KeepAliveTimeout is the time that a given connection to a client is kept open to receive more requests from that client.

Additional directives set user and group, local directory configuration files, and logs. The User and Group directives set the User and Group that run the Apache server. The APACHE_RUN_USERS and the APACHE_RUN_GROUP variables are set in the /etc/apache2/envvars file. The name of the user and group is www-data.

User ${APACHE_RUN_USERS}
Group ${APACHE_RUN_GROUP}

The Listen directive will bind the server to a specific port or IP address. By default this is port 80. The Listen directive is defined in the /etc/apache2/ports.conf file.

Listen 80

Directory security defaults in apache2.conf

One of the most flexible aspects of Apache is its ability to configure individual directories. With the Directory directive, you can define a block of directives that apply only to a particular directory. Such a directive can be placed in the apache2.conf configuration file.

You can also use an .htaccess file within a particular directory to hold configuration directives. Those directives are then applied only to that directory. The name “.htaccess” is set with the AccessFileName directive. You can change this if you want.

AccessFileName .htaccess

Several default Directory blocks are defined in the apache2.conf file to control access to your Web site. All of them prevent the use of .htaccess files in their directories by setting the AllowOverride directive to none.

AllowOverride None

For the Web site's root directory, /, symbolic links are allowed.

<Directory />
Options FollowSymLinks
AllowOverride None
Require all denied
</Directory>

<Directory /usr/share>
AllowOverride None
Require all granted
</Directory>

Then the directory block is defined for the Web site directory, /var/www/. This is the location for all the Web site files. The "Require all granted" directive will allow anyone to access the files. Keep in mind that the Web site's document directory is defined by the DocumentRoot directive as /var/www/html in the site's sites-available configuration file.

<Directory "/var/www">
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>

An additional commented directive is listed for the srv directory, should you want to enable it.

#<Directory "/srv ">
# Options Indexes FollowSymLinks
# AllowOverride None
# Require all granted
#</Directory>

The Options directive specifies options to display default indexes, allows symbolic links, and supports MultiViews. The Indexes option will list files, should there be no default page for the directory (DirectoryIndex). MultiViews supports content negotiation, like using a particular language or a preferred image type.

Options Indexes FollowSymLinks MultiViews

To deny access to the .htaccess files by Web clients, a FilesMatch block is defined with the access control directives "Require all denied", which denies access to all users. The FilesMatch directive references any file beginning with .ht (the period is quoted with a backslash). The FilesMatch directive allows the use of regular expressions, in this case, the ^ expression. The </FilesMatch> entry ends the <Files> block.

<FilesMatch ~ "^\.ht">
Require all denied
</Files>

logs

For efficiency, the HostnameLookups operation is turned off. HostnameLookups, if turned on, would log all Web clients, generating a DNS server search for each client that accesses the Web server.

HostnameLookups Off

ErrorLog specifies the location of the log file (APACHE_LOG_DIR is set in the /etc/apache2/envvars file).

ErrorLog ${APACHE_LOG_DIR}/error.log

LogLevel sets the level at which messages should be logged. The warn level is usually used, though you can choose others like notice, info, debug, as well as more serious ones like crit, alert, and emerg.

LogLevel warn

The LogFormat directive defines some nicknames to be used with the CustomLog directive, like host_combined, common, and referrer. These are the formats in which messages are saved in the log file. The formats use substitution symbols like %h for the host, %t for the time, and%u for the user. The following defines a common format that displays the host, remote logname, user, time, the first line of the request in quotes, status, and size. The substitution characters are listed at http://httpd.apache.org/docs/2.3/mod/mod_log_config.html.

LogFormat "%h %l %u %t \"%r\" %>s %0" common

The CustomLog directive defines a default log for virtual hosts that don't define one. It is now defined in the /etc/apache2/conf-available/other-vhosts-access-log file, which is read by the apache2.conf file. The format used is the vhost_combined format.

CustomLog ${APACHE_LOG_DIR}/other_vhosts_access.log vhost_combined

Included files in apache2.conf

The apache2.conf file will include all module, port, and site configuration files with the Include and IncludeOptional directives. Specialized configurations will be located in the conf-available directory.

# Include module configuration:
IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf
# Include ports listing
Include ports.conf
# Include generic snippets of statements
IncludeOptional conf-enabled/*.conf
# Include the virtual host configurations:
IncludeOptional sites-enabled/*.conf

MPM Configuration: mods-available

Configuration settings for MPM prefork, worker, and event modules let you tailor your Apache web server to your workload demands. Default entries will already be set for a standard web server operating under a light load. You can modify these settings for different demands. These setting are located in the mods-available directory in the mpm_prefork.conf, mpm_worker.conf, and mpm_event.conf files. A link in the mods-enabled directory shows the one enabled, usually the mpm_prefork module. Use a2enmod to enable the module you want.

Three MPM modules commonly available to UNIX and Linux systems are prefork, worker, and event. The prefork module supports one thread per process, which maintains compatibility with older systems and modules. The worker module supports multiple threads for each process, placing a much lower load on system resources. The event module serves more requests simultaneously. They share several of the same directives, such as StartServer and MaxRequestPerChild. Ubuntu currently uses the worker modules.

Apache runs a single parent process with as many child processes as are needed to handle requests. Configuration for MPM modules focuses on the number of processes that should be available. The prefork module will list server numbers as a process is started for each server; the worker module will control threads, since it uses threads for each process. The StartServer directive lists the number of server processes to start for both modules. This will normally be larger for the prefork than for the worker module.

In the prefork module (mpm_prefork.conf) you need to set minimum and maximum settings for spare servers. MaxClients sets the maximum number of servers that can be started, and ServerLimit sets the number of servers allowed. The MaxRequestsPerChild sets the maximum number of requests allowed for a server.

<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfModule>

The directives serve as a kind of throttle on the web server access, controlling processes to keep available, and limiting the resources that can be used. In the prefork configuration, the StartServer is set number to 5, and the spare minimum to 5, with the maximum spare as 20. This means that initially 5 server processes will be started up and will wait for requests, along with 5 spare processes. When server processes are no longer being used, they will be terminated until the number of these spare processes is less than 10. The maximum number of server processes that can be started is 150.

In the worker MPM (mpm_worker.conf), only 2 server processes are initially started (StartServer). Spare threads are set at 25 and 75. The maximum number of threads is set at 150, with the threads per child at 25. MaxClients sets the maximum number of client threads, andThreadsPerChild sets the number of threads for each server. MaxRequestsPerChild limits the maximum number of requests for a server.

<IfModule mpm_worker_module>
StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadLimit 64
ThreadsPerChild 25
MaxClients 150
MaxRequestsPerChild 0
</IfModule>

The event MPM is based on the worker MPM and has the same configuration. It is designed to pass off processing to supporting threads, freeing up the main threads to handle new requests.

Error Messages: conf-available/localized-error-pages.conf

Configured in the conf-available/localized-error-pages file, and included in the apache2.conf file with other conf-available files, are directives for internationalized error messages. The LanguagePriority directive lets you rank the languages to use. The mod_alias, mod_include, and mod_negotiation modules have to be loaded. The Alias and Directory directives specify the error directory as /usr/share/apache2/error. Here you will find .var files for different error messages, like HTTP_BAD_GATEWAY.html.var. These .var files contain configuration for displaying the messages in the languages specified by LanguagePriority directive. Some of the key internationalization error directives are shown here:

Alias /error/ "/usr/share/apache2/error'
LanguagePriority en cs de es fr it nl sv pg-br ro
ErrorDocument 502 /error/HTTP_BAD_GATEWAY.html.var

Security: conf-available/security.conf

Configured in the conf-available/security file, and included in the apache2.conf file with other conf-available files, are directives for site security. Most entries are commented out. ServerTokens determines the content of the site's response header. On Ubuntu, it is set to OS to return the operating system type. ServerSignature is set to On, which adds server version and hostname information for server generated pages. TraceEnable is set to Off to disable trace requests.

cgi-bin: conf-available/serve-cgi-bin.conf

Configured in the conf-available/serve-cgi-bin file, and included in the apache2.conf file with other conf-available files, are directives for site cgi-bin directory access. The cgi-bin directory holds the Web site's executable scripts like the CGI (Common Gateway Interface) and SSI (Server Side Includes) scripts. An alias is set up for the cgi-bin directory, which is actually located at /usr/lib/cgi-bin.

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

Controls are then placed on the /usr/lib/cgi-bin directory. All users are allowed access. Options designate that CGI programs can be executed and symbolic links are allowed if the owner's match. Multiviews are not allowed. The ExeCGI option allows the execution of CGI scripts. The + and - signs are used to indicate whether an option is turned on or off. If you use a + and - sign for one option, you have to use them for all.

<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Require all granted
</Directory>

The configuration file will also check for the existence of the mod_cgi and mod_cgid modules, defining the ENABLE_USR_LIB_CGI_BIN variable if found..

Documentation: conf-available/apache2-doc.conf

If you installed the apache-doc package, documentation is set up for you at /usr/share/doc/apache2-doc. The configuration file for the apache documentation is at /etc/apache2/conf-available/apache2-doc.conf. The manual directory is aliased (/usr/share/doc/apache2-doc/manual) and controls are set up to allow access from all users.

Alias /manual/ /usr/share/doc/apache2-doc/manual/

<Directory "/usr/share/doc/apache2-doc/manual/">
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
AddDefaultCharset off
</Directory>

Site-Level Configuration Directives

Site specific information is kept in the site's configuration files in /etc/apache2/sites-available directory. The 000-default.conf site configuration file will hold directives for the main server. A default-ssl.conf file holds configuration for a main server with SSL support. The site configuration files hold site-specific information like Directory directives for their Web pages and server information like the administrator address. Authentication controls can be placed on particular directives. You can use the default configuration file as a partial model.

The site configuration files begin with few directives. Most global, module, and default directives are already enabled by the apache2.conf file, the added configuration files (conf-available directory), and the module configuration files (modules-conf directory). The actual site configuration file initially has only a few directives. You can add ones that you want to apply to that site.

A site configuration begins with a VirtualHost directive. The directive can name a particular IP address of a site or *:80 for the main server (you can use a fully qualified domain name instead of the IP address, but this is not recommended). The directive block ends with a</VirtualHost> directive at the end of the file. Your site specific directives like Directory directives are placed within the block. Keep in mind that all the site level configurations that are enabled will be read directly as if they were part of one large apache2.conf file.

<VirtualHost *:80>

</VirtualHost>

The following is an example of the ServerAdmin directive used to set the address where users can send mail for administrative issues. The default entry is webmaster@localhost. You can replace this with the address you want to use to receive system administration mail.

ServerAdmin webmaster@localhost

The DocumentRoot directive specifies where the Web server's HTML files are located. On Ubuntu this is the /var/www/html directory.

DocumentRoot /var/www/html

The ServerName directive (not used for the default host) determines the name of the virtual host.

ServerName www.example.com

Virtual Hosting on Apache

All sites are treated as virtual hosts configured by their site configuration files in /etc/apashe2/sites-available directory. In effect, the server can act as several servers, each hosted website appearing separate to outside users.

Apache supports both IP address–based and name-based virtual hosting. IP address–based virtual hosts use valid registered IP addresses, whereas name-based virtual hosts use fully qualified domain addresses. These domain addresses are provided by the host header from the requesting browser. The server can then determine the correct virtual host to use on the basis of the domain name alone. See http://httpd.apache.org for more information.

You can enable or disable a virtual site with the a2dissite and a2ensite commands. . Enabled sites are listed as symbolic links in the /etc/apache2/sites-enabled directory.

Virtual Host for main server: 000-default.conf

The main server must also have a virtual host configuration. This is set up by Ubuntu as the default configuration in the sites-available directory, /etc/apache2/sites-available/000-default. For the main server, the VirtualHost directive uses an * as its name with its port, 80. The directive block begins with <VirtualHost *:80> and ends with </VirtualHost>. The DocumentRoot is set to /var/www/, the location of the Web server's HTML files and subdirectories.

<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
...
</VirtualHost>

For logging, the ErrorLog location is specified and the LogLevel is set at warn. The log display format used is combined (APACHE_LOG_DIR is defined in /etc/apache2/envvars).

LogLevel warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

Should you have an alias for your main host, you can specify that using an added Virtual host directive that also uses the *:80 name, but with the alias as the ServerName. The following example sets up the default for the main Web server host as well as an alias, www.turtle.com andwww.turtle.org.

<VirtualHost *:80>
ServerName www.turtle.com
ServerAdmin webmaster@mail.turtle.com
DocumentRoot /var/www/html
</VirtualHost>

<VirtualHost 192.168.1.5>
ServerName www.turtle.org
ServerAdmin webmaster@mail.turtle.com
DocumentRoot /var/www/html
</VirtualHost>

You may want to modify the /etc/apache2/sites-available/000-default.conf configuration file to reflect the server name and mail address you want to use for your site.

A copy of the /etc/apache2/sites-available/000-default.conf file is shown here.

<VirtualHost *:80>
ServerAdmin webmaster@localhost

DocumentRoot /var/www/html

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
# LogLevel warn

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

Site and Global Configuration

It may be the case that certain directives that are configured globally, you may want to configure just for particular sites. This would entail turning off their global configuration, and enabling them on a site by site basis. As an example, access to the cgi-bin directory is currently global, with its conf-available/serve-cgi-bin.conf file enabled by a link to it in the conf-enabled directory. If you only want a few sites to have access to the cgi-bin directory, instead of all of them (global), you would disable the global link. Then, in the sites-available files for those sites you want to give access to the cgi-bin directory, you would insert an include statement for the serve-cgi-bin.conf file.

Use the a2disconf command to disable the global use of the configuration file. This removes its link in the /etc/apache2/conf-enabled directory.

a2disconf serve-cgi-bin.conf

Add the following include statement to the site files for the sites you want to have access to the cgi-bin directory.

include conf-available/serve-cgi-bin.conf

Virtual Host for main server: default-ssl.conf

The default-ssl.conf file has the same entries as the default site file, but adds directives for SSL. The directives are explained with detailed comments. Several directives are commented out, which you can enable as you need them, like those for the certificate authority, revocation lists, client authentication, SSL options, and access control. The virtual host is set to use port 443, <Virtualhost_default_:443>.

In the SSL Engine Switch section, SSL is enabled.

SSLEngine on

A self-signed SLL certificate is specified

SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

SSL options are applied to the Web site files and the cgi-bin.

<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>

For an SSL enabled Web server to work you will need an SSL certificate and key specific to your Web site to implement SSL encryption. See the followings section in the Ubuntu Server Guide for details:

https://help.ubuntu.com/stable/serverguide/certificates-and-security.html

Creating Virtual Hosts

The easiest way to create a new Virtual host is to copy the default file, giving it the name of the new Web site. Then edit the file to add the ServerName directive with the domain name of the Web site. Be sure to change the ServerAdmin, DocumentRoot, ErrorLog, and CustomLog directives. You also could remove the document directives. The following example implements a name-based virtual host, www.mypics.com. A subdirectory for the Web site has to be created in the /var/www directory, in this case, /var/www/mypics/, with the DocumentRoot at/var/www/mypics/. The Directory directive now references the /var/www/mypics/ directory. The /usr/share/doc Directory directives are not needed. If you wanted to allow the use of .htaccess files on this site you would change the AllowOverride directive to all. You also have to add a subdirectory in the Apache log directory for the logs such as /var/log/apache2/mypics, (APACHE_LOG_DIR). Basic steps would include the following:

Create a configuration file in /etc/apache2/sites-available

Create a directory for the Web site documents at /var/www/

Create a subdirectory for the Web site log files at /var/log/apache2/

If your virtual host is referenced by other domain names, you can specify them with the ServerAlias directive, listing the domain names within the selected VirtualHost block.

ServerAlias www.greatpics.org

A sample configuration file called here mypics would be placed in the sites-available directory. The file is shown here with ServerName and ServerAlias directives included.

<VirtualHost *:80>
ServerName www.mypics.com
ServerAdmin webmaster@mail.mypics.com
ServerAlias www.greatpics.org
DocumentRoot /var/www/mypics/

<Directory /var/www/mypics/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Require all granted
</Directory>

ErrorLog ${APACHE_LOG_DIR}/mypics/error_log
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/mypics/access.log combined

</VirtualHost>

Once configured, you would then activate the site with the a2ensite command.

sudo a2ensite mypics

Name-based Virtual Hosts

The Apache default configuration described in the previous section uses name-based virtual hosting. With name-based virtual hosting, you can support any number of virtual hosts using no additional IP addresses. With only a single IP address for your machine, you can still support an unlimited number of virtual hosts. Such a capability is made possible by the HTTP/1.1 protocol, which lets a server identify the name by which it is being accessed. This method requires the client, the remote user, to use a browser that supports the HTTP/1.1 protocol, as current browsers do. A browser using such a protocol can send a host header specifying the particular host to use on a machine.

If you are using a particular IP address for your Web site, you would use that address instead of the port number in the VirtualHost directive. To implement name-based virtual hosting for a particular IP address, you use a VirtualHost directive and a NameVirtualHost directive to specify the IP address you want to use for the virtual hosts. If your system has only one IP address, you need to use that address. Within the VirtualHost directives, you use the ServerName directive to specify the domain name you want to use for that host. Using ServerName to specify the domain name is important to avoid a DNS lookup. A DNS lookup failure disables the virtual host. The VirtualHost directives each take as their argument the same IP address specified in the NameVirtualHost directive. You use Apache directives within the VirtualHost blocks to configure each host separately. Name-based virtual hosting uses the domain name address specified in a host header to determine the virtual host to use. If no such information exists, the first host is used as the default.

Here, www.mypics.com and www.myproj.org are implemented as name-based virtual hosts instead of IP-based hosts. Though on Ubuntu these would be placed in separate sites-available files, they are shown here together to make for a clearer example, with directives for the main server added (turtle.mytrek.com).

ServerName turtle.mytrek.com
NameVirtualHost 192.168.1.5

<VirtualHost 192.168.1.5>
ServerName www.mypics.com
ServerAdmin webmaster@mail.mypics.com
DocumentRoot /var/www/mypics/html
ErrorLog /var/www/mypics/logs/error_log
...
</VirtualHost>

<VirtualHost 192.168.1.5>
ServerName www.myproj.org
ServerAdmin webmaster@mail.myproj.org
DocumentRoot /var/www/myproj/html
ErrorLog /var/www/myproj/logs/error_log
....
</VirtualHost>

If your system has only one IP address, implementing virtual hosts prevents access to your main server with that address. You could no longer use your main server as a Web server directly; you could use it only indirectly to manage your virtual host. You could configure a virtual host to manage your main server’s Web pages. You would then use your main server to support a set of virtual hosts that would function as Web sites, rather than the main server operating as one site directly. This is the approach implemented by Ubuntu for the Apache Web server.

If your machine has two or more IP addresses, you can use one for the main server and the other for your virtual hosts. You can even mix IP-based virtual hosts and name-based virtual hosts on your server. You can also use separate IP addresses to support different sets of virtual hosts.

Dynamic Virtual Hosting

If you have implemented many virtual hosts on your server that have the same configuration, you can use a technique called dynamic virtual hosting to have these virtual hosts generated dynamically. The code for implementing your virtual hosts becomes much smaller, and as a result, your server accesses them faster. Adding yet more virtual hosts becomes a simple matter of creating appropriate directories and adding entries for them in the DNS server.

To make dynamic virtual hosting work, the server uses commands in the mod_vhost_alias module (supported in Apache version 1.3.6 and up) to rewrite both the server name and the document root to those of the appropriate virtual server (for older Apache versions before 1.3.6, you use the mod_rewrite module). Dynamic virtual hosting can be either name-based or IP-based. In either case, you have to set the UseCanonicalName directive in such a way as to allow the server to use the virtual hostname instead of the server’s own name. For name-based hosting, simply turn off UseCanonicalName. This allows your server to obtain the hostname from the host header of the user request. For IP-based hosting, you set the UseCanonicalName directive to DNS. This allows the server to look up the host in the DNS server.

UseCanonicalName Off
UseCanonicalName DNS

You then have to enable the server to locate the different document root directories and CGI bin directories for your various virtual hosts. You use the VirtualDocumentRoot directive to specify the template for virtual host directories. For example, if you place the different host directories in the /var/www/hosts directory, you can then set the VirtualDocumentRoot directive accordingly.

VirtualDocumentRoot /var/www/hosts/%0/html

The %0 will be replaced with the virtual host’s name when that virtual host is accessed. It is important that you create the dynamic virtual host’s directory using that host’s name. For example, for a dynamic virtual host called www.mygolf.org, you first create a directory named/var/www/hosts/www.mygolf.org, and then create subdirectories for the document root and CGI programs, as in /var/www/hosts/www.mygolf.org/html. For the CGI directory, use the VirtualScriptAlias directive to specify the CGI subdirectory you use.

VirtualScriptAlias /var/www/hosts/%0/cgi-bin

A simple example of name-based dynamic virtual hosting directives follows:

UseCanonicalName Off
VirtualDocumentRoot /var/www/hosts/%0/html
VirtualScriptAlias /var/www/hosts/%0/cgi-bin

A request for www.mygolf.com/html/mypage evaluates to

/var/www/hosts/www.mygolf.com/html/mypage

A simple example of dynamic virtual hosting is shown here:

UseCanonicalName Off
NameVirtualHost 192.168.1.5

<VirtualHost 192.168.1.5>
ServerName www.mygolf.com
ServerAdmin webmaster@mail.mygolf.com
VirtualDocumentRoot /var/www/hosts/%0/html
VirtualScriptAlias /var/www/hosts/%0/cgi-bin
...
</VirtualHost>

To implement IP-based dynamic virtual hosting instead, set the UseCanonicalName to DNS instead of Off.

UseCanonicalName DNS
VirtualDocumentRoot /var/www/hosts/%0/html
VirtualScriptAlias /var/www/hosts/%0/cgi-bin

Interpolated Strings

The mod_vhost_alias module supports various interpolated strings, each beginning with a % symbol and followed by a number. The %0 symbol references the entire web address. %1 references only the first segment, %2 references the second, %-1 references the last part, and %2+ references from the second part on. For example, to use only the second part of a web address for the directory name, use the following directives:

VirtualDocumentRoot /var/www/hosts/%2/html
VirtualScriptAlias /var/www/hosts/%2/cgi-bin

In this case, a request made for www.mygolf.com/html/mypage uses only the second part of the web address. This would be “mygolf” in www.mygolf.com, and would evaluate to

/var/www/hosts/mygolf/html/mypage

If you used %2+ instead, as in /var/www/hosts/%2/html, the request for www.mygolf.com/html/mypage would evaluate to

/var/www/hosts/mygolf.com/html/mypage

The same method works for IP addresses, where %1 references the first IP address segment, %2 references the second, and so on.

Logs for Dynamic Virtual Hosts

One drawback of dynamic virtual hosting is that you can set up only one log for all your hosts. However, you can create your own shell program to simply cut out the entries for the different hosts in that log.

LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
CustomLog logs/access_log vcommon

Note: Apache also supports IP address–based virtual hosting. Your server must have a different IP address for each virtual host. Your machine can have separate physical network connections for each one. You can configure Apache to run a separate daemon for each virtual host, separately listening for each IP address, or you can have a single daemon running that listens for requests for all the virtual hosts. To set up a single daemon to manage all virtual hosts, use VirtualHost directives. To set up a separate daemon for each host, also use the Listen directive.