Multiple Apache HTTPd Instances to Secure your Cloud Instance

Most of the time you start using a server on the cloud with a basic server configuration. Most likely Linux, but it could be windows. This small essay is for those of you that choose Linux.

There are many reasons why to start a second instance of Apache Web Server (httpd). The reason that I prefer, is the control web server speech. By having a second server, you are able to host some (php, perl, cgi, or other) scripts that will enable you, as the administrator or IT especialist, to administer that server in an easy and more efficient way.

Many of you out there might be trying to figure out, why someone is going to need this, but if you got to this essay is because you have been thinking about it. In my specific case, I cannot afford to have all apache modules on for my other application, and need to be on a non-default port. Also, I don't want people to login into the server for any other reason other than root tasks.

How to setup a second apache instance for Control purposes?

Setting up a second apache web server (httpd) instance for control and independent instantiation purposes could be an easy solution to be able to manage automatic maintenance and reliability tasks in an IT environment. Many times the idea of something is way much simpler than the actual implementation due to lack of standardization among OS distributions or default initialization scripts.

This is one of those instances, where is easier said than done. Apache httpd, depending on your distribution, will come with an init.d script that will relay on many things outside the control of the apache server itself. The first thing there, and most dangerous, at least in Red Hat Enterprise 4, is the killproc command that is used to kill all processes with a given name. This command makes the stop argument of httpd script a very dangerous task to run in a production environment.

In our own production environment with 6 tomcat servers running and 1 httpd (1st instance running) it produce the unpredictable behavior of stopping some of the tomcat services (not all) and the initial httpd environment.

Below are the steps that are needed to overcome the issues above and make sure that your second control instance of httpd will be independent and solid from any other script initialization.

Assumptions:

• Red Hat Enterprise 4
• Apache 2.0.52 installed with built: Feb 18 2009 7:54:31

STEPS:

Copy the httpd initial script to a second instance with <#cp /etc/init.d/httpd /etc/init.d/httpd2>

Copy the httpd binary to a second instance with <#cp /usr/sbin/httpd /usr/sbin/httpd2>

Copy the apachectl to a second instance with <#cp /usr/sbin/apachectl /usr/sbin/apachectl2>

Copy the sysconfig httpd config file with <#cp /etc/sysconfig/httpd /etc/sysconfig/httpd2>

Copy the httpd.conf file with <#cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd2.conf>

Change the following settings in httpd2.conf file:

PidFile run/httpd2.pid
Listen xxx1
ErrorLog
logs/error_httpd2_log
CustomLog logs/access_httpd2_log combined
ServerName domain.com
DocumentRoot "/var/www/html"

Change the /etc/init.d/httpd2 file with the following settings:

/etc/sysconfig/httpd2 instead of httpd

Httpd=${HTTPD-/usr/sbin/httpd2}

prog=httpd2

pidfile=${PIDFILE-/var/run/httpd2.pid}

lockfile=${LOCKFILE-/var/lock/subsys/httpd2}

CONFFILE=/etc/httpd/conf/httpd2.conf

Make sure that the new service will be up on restarts with chkconfig command.

---

As always, I hope you keep enjoying the cloud world and your comments are always welcomed.