Apache Webserver

Agenda
Introduction to Apache Types of Installations Module Installation Types Directives (Core Module) Directives (Prefork Module) Some Apache hardening Concepts Performance Improvement Parameters Introduction to module Installation & Integration with application Server Apache SSL setup

Introduction to Apache
Apache is a service provided by an open community of developers called Apache Software Foundation. This community provides various services/ products one of them being the open source Apache HTTP Server (httpd) which is commonly known as Apache. This is a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards. Another service being the Apache Tomcat application Server which is an open source implementation of the Java Servlet and Java Server Pages. Httpd alone is capable of serving static pages and in order for it to serve dynamic pages it needs a application server at the backend which could be either a simple tomcat server, hybris server etc. Apache supports a variety of features, many implemented as compiled modules which extend the core functionality. These can range from serverside programming language support to authentication schemes.

Some common language interfaces support Perl, Python, PHP etc. Popular authentication modules include mod_access, mod_auth, mod_digest, and mod_auth_digest. Some other features include SSL and TLS which support mod_ssl, mod_proxy, mod_rewrite which is a URL rewriter. Virtual Hosting is another feature which allows an Apache installation to serve many different actual websites. For example, one machine with one Apache installation could simultaneously serve www.example.com, www.example.org, test47.test-server.example.edu, etc. Apache has performance comparable to other "high-performance" web servers as instead of implementing a single architecture, Apache provides a variety of MultiProcessing Modules (MPMs) which allow Apache to run in a process-based, hybrid (process and thread) mode, to better match the demands of each particular infrastructure.

Types of Installations
Apache can be installed via two methods: Source code Installation RPM Installation There are a set of Prerequisites that need to be met before installation of Apache as follows: 1) Disk Space: One must have at least 500 MB of temporary free disk space available. After installation Apache occupies approximately 50 MB of disk space. The actual disk space requirements will vary considerably based on the chosen configuration options and any third-party modules. 2) ANSI-C compiler should be installed on the server. The GNU C compiler (GCC) from the Free Software Foundation (FSF) is recommended.

 Source Code Installation: 1) The Apache HTTP Server can be downloaded from the Apache HTTP Server download site, which lists several mirrors. Refer to the following site for source package http://httpd.apache.org/download.cgi 2) After downloading the tar file from above URL in /tmp folder one needs to check for MD5 signature with downloaded signature as follows: a) Go to MD5 link provided with the UNIX source tab on the above site b) It will pop up with MD5 signature. Just copy 32 digit alpha numeric signature c) Go to the server where you have uploaded the downloaded tar file and run md5sum tar-file-name. This will also display a MD5 signature. If this is same as the one obtained from the site then the download is correct. 3) Source code compilation: a) Untar the source code downloaded tar -zxvf httpd-2.2.9.tar.gz b) Run the configure command with the installation directory as ./configure --prefix=/opt/apache

c) Run the make command. This shall compile the base modules d) Run the make install command. This shall do the installation of the compiled modules 4) If the above commands finish without any errors then the Apache installation is complete. 5) Start Apache: ./bin/apachectl k start 6) Check if Apache started or not by issuing command telnet localhost 80. If you are able to telnet then Apache started correctly and you shall be able to see the default It Works page once you try and open in your web browser the URL http://localhost:80 . 7) Moreover since we did a default installation you shall be able to see the base modules that are installed in a default mode by using ./httpd l from the bin directory. The output shall be: core.c prefork.c http_core.c mod_so.c

 RPM Installation Here one shall need to depend on the utilities such as rpm and yum to install Apache. However these are simpler ways of installing the web server these result in a distributed architecture of the installation as compared to a one directory install in the source method. The commands shall be: rpm uvh RPM name yum install name

Rest after install the starting and verification process shall be the same as in source install.

Module Installation Types

There are two methods for installing modules in Apache that shall be responsible for the various features that Apache can provide. Static Module Installation Dynamic Module Installation
Static Module Installation: Apache provides a facility wherein one can define statically or explicitly which all modules one needs to incorporate during installation and thus avoid any unnecessary modules from being installed. In this method once the modules are specified at installation time statically they are build/ compiled with Apache and thus after installation when one starts the Apache services then the service alone starts and is accountable for the starting time and no compilation/ building of the module takes place as they are already build at installation time. The syntax for such an installation is as follows:

