Apache Webserver

Sanjeev Gautam
26 min readJan 10, 2019

--

Apache is the most widely used web server software. Developed and maintained by Apache Software Foundation, Apache is an open source software available for free. It runs on 67% of all web servers in the world. It is fast, reliable, and secure. It can be highly customized to meet the needs of many different environments by using extensions and modules.

Apache breaks down its functionality and components into individual units that can be customized and configured independently. The basic unit that describes an individual site or domain is called a virtual host. Virtual hosts allow one server to host multiple domains or interfaces by using a matching system.

Each domain that is configured will direct the visitor to a specific directory holding that site’s information, without ever indicating that the same server is also responsible for other sites.

Features of Apache Server

  • Apache server is a free and an open source web server.
  • It can be installed on all operating systems like Linux, Windows, Unix, FreeBSD, Solaris, Mac OS X etc.
  • It is a powerful, flexible, HTTP/1.1 compliant web server.
  • This server is highly configurable and extensible with third-party modules.
  • It provides complete source code and comes with an unrestricted license.
  • Apache supports some of the capabilities like CGI (Common Gateway Interface) and SSI (Server Side Includes), URL redirection, loading modules support, user authentication, proxy caching abilities etc.

Installation and configuration on Ubuntu

Apache webserver is already available in our repository, so we can download simply by single command.

# apt-get install apache2

version oy apache2 server

After instalation, we check webserver is enabled or not enable using systemctl enable apache2

apache 2 is in running state

we can check using the browser http://192.168.1.110/

apache2 default page get loaded.

After installation check the /etc/apache2 directory

structure of /etc/apache2

Configuration FilesDescription

Content

  • /var/www/html: The actual web content, which by default only consists of the default Apache page we saw earlier, is served out of the /var/www/html directory. This can be changed by altering Apache configuration files.

Server Configuration

  • /etc/apache2: The Apache configuration directory. All of the Apache configuration files reside here.
  • /etc/apache2/apache2.conf: The main Apache configuration file. This can be modified to make changes to the Apache global configuration. This file is responsible for loading many of the other files in the configuration directory.
  • /etc/apache2/ports.conf: This file specifies the ports that Apache will listen on. By default, Apache listens on port 80 and additionally listens on port 443 when a module providing SSL capabilities is enabled.
  • /etc/apache2/sites-available: The directory where per-site “Virtual Hosts” can be stored. Apache will not use the configuration files found in this directory unless they are linked to the sites-enabled directory. Typically, all server block configuration is done in this directory and then enabled by linking to the other directory with the a2ensite command.
  • /etc/apache2/sites-enable: The directory where enabled per-site “Virtual Hosts” are stored. Typically, these are created by linking to configuration files found in the sites-available directory with the a2ensites. Apache reads the configuration files and links found in this directory when it starts or reloads to compile a complete configuration.
  • /etc/apache2/conf-available, /etc/apache2/conf-enabled: These directories have the same relationship as the sites-available and sites-enabled directories, but are used to store configuration fragments that do not belong in a Virtual Host. Files in the conf-available directory can be enabled with the a2enconf command and disabled with the a2disconf command.
  • /etc/apache2/mods-available, /etc/apache2/mods-enabled: These directories contain the available and enabled modules, respectively. Files in ending in .load contain fragments to load specific modules, while files ending in .conf contain the configuration for those modules. Modules can be enabled and disabled using the a2enmod and a2dismod command.

Server Logs

  • /var/log/apache2/access.log: By default, every request to your web server is recorded in this log file unless Apache is configured to do otherwise.
  • /var/log/apache2/error.log: By default, all errors are recorded in this file. The LogLevel directive in the Apache configuration specifies how much detail the error logs will contain.

we can configure SSL using

vim /etc/apache2/sites-available/default-ssl.conf

To change in a server CGI script, we can change using

vim /etc/apache2/conf-available/serve-cgi-bin.conf

Configuration Directives in apache2.conf

The main configuration details for your Apache server are held in the “/etc/apache2/apache2.conf” file.

This file is divided into three main sections: configuration for the global Apache server process, the configuration for the default server, and configuration of Virtual Hosts.

