Migrating Users in Linux

When a server is to be replaced, often it is a requirement to migrate all user accounts as it is to the new server, which means that the password on these accounts also should not change.

Before the account migration a brief freeze should be imposed on the server. This means no new accounts are to be created till the migration is completed and tested.

To do the migration I used the “pwunconv” utility and merged the passwd file and shadow file on the source server, then copied it across to the new server.

On the new server also I ran the “pwunconv” utility to merge the passwd and shadow files and then appended the file copied from the old server to it.
On old server

sysadmin@old-server:$ sudo /usr/sbin/pwunconv
sysadmin@old-server:$ cp /etc/passwd newpasswd
sysadmin@old-server:$ scp newpasswd new-server:.

On new server

  • Removing the system accounts of the old-server as the new-server already has its own system accounts.
    ajitabhp@new-server:$ vi newpasswd
    ......
    [remove the system accounts]
    
  • Merge the passwd and shadow files and then append the newpasswd to the /etc/passwd file
    ajitabhp@new-server:$ sudo /usr/sbin/pwunconv
    ajitabhp@new-server:$ sudo cat newpasswd >>/etc/passwd
    
  • Change the shell of all users who have /sbin/nologin to /bin/false. This step was required as Debian does not have /sbin/nologin shell, instead it has /bin/false.
    ajitabhp@new-server:$ sudo sed -i 's/\/sbin\/nologin/\/bin\/false/' /etc/passwd
    
  • Finally split the /etc/passwd file to /etc/passwd and /etc/shadow files and do a syntax check and then sort the entries on the basis of UIDs
    ajitabhp@new-server:$ sudo /usr/sbin/pwconv
    ajitabhp@new-server:$ sudo /usr/sbin/pwck
    ajitabhp@new-server:$ sudo /usr/sbin/pwck -s
    

The syntax check told me that the home directories for all the accounts which I migrated from old-server does not exist. So, I ran this one liner to automatically generate the home directories from the /etc/passwd file, if they dont already exists:

ajitabhp@new-server:~$ grep "/home" /etc/passwd|cut -d: -f1,6|sed -e 's/:/ /'|while read user directory;do if [ ! -d $directory ]; then sudo mkdir $directory;sudo chown $user:users $directory;sudo chmod 755 $directory;fi;done

Another quick run on /usr/sbin/pwck gave the following:

ajitabhp@new-server:~$ sudo /usr/sbin/pwck
user news: directory /var/spool/news does not exist
user uucp: directory /var/spool/uucp does not exist
user www-data: directory /var/www does not exist
user list: directory /var/list does not exist
user irc: directory /var/run/ircd does not exist
user gnats: directory /var/lib/gnats does not exist
user nobody: directory /nonexistent does not exist
pwck: no changes

This is fine as these are all system accounts.

Posted in FLOSS | Tagged | Leave a comment

Setting up SNMP

SNMP is Simple Network Management Protocol. It allows the operational statistics of a computer to be stored in object identifiers (OIDs) which can then be remotely queried and changed.
For any serious remote monitoring, SNMP is required. I generally prefer to monitor server performances remotely using Nagios and SNMP.
This document describes the SNMP setup, which can then be used by any SNMP remote management software.
As a security measure, one needs to know the passwords or community strings in order to query the OIDs. The read-only community strings allow the data to be queried only and the read-write community strings allows the data to be changed.
I will be refering the setup on an Ubuntu server, while they should apply to any linux distribution.
Install SNMP daemon by

$ sudo apt-get install snmpd

and then add the following lines on top of the cofiguration file – /etc/snmp/snmpd.conf as follows.

$ sudo vi /etc/snmp/snmpd.conf
# type of string   private/public  host-from-which-access-is-restricted
rwcommunity        private         127.0.0.1
rocommunity        public          127.0.0.1

rwcommunity        ultraprivate    cms.unixclinic.net
rocommunity        itsallyours     cms.unixclinic.net

The first column is the type of community string, the second column is the community string itself and the third column (not mandatory) is the host restricted to use that community string.
The first two lines specifies that only localhost (127.0.0.1) is allowed to query the SNMP daemon using the specified read-only and read-write community strings. The next two lines specifies that only the host cms.unixclinic.net is allowed to query the SNMP daemon using the specified read-only and read-write strings.

If I remove the hostname (cms.unixclinic.net) then basically any host can query the snmp daemon if it knows the right community strings.

