Configuring Apache for maximum performance requires our interest in 2 areas:

i) Tuning Apache so that it exploits the maximum out of the system’s available Hardware and Software. The term Hardware signifies the system CPU, RAM and the disk I/O. Software signifies apache-modules and system OS. Be it software or hardware, I haveoverhead mentioned only those components which the apache software is in direct concern with.

ii)Tuning Apache so that it withstands attacks. Just imagine. All our above efforts in (i)would be in vain if the software is not properly configured to resist attacks such as DOS and even more undesirable, the DDOS. Web server administrators in trying to do so discovered that this itself was a vast area to study and explore and lead to a stream called as ‘Apache Security’. This is why I have placed apache tuning into 2 areas.

So we are now going to journey into the former part. Although, I will not be able to give you a comprehensive detail on each subject (which will require hundreds of pages!) I will try to throw light on some of the most important areas to cover.

The performance tuning of apache will be done in a few stages. These are:

1. Choosing the Best Platform for Apache

2. Editing the Apache Software for Performance

From Part I through Part III, I have references from:

- FMC – The Apache Modelling Project

- Pro Apache by Peter Wainwright

- http://perl.apache.org/docs/1.0/guide/performance.html

Lets discuss the former part.

A fine performing and well tuned software is of no use unless it has a good foundation to work on. It must have the best suited combination of both the Hardware & Software(primarily the OS). Below I attempt to discuss some points which should be kept in mind.

1.1 Choosing the Right Operating System

This is one of the main key element required for proper functioning of the server software. The characteristics of this highly influences the Apache software. Search for the below points when choosing the OS for apache.

1.1.(i) mod_perl Support for the Operating System

This is to be considered seriously since the module mod_perl is a very handy tool which can help in extracting the maximum out Apache. I will be discussing its significance(not tuning with mod_perl) towards the end of this document.

1.1.(ii) Supports ‘sendfile’ system call

This mainly benefits applications following the client-server arhitecture. A sendfile system call in general improves delivery of data from disk over to sockets. For retriveing a client requrested data, from disk, applications spends much time in transferring data from disk to many intermediate buffers and only then, to the socket. This induces much delay. With OS having kernel supporting sendfile, this can be achieved in a single operation.

1. 1.(iii) Good Memory Management

The reason why I mention this is because for the same script, some OS will tend to use the twice as much as memory used by another. Please consider from discarding such OS from your list immediately.

1.1.(iv) Avoiding Memory Leaks

A memory leak happens when some process occupies some blocks of memory and does not release it after it completes the execution of instructions which require those memory blocks. As a result, this part of the memory becomes unusable to other processes until the process that has occupied it has died. We certainly do not want that.

1.1.(iv) Memory-Sharing Capabilities

The new processes(children) that are spawned by apache should be able to share the features of the loaded modules of the parent apache process. This can save much memory and can be realized only if the OS supports memory sharing.

1.1.(v) The Support for OS

Good technical support must be available for the OS you implement and the support team remain vigilant about the holes and other aspects so that they do not give way for hackers. They should also be able to provide you personal support regarding the issues you have with your OS.

1.1.(vi) Discontinued Products

The company of your OS should not all of a sudden withdraw the release of new products and this can prove very bad in course of time even if you are satisfied with the functioning of the OS currently.

1.1.(vii) Regular OS releases

The OS needs to be kept up to date with the latest technology and kernel updates which are utmost necessary to keep the OS stable and free from security leaks.

1.2 Choosing the Right Hardware

In concern with Hardware, there are no hard-set rules in calculating the appropriate number(the number specification of hardware. Eg: 128M RAM). This is because the number needed will be depend on the environment you place Apache in. A well functioning OS can be built on a good hardware and implementation such as:

1.2.(i) Random Access Memory (RAM)

Although you may see everywhere as the amount of installed RAM on the system, this is misleading. What actually counts is the RAM that is actually available to apache process. So we should actually calculate the amount of RAM usage on the system with all the process except apache started. This will be the available RAM for apache. The main goal while calculating the RAM for the server should be: the system never goes into a state to use the SWAP memory. When you need to write something into memory, and it is full, it swaps pages out of the memory that are less frequently used to the SWAP space. Only then you will be able to perform write operation to RAM memory. Thus delay is caused.