In Ubuntu and Debian, the majority of the file is for global definitions, and the configuration of the default server and virtual hosts is handled at the end, by using the “Include …” directive.

There are a number of different “Include” statements. These load module definitions, the ports.conf document, the specific configuration files in the “conf.d/” directory, and finally, the Virtual Host definitions in the “sites-enabled/” directory.

Global Configuration Section

This section is used to configure some options that control how Apache works as a whole.

Timeout: By default, this parameter is set to “300”, which means that the server has a maximum of 300 seconds to fulfill each request. This is probably too high for most setups and can safely be dropped to something between 30 and 60 seconds.

KeepAlive: This option, if set to “On”, will allow each connection to remain open to handle multiple requests from the same client. If this is set to “Off”, each request will have to establish a new connection, which can result in significant overhead depending on your setup and traffic situation.

KeepAliveTimeout: This setting specifies how long to wait for the next request after finishing the last one. If the timeout threshold is reached, then the connection will die. Means that the next time content is requested, the server will establish a new connection.

MPM Configuration: specifies the configuration of the MPM (Multi-Processing Module) options.

apache2 -l

AllowOverride: directive is used to allow the use of .htaccess within the web server to allow overriding of the Apache config on a per-directory basis. … That’s why it only works when you have AllowOverride All because you are telling the webserver to allow the use of a .htaccess file which CI uses.

Exploring the Default Virtual Host File

# sudo vim /etc/apache2/sites-available/000-default.conf

The default Virtual Host is configured to handle any request on port 80, the standard http port. This is defined in the declaration header where it says “*:80”, meaning port 80 on any interface.

The “DocumentRoot” option specifies where the content that is requested for this Virtual Host will be located. The default Virtual Host is set up to serve content out of the “/var/www” directory on Ubuntu.

Enabling Sites and Modules in Apache

To automatically create a symbolic link in the “sites-enabled” directory to an existing file in the “sites-available” directory, issue the following command:

# a2ensite Vitual_Host_FileName

After enabling a site, issue the following command to tell Apache to re-read its configuration files, allowing the change to propagate:

# systemctl restart apache2

Modules can be enabled or disabled by using the “a2enmod” and “a2dismod” commands respectively. They work in the same way as the “site” versions of these commands.

Lab Section to setup own website

Create a virtual host in sites-available for the specific website.

Here we create sanjeev-apache.conf in site available and we have to create a symlink for same in the sites-enabled directory.

a2ensite is used to create a symlink

# systemctl reload apache2

After taking reload to apache2 service symlink start working.

virtual host created for sanjeev-apache.net
created document root file in /var/www/test

Make an entry in /etc/hosts to resolve ip address to domain name locally

hostname entry in /etc/hosts

Now check same using http://sanjeev-apache.net/

.htaccess

.htaccess is a configuration file for use on web servers running the Apache Web Server software. When a .htaccess file is placed in a directory which is in turn ‘loaded via the Apache Web Server’, then the .htaccess file is detected and executed by the Apache Web Server software.

These .htaccess files can be used to alter the configuration of the Apache Web Server software to enable/disable additional functionality and features that the Apache Web Server software has to offer. These facilities include basic redirect functionality

we can also create a .htaccess file using a text editor like vim, gedit. example:

To Activate a .htaccess file

To activate .htaccess file we have to alter the AllowOveride setting to all as shown below.

Five Common Uses for a .htaccess Page

  1. Mod_Rewrite: one of the most useful facets of the .htaccess file is mod_rewrite. You can use the space in the .htaccess file to designate and alter how URLs and web pages on your sites are displayed to your users.
  2. Authentication: Although using the .htaccess file does not require as many permissions as accessing the apache2.conf file would require, we can still make effective changes to a site. Once such change is to require a password to access certain sections of the webpage.

The .htaccess passwords are kept in a file called .htpasswd. Go ahead and create and save that file, being sure to store it somewhere other than the web directory, for security reasons.

You should use the space inside the .htpasswd file to write in the name and passwords of all the users that you want to have access to the protected part of the site.