After making these changes, give the snmp daemon a restart and then test it using snmpwalk program:

$ sudo invoke-rc.d snmpd restart
Restarting network management services: snmpd.
$ snmpwalk -v1 -c public localhost system
SNMPv2-MIB::sysDescr.0 = STRING: Linux cms.unixclinic.net 2.6.17-10-generic #2 SMP Tue Dec 5 21:16:35 UTC 2006 x86_64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1314) 0:00:13.14
SNMPv2-MIB::sysContact.0 = STRING: Ajitabh Pandey <hostmaster (at) unixclinic (dot) net>
SNMPv2-MIB::sysName.0 = STRING: cms.unixclinic.net
.......
.......

As a result of snmpwalk, you should see the system details as reported by SNMP. The snmpwalk command executed above means, you are querying “localhost” for “system” MIB and have specified SNMP ver 1 protocol to be used and the community string is “public”. Now as you know that this community string is for read-only access and is restricted to queries from 127.0.0.1 IP address only, so this works fine.

Further, if you now try to execute the following command over the network from host “cms.unixclinic.net” using the community string “itsallyours”, it should also work. But in mycase instead a timeout is received:

$ snmpwalk -v1 -c itsallyours cms.unixclinic.net system
Timeout: No Response from cms.unixclinic.net

Just for clarification, the current host from which snmpwalk is being run is also cms.unixclinic.net.

This should work on most distributions (RHEL 3, RHEL 4 and Debian Sarge it works like this), but on Ubuntu “Edgy Eft” 6.10 its not the case. This will fail. The reason being the defualt settings of SNMP. Following is the output of ps command from both an Edgy Eft machine and Sarge machine:

Ubuntu $  ps -ef|grep snmp|grep -v "grep"
snmp      5620     1  0 11:39 ?        00:00:00 /usr/sbin/snmpd -Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1

Debian $ ps -ef|grep snmp|grep -v "grep"
root      2777     1  0  2006 ?        00:46:35 /usr/sbin/snmpd -Lsd -Lf /dev/null -p /var/run/snmpd.pid

If you see carefully, that Ubuntu 6.10 snmp daemon is by default restricted to 127.0.0.1. This means that it is only listening on localhost. To change that and make it listen on all interfaces we need to change the /etc/default/snmpd file:

Change the following line

$ sudo vi /etc/default/snmpd
.....
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1'
.....

to

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid'

and then restart SNMPD

$ sudo invoke-rc.d snmpd restart
Posted in FLOSS | Tagged , , | Leave a comment

Relocating to India

Finally I am relocating to India. I was thinking about it from quite sometime but obviously it was a difficult decision. I finally decided when I got a very good offer from ITC Infotech India Ltd. My resignation on 22nd December 2006 came as a surprise to colleagues and managers in office. But I was firm on my decision. I was asked to give more notice on the basis that this is christmas period and it will be difficult to find a replacement so soon. But I stood firm. After all, my contract of employment says only one month notice is required and ofcourse I was not getting more period from my new employers.

Its become quite hectic after that, cancelling contracts, selling mobile phones at throw-away prices as they were locked to a UK network and unlocking softwares were not in market for them. Good things is that ITC is paying for all my travel and cargo expenses as per actuals as per their relocation policy. I dont have many things to take, but still this means that I dont have to sell my TV and computer. I am still trying to find out a good door-to-door cargo deal.

Posted in Personal | Leave a comment

Setting Up Tomcat and Apache

This howto describes the tomcat+apache setup using mod_jk. The setup described here is where an instance of Apache load balances multiple tomcat instances. The web applications served by both the Tomcat instances must be identical for this to work. This setup can also be modified easily if each tomcat instance is supposed to serve a different web application.

Assumptions

  • Apache webserver installed and configured in the default setup.
  • Tomcat downloaded and installed. Since this setup is to load balance tomcat instances through Apache, two identical instances of tomcat need to be installed like – /opt/apache-tomcat1 and /opt/apache-tomcat2. Do not symlink as we will modify the server.xml file later, differently for each tomcat instance. Its not mandatory to install tomcat in /opt, for example you can choose to install tomcat as provided by your unix/linux distribution, but we need two instances, so in most cases you would be better off installing it directly from apache’s website. For this document, I have assumed that it is installed in /opt.
  • mod_jk downloaded and installed for your distribution. Again it will be better if you download it from apache’s website.
  • Java SDK/Runtime. I chose to install jdk1.5.0_09 and jre1.5.0_09. JDK is not required unless you plan to serve servlets through your instances. I normally create symlinks to original JDK and JRE directories, so that other things are not impacted when I upgrade them.