In the meantime if an other application supplementing the web server requests some pages and if it happens to be in one of the swapped pages, then the processor will have to load those pages again into main memory(RAM) swapping out some other data which might be needed in a short while. Let to repeat this, the state of the system can get worse. While configuring, you should also be aware that other essential system processes also need to be running smoothly.

1.2.(ii) CPU

This is the ‘Processor’. Using multicore processor with multi cache levels is a general and accepted implementation.

1.2.(iii) Disks with good I/O

Since apache is constant process of retrieval and writing data into disk, a good disk with high I/O capabilities is very much essential. This can also be achieved by implementing RAID.

1.2.(iv) Network Interface Card (NIC)

A hardware component that allows your machine to connect to the network. It sends and receives packets. NICs come in different speeds, varying from 10 MBps to 10 GBps and faster. The most widely used NIC type is the one that implements the Ethernet networking protocol.

1.2.(v) Cluster Implementation

As the name suggests, one or more interconnected machines working together to perform one big task is the core idea behind clustering. This is also implemented to provide backup during failure of one machine in the cluster. Similar to implementing RAID in disks to account for recovery from data loss due to disk failure.

1.2.(vi) Load balancing

This is a by product of clustering. If a web server is unable to handle load, it then dispatches the requests it receives to the web servers in it’s cluster to server the requests. In this mode of implementation, the http request will always reach first to the main server which is configured to hold the sites(or the as mentioned in the DNS). The server according to its load, will either server the request or dispatch the request to its’s load balancing server which handles the request from thereon.

Error
The password for “user” could not be changed because:

Check the error in log file: /usr/local/cpanel/logs/error_log
You will find similar error as shown below.

=============================================================

Can’t locate Crypt/PasswdMD5/XS.pm in @INC (@INC contains:
/scripts /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi
/usr/lib/perl5/5.8.8 .) at /scripts/cPScript/CheckPass/UNIX.pm line 6.
BEGIN failed–compilation aborted at /scripts/cPScript/CheckPass/UNIX.pm line 6.
Compilation failed in require at /scripts/cPScript/CheckPass.pm line 6.
BEGIN failed–compilation aborted at /scripts/cPScript/CheckPass.pm line 6.
Compilation failed in require at /scripts/realchpass line 16.
BEGIN failed–compilation aborted at /scripts/realchpass line 16.

=============================================================

Fix:

ssh into the server with root login credentials.
# /scripts/perlinstaller Crypt::PasswdMD5
Check if the issue still persists.

Then, let’s try fixing the problem without rebuilding Perl or changing any system configuration files. Run:

# /scripts/checkperlmodules
# service cpanel restart

Try changing the password again. If you’re still getting the error, it’s likely that the cPanel Perl installation was overwritten by an updated Perl RPM either manually or by yum. Let’s make sure Perl is left up to cPanel and check if perl automatic perl update is disabled in cPanel and excluded from yum list.

# grep allowperlupdates /var/cpanel/cpanel.config

If you see allowperlupdates=1 you’ve enabled “Allow Perl updates from RPM-based linux vendors” in WHM under Tweak Settings -> System. Return to WHM and uncheck this option then click the “Save” button.

In /etc/yum.conf, check if perl is present in exclude and intall the pearl module.
exclude=apache* bind-chroot courier* dovecot* exim* httpd* mod_ssl* mysql* nsd* perl* php*

Steps to install the pearl module.
First check the current version of Perl
# perl -v
If the older version of Perl is running on server, you get an output something like,
This is perl, v5.8.7 built for i686-linux
Upgrade perl on the Cpanel server
1) Download the latest perl installer from cPanel site.
# wget http://layer1.cpanel.net/perl588installer.tar.gz

2) Untar the file.
# tar -zxvf perl588installer.tar.gz

3) Change the directory to perl588installer.
# cd perl588installer

4) Now run the installer file.
# ./install

5) Check perl modules.
# /scripts/checkperlmodules

6) Force a cPanel update.
# /scripts/upcp –force

****************************************************************************************************************

How to locate mysql log file in the server.

* Check whether the mysql log file is present in /var/log such as /var/log/mysqld.log

* Usually, the mysql log file is present in /var/lib/mysql for cPanel servers. Kindly follow the steps to find the log file