./configure --prefix=/root/apache --disable-module=all --enablemodule=access --enable-module=log_config --enable-module=dir --enablemodule=mime --enable-module=auth --enable-ssl --with-ssl=/opt/openssl Thus one would can specify as many modules as required and leave all the rest non desirable ones. Thereafter if and when the need arise one can compile a module, copy the module.so file in the modules directory and enable the same in the httpd.conf file with the LoadModule directive.

Dynamic Module Installation: Herein one installs all the modules dynamically that is all modules are installed or referenced in the httpd.conf configuration file and are build / compiled every time Apache server is started. So this will lead to a bit overhead while starting as the modules shall build every time when started. However this provided the flexibility that all the module files i.e. the module.so files are already present in the modules directory of Apache and they are all referenced in the httpd.conf file already after installation.

Thus after install one has a choice of enabling the modules by just commenting/ uncommenting the already present LoadModules directives for various Modules in the httpd.conf file as below: #LoadModule authn_file_module modules/mod_authn_file.so #LoadModule authn_dbm_module modules/mod_authn_dbm.so #LoadModule authn_anon_module modules/mod_authn_anon.so #LoadModule authn_dbd_module modules/mod_authn_dbd.so LoadModule authn_default_module modules/mod_authn_default.so LoadModule authz_host_module modules/mod_authz_host.so #LoadModule authz_groupfile_module modules/mod_authz_groupfile.so #LoadModule authz_user_module modules/mod_authz_user.so #LoadModule authz_dbm_module modules/mod_authz_dbm.so #LoadModule authz_owner_module modules/mod_authz_owner.so #LoadModule authz_default_module modules/mod_authz_default.so LoadModule auth_basic_module modules/mod_auth_basic.so #LoadModule auth_digest_module modules/mod_auth_digest.so #LoadModule dbd_module modules/mod_dbd.so

The dynamic installation can be achieved by the following method: a) ./configure --prefix=/opt/apache2/ --enable-mods-shared=all b) make c) make install

Certain Module and there utility: 1) mod_ssl: This facilitates the use of SSL with Apache and hence provide security with trusted certificates. This module provides SSL v2/v3 and TLS v1 support for the Apache HTTP Server. This shall rely on Openssl to act as a cryptographic engine. 2) mod_rewrite: This module uses a rule-based rewriting engine (based on a regular-expression parser) to rewrite requested URLs on the fly. It supports an unlimited number of rules and an unlimited number of attached rule conditions for each rule, to provide a really flexible and powerful URL manipulation mechanism.

3) mod_proxy: This module implements a proxy/gateway for Apache. It implements proxying capability for AJP13 (Apache JServe Protocol version 1.3), FTP, CONNECT (for SSL), HTTP/0.9, HTTP/1.0, and HTTP/1.1. The module can be configured to connect to other proxy modules for these and other protocols. 4) mod_deflate: This module provides the DEFLATE output filter that allows output from your server to be compressed before being sent to the client over the network. 5) mod_auth_basic: This module allows the use of HTTP Basic Authentication to restrict access by looking up users in the given providers. 6) core: Core Apache HTTP Server features that are always available and are installed by default 7) MPM: The Apache HTTP Server is designed to be a powerful and flexible web server that can work on a very wide variety of platforms in a range of different environments. Different platforms and different environments often require different features, or may have different ways of implementing the same feature most efficiently.

The server ships with a selection of Multi-Processing Modules (MPMs) which are responsible for binding to network ports on the machine, accepting requests, and dispatching children to handle the requests. Thus due to MPM functionality: 1) Apache can more cleanly and efficiently support a wide variety of operating systems 2) The server can be better customized for the needs of the particular site. For example, sites that need a great deal of scalability can choose to use a threaded MPM like worker, while sites requiring stability or compatibility with older software can use a prefork which is a nonthreaded MPM. A required MPM can be chosen by explicitly specifying during installation with the configure script --with-mpm=NAME . If nothing is specified then the default for the OS is installed for e.g. in Unix by default prefork MPM shall be installed if not specified explicitly.

Prefork MPM: This is a non-threaded MPM which is appropriate for sites that need to be compatible with the older non-threaded libraries. Herein a single control process is responsible for launching child processes which listen for connections and serve them when they arrive. Apache always tries to maintain several spare or idle server processes, which stand ready to serve incoming requests. In this way, clients do not need to wait for a new child processes to be forked before their requests can be served.