I have defined the following environment variables in /etc/profile:

JRE_HOME=/opt/jre
JAVA_HOME=/opt/jdk
JDK_HOME=/opt/jdk
PATH=$PATH:$JRE_HOME/bin:$JDK_HOME/bin
export JAVA_HOME JDK_HOME JRE_HOME PATH

This is how my /opt looks like:

[root@webhst01 ~]# ls -l /opt
total 48
lrwxrwxrwx   1 root   root     34 Dec 28 12:45 apache-tomcat-1 -> /opt/apache-tomcat-5.5.17_tomcat1/
lrwxrwxrwx   1 root   root     34 Dec 28 12:45 apache-tomcat-2 -> /opt/apache-tomcat-5.5.17_tomcat2/
drwxr-xr-x  11 tomcat tomcat 4096 Dec 28 12:42 apache-tomcat-5.5.17_tomcat1
drwxr-xr-x  11 tomcat tomcat 4096 Dec 28 12:42 apache-tomcat-5.5.17_tomcat2
lrwxrwxrwx   1 root   root     16 Dec  7 05:49 jdk -> /opt/jdk1.5.0_09
drwxr-xr-x   9 root   root   4096 Sep  7 22:14 jdk1.5.0_09
lrwxrwxrwx   1 root   root     16 Dec  7 05:49 jre -> /opt/jre1.5.0_09
drwxr-xr-x   5 root   root   4096 Sep  7 22:13 jre1.5.0_09

Setting up Tomcat

Tomcat by default runs as root which is not secure. I personally prefer to run it as an ordinary user and start using a custom init script rather than the startup.sh and shutdown.sh scripts.

Creating Tomcat User

[root@webhst01 ~]# /usr/sbin/groupadd tomcat
[root@webhst01 ~]# /usr/sbin/useradd -m -g tomcat -c "Tomcat Application User" -d /home/tomcat tomcat
[root@webhst01 ~]# /bin/chown -R tomcat:tomcat /opt/apache-tomcat-1/;/bin/chown -R tomcat:tomcat /opt/apache-tomcat-2/
[root@webhst01 ~]# mkdir /var/run/tomcat;/bin/chown tomcat:tomcat /var/run/tomcat

Creating Tomcat Init Script

#!/bin/sh
#
# Tomcat        Startup script for the Apache Tomcat Server instance 1
#
# chkconfig: - 85 15
# description: Tomcat Java JSP/Servelet Server instance 1
#
# Local variables
TOMCAT_INSTANCE_NAME="tomcat-1" # Change as required
TOMCAT_INSTANCE_HOME="/opt/apache-$TOMCAT_INSTANCE_NAME"

# Create the Profile Environment... you will need to modify these settings.
export CATALINA_HOME=$TOMCAT_INSTANCE_HOME
export CATALINA_BASE=$CATALINA_HOME
export BASEDIR=$CATALINA_HOME
export CATALINA_PID='/var/run/tomcat/$TOMCAT_INSTANCE_NAME.pid'
export JAVA_HOME='/opt/jdk'
export JDK_HOME='/opt/jdk'
export JRE_HOME='/opt/jre'

if [ "$JAVA_HOME" = "" ]; then
echo
echo "The JAVA_HOME variable is not set.  Please set JAVA_HOME within this script."
echo "JAVA_HOME should point to the apropriate base dir of your Java installation, such"
echo "as '/usr/java/jre1.5.0_08' for example."
echo
echo "This script will not start Tomcat without JAVA_HOME set"
echo

exit 1
fi

user=tomcat
catalina=/opt/apache-$TOMCAT_INSTANCE_NAME/bin/catalina.sh
pidfile=/var/run/tomcat/$TOMCAT_INSTANCE_NAME.pid

if [ -e $pidfile ]; then
pid=`cat $pidfile`
fi

start() {

if [ ! -e $pidfile ]; then
echo "Starting Tomcat . . ."
sudo -u $user $catalina start
else
echo "Tomcat appears to be running.  Process ID is $pid"
fi
}