======================================================================================================
root@server1 [/var/lib/mysql]# top -c | grep mysql
17545 mysql 15 0 427m 209m 5176 S 3.9 2.6 266:16.79 /usr/sbin/mysqld –basedir=/ –datadir=/var/lib/mysql –user=mysql –pid-file=/var/lib/mysql/server1.abc.com
======================================================================================================

Find the hostname of the server.
=======================
root@server1 [~]# hostname
server1.abc.com
=======================

We need to find the presently running mysql log file in the server. Usually, mysql log file will be associated with the hostname.

=======================================================
root@server1 [/var/lib/mysql]# ls -l | grep -i server1.abc.com
-rw-rw—-   1 mysql mysql  48495912 Aug 19 16:46 server1.abc.com.err
-rw-rw—-   1 mysql mysql     41720 May 18  2009 SERVER1.ABC.COM.err
-rw-rw—-   1 mysql mysql         6 Aug 19 16:46 server1.abc.com.pid
-rw-rw—-   1 mysql mysql         6 May 18  2009 SERVER1.ABC.COM.pid
=======================================================

From the above code, we find that server1.abc.com.err is used recently (checking with date). Therefore, server1.abc.com.err is the log file. To confirm it further, kindly check the process ID of server1.abc.com.pid with that of mysql process ID.

==========================================
root@server1 [/var/lib/mysql]# cat server1.abc.com.pid
17545
==========================================

The mysql log file displayed below.

==============================================================================
root@server1 [/var/lib/mysql]# vi server1.abc.com.err

090503 04:31:43 mysqld started
InnoDB: The first specified data file ./ibdata1 did not exist:
InnoDB: a new database to be created!
090503 4:31:43 InnoDB: Setting file ./ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait…
090503 4:31:43 InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait…
090503 4:31:43 InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait…
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
090503 4:31:43 InnoDB: Started; log sequence number 0 0
090503 4:31:43 [Note] /usr/sbin/mysqld: ready for connections.
Version: ’5.0.67-community’ socket: ‘/var/lib/mysql/mysql.sock’ port: 3306 MySQL Community Edition (GPL)
090503 4:31:46 [Note] /usr/sbin/mysqld: Normal shutdown

090503 4:31:46 InnoDB: Starting shutdown…
090503 4:31:47 InnoDB: Shutdown completed; log sequence number 0 43655
090503 4:31:47 [Note] /usr/sbin/mysqld: Shutdown complete

090503 04:31:47 mysqld ended
==============================================================================

***********************************************************************************

The “latest visitor” log in the stats of the cpanel is weird and not getting updated.

Error: Raw Access log contain only term “combined”, liked combined combined combined……………………

Fix:
Check if the format provided below is correct in the apache configuration file where version is Apache/2.2.15.
=======================================================================
<IfModule log_config_module>
LogFormat “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\”" combined
LogFormat “%h %l %u %t \”%r\” %>s %b” common

CustomLog logs/access_log common

<IfModule logio_module>
LogFormat “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\” %I %O” combinedio

</IfModule>

</IfModule>
=====================================================================

Like in the case of all apache modules, you can either compile PHP as a static module or compile it as a dynamic module.  In the case of static module , you  can’t perform any modification for the module without recompiling the binary to which it is attached.  For eg.  you can’t add ssl support for the mod_php without re-compiling apache as a whole. And any failure in the compilation may cause downtime for the entire webserver also, including plain html support.

The advantage is that it provides a faster  performance, because the module is initialized  whenever the apache binary is started.

In the case of a dynamic mod_php installation, the necessary modifications or module additions can be done by recompiling the module alone. There is no need to recompile the Apache as the mod_php is not linked with the binary of apache.  But since the webserver loads the module on the fly, it needs to load, initialize and then execute the module.  So it can create some level of slowness while processing php pages.

How does mod_php work?

When PHP  is loaded into Apache as a module (using mod_php), each Apache process will contain an instance of mod_php or PHP interpreter also.   The interpreter comes with a bundle of libraries we enabled during compilation and each  process can make use of these libraries to process the requests. This means that the Apache process that just started  to load a simple HTML page  too will contain a PHP interpreter with all assigned libraries which inturn means resource consumption.

When the webserver gets an HTTP request. The  request header  contains the path to the requested document