Worker MPM: This is useful for a hybrid multi-process multi-threaded server. By using threads to serve requests, it is able to serve a large number of requests with less system resources than a process-based server. Yet it retains much of the stability of a process-based server by keeping multiple processes available, each with many threads.

A single control process (the parent) is responsible for launching child processes. Each child process creates a fixed number of server threads as specified in the ThreadsPerChild directive, as well as a listener thread which listens for connections and passes them to a server thread for processing when they arrive. In this way, clients do not need to wait for a new threads or processes to be created before their requests can be served.

Directives (Core Module)

The Core Module Directives are the features that are always available with a default Apache HTTP server installation as the core module is always installed. Moreover all the directives can be found in the configuration file of apache (conf/httpd.conf) Some of the directives of the core module are as below: DocumentRoot Directive: This directive sets the directory from which httpd will serve files. The server appends the path from the requested URL to the document root to make the path to the document. Example: DocumentRoot /usr/web Thus an access to http://www.my.host.com/index.html refers to /usr/web/index.html. If the directory-path is not absolute then it is assumed to be relative to the ServerRoot directive. The DocumentRoot should be specified without a trailing slash.

 ServerRoot Directive: This directive sets the directory in which the server lives. Typically it will contain the subdirectories conf/ and logs/. Relative paths in other configuration directives (such as Include or LoadModule, for example) are taken as relative to this directory. Example: ServerRoot /home/httpd ServerName Directive: This directive sets the request scheme, hostname and port that the server uses to identify itself. This is used when creating redirection URLs. Additionally, ServerName is used (possibly in conjunction with ServerAlias) to uniquely identify a virtual host, when using name-based virtual hosts.

For example, if the name of the machine hosting the web server is simple.example.com, but the machine also has the DNS alias www.example.com and you wish the web server to be so identified,

the following directive should be used: ServerName www.example.com (FQDN:port/ IP:port) If no ServerName is provided then the server will attempt to deduce the hostname by reverse IP lookup and if no port is specified the port from the request will be used. Thus it is suggested to explicitly mention both. ServerAlias Directive: This directive sets the alternate names for a host, for use with namebased virtual hosting. This may include wildcards ServerSignature Directive: This directive allows the configuration of a trailing footer line under server-generated documents (error messages etc). The reason why you would want to enable such a footer line is that in a chain of proxies, the user often has no possibility to tell which of the chained servers actually produced a returned error message. It can have the following values: ServerSignature On|Off|EMail

 <Directory> Directive: <Directory> and </Directory> are used to enclose a group of directives that will apply only to the named directory, sub-directories of that directory, and the files within the respective directories. Any directive that is allowed in a directory context may be used. Example: <Directory /> AllowOverride None </Directory> <Directory /home> AllowOverride FileInfo </Directory>

The default Apache access for <Directory /> is Allow from ALL and thus it should be changed to the below and then override this for the directories that you want accessible.

<Directory /> Order Deny,Allow Deny from All </Directory> AccessFileName Directive: While processing a request the server looks for the first existing configuration file from this list of names in every directory of the path to the document. Example: AccessFileName filename [filename] AccessFileName .htaccess Thus before returning the document /usr/local/web/index.html, the server will read /.htaccess, /usr/. htaccess, /usr/local/. htaccess and /usr/local/web/. htaccess for directives unless they have been disabled by <Directory /> AllowOverride None </Directory>

 AllowOverride Directive: When the server finds an .htaccess file it needs to know which directives declared in that file can override earlier configuration directives. This is allowed only in the <Directory> directive.

It can have the following values: AllowOverride All|None|directive-type [directive-type] AllowOverride All this is default conf AllowOverride None this will completely ignore the .htaccess file and server will not read this file at all
The directive-type can be as follows: AuthConfig: this allows the use of all authorization directives FileInfo: this allows the use of directives controlling document types e.g. ErrorDocument etc. Limit: Allows use of directives controlling host access Allow, Deny, Order

 ErrorDocument Directive: This determines what the server will return to the client in case of an error Syntax: ErrorDocument error-code document ErrorDocument 404 /cgi-bin/bad_urls.pl ErrorDocument 403 "Sorry can't allow you access today" ErrorLog Directive: This directive sets the name of the file to which the server will log any errors it encounters. If the file-path is not absolute then it is assumed to be relative to the ServerRoot. Example: ErrorLog /var/log/httpd/error_log