stop() {
if [ -e $pidfile ]; then
echo "Shutting down Tomcat. . ."
$catalina stop
if [ "$pidfile" != "/" ]; then
rm -rf $pidfile
fi
else
echo "Tomcat does not appear to be running.  No process id found."
exit 1
fi
}

restart() {
stop
start
}

status() {
if [ -e $pidfile ]; then
echo "Tomcat is running with process ID $pid"
else
echo "Tomcat does not appear to be running.  No process id found."
fi
}

# See how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
status)
status
;;
restart)
restart
;;
*)
echo $"Usage: $0 {start|stop|status|restart}"
exit 1
esac

exit $?

Setting up server.xml file

server.xml file allows to configure tomcat using a simple XML descriptor. This file resides in conf directory within the tomcat installation. In our case the server.xml file will be almost similar except the port numbers.
Following are the two server.xml files:

tomcat-1 server.xml file

[root@webhst01 ~]# mv /opt/apache-tomcat-1/conf/server.xml /opt/apache-tomcat-1/conf/server.xml.original
[root@webhst01 ~]# vi /opt/apache-tomcat-1/conf/server.xml
<Server port="8005" shutdown="144b6c105668ca5b10a63545abea46d5">

<!-- Define the Tomcat Stand-Alone Service -->
<Service name="Catalina">

<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009"
enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />

<!-- Define the top level container in our container hierarchy -->
<Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat1">

<Host name="localhost" appBase="/var/www/tomcat-1"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
</Host>

</Engine>

</Service>

</Server>

tomcat-2 server.xml file

root@webhst01 ~]# mv /opt/apache-tomcat-2/conf/server.xml /opt/apache-tomcat-2/conf/server.xml.original
[root@webhst01 ~]# vi /opt/apache-tomcat-2/conf/server.xml

<Server port="8105" shutdown="144b6c105668ca5b10a63545abea46d5">

<!-- Define the Tomcat Stand-Alone Service -->
<Service name="Catalina">

<!-- Define an AJP 1.3 Connector on port 8109 -->
<Connector port="8109" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />

<!-- Define the top level container in our container hierarchy -->
<Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat2">

<Host name="localhost" appBase="/var/www/tomcat-2" unpackWARs="true"
autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
</Host>

</Engine>

</Service>

</Server>

As you can see the port numbers of both the servers are different, one listens on 8005 and the other on 8105. The Server shutdown property is the text string that is sent over a socket connection to stop Tomcat. The default value if “SHUTDOWN”. The shutdown port is always on a loopback interface, which provides host level protection. However, still for better security, replace the default text with some difficult to guess random strings. A random string can be generated as follows:

head -1024c /dev/random | md5sum
chmod 600 /opt/apache-tomcat-1/conf/server.xml
chmod 600 /opt/apache-tomcat-2/conf/server.xml

The AJP instances are listening on ports 8009 and 8109 respectively.

The mod_jk Connector

mod_jk connector is the communication link between Apache and Tomcat. It listens on a defined port for requests from Apache and forwards those requests to Tomcat. Although tomcat can be run in standalone mode as an Apache alternative and sometimes its reportedly faster as well, but still there are following benefits of using Apache as an frontend to Tomcat:

  • Apache can be used to buffer slow connections. Tomcat uses java.io, which uses a thread for each request, so Tomcat can run out of connections as the n umber of slow requests grows. This is a typical problem with application being used by large number of dialup users.
  • mod_jk can be used to load balance amongst several Tomcat instances.
  • Apache features can be used like cgi, php, modules etc
  • Virtual hosts can be isolated in their own Tomcat instances.

Install the mod_jk connector for your distribution, most of the time you need to build it yourself from source. I was lucky enough to find binaries for RHEL4_x86-64 and Debian. I am saying lucky enough because when writing this, I went to tomcat-connectors download site, I could not find the Red Hat connector, which I downloaded earlier, Debian has it in its repositories. Perhaps sometime later I will put in instructions here on how did I compiled the mod_jk connector.
The mod_jk connector file needs to be put in the apache modules directory, which is /etc/httpd/modules (Red Hat and derivatives) or /etc/apache2/modules (Debian and derivatives).

[root@webhst01 ~]# cp mod_jk.so /etc/httpd/modules

I load the mod_jk as follows by putting these lines in the apache configuration files:

<IfModule !mod_jk.c>
LoadModule jk_module "/etc/httpd/modules/mod_jk.so"
</IfModule>

JkWorkersFile           "/etc/httpd/conf/workers.properties"
JkLogFile               "/var/log/httpd/mod_jk.log"