e.g. access.log:    xx.xx.xx.xx – - [22/June/2010:21:14:53 -0700] “GET /info.php?=PHPE9568F35-D428-11d2-A769-00AA001ACF42 HTTP/1.1″ 200 2146 “http://domain.com/info.php” “Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7″

1. The request will be redirected to the document root of the domain and then to the file “info.php” , if it fails then the corresponding error message will be given.

2. The info.php file is to be processed. It follows the following steps

Normally every httpd.conf file will have an entry like this

AddType application/x-httpd-php .php5 .php4 .php

It instructs the webserver that the files with extension .php ,.php4,.ph5 are of PHP mime type . The TypesConfig directive sets the location of the MIME types configuration file. This file controls what Internet media types are sent to the client for  given file extension(s).  Sending the correct media type to the client  is important so they know how to handle the content of the file.

root@new [/usr/local/apache/conf]# cat mime.types | grep x-httpd-php
application/x-httpd-php-source          phps
application/x-httpd-php          php php3 php4 php5 php6
root@new [/usr/local/apache/conf]#

Here we can see that the Mime type to be used for files with extension .php  is application/x-httpd-php , while the file with .phps is to be mapped to the php mime type application/x-httpd-php-source .

The webserver identifies that the requested file is of Mime type x-httpd-php.

To handle or process it , the apache has to load the corresponding module. Since it is a php type , the module mod_php will be loaded and it will execute the file.

Since apache is a HTTP server. It gets the HTTP requests and answers with the HTML code.  So the mod_php will execute the commands within php flag and creates the HTML page dynamically and send it back to the client – internet browser which sent HTTP request.

Security concerns / Implications

You can see that  every request or execution of a php file through web is initiated by the webserver. So the webserver acts as the parent of every php execution through web. It imposes a great security threat. Since apache is being executed as an apache  user, all process will be owned by that user. By default  it is “nobody” or “apache”.  Let me try to explain.

If your  web application performs some operations in the db, unless that database (eg: a flat text DB) has built-in access control, you will have to make the database accessible to the “nobody” user. This means a malicious script could access and modify the database, even without a username and password.  Such can be the case with various configuration files too.  Unless you protect these directories or applications with necessary authorization techniques like .htaccess, session control etc. There is a high possibility of attack through webapplication.

Another dangerous issue is of root escalation. If the webserver has a bug, by exploiting that bug, a malicious user can gain some root privileges or escalated to root. Its quite alarming situation as an escalated apache user can do any sort of  actions without any level of authentication.

Also it is difficult to identify the script which performs the malicious activity as all php scripts will be executed as “nobody”

Since PHP applications are executed as web server user, you need to give access and write permissions for the directories wherever the application  is supposed to be working. Sometimes you may be forced to give 777 permissions and it invites lot of attacks.

The files created by php applications will be owned by user “nobody” . So the user will not be able to delete the files unless it is done through another php application. Otherwise he needs to contact the server admin to get the same.

As a security measure, we may be forced to block mails from “nobody” users . But it can create mails generated from php applications being blocked in the server. Various php applications widely used for spamming . So some servers are configured to block mails from nobody users. This creates inconvenience to users.

PHP is similar to many other scripting languages like perl, python etc. But unlike perl and python what makes it stand apart is, its adaptability and power to be used as both command line and server side scripting.  I hear Yahoo’s mail runs on PHP.

I shall try to explain you the difference by executing the same file on different modes. Don’t expect too much from this post.

Command Line (CLI)

PHP Command Line Interface or PHP CLI  as the name implies,  is a way of using PHP in the system command line, like below.

# php -i | more
phpinfo()
PHP Version => 5.2.10-2ubuntu6.3

System => Linux den 2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:54:29 UTC 200
9 i686
Build Date => Nov 26 2009 14:40:20
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /etc/php5/cli
Loaded Configuration File => /etc/php5/cli/php.ini

In other words when the SAPI ( Server API) is “Command Line Interface” as you see above php-cli acts as a connector between underlying  php binary and the command / script which invokes php from shell . This enables processing of the scripts which require php functions and provide the result after execution of the script.   The advantage is that it doesn’t require a browser or webserver  for the execution. It simply requires a PHP parser ie PHP_CLI. This type of usage is ideal for scripts regularly executed using cron (on *nix or Linux) or Task Scheduler (on Windows). These scripts can also be used for simple text processing tasks. (Okay even image processing tasks )