Include Directive: This directive allows inclusion of other configuration files from within the server configuration files.

The file path specified may be an absolute path, or may be relative to the ServerRoot directory. Example: Include /usr/local/apache2/conf/ssl.conf

KeepAlive Directive: This directive enables HTTP persistent connections providing long-lived HTTP sessions which allow multiple requests to be sent over the same TCP connection. Syntax: KeepAlive On|Off
When a client uses a Keep-Alive connection it will be counted as a single "request" for the MaxRequestsPerChild directive, regardless of how many requests are sent using the connection.

 KeepAliveTimeout Directive: This is the number of seconds Apache will wait for a subsequent request before closing the connection. However once a request has been received, the timeout value specified by the Timeout directive applies.

Setting KeepAliveTimeout to a high value may cause performance problems in heavily loaded servers as the higher the timeout, the more server processes will be kept occupied waiting on connections with idle clients.
LogLevel Directive: This adjusts the verbosity/ level of the messages recorded in the error logs Example: LogLevel notice The permissible set of values are: emerg, alert, crit, error, warn, notice, info, debug. With debug being the highest verbosity possible.

 MaxKeepAliveRequests Directive: This directive limits the number of requests allowed per connection when KeepAlive is on. If it is set to 0, unlimited requests will be allowed. It is recommended that this setting be kept to a high value for maximum server performance. Example: MaxKeepAliveRequests 500

TimeOut Directive: The directive defines the length of time Apache will wait for certain I/O events in various circumstances before failing a request: a) When reading data from the client, the length of time to wait for a TCP packet to arrive if the read buffer is empty. b) When writing data to the client, the length of time to wait for an acknowledgement of a packet if the send buffer is full.

 <VirtualHost> Directive: <VirtualHost> and </VirtualHost> are used to enclose a group of directives that will apply only to a particular virtual host i.e. a specific IP or hostname. When the server receives a request for a document on a particular virtual host, it uses the configuration directives enclosed in the <VirtualHost> section Example: <VirtualHost 10.1.2.3:80> ServerAdmin webmaster@host.example.com DocumentRoot /www/docs/host.example.com ServerName host.example.com ErrorLog logs/host.example.com-error_log TransferLog logs/host.example.com-access_log </VirtualHost> Here the address can be either IP, FQDN or character * (in case of name based virtual hosting)

Virtual hosting refers to hosting more than one web-site on a single machine. Types of Virtual Hosting are: IP Based Name Based Port Based IP Based Virtual Hosting: This incorporates the phenomenon wherein the various sites are hosted on different IP addresses. Thus for a server having has two IP addresses (172.20.16.22 and 172.20.16.33) which resolve to the names server.domain.com and www.otherdomain.com respectively the virtual host configuration shall be as follows: <VirtualHost 172.20.16.22:80> DocumentRoot /www/domain ServerName www.server.domain.com ... </VirtualHost> Similarly for the other virtual host with different IP.

Name based Virtual Hosting: Here the IP shall remain same but the server has two aliases which refer to different sites <VirtualHost *:80> DocumentRoot /www/domain ServerName www.domain.com ... </VirtualHost>

<VirtualHost *:80> DocumentRoot /www/subdomain ServerName www.sub.domain.com ... </VirtualHost>

Port based Virtual Hosting: Here the virtual hosts are created with the difference in ports alone but same IP address. <VirtualHost 172.20.16.22 :80> DocumentRoot /www/domain ServerName www.domain.com ... </VirtualHost> <VirtualHost 172.20.16.22 :81> DocumentRoot /www/subdomain ServerName www.sub.domain.com ... </VirtualHost>

Prefork Module Directives

These are the MPM directives which are installed by default on a Unix machine Listen Directive: This directive instructs Apache to listen to only specific IP addresses or ports and by default it responds to requests on all IP interfaces. Syntax: Listen [IP-address:]portnumber Listen 80 This directive tells the server to accept incoming requests on the specified port or address-and-port combination only. StartServers Directive: This directive sets the number of child server processes created on startup. As the number of processes is dynamically controlled depending on the load, there is usually little reason to adjust this parameter.