You can use this useful site to generate the username and encrypted password pair. If the username of your authorized user is jsmith and password is “awesome”, the pair would look like this: jsmith:VtweQU73iyETM. You can paste as many lines as needed into the .htpasswd file, but be sure that every user gets their own line.

  • AuthUserFile: This line designates the server path to the .htpasswd file.
  • AuthGroupFile: This line can be used to convey the location of the .htgroup. As we have not created such a file, we can leave /dev/null in place.
  • AuthName: This is text that will be displayed at the password prompt. You can put anything here.
  • AuthType: This refers to the type of authentication that will be used to check the passwords. The passwords are checked via HTTP and the keyword Basic should not be changed.
  • Require valid-user: This line represents one of two possibilities. “Require valid-user,” tells the .htaccess file that there are several people who should be able to log into the password protected area. The other option is to use the phrase “require user username” to indicate the specific permitted person.

3. Custom Error Pages: the .htaccess file additionally allows you to create custom error pages for your site. Some of the most common errors are:

  • 400 Bad Request
  • 401 Authorization Required
  • 403 Forbidden Page
  • 404 File not Found
  • 500 Internal Error

To make a page look friendlier and to provide more information to the site visitor than the default server error page offers, you can use the .htaccess file to create custom error pages.

I’m going to create a 404 page in this tutorial. However, you can substitute that error for whatever you prefer:

Once you have created and uploaded the desired error page, you can go ahead and designate its location in the .htaccess file.

ErrorDocument 404 /new404.html

Keep in mind that the Apache looks for the 404 pages located within the site’s root. If you placed the new error page in a deeper subdirectory, you need to include that in the line, making it look something like this:

ErrorDocument 404 /error_pages/new404.html

4. Mime Types: In cases where your site features some application files that your server was not set up to deliver, you can add MIME types to your Apache server in the .htaccess file with the following code.

AddType audio/mp4a-latm .m4a

Be sure to replace application and file extension with the Mime Type that you want to support.

5. SSI: Server Side Includes are a great time-saver on a website. One of the most common uses of SSI is to update a large number of pages with some specific data, without having to update each page individually (for example, if you want to change a quotation at the bottom of a page).

To enable SSI, type the following code into your .htaccess file.

AddType text/html .shtml
AddHandler server-parsed .shtml

These three lines have the effect of telling the .htaccess that .shtml files are valid, with the second line specifically making the server parse all files ending in .shtml for any SSI commands.

However, if you have many .html pages that you are not eager to rename with .shtml extensions, you can use another tactic to parse them for SSI commands, the XBitHack.

Adding this line to the .htaccess file makes Apache check all the html files with the appropriate permissions for Server Side Includes.

XBitHack on

To make a page eligible for the XBitHack, use this command:

chmod +x pagename.html

Some more Configuration Directives in httpd.conf

AccessFileName

AccessFileName names the file which the server should use for access control information in each directory. The default is .htaccess.

Immediately after the AccessFileName directive, a set of Files tags apply access control to any file beginning with a .ht.

Action

The Action specifies a MIME content type and CGI script pair so that when a file of that media type is requested, a particular CGI script is executed.

AddDescription

When using FancyIndexing as an IndexOptions parameter, the AddDescription directive can be used to display user-specified descriptions for certain files or file types in a server-generated directory listing.

AddEncoding

AddEncoding names file name extensions which should specify a particular encoding type. AddEncoding can also be used to instruct some browsers to uncompress certain files as they are downloaded.

AddHandler

AddHandler maps file extensions to specific handlers. For example, the cgi-script handler can be matched with the extension .cgi to automatically treat a file ending with .cgi as a CGI script. The following is a sample AddHandlerdirective for the .cgi extension.

AddHandler cgi-script .cgi

This directive enables CGIs outside of the cgi-bin to function in any directory on the server which has the ExecCGI option within the directories container.

In addition to CGI scripts, the AddHandler directive is used to process server-parsed HTML and image-map files.

AddLanguage

AddLanguage associates file name extensions with specific languages. This directive is useful for Apache HTTP Servers which serve content in multiple languages based on the client Web browser’s language settings.

AddType

Use the AddType directive to define or override a default MIME type and file extension pairs. The following example directive tells the Apache HTTP Server to recognize the .tgz file extension:

AddType application/x-tar .tgz

Allow