PHP CLI is available on all popular operating systems.  The first step we need to ensure is that the CLI SAPI is installed. For this locate php binary path and execute the command as given below

[george@server3]$ type php
php is /usr/local/bin/php
[george@server3]$ /usr/local/bin/php -v | grep cli
PHP 5.2.9 (cli) (built: Jul 10 2009 19:22:08)

The result ensures that the php-cli module is installed. Now let us  see, how to make it work in a shell. The first thing is to identify the exact path on which php  binary is present. I assume that its /usr/local/bin/php.

Now create the test file info.php

vi info.php

<?php
phpinfo();
?>

Execute the  file from the shell using the command line or shell. If you intent to use it in a cron specify the binary path (interpreter) as the first entry of file .

/usr/local/bin/php info.php

Then the out put will be  of the following  format

[geroge@server3]# php info.php | head
phpinfo()
PHP Version => 5.2.9

System => Linux server3.xxxxxx.xxx 2.6.18-128.7.1.el5 #1 SMP Mon  Aug 24 08:21:56 EDT 2009 x86_64
Build Date => Jul 10 2009 19:17:35
Configure Command =>  './configure'  '--enable-bcmath'  '--enable-calendar' '--enable-dbase' '--enable-ftp'  '--enable-gd-native-ttf' '--enable-libxml' '--enable-magic-quotes'  '--enable-mbstring' '--enable-pdo=shared' '--enable-soap'  '--enable-sockets' '--enable-zend-multibyte' '--enable-zip'  '--prefix=/usr/local' '--with-curl=/opt/curlssl/'  '--with-tidy=/opt/tidy/' '--with-ttf' '--with-xmlrpc'  '--with-xpm-dir=/usr' '--with-zlib' '--with-zlib-dir=/usr'  '--with-litespeed'
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /usr/local/lib
Loaded Configuration File => /usr/local/lib/php.ini

You can see the Application Programming Interface (API) for this script by  checking the variable Server API. In the above test, it is shown as Command Line Interface. The value gets changed according to the mode of usage or execution.

As I mentioned above the php binary was  invoked  by the php-cli interpreter. Once php binary executed the query , the result was returned to the SAPI  ie php-cli, it then passed the results to the command line.

Why do we use it?

Its a quite handy option to create cron jobs. Some times we may need to perform some sort of updates or script execution periodically. If we set  a cron job for this using php, the php-cli option is quite useful.

Server-side scripting

PHP is extensively used for creating dynamic Web pages. You create pages with PHP and HTML. When a visitor opens the page, the server processes the PHP commands and then sends the results to the visitor’s browser along with the static HTML pages. PHP code is embedded into the HTML source document and interpreted by a web server with a PHP processor module, which generates the web page document.

So the minimum requirement for here are the following ones

1.  Web browser ( client side)

2.  Web server

3.   The PHP parser :  which connects the webserver with the underlying php installation.

Illustration :

Now lets us, take the same example. Here I am trying to access the page through a web browser. Let us see how the result looks like

Here , you can see the difference. In the first case when I executed the same file from shell  I got the output without any format. Now the same result is shown as an HTML page.  So let us see  how the conversion takes pace.

The webserver is  connected to the php with the help of “Server API” . This is called PHP parser  it is either CGI or Server Module like apache, litespeed etc. You can see  it is “CGI” here, but it can vary according the mod of installation and webserver it uses. Common values are FastCGI/CGI , Litespeed API, Apache etc

Once the HTTP  / Web server gets the request for the page with php , it calls PHP interpreter to generate HTML. Then this HTML is returned to the client – internet browser which sent the HTTP request.

I believe you might got some ideas how it works or differs . I shall try to give  the difference between CGI and a server module on another post

Server API (SAPI)

PHP is meant  to work on all platforms. So it is essential that it should work with different types of webservers as well.   Every version of  php comes with a set of Binaries to connect php with various webservers and it is known as SAPI.  During configuration of php, we  need to give corresponding options for the webserver to which the interpreter is to be enabled. Once the php is compiled and installed , the corresponding SAPI  will be activated. So every communication between the webserver and PHP will be interpreted  using the corresponding SAPI module enabled.

Apache may use “Apache Handler” while LiteSpeed webserver use “LiteSpeed API” as the SAPI.

Extensions