JkLogLevel              debug
JkLogStampFormat        "[%a %b %d %H:%M:%S %Y] "
JkOptions               +ForwardKeySize +ForwardURICompat -ForwardDirectories
JkRequestLogFormat      "%w %V %T"

Please note that if you are configuring virtual servers in Apache (as I did) then these lines needs to be put outside the virtual server area. If you put these lines in virtual server then it will never work, I don’t know why, but if you know do tell me.

The workers.properties file

The workers.properties file contains information so mod_jk can connect to Tomcat worker processes. I have set up Apache and Tomcat on the same box, but they can be on different boxes as well. You just need to change localhost in the workers.properties file to appropriate host name or IP address. Ofcourse our Tomcat has been restricted to listen only on localhost, which ofcourse needs to be changed if we want it to accept mod_jk requests from a different host. Perhaps I will update this document someday with that as well.

# File    - workers.properties
# Purpose - Configures load balanced tomcat worker threads.
# Author  - Ajitabh Pandey <ajitabhpandey@ajitabhpandey.info>
# History -
#       ver 0.1 - Created on 19th Oct 2006 - AP
#
ps=/

#
# List of all workers by name
#
worker.list=loadbalancer

#
# First tomcat instance
#
worker.tomcat1.port=8009
worker.tomcat1.host=localhost
worker.tomcat1.type=ajp13
# lbfactor must be >0. A low lbfactor value for a worker means that worker
# performs less work
worker.tomcat1.lbfactor=100

#
# Second tomcat instance
#
worker.tomcat2.port=8109
worker.tomcat2.host=localhost
worker.tomcat2.type=ajp13
# lbfactor must be >0. A low lbfactor value for a worker means that worker
# performs less work
worker.tomcat2.lbfactor=100

#
# Load Balancer worker instance
# The loadbalancer  (type lb) worker performs weighted round-robin
# load balancing with sticky sessions.
# If a worker dies, the load balancer  will check its  state once in
# a while. Until then all work is redirected to peer worker.
#

worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=tomcat1,tomcat2

Apache virtual host configuration

I prefer to use virtual hosts in Apache even if there is only one host. I have created the following virtual host with the mod_jk mount points defined. So any requests for these mount points will be passed to a Tomcat instance by mod_jk connector as per load balancing algorith defined in workers.properties file.

[root@webhst01 ~]# vi /etc/httpd/conf.d/00_webhst01.unixclinic.net.conf
# File          - 00_webhst01.unixclinic.net
# Purpose       - Virtual Server configuration file for webhst01.unixclinic.net
# Author        - Ajitabh Pandey
# History       -
#       ver 0.1 -  Created the file on 20th Sept 2006 - AP
#
<VirtualHost *:80>
ServerName   webhst01.unixclinic.net
ServerAlias  webhst01
ServerAdmin  webmaster@unixclinic.net
DocumentRoot /var/www/webhst01.unixclinic.net

# Globally deny access to the WEB-INF directory
<LocationMatch '.*WEB-INF.*'>
AllowOverride None
deny from all
</LocationMatch>