Example: StartServers number MaxSpareServers Directive: This directive sets the desired maximum number of idle child server processes. An idle process is one which is not handling a request. If there are more than MaxSpareServers idle, then the parent process will kill off the excess processes. Also this should be always at least equal to MinSpareServers + 1. Example: MaxSpareServers 10 MinSpareServers Directive: This directive sets the desired minimum number of idle child server processes. An idle process is one which is not handling a request. If there are fewer than MinSpareServers idle, then the parent process creates new children at a maximum rate of 1 per second.

Example: MinSpareServers 5 MaxClients Directive: This directive sets the limit on the number of simultaneous requests that will be served. Any connection attempts over the MaxClients limit will normally be queued, up to a number based on the ListenBacklog directive. Once a child process is freed at the end of a different request, the connection will then be serviced. For non-threaded servers this directive translates into the maximum number of child processes that will be launched to serve requests. The default value is 256 Example: MaxClients number

 MaxRequestsPerChild Directive: This directive sets the limit on the number of requests that an individual child server process will handle. After MaxRequestsPerChild requests, the child process will die. If MaxRequestsPerChild is 0, then the process will never expire. Example: MaxRequestsPerChild 10000

Some Apache hardening Concepts

Install Apache from a separate group/ user than root which has less privileges so as it has a dedicated UID/GID Turn ServerSignature Off to avoid giving version info on error pages Set ServerTokens Prod to avoid giving version info in http headers Define custom Error Pages rather than use default Apache Error pages to avoid any version info display Deny access to the root file system and then allow access on per directory basis as and where required <Directory /> Order Deny, Allow deny from all </Directory> Run Apache on a separate port than the generic 80 HTTP port Another concept is to implement jail i.e. the chroot module for Apache which makes an all together new filesystem within the existing filesystem for Apache separately so that anyone coming from outside can only see the filesystem for Apache and not the actual one on server used for other processes as well.

Performance Improvement Parameters

Performance Tuning can be practiced by keeping a few general points in mind as below: The RAM on the server should be enough to support the processes and load of your webserver so that there is no swapping of RAM happening in between processes as this will tend to lower the fastness and increase latency effecting the performance. Thus the Maxclients should be chosen optimally considering the RAM and other processes. Apache has a HostnameLookups directive which if turned ON results in logging of hostnames in log for every address via DNS lookup which of course adds latency to requests. Thus this should be OFF and use other alternatives for log reporting. Also the directives such as Allow from and Deny from should use Ips instead of hostnames to avoid DNS lookups again. If the AllowOverride option is not set to none then Apache will look for the .htaccess file in every directory leading to latency. Thus this should be enabled for specific directories alone if required.

 The MaxClients directive determining the max simultaneous requests that can be supported should be mentioned with care as if it is too large it will lead to memory swapping and latency and if too low will result in bad performance with requests waiting so an approximate idea for the same is: MaxClients = Total RAM dedicated to the web server / Max child process size i.e. leaving memory for other processes from RAM. Care should also be taken for the MaxSpareServers, MinSpareServers and StartServers as these define the starting child processes and the min and max processes that should be active at a time to server requests. It should be idle enough so that Apache doesnt have to spawn more than 32 processes per second or else that will be an erroneous situation. An example is: StartServers 8 MinSpareServers 5 MaxSpareServers 20 ServerLimit 256 MaxClients 256

 MaxRequestsPerChild defines the number of requests that a child process can serve before it dies. This should be optimum as well since if it is too low then it will put overhead for creating new processing again and again and if high then can lead to memory leak due to zombie processes. E.g. MaxRequestsPerChild 4000 KeepAlive should be ON so as to avoid load due to new TCP connections and KeepAliveTimeout should be optimal enough to avoid idle connections increasing overheads. Static versus Dynamic Installs- though dynamic is convenient but it leads to overhead as every time all modules are build whereas in static they are already build and only apache service starts.

Introduction to module Installation & Integration with application Server

Within an already installed Apache server we can install more modules as and when required. A general procedure for the same shall be to download the source for the required module and then install it using the apxs utility within Apache. This shall create a <module_name>.so file under the /module directory of Apache which can be included by adding a LoadModule directive for this in the configuration file. Thus a general approach shall be to: Download the source for the module and untar it Run the command ./configure --with-apxs=/opt/apache/bin/apxs make make install

 Give 755 permission to the <module_name>.so file created under module directory Add the following line in httpd.conf file: LoadModule <module_name> modules/<mod_name>.so Thus the above procedure shall help Apache identify the newly added module and load it during starting to provide the desired functionality.