Allow specifies which client can access a given directory. The client can be all, a domain name, an IP address, a partial IP address, a network/netmask pair, and so on. The DocumentRoot directory is configured to Allow requests from all, meaning everyone has access.

AllowOverride

The AllowOverride directive sets whether any Options can be overridden by the declarations in a .htaccess file. By default, both the root directory and the DocumentRoot are set to allow no .htaccess overrides.

BrowserMatch

The BrowserMatch directive allows the server to define environment variables and take appropriate actions based on the User-Agent HTTP header field — which identifies the client’s Web browser type. By default, the Web server uses BrowserMatch to deny connections to specific browsers with known problems and also to disable keepalives and HTTP header flushes for browsers that are known to have problems with those actions.

Cache Directives

The following, however, is a list of some of the more important cache-related directives.

  • CacheEnable — Specifies whether the cache is a disk, memory, or file descriptor cache. By default CacheEnableconfigures a disk cache for URLs at or below /.
  • CacheRoot — Specifies the name of the directory containing cached files. The default CacheRoot is the /var/httpd/proxy/ directory.
  • CacheSize — Specifies how much space the cache can use in kilobytes. The default CacheSize is 5 KB.

The following is a list of some of the other common cache-related directives.

  • CacheMaxExpire — Specifies how long HTML documents are retained (without a reload from the originating Web server) in the cache. The default is 24 hours (86400 seconds).
  • CacheDefaultExpire — Specifies the expiry time in hours for a document that was received using a protocol that does not support expiry times. The default is set to 1 hour (3600 seconds).
  • NoProxy — Specifies a space-separated list of subnets, IP addresses, domains, or hosts whose content is not cached. This setting is most useful for Intranet sites.

CacheNegotiatedDocs

By default, the Web server asks proxy servers not to cache any documents which were negotiated on the basis of content (that is, they may change over time or because of the input from the requester). If CacheNegotiatedDocs is set to on, this function is disabled and proxy servers are allowed to cache such documents.

CustomLog

CustomLog identifies the log file and the log file format. By default, the access log is recorded to the /var/log/apache2/access.log file while errors are recorded in the /var/log/apache2/error.log file.

The default CustomLog format is the combined log file format, as illustrated here:

remotehost rfc931 user date "request" status bytes referrer user-agent

DefaultType

DefaultType sets a default content type for the Web server to use for documents whose MIME types cannot be determined. The default is text/plain.

Deny

Deny works similar to Allow, except it specifies who is denied access. The DocumentRoot is not configured to Deny requests from anyone by default.

Directory

<Directory /path/to/directory> and </Directory> tags create a container used to enclose a group of configuration directives which apply only to a specific directory and its subdirectories. Any directive which is applicable to a directory may be used within Directory tags.

By default, very restrictive parameters are applied to the root directory (/), using the Options (refer to Options) andAllowOverride directives. Under this configuration, any directory on the system which needs more permissive settings has to be explicitly given those settings.

The Directory container can be also be used to configure additional cgi-bin directories for server-side applications outside of the directory specified in the ScriptAlias directive.

To accomplish this, the Directory container must set the ExecCGI option for that directory.

For example, if CGI scripts are located in /home/my_cgi_directory, add the following Directory container to the httpd.conf file:

<Directory /home/my_cgi_directory>     Options +ExecCGI </Directory>

Next, the AddHandler directive must be uncommented to identify files with the .cgi extension as CGI scripts.

DirectoryIndex

The DirectoryIndex is the default page served by the server when a user requests an index of a directory by specifying a forward slash (/) at the end of the directory name.

When a user requests the page http://example/this_directory/, they get either the DirectoryIndex page, if it exists, or a server-generated directory list. The default for DirectoryIndex is index.html. The server tries to find either of these files and returns the first one it finds. If it does not find one of these files and Options Indexes is set for that directory, the server generates and returns a listing, in HTML format, of the subdirectories and files within the directory, unless the directory listing feature is turned off.

DocumentRoot

DocumentRoot is the directory which contains most of the HTML files which are served in response to requests. The default DocumentRoot, for both the non-secure and secure Web servers, is the /var/www/html directory. For example, the server might receive a request for the following document:

http://sanjeev-apache.net/