Being a powerful language which can perform various levels of operation,  PHP needs to utilize various functions and libraries installed on the server. For example GD libraries are required for a php script which performs image manipulations. While a shopping cart or such applications require db connectivity to be enabled.  Like in the case of SAPI a lot of such connectors are shipped along with PHP.  To extend the functionality of php, we enable the necessary libraries while configuring the application using “–with”  option.

You can create your own php extensions and php modules and compile them also.  Again, we will have a discussion about it later.

Here we are going to install apache using the source only. The choice of Operating System here is Linux (distro: Centos). The procedure we follow here will lead to a simple apache installation for dynamic loading of php. PHP will be installed as a module to apache. With a little bit of patience and time, all the necessary modules can be installed with apache. I will be giving a brief idea about the installation of the other modules later.
The basics of installation from the source involves mainly three simple steps (assuming you are lucky):

./configure
make
make install

./configure creates the MAKEFILE on the fly. We can provide the necessary options to configure. To list the available options in the configuring step use

./configure --help

–prefix=/path/… mentions where the executable and its files are installed. If not mentioned it takes the default values.
–enable-[Feature] will enable the specified Feature in apache as it is being built. We are only interested in the DSO capability and hence we enable it with: –enable-so

As a convention we always keep the source code tar ball inside a directory in /usr/src/, thus source installation begins in this directory.

Apache Compilation

Download the required source tar ball of the apache you would like to compile. Here I am installing httpd-2.0.63 from http://httpd.apache.org/download.cgi#apache20. I save it in the /usr/src/ folder.

cd /usr/src/
wget http://www.bizdirusa.com/mirrors/apache/httpd/httpd-2.0.63.tar.gz

This will result in the generation of the file httpd-2.0.63.tar.gz

tar -xzf httpd-2.0.63.tar.gz

This will result in the creation of the directory httpd-2.0.63. Next enter inside this directory and execute the ./configure command.

cd httpd-2.0.63
./configure --prefix=/usr/local/webserver --enable-so

We are installing apache inside /usr/local/webserver and enable DSO to run php as a module to apache. During this process we may get a lot of errors. We resolve these by manually installing the unresolved dependencies either by obtaining their rpms or by using yum. Normally the first dependency we will get to resolve are:

gcc
glibc
libxml and
their corresponding devel packages

In the days where there were no package management tools like yum, pirut, apt-get etc. The old rpms served the installation of these packages with some effort. The task of determining the required rpm package for the required architecture and resolving the other dependencies which arise due to the installation of this rpm may be a tedious task. Some sites which helped in obtaining the necessary rpm suited for our installation and its other dependancies are:

http://rpm.pbone.net/

http://www.rpmfind.net/linux/RPM/

http://ftp.freshrpms.net/

http://dries.ulyssis.org/rpm/packages.html

http://apt.sw.be/

http://rpms.famillecollet.com/ (Remi RPM Repository)

Once everything goes well (we do the ./configure step again to determine this), the make command is executed.

make

If errors are encountered in this stage, We resolve them by installing the unresolved dependencies (Same as the previous step) and then do:

make clean

After this we repeat the make command and then issue:

make install

This process installs the package finally within the system. Modify the init script ( /etc/rc.d/init.d/httpd or /etc/init.d/httpd they are symbolic links) Or sometimes you may even have to create one from the apache site.

The following is the content of one such init script I have used. The line beginning with apachectl/some/path/here and httpd=/some/path/here have to replaced with the appropriate line we have used in the –prefix portion of ./configure.