Integration with Application Server (Tomcat): Apache can be integrated with Tomcat via 3 methods: JK connector Proxy Pass Rewrite Rules

 JK connector method: Assuming that Tomcat and Apache are already installed on server one would need to follow the following steps for integration of the two: 1. download JK connector source from http://mirror.nyi.net/apache//tomcat/tomcat-connectors/jk/tomcatconnectors-1.2.32-src.tar.gz untar the same 2. Go to native directory under the untarred folder and run the following commands: ./configure --with-apxs=/opt/apache/bin/apxs make make install 3. This will make the mod_jk.so file in the apache/module directory and confirm that this file has 755 permissions. 4. Create a file named workers.properties in apache/conf folder and edit the same to add the following:

workers.tomcat_home=/opt/apache-tomcat-6.0.35 workers.java_home=/opt/jdk1.7.0_02 ps=/ worker.list=myworker worker.myworker.port=8009 worker.myworker.host=localhost worker.myworker.type=ajp13 worker.myworker.lbfactor=1 5. Edit the httpd.conf file to add the following: LoadModule jk_module modules/mod_jk.so JkWorkersFile conf/workers.properties JkLogFile logs/mod_jk.log JkLogLevel debug JkLogStampFormat [%a %b %d %H:%M:%S %Y] JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories JkRequestLogFormat %w %V %T

# Send JSPs for context /ROOT to worker named myworker JkMount /*.jsp myworker # Send /ROOT to worker named myworker JkMount /* myworker

6.

Start Apache (bin/apachectl start) and then Tomcat (bin/startup.sh). Open web browser at http://localhost:80. This shall display the Tomcat startup page.

Proxy Pass Method: Another way to connect Apache with Tomcat is to setup a reverse proxy which is a gateway for servers and enables one web server to provide content from another transparently. One needs to install the mod_proxy and mod_proxy_http modules for this method so that the mod_proxy.so and mod_proxy_http.so are there in the module directory and the following lines are there in the httpd.conf file

LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so Once the above is there we can define Proxy pass in the individual virtual host configuration within the httpd.conf file as below: <VirtualHost 192.168.0.200:80> ServerName www.virago.com.sg DocumentRoot /var/www/html DirectoryIndex index.html index.shtml ProxyPass /MyFirst http://www.virago.com.sg:8082/MyFirst ProxyPassReverse /MyFirst http://www.virago.com.sg:8082/MyFirst </VirtualHost> Also at Tomcat end one should have the following configuration for the 8082 proxy port as below in the server.xml file:

<Connector port="8082" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" acceptCount="100" debug="0" connectionTimeout="20000" proxyPort="80" disableUploadTimeout="true" /> Thus the above configuration shall redirect request to the specific path to the Tomcat server and hence server the pages. Rewrite Rule Method: This method requires the mod_rewrite module which further uses a rulebased rewriting engine (based on a regular-expression parser) to rewrite requested URLs on the fly. It supports an unlimited number of rules and an unlimited number of attached rule conditions for each rule, to provide a really flexible and powerful URL manipulation mechanism. The URL conditions can depend upon various environment variables, timestamps, server variables etc providing a lot of flexibility.

The rewrite module can be configured either globally or on a per-directory basis in the <Directory> </Directory> tags within the httpd.conf file.

The main directives for the rewrite condition application are: RewriteEngine: This directive enables or disables the runtime rewrite engine. RewriteOptions: This directive sets either the Inherit or the MaxRedirects options for the current per-server or per-directory configuration. The Inherit option shall be specified when Rewrite rules are to be used within Virtual hosts. RewriteBase: This directive explicitly sets the base URL for per-directory rewrites. So that the Rewrite rule shall only be applied to the URL after the base URL and thus the rewritten pattern after processing shall also be appended after the base URL only. RewriteCond: This directive defines a rule condition i.e. when the rewrite rule is to be applied. RewriteRule: This directive serves as the actual rule that will define how the URL is rewritten.