# Requests for these URIs go to loadbalancer worker thread
JkMount /servlets-examples/*        loadbalancer
</VirtualHost>
Posted in FLOSS | Tagged , | Leave a comment

Highly Available Apache with mod_jk load balanced Tomcat

This how-to describes the procedure for setting up a highly available setup in which a pair of apache servers are load balancing a pair of tomcat servers. I have tested this configuration with Red Hat Enterprise 4, Fedora Core 5, Debian GNU/Linux 3.1 and CentOS 4. Technically this should work on any Unix capable of running apache+mod_jk, tomcat and heartbeat.

Pre-requisites

A pair of linux machine with Apache web server running with the default configuration.

Assumptions

Hostnames – webhst01, webhst02 Domain – Unixclinic.net IP addresses – 192.168.1.1, 192.168.1.2

This is described in another post – Setting Up Tomcat and Apache

Setting up highly available Apache

We need to install “heartbeat” on both the machines for making apache as highly available. Except for Red Hat Enterprise linux, heartbeat is in the package set of Fedora, Debian and CentOS. CentOS packages work on Red Hat enterprise linux.

On Fedora and CentOS

yum install heartbeat

On Debian

apt-get install heartbeat

Configuring heartbeat

With a high availability set-up, its recommended that the heartbeat travels over a separate link. But in my setup, the servers were geographically separate location (in two different data centres) and hence I had to send the heartbeat over standard ethernet link. But this does not make any difference to the working of the servers.

Heartbeat can be configured for active -standby mode or active-active mode. Active-Standby mode – One host remains active for all the HA services (known as primary host) and the other remains standby. Active-Active mode – Service-1 is primary at one node and service-2 primary at second node, so both nodes are active at the same time but offering different services. In case any one of these nodes fails, heartbeat transfer the services to the other host.

/etc/hosts file

In a highly available environment all nodes should be able to see each other irrespective of whether the DNS server is available or not. The /etc/hosts file is typically used in this case. Add the following two lines in the /etc/hosts file in both the hosts.

192.168.1.1 webhst01.unixclinic.net webhst01
192.168.1.2 webhst02.unixclinic.net webhst02

You should be able to ping both servers i.e. both servers should be able to see each other.

/etc/ha.d/ha.cf file

This is the heartbeat configuration file and has to be configured identically on all the nodes of the set-up. Its quite possible that you do not want to exceed more than two nodes in the highly available set-up. If you are sure about that then there is not need to use multicast for heartbeat and unicast can be used. If unicast is used then the only difference between this file in the two nodes is the IP address of the host to unicast to.

# File          - ha.cf
# Purpose       - Heartbeat configuration file
#       ATTENTION: As the configuration file is read line by line,
#               THE ORDER OF DIRECTIVE MATTERS!
# Author        - Ajitabh Pandey
# History       -
#       ver 0.1 -  Created the file on 31st Oct 2006 - AP
#
debugfile /var/log/ha-debug # Debug messages are logged here
logfile /var/log/ha-log     # all heart-beat log messages are stored here
logfacility     local0      # This is the syslog log facility
keepalive 2                 # no of secs between two heartbeats
deadtime 30                 # no of secs after which a host is considered dead if not responding
warntime 10                 # no of secs after which late heartbeat warning will be issued
initdead 120                # After starting up heartbeat no of secs to wait for other
                            # host to respond to heartbeat before considering it dead
udpport 695                 # This is the UDP port for the bcast/ucast communication
bcast   bond0               # this is the interface to broadcast
auto_failback on            # resources are automatically failback to its primary node
node webhst01               # first node in the setup
node webhst02               # second node in the setup

/etc/ha.d/haresources

This file contains a list of all resources being managed by heartbeat and their primary nodes.

I will discuss Active-standby in this post:

Here webhst01 will host the IP address 192.168.1.5 and the httpd and hence any services under this IP address will also be hosted on this. In case this host fails this IP address will be taken over by webhst02.

webhst01.bds.tv 192.168.1.3 httpd

/etc/ha.d/authkeys

This file must be owned, readable and writeable by root only, otherwise heartbeat will refuse to start. Also this file must be same on all the nodes.

auth 1
1 crc

Configuring Apache

httpd.conf

Depending on distribution being used, this file can be present at different locations. Red Hat, Fedora and CentOS will have this file as /etc/httpd/conf/httpd.conf and Debian and derivatives will have this as /etc/apache2/apache2.conf.

We will make apache listen only on the service IP address.

Listen 192.168.1.3:80

I normally use name based virtual hosts, even if there is a single website to be hosted. So I will create a virtual host

<VirtualHost NameVirtualHost *:80>
    ServerName   webhst.unixclinic.net
    ServerAlias  webhst
    ServerAdmin  webmaster@unixclinic.net
    DocumentRoot /var/www/webhst.unixclinic.net
</VirtualHost>

Now since this IP address can be taken over by any machine in the cluster, we have to make sure that apache webserver does not start up automatically on this system.

On Red Hat and derivatives its easy:
chkconfig httpd remove

On Debian and derivatives:

update-rc.d -f apache2 remove && update-rc.d apache2 stop 45 S .

Start heartbeat and do fail-over testing

On Red Hat and derivatives

service heartbeat start

On Debian and derivatives

invoke-rc.d heartbeat start

The activities can be seen in /var/log/ha-log file on both the nodes. Fail-over testing can be done as below:

  1. Shutdown primary node, while keeping the secondary running. Secondary should take over the services when primary goes down.
  2. Bring primary node up while the secondary is running the services, the services should automatically be fallback to primary.
Posted in FLOSS | Tagged , , , | Leave a comment