The server looks for the following file in the default directory:

/var/www/html/index.html

ErrorDocument

The ErrorDocument directive associates an HTTP response code with a message or a URL to be sent back to the client. By default, the Web server outputs a simple and usually cryptic error message when an error occurs. The ErrorDocumentdirective forces the Web server to instead output a customized message or page.

HostnameLookups

HostnameLookups can be set to on, off, or double. If HostnameLookups is set to on, the server automatically resolves the IP address for each connection. Resolving the IP address means that the server makes one or more connections to a DNS server, adding processing overhead. If HostnameLookups is set to double, the server performs a double-reverse DNS look up adding even more processing overhead.

To conserve resources on the server, HostnameLookups is set to off by default.

IfModule

<IfModule> and </IfModule> tags create a conditional container which are only activated if the specified module is loaded. Directives within the IfModule container are processed under one of two conditions. The directives are processed if the module contained within the starting <IfModule> tag is loaded. Or, if an exclamation point ! appears before the module name, the directives are processed only if the module specified in the <IfModule> tag is not loaded.

Include

Include allows other configuration files to be included at runtime.

The path to these configuration files can be absolute or relative to the ServerRoot.

For the server to use individually packaged modules, such as mod_ssl, mod_perl, and php, the following directive must be included in Section 1: Global Environment of apache2.conf:

Include conf.d/*.conf

IndexIgnore

IndexIgnore lists file extensions, partial file names, wildcard expressions, or full file names. The Web server does not include any files which match any of those parameters in server-generated directory listings.

LanguagePriority

LanguagePriority sets precedence for different languages in case the client Web browser has no language preference set.

Listen

The Listen command identifies the ports on which the Web server accepts incoming requests. By default, the Apache HTTP Server is set to listen to port 80 for non-secure Web communications and (in the ssl.conf file which defines any secure servers) to port 443 for secure Web communications.

If the Apache HTTP Server is configured to listen to a port under 1024, only the root user can start it. For port 1024 and above, httpd can be started as a regular user.

The Listen directive can also be used to specify particular IP addresses over which the server accepts connections.

Location

The <Location> and </Location> tags create a container in which access control based on URL can be specified.

For instance, to allow people connecting from within the server’s domain to see status reports, use the following directives:

<Location /server-status>  
SetHandler server-status
Order deny,allow
Deny from all
Allow from <.sanjeev-apache.net>
</Location>

Replace <.sanjeev-apache.net> with the second-level domain name for the Web server.

To provide server configuration reports (including installed modules and configuration directives) to requests from inside the domain, use the following directives:

<Location /server-info>     
SetHandler server-info
Order deny,allow
Deny from all
Allow from <.example.com>
</Location>

Again, replace <.sanjeev-apache.net> with the second-level domain name for the Web server.

LogFormat

The LogFormat directive configures the format of the various Web server log files. The actual LogFormat used depends on the settings given in the CustomLog directive.

The following are the format options if the CustomLog directive is set to combined:

%h (remote host’s IP address or hostname)

Lists the remote IP address of the requesting client. If HostnameLookups is set to on, the client hostname is recorded unless it is not available from DNS.

%l (rfc931)

Not used. A hyphen — appears in the log file for this field.

%u (authenticated user)

Lists the username of the user recorded if authentication was required. Usually, this is not used, so a hyphen -appears in the log file for this field.

%t (date)

Lists the date and time of the request.

%r (request string)

Lists the request string exactly as it came from the browser or client.

%s (status)

Lists the HTTP status code which was returned to the client host.

%b (bytes)

Lists the size of the document.

%\”%{Referer}i\” (referrer)

Lists the URL of the webpage which referred the client host to Web server.

%\”%{User-Agent}i\” (user-agent)

Lists the type of Web browser making the request.

LogLevel

LogLevel sets how verbose the error messages in the error logs are. LogLevel can be set (from least verbose to most verbose) to emerg, alert, crit, error, warn, notice, info, or debug. The default LogLevel is warn.

MaxKeepAliveRequests

This directive sets the maximum number of requests allowed per persistent connection. The Apache Project recommends a high setting, which improves the server’s performance. MaxKeepAliveRequests is set to 100 by default, which should be appropriate for most situations.

Options

The Options directive controls which server features are available in a particular directory. For example, under the restrictive parameters specified for the root directory, Options is only set to the FollowSymLinks directive. No features are enabled, except that the server is allowed to follow symbolic links in the root directory.

By default, in the DocumentRoot directory, Options is set to include Indexes and FollowSymLinks. Indexes permit the server to generate a directory listing for a directory if no DirectoryIndex (for example, index.html) is specified.FollowSymLinks allows the server to follow symbolic links in that directory.

Order

The Order directive controls the order in which allow and deny directives are evaluated. The server is configured to evaluate the Allow directives before the Deny directives for the DocumentRoot directory.

PidFile

PidFile names the file where the server records its process ID (PID). By default the PID is listed in /var/run/apache2.pid.

Redirect

When a webpage is moved, Redirect can be used to map the file location to a new URL. The format is as follows:

Redirect /<old-path>/<file-name> http://<current-domain>/<current-path>/<file-name>

In this example, replace <old-path> with the old path information for <file-name> and <current-domain> and <current-path> with the current domain and path information for <file-name>.

In this example, any requests for <file-name> at the old location is automatically redirected to the new location.

For more advanced redirection techniques, use the mod_rewrite module included with the Apache HTTP Server. For more information about configuring the mod_rewrite module.

ScriptAlias

The ScriptAlias directive defines where CGI scripts are located. Generally, it is not good practice to leave CGI scripts within the DocumentRoot, where they can potentially be viewed as text documents. For this reason, a special directory outside of the DocumentRoot directory containing server-side executables and scripts is designated by the ScriptAliasdirective. This directory is known as a cgi-bin and is set to /var/www/cgi-bin/ by default.

ServerName

ServerName specifies a hostname and port number (matching the Listen directive) for the server. The ServerNamedoes not need to match the machine’s actual hostname.

The following is a sample ServerName directive:

ServerName www.sanjeev-apache.net:80

When specifying a ServerName, be sure the IP address and server name pair are included in the /etc/hosts file.

ServerRoot

The ServerRoot directive specifies the top-level directory containing website content. By default, ServerRoot is set to “/etc/apache2” for both secure and non-secure servers.

VirtualHost

<VirtualHost> and </VirtualHost> tags create a container outlining the characteristics of a virtual host. The VirtualHost container accepts most configuration directives.

A commented VirtualHost container is provided in apache2.conf, which illustrates the minimum set of configuration directives necessary for each virtual host.

<VirtualHost *:80>
ServerAdmin
admin@sanjeev-apache.net
ServerName sanjeev-apache.net
ServerAlias
www.sanjeev-apache.net
DocumentRoot /var/www/test/index.html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Rewrite URLs with mod_rewrite

Enabling mod_rewrite

sudo a2enmod rewrite

Now take apache2.service restart

Setting up .htaccess: An .htaccess file allows us to modify our rewrite rules without accessing server configuration files. For this reason, .htaccess is critical to your web application’s security.

For enabling .htaccess file in the configuration we need to mention some condition in /etc/apache2/sites-available/sanjeev-apache.net as shown below and then take apache2 service restart.

<VirtualHost *:80>
<Directory /var/www/html>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Require all granted
</Directory>
. . .
</VirtualHost>

Now, create the .htaccess file in the web root.

cd /var/www/test/.htaccess

vim /var/www/html/.htaccess

RewriteEngine on
RewriteRule ^about$ about.html [NC]
redirect to about section using mod_rewrite module

In this case, ^about$ is the pattern, about.html is the substitution, and [NC] is a flag. Our example uses a few characters with special meaning:

  • ^ indicates the start of the URL after localhost/about
  • $ indicates the end of the URL.
  • about matches the string “about”.
  • about.html is the actual file that the user accesses.
  • [NC] is a flag that makes the rule case insensitive.

Simplifying Query Strings with RewriteRule

RewriteRule ^shirt/summer$ results.php?item=shirt&season=summer [QSA]

The shirt/summer is explicitly matched in the requested address and Apache is told to serve results.php?item=shirt&season=summer instead.

To make the rule more generic, we can use the regular expression to match parts of the original address and use those parts in a substitution pattern. The modified rule will then look as follows:

RewriteRule ^([A-Za-z0-9]+)/(summer|winter|fall|spring) results.php?item=$1&season=$2 [QSA]

The first regular expression group in parenthesis matches a string containing alphanumeric characters and numbers like shirt or pants and saves the matched fragment as the $1 variable. The second regular expression group in parenthesis matches exactly summer, winter, fall, or spring, and similarly saves the matched fragment as $2.

Adding Conditions with Logic Using RewriteConds

The RewriteCond directive lets us add conditions to our rewrite rules to control when the rules will be processed. All RewriteConds abide by the following format:

General RewriteCond structure

RewriteCond TestString Condition [Flags]
  • RewriteCond specifies the RewriteCond directive.
  • TestString is the string to test against.
  • Condition is the pattern or condition to match.
  • Flags are optional parameters that may modify the condition and evaluation rules.

If a RewriteCond evaluates to true, the RewriteRule immediately following will be considered. If it won't, the rule will be discarded. Multiple RewriteCond may be used one after another and, with the default behavior, all must evaluate to true for the following rule to be considered.

As an example, let’s assume you would like to redirect all requests to non-existent files or directories on your site back to the home page instead of showing the standard 404 Not Found error page. This can be achieved with following conditions rules:

vim /var/www/test/.htaccess

Enabling Necessary Apache Modules

The modules we need are mod_proxy itself and several of its add-on modules, which extend its functionality to support different network protocols. Specifically, we will use:

  • mod_proxy, the main proxy module Apache module for redirecting connections; it allows Apache to act as a gateway to the underlying application servers.
  • mod_proxy_http, which adds support for proxying HTTP connections.
  • mod_proxy_balancer and mod_lbmethod_byrequests, which add load balancing features for multiple backend servers.

To enable these four modules, execute the following commands in succession.

  • sudo a2enmod proxy
  • sudo a2enmod proxy_http
  • sudo a2enmod proxy_balancer
  • sudo a2enmod lbmethod_byrequests

To put these changes into effect, restart Apache.

  • sudo systemctl restart apache2

Modifying the Default Configuration to Enable Reverse Proxy

Example 1 — Reverse Proxying a Single Backend Server

Replace all the contents within VirtualHost block with the following, so your configuration file looks like this:

/etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
</VirtualHost>

If you followed along with the example servers in Step 2, use 127.0.0.1:8080 as written in the block above. If you have your own application servers, use their addresses instead.

There are three directives here:

  • ProxyPreserveHost makes Apache pass the original Host header to the backend server. This is useful, as it makes the backend server aware of the address used to access the application.
  • ProxyPass is the main proxy configuration directive. In this case, it specifies that everything under the root URL (/) should be mapped to the backend server at the given address. For example, if Apache gets a request for /example, it will connect to http://your_backend_server/example and return the response to the original client.
  • ProxyPassReverse should have the same configuration as ProxyPass. It tells Apache to modify the response headers from backend server. This makes sure that if the backend server returns a location redirect header, the client's browser will be redirected to the proxy address and not the backend server address, which would not work as intended.

To put these changes into effect, restart Apache.

  • sudo systemctl restart apache2

Now, if you access http://your_server_ip in a web browser, you will see your backend server response instead of standard Apache welcome page. If you followed Step 2, this means you'll see Hellow world!.

Example 2 — Load Balancing Across Multiple Backend Servers

If you have multiple backend servers, a good way to distribute the traffic across them when proxying is to use load balancing features of mod_proxy.

Replace all the contents within the VirtualHost block with the following, so your configuration file looks like this:

/etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>
<Proxy balancer://mycluster>
BalancerMember http://127.0.0.1:8080
BalancerMember http://127.0.0.1:8081
</Proxy>
ProxyPreserveHost OnProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

The configuration is similar to the previous one, but instead of specifying a single backend server directly, we’ve used an additional Proxy block to define multiple servers. The block is named balancer://mycluster (the name can be freely altered) and consists of one or more BalancerMembers, which specify the underlying backend server addresses. The ProxyPass and ProxyPassReverse directives use the load balancer pool named mycluster instead of a specific server.

If you followed along with the example servers in Step 2, use 127.0.0.1:8080 and 127.0.0.1:8081for the BalancerMember directives, as written in the block above. If you have your own application servers, use their addresses instead.

Create a Self-Signed SSL Certificate

TLS, or transport layer security, and its predecessor SSL, which stands for secure sockets layer, are web protocols used to wrap normal traffic in a protected, encrypted wrapper.

Using this technology, servers can send traffic safely between the server and clients without the possibility of the messages being intercepted by outside parties. The certificate system also assists users in verifying the identity of the sites that they are connecting with.

Step 1: Create SSL certificate

# sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt

After this, we need to make entry of some required detail as shown below.

apache-selfsigned.key created
apache-selfsigned.crt created
  • OpenSSL: This is the basic command line tool for creating and managing OpenSSL certificates, keys, and other files.
  • req: This subcommand specifies that we want to use X.509 certificate signing request (CSR) management. The “X.509” is a public key infrastructure standard that SSL and TLS adhere to for its key and certificate management. We want to create a new X.509 cert, so we are using this subcommand.
  • -x509: This further modifies the previous subcommand by telling the utility that we want to make a self-signed certificate instead of generating a certificate signing request, as would normally happen.
  • -nodes: This tells OpenSSL to skip the option to secure our certificate with a passphrase. We need Apache to be able to read the file, without user intervention, when the server starts up. A passphrase would prevent this from happening because we would have to enter it after every restart.
  • -days 365: This option sets the length of time that the certificate will be considered valid. We set it for one year here.
  • -newkey rsa:2048: This specifies that we want to generate a new certificate and a new key at the same time. We did not create the key that is required to sign the certificate in a previous step, so we need to create it along with the certificate. The rsa:2048 portion tells it to make an RSA key that is 2048 bits long.
  • -keyout: This line tells OpenSSL where to place the generated private key file that we are creating.
  • -out: This tells OpenSSL where to place the certificate that we are creating.

Now we have to enable /etc/apache2.sites-available/default-ssl.conf using a2ensite and ssl module using a2enmod.

MPM (Multi-Processing Module)

Apache uses one of following MPM (Multi-Processing Module) for handling incoming requests and processes them. Both have their own working type. Below is some basic details about both MPM and there working.

Prefork MPM:

Prefork MPM launches multiple child processes. Each child process handle one connection at a time.

Prefork uses high memory in comparison to worker MPM. Prefork is the default MPM used by Apache2 server. Preform MPM always runs few minimum (MinSpareServers) defined processes as spare, so new requests do not need to wait for new process to start.

Worker MPM:

Worker MPM generates multiple child processes similar to prefork. Each child process runs many threads. Each thread handles one connection at a time.

In sort Worker MPM implements a hybrid multi-process multi-threaded server. Worker MPM uses low memory in comparison to Prefork MPM.

StartServers

  1. This directive set the number of thread created at the time of startup.
  2. The number of thread is dynamically controlled depending upon load.

ThreadPerChild

  1. This directive set number of threads created by each child process
  2. child create these thread at startup and never create more.

ThreadLimit

  1. set upper limit on the configurable number of thread per child process.
  2. If the thread limit is set higher than ThreadPerChild than, extra unused shared memory will be allocated.
  3. If both ThreadLimit and ThreadPerChild are set to value higher than the system can handle, Apache may not start or system can become unstable.

ServerLimit

  1. The upper limit on the number of processes.
  2. If ServerLimit is 10, ThreadLimit is 10, than MaxClient is 100

MaxRequestPerChild

  1. The MaxRequestPerChild directive set the limit on the number of requests that an individual child process will handle.
  2. After MaxRequestPerChild request, a child process will die.
  3. If MaxRequestPerChild is 0, then the process will never expire.

Event MPM:

Event MPM is introduced in Apache 2.4, It is pretty similar to worker MPM but it designed for managing high loads.

This MPM allows more requests to be served simultaneously by passing off some processing work to supporting threads. Using this MPM Apache tries to fix the ‘keep alive problem’ faced by other MPM. When a client completes the first request then the client can keep the connection open, and send further requests using the same socket, which reduces connection overload.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--

--