#!/bin/bash
#
# Startup script for the Apache Web Server
#
# chkconfig: - 85 15
# description: Apache is a World Wide Web server.  It is used to serve \
#              HTML files and CGI.
# processname: httpd
# processname: httpd
# pidfile: /usr/local/apache2/logs/httpd.pid
# config: /usr/local/apache2/conf/httpd.conf
# Source function library.
. /etc/rc.d/init.d/functions
if [ -f /etc/sysconfig/httpd ]; then
. /etc/sysconfig/httpd
fi
# This will prevent initlog from swallowing up a pass-phrase prompt if
# mod_ssl needs a pass-phrase from the user.
INITLOG_ARGS=""
# Path to the apachectl script, server binary, and short-form for messages.
apachectl=/usr/local/webserver/bin/apachectl
httpd=/usr/local/webserver/bin/httpd
pid=$httpd/logs/httpd.pid
prog=httpd
RETVAL=0
# The semantics of these two functions differ from the way apachectl does
# things -- attempting to start while running is a failure, and shutdown
# when not running is also a failure.  So we just do it the way init scripts
# are expected to behave here.
start() {
echo -n $"Starting $prog: "
daemon $httpd $OPTIONS
RETVAL=$?
echo
[ $RETVAL = 0 ] && touch /var/lock/subsys/httpd
return $RETVAL
}
stop() {
echo -n $"Stopping $prog: "
killproc $httpd
RETVAL=$?
echo
[ $RETVAL = 0 ] && rm -f /var/lock/subsys/httpd $pid
}
reload() {
echo -n $"Reloading $prog: "
killproc $httpd -HUP
RETVAL=$?
echo
}
# See how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
status)
status $httpd
RETVAL=$?
;;
restart)
stop
start
;;
condrestart)
if [ -f $pid ] ; then
stop
start
fi
;;
reload)
reload
;;
graceful|help|configtest|fullstatus)
$apachectl $@
RETVAL=$?
;;
*)
echo $"Usage: $prog {start|stop|restart|condrestart|reload|status"
echo $"|fullstatus|graceful|help|configtest}"
exit 1
esac
exit $RETVAL

Next we add the daemon name to the list of services and run it. For this follow the below steps.

chkconfig --add httpd
chkconfig --level 2345 httpd on
chkconfig --list httpd
/etc/init.d/httpd start
lynx http://localhost/ will display the default apache page which means success.

PHP Compilation
Now we are going to install PHP 5.2.13 from source!
Go to /usr/src/

cd /usr/src/

Download the PHP source tarball and extract it

wget http://in3.php.net/get/php-5.2.13.tar.gz/from/in.php.net/mirror
tar -xzf php*
cd php*

Just like in the previous apache installation, we are going to do the ./configure step with the required setting which are displayed using

./configure --help

We are only interested in enabling php as a module (–with-apxs2) support for mysql (–with-mysql) and prefix line. So we go for:

./configure --with-apxs2=/usr/local/webserver/bin/apxs --with-mysql --prefix=/usr/local/webserver/php

The long command can be written in a shorter, more clearer format with:

./configure --with-apxs2=/usr/local/webserver/bin/apxs \
--with-mysql \
--prefix=/usr/local/webserver/php

The same instructions go for the errors here.
Once everything goes smooth:

make
make install

We can provide the recommeneded php.ini setting in the path /usr/local/webserver/php/lib (what ever is the –prefix + /lib) or just copy the recommended settings to /usr/local/webserver/php/lib (This file may have the name php.ini-recommended or php.ini-production)
cp php.ini-recommended /usr/local/webserver/php/lib/php.ini

From now on we can have php’s index page to be the default index page. For this in the apache’s config file append index.php to the directive – DirectoryIndex

The line would thus look like:

DirectoryIndex index.html index.html.var index.php

To make make apache call modular php to execute the php script when encountered, add the following lines to the conf file.

AddType application/x-httpd-php .php
DirectoryIndex index.html index.html.var index.php

Next to test your installation.
In the default document root, create a phpinfo file with the file name index.php an d the contents as:

<?
phpinfo();
?>

Now we will test the apache configuration for any syntax errors and then reload the apache webserver:

apachectl configtest (No errors should be reported)
/etc/init.d/httpd reload

Open a browser window and load the localhost as URL, we will be viewing the phpinfo page in here. In the phpinfo page, the portion Configure Command shows the actual compilation time options used while ./configure is used. The row corresponding to Server API mentions how the php is loaded. ‘Apache 2.0 Handler’ means that php was loaded as a module of apache. The rest of the values can be globally changed by making the required changes in php.ini or locally in .htaccess (which is possible only because it is loaded as an apache module).

Tips on installing PHP as a CGI

Here we do not require installing apache with the –enable-so option. A normal installation will do. The installation of php will not require the option –with-apxs2. However we will have to mention the location of apache source directory with –with-apache=../apache_1.3.14

In the httpd.conf file you will require adding:

ScriptAlias /php/ [path where your php folder is located]
AddType application/x-httpd-php .php
AddType application/x-httpd-php .php3
AddType application/x-httpd-php .phtml
Action application/x-httpd-php /php/php5