An example being as below: <Directive /var/www/html> RewriteEngine ON RewriteLog /var/log/httpd_rewrite RewriteLevel 1 # this could be from 0-9 with 9 being debug RewriteBase /~stuff/ RewriteRule ^foo$ foo/ [R] </Directive> A general syntax of a Rewrite rule is: RewriteRule <pattern><action> [flags] where <pattern> being the regular expression matching the URL to be rewritten, action describes how the URL is to be rewritten and flags are optional that can be attached to a rule for e.g. the one above [R] means Redirect. A list of all available Flags can be found at: http://httpd.apache.org/docs/current/rewrite/flags.html#flag_r

Rewrite Condition: An example of rewrite condition is as below RewriteCond %{HTTP_USER_AGENT} ^Mozilla RewriteRule ^/$ /homepage.max.html [L] RewriteCond %{HTTP_USER_AGENT} ^Lynx RewriteRule ^/$ /homepage.min.html [L] RewriteRule ^/$ /homepage.std.html [L] Thus as per above if you use a browser which identifies itself as 'Mozilla', then you get the max homepage (which could include frames, or other special features). If you use the Lynx browser (which is terminal-based), then you get the min homepage (which could be a version designed for easy, text-only browsing). If neither of these conditions apply (you use any other browser, or your browser identifies itself as something non-standard), you get the std (standard) homepage. The L flag here means stop the rewriting process immediately and don't apply any more rules.

Apache SSL setup

Apache can provide security with SSL in integration with openssl. Thus to enable SSL on Apache follow the following steps: 1. Install openssl either through source or rpm (yum install openssl libssldev) 2. Apache can be configured for SSL either during installation only by using --enable-ssl --with-ssl=/opt/openssl with the ./configure or later on by installing the mod_ssl module separately and adding the mod_ssl.so in module folder 3. For the approach where we install apache with SSL steps are a) ./configure --prefix=/opt/apache/ --enable-mods-shared=all --enable-ssl b) make c) make install d) Keep the below line uncommented in httpd.conf file LoadModule ssl_module modules/mod_ssl.so e) Configure virtual host for https port 443

<VirtualHost *:443> DocumentRoot "/opt/apache//htdocs" ServerName www.example.com ServerAdmin you@example.com ErrorLog "/opt/apache//logs/error_log" TransferLog "/opt/apache//logs/access_log" SSLEngine on SSLCertificateKeyFile "/opt/apache//conf/server.key" SSLCertificateFile "/opt/apache//conf/server.crt" </VirtualHost> f) Also add port 443 to the Listen directive in httpd.conf file g) Certificates should be present in the conf directory as mentioned in virtual host h) Now when Apache is started it shall be accessible over https://localhost:443

 Rotate Log and Log Rotate: Log rotation can be facilitated for Apache logs either by the Rotate Log feature/ script for apache or via the system Log Rotate mechanism 1. Rotate Log Script: This is present in /bin directory of Apache and has the following syntax: rotatelogs [ -l ] logfile [ rotationtime [ offset ]] | [ filesizeM ] Thus this can be used in conjunction with log directives in the httpd.conf file to specify the log rotation as below: CustomLog "|bin/rotatelogs /var/logs/logfile 86400" common CustomLog "|bin/rotatelogs /var/logs/logfile 5M" common ErrorLog "|bin/rotatelogs /var/logs/errorlog.%Y-%m-%d-%H_%M_%S 5M"

 Log Rotate for Unix machines: Log rotate is a build in feature for Unix machines and can be installed at OS installation time only or later on using the package The Log rotate provides 3 files/folders that are used for configuration: /etc/logrotate.conf /etc/logrotate.d /etc/cron.daily/logrotate Further the /etc/crontab file has entry for the /etc/cron.daily folder to execute the files within it at a designated time. So it shall execute whatever is there in the /etc/cron.daily/logrotate file. Next the /etc/cron.daily/logrotate calls the /etc/logrotate.conf file which has instructions to execute execute every thing within the /etc/logrotate.d folder. Thus finally one just needs to define specific format files for any application (Apache in our case) in the /etc/logrotate.d folder for

1. 2. 3.

execution of log rotation. A sample of such a file for Apache is as below: /var/log/apache2/*.log { weekly missingok rotate 52 compress delaycompress notifempty create 640 root adm sharedscripts postrotate if [ -f "`. /etc/apache2/envvars ; echo ${APACHE_PID_FILE:/var/run/apache2.pid}`" ]; then /etc/init.d/apache2 reload > /dev/null fi endscript }