RaspberryPi: Tweeting in Morse Code

It has been months without any idea. With RaspberryPi and my recent interest in Node.js and no interesting ideas around. I decided do a simple project just for fun. Here was the plan:

• Listen to the tweets on particular topic, keywords, and from specific users
• Convert it to Morse code
• Emit the code from sound (beeper) and light (LED) source.
• Make it testable without RaspberryPi and offline (using Telnet)

So, I wrote a Node.js based code which can be downloaded from my Github repository naishe/tweemorse the code basically does the following stuffs:

1. Based on what parameter you passed it either starts to listen to Twitter for the keywords and users that you have configured; or it launches a Telnet server on port 23 where you can sent it a message, and it will translate it.
2. Once the message arrives it is "queued" in a message queue for processing.
3. There is a queue consumer that takes the messages one by one and converts them into Morse code.
4. This Morse code gets read character by character "dit" or "dah" or "white space". (You may know more about Morse code from this Wikipedia article.) Based on the character, the output pin is sent either a HIGH or a LOW signal. Here is a rough idea:
1. dit: short HIGH
2. dah: long HIGH
3. transition between two characters: short LOW
4. white space: long LOW
5. HIGH means LED and and beeper on, LOW means they are off.

For more details and instructions look the Github repo. And, finally, here is how it looks when I tweeted a SOS:

That's all folks!

Raspberry Pi: Setting up Your Pi without External Keyboard and Monitor

This article shows how to do it on an Ubuntu machine. But the procedure will be the same on all the Unix and Linux machine. You will need to look for equivalent command for Windows platform. Essentially, this is what I am doing: 

•  Formatting and copying Raspbian OS to the SD card 
•  Editing /etc/network/interfaces file 
•  Putting the SD card in Pi and plugging it to router. 
•  SSHing to Pi and running a couple of commands

This post is geared towards getting Raspberry Pi set up to work from network.

• You will not need a separate keyboard or monitor for installation and setup.
• You will need a router to access your Pi via VNC or SSH.
• Keep handy: an 8GB SD card, Raspberry Pi, network/LAN cable to connect your Pi to the router, access to the Internet.

Lets get started:

1. Insert the SD card, run df -h to see where it is mounted:
   
   

   $ df -h
     Filesystem      Size  Used Avail Use% Mounted on
     /dev/sda8        35G   28G  5.1G  85% /
     none            4.0K     0  4.0K   0% /sys/fs/cgroup
     udev            2.0G  4.0K  2.0G   1% /dev
     tmpfs           392M  928K  391M   1% /run
     none            5.0M     0  5.0M   0% /run/lock
     none            2.0G   17M  1.9G   1% /run/shm
     none            100M   44K  100M   1% /run/user
     /dev/mmcblk0    7.4G  4.0K  7.4G   1% /media/nishant/naishePi
   

2.  Format the SD card
   
   

   $ sudo mkdosfs -F 32 -v /dev/mmcblk0

   or you can use disk utility GUI tool by typing "Disks" in Ubuntu HUD
   
   
3. Get a copy of Raspian from http://www.raspberrypi.org/download 
4. Unzip it:
   

   $ unzip 2014-01-07-wheezy-raspbian.zip 
     Archive:  2014-01-07-wheezy-raspbian.zip
     inflating: 2014-01-07-wheezy-raspbian.img    
   $ ls
     2014-01-07-wheezy-raspbian.img  2014-01-07-wheezy-raspbian.zip
   

5. Copy the image file to the SD card using dd
   

   $ sudo dd if=2014-01-07-wheezy-raspbian.img of=/dev/mmcblk0 bs=1M
     2825+0 records in
     2825+0 records out
     2962227200 bytes (3.0 GB) copied, 588.065 s, 5.0 MB/s
   

6.  Execute sync to ensure nothing it left to write:
   

   $ sync
   

7.  Unmount the SD card:
   

   $ sudo umount /dev/mmcblk0

8. Remove the SD card from the slot and reinsert. It is required because the file system table has changed.
9.  Now if you browse the SD card it will look like you are browsing a Linux distro. Also, you will see two partitions:
   

   $ df -h
     Filesystem      Size  Used Avail Use% Mounted on
     /dev/sda8        35G   28G  5.1G  85% / 
     none            4.0K     0  4.0K   0% /sys/fs/cgroup
     udev            2.0G  4.0K  2.0G   1% /dev
     tmpfs           392M  932K  391M   1% /run
     none            5.0M     0  5.0M   0% /run/lock
     none            2.0G   17M  1.9G   1% /run/shm
     none            100M   52K  100M   1% /run/user
     /dev/mmcblk0p2  2.6G  1.9G  586M  77% /media/nishant/fc254b57-8fff-4f96-9609-ea202d871acf
     /dev/mmcblk0p1   56M   19M   38M  34% /media/nishant/boot
   

Here you are 80% done. We now need to setup the network configuration so that we can SSH to our RasPi.

This is my plan. I should be able to place this SD Card in my Raspi and I shall be able to access it via SSH when I power it and connect it to the router that my laptop is connected to.

1. Lookup your configuration using route command
   

   $ route -n
     Kernel IP routing table
     Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
     0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 eth1
     169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth1
     192.168.2.0     0.0.0.0         255.255.255.0   U     9      0        0 eth1
   

2. We have mask, and gateway from last command. We know that the IP is going to be in 192.168.2.X series. So, lets assign 192.168.2.42 to RasPi. To do this, we need to edit /etc/network/interfaces on the Raspbian OS ***in the SD CARD** which is located at /media/nishant/fc254b57-8fff-4f96-9609-ea202d871acf/etc/network/interfaces. MAKE SURE YOU DO NOT END UP EDITING YOUR UBUNTU'S CONFIG.
   
   Replace the iface eth0 inet dhcp line with this:
   

   iface eth0 inet static
   address 192.168.2.42
   netmask 255.255.255.0
   gateway 192.168.2.1
   

DONE! Now place this SD card in your RaspberryPi, power it up, connect it to your router. Wait for 5 minutes. Now, try SSH from your laptop:

$ ssh pi@192.168.2.42

The password is "raspberry" by default. Now you are in Raspberry shell. You need to configure it.

Configuring the system: Execute the following, one by one:

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo raspi-config

Use up, down, tab, shift-tab to navigate through the wizard. Enter/space for selecting an option, and esc to going back to previous option.

Remember, unless you Finish this wizard, Raspbian will keep complaining that the config is not yet complete. So, make sure you finally select the "finish" button.

With basic configuration done, I wanted to use the hostname to SSH to the machine. If you wanted to do that, install Avahi.

$ sudo apt-get install avahi-daemon

Now, reboot.

sudo reboot -n

Wait a couple of minutes. Now, ssh pi@raspberry.local (e.g. ssh pi@.local)

Setting up VNC: If you wanted to work on Raspberry GUI. You will have to run VNC server on that so that you can access GUI through network. Here are the steps

1. SSH to your Raspberry Pi.
2. Install and run Tight VNC Server
   
   

   $ sudo apt-get install tightvncserver
   $ tightvncserver
   $ vncserver :1 -geometry 1024x728 -depth 24
   

3. Access the GUI by using your favorite VNC client I use Remmina Remote Desktop Client on Ubuntu.
   
   
4. If everything goes fine, you will see your RasPi Screen on your computer. And you could play with it as if you are directly connected to it.
   
   

Fun with Ultrasonic Ranging Device and Buzzer

This is my first Arduino project. It is a subset of the object avoidance robot project that I am planning to work over the weekends. In this project, I will make Arduino scream louder as soon as anything comes closer to the range sensor (from front, obviously).

The circuit diagram is as below:

This image is created using Fritzing

Here are the components:

1. Ultrasonic Ranging Module HC-SR04
2. Buzzer 2 KHz
3. 100Ω Resistor
4. Arduino Uno

I have connected ranging modules ground to Arduino ground pin, Vcc to 5V pin, echo to pin 7, and trigger to pin 8. Buzzer's negative (black) terminal is connected to another Arduino ground pin and positive terminal is connected to a 100Ω resistor. Which, in turn, is connected to pin 5 which is a PWM pin.

Here is the Arduino sketch that I used:

const int TRIG = 8;
const int ECHO = 7;
const int BUZZ = 5;

void setup(){
  pinMode(TRIG, OUTPUT);
  pinMode(ECHO, INPUT);
  pinMode(BUZZ, OUTPUT);
  Serial.begin(9600);
}

void loop(){
  long duration, inches, cm;
  
  digitalWrite(TRIG, LOW);
  delayMicroseconds(2);  
  digitalWrite(TRIG, HIGH);
  delayMicroseconds(10);
  digitalWrite(TRIG, LOW);
  
  duration = pulseIn(ECHO, HIGH);
  inches = duration / 74 / 2 ;
  cm = duration / 29 / 2 ;
  
  Serial.print(inches);
  Serial.print("in, ");
  Serial.print(cm);
  Serial.print("cm");
  Serial.println();
  if(cm < 20){
    analogWrite(BUZZ, (20 - cm) * 10);
  }else{
    digitalWrite(BUZZ, LOW);
  }
  
  delay(100);
}

You can see that I setup the pins in startup() and in loop I do the distance checks. I send a LOW signal for 2 microsecs, then HIGH for next 10, then turn off. I then read from ECHO input. It tells me the time in microsec that it took to get the echo of the signal that was sent. We use speed-time-distance formula to get the distance in inches and centimeters. We print it to Serial to observe this value in Serial console of Arduino IDE.

Now that we know the distance. Here comes the logic to make sound. If the object is closer than 20 cms, I write (20 - distance) * 10. This means the sound gets louder as the object comes closer to the sensor. If the object is more than 20 cms away, the buzzer will stay mum.

Here is the video. Sorry for the bad English.


Here is the final product:

PPTP VPN Fails Frequently?

I have upped my Ubuntu to Raring Ringtail 13.04. Everything was just awesome. I set up my workspace. Now, it was the time to code. Woohoo! Connected to PPTP VPN to checkout code.  While I was checking out the code, VPN disconnected. Then on, each time I connect to VPN, it gets disconnected in a minute or so. Never stayed long enough to do something useful. When I switched from ethernet to another broadbad wi-fi, PPTP was stable. So, there was something wrong with my ethernet setting.

After a lot of head banging and, hit and trial, I landed on this post on a forum. It was not very encouraging, plus it was really old. I gave it a try anyway and voilà! it worked! The trick is to lower MTU value. MTU is maximum transmission unit, to quote Wikipedia:

In computer networking, the maximum transmission unit (MTU) of a communications protocol of a layer is the size (in bytes) of the largest protocol data unit that the layer can pass onwards. MTU parameters usually appear in association with a communications interface (NIC, serial port, etc.). Standards (Ethernet, for example) can fix the size of an MTU; or systems (such as point-to-point serial links) may decide MTU at connect time.

 I have set MTU to 1200 down from 1500. Using sudo ifconfig eth0 mtu 1200 command in Ubuntu.

#Before
$ sudo ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:24:d8:d8:32:09
          inet addr:192.168.1.33  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: feff::224:e8ff:fe88:3209/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:142813 errors:0 dropped:0 overruns:0 frame:0
          TX packets:97325 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:174397037 (174.3 MB)  TX bytes:8177616 (8.1 MB)

#Execute command
$ sudo ifconfig eth0 mtu 1200

#After (successfully connected to VPN and stable)
$ sudo ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:24:d8:d8:32:09
          inet addr:192.168.1.33  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1200  Metric:1
          RX packets:142851 errors:0 dropped:0 overruns:0 frame:0
          TX packets:97372 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:174401881 (174.4 MB)  TX bytes:8184649 (8.1 MB)

High-Availability Ngnix using Heartbeat on Amazon EC2

Background: I have mentioned earlier that we were baffled by Amazon's Elastic Load Balancer(ELB). We tested with Nginx as reverse proxy, it seems to be hands down better than ELB. (I will have Nginx performance in another post.) To scale this setup horizontally, we configured multiple Nginx with Weighted Round Robin (WRR) DNS configuration; to alleviate some load off Nginx server.

We later decided to have redundant Nginx server in N+1 setup, so that if one server goes down the redundant takes over. I stumbled on Heartbeat. Unfortunately there is no good tutorial on how this can be done on Amazon EC2.

Warning: I will keep this tutorial brief. Limited to Heartbeat configuration, as the Wiki mentioned:

In order to be useful to users, the Heartbeat daemon needs to be combined with a cluster resource manager (CRM) which has the task of starting and stopping the services (IP addresses, web servers, etc.) that cluster will make highly available. Pacemaker is the preferred cluster resource manager for clusters based on Heartbeat.

Goal: We need to make sure auxiliary node takes over, as soon as a main node dies. This is what should happen:

1. We assign Elastic IP(EIP) to main node that runs Nginx, initially.
2. When main node goes down, we want
1. the aux node gets assingned the EIP. (refer /etc/init.d/updateEIP script below)
2. the aux node's nginx starts up. (refer /etc/init.d/nginx script below)
3. When main node comes back up,
1. aux node relinquishes the EIP
2. aux node shuts down Nginx
3. main node acquires EIP.
4. main node starts Nginx. 

Preparation: Assuming you have launched two instances of your favorite Unix flavor.

1. Get elastic IP. We will use this to switch over.

   ec2-allocate-address
   ADDRESS 50.17.213.152 

2. Install Nginx on both machines. I will install from source from here http://nginx.org/en/download.html

   wget http://nginx.org/download/nginx-1.2.5.tar.gz
   tar xvzf nginx-1.2.5.tar.gz 
   cd nginx-1.2.5
   ./configure 
   make
   make install

3. Configure Nginx

   cd /usr/local/nginx/conf
   mv nginx.conf nginx.conf.orig
   vi nginx.conf

   
   My nginx.conf looks like this.

   worker_processes  2;
   worker_rlimit_nofile 100000;
   
   events {
       worker_connections  1024;
   }
   
   http {
   
     access_log off;
   
     upstream myapp {
       server ip-10-10-225-146.ec2.internal weight=10 max_fails=3 fail_timeout=10s;  # Reverse proxy to app01
       server ip-10-226-95-45.ec2.internal weight=10 max_fails=3 fail_timeout=10s;   # Reverse proxy to app02
       server ip-10-244-145-130.ec2.internal weight=10 max_fails=3 fail_timeout=10s; # Reverse proxy to app03
     }
   
     server {
       listen 80;
       add_header X-Whom node_1;
       location / {
         proxy_pass http://myapp;
       }
     }
   }

   This configuration is same on both Nginx server except one thing, the add_header X-Whom node_1; part. This is to identify which Nginx loadbalancer is serving. This will help to debug the situation later. On the second Nginx, we have add_header X-Whom node_2;. This line says Nginx to inject a header X-Whom to each response.
   
4. Install Heartbeat:
   

   #RHEL, CentOS
   yum install heartbeat
   
   #Debian, Ubuntu
   sudo apt-get install heartbeat-2

Configure Heartbeat: There are three things you need to configure to get stuffs working with Heartbeat.

1. ha.cf: /etc/ha.d/ha.cf is main configuration file. It has list of nodes, features to be enabled. And the stuffs in it is order sensitive. 
2. authkeys: It is basically to maintain security of cluster. It provide a mean to authenticate nodes in a cluster. 
3. haresources: List of resources to be managed by heartbeat. It looks like this preferredHost service1 service2. where preferredHost is the hostname where you prefer the subsequent services to be executed. service1 service2 are the service that stay inside /etc/init.d/ and stops and starts the service when called in /etc/init.d/service1 stop|start.
   
   When a node is woken up, the service is called from left to right. Means service1 first; and then service2. And when a node is brought down service2 is terminated first, and then service1.

---------
 For sake of simplicity lets call one node main node and the other aux node.

On main node,

uname -n
ip-10-144-75-85

On aux node,

uname -n
ip-10-36-5-11

----
/etc/ha.d/ha.cf
On main node,

logfile /tmp/ha-log
debugfile /tmp/ha-debug
logfacility local0
keepalive 2
deadtime 30
initdead 120
udpport 694
ucast eth0 10.36.5.11
ucast eth0 10.144.75.85
auto_failback on
node ip-10-36-5-11
node ip-10-144-75-85

On aux node, exact as on main node

logfile /tmp/ha-log
debugfile /tmp/ha-debug
logfacility local0
keepalive 2
deadtime 30
initdead 120
udpport 694
ucast eth0 10.36.5.11
ucast eth0 10.144.75.85
auto_failback on
node ip-10-36-5-11
node ip-10-144-75-85

where,
  deadtime: seconds after which a host is considered dead if not responding.
  warntime: seconds after which the late Heartbeat warning will be issued.
  initdead: seconds to wait for the other host after starting Heartbeat, before it is considered dead.
  udpport: port number used for bcast/ucast communication. The default value for this is 694.
  bcast/ucast: interface on which to broadcast/unicast.
  auto_failback: if ‘on’, resources are automatically failed back to its primary node.
  node: nodes in the HA set-up, dentified by uname -n.
----

/etc/ha.d/authkeys must be the same on both the machines. You may generate a random auth-secretkey using, date|md5sum

authkeys on both the machines:

auth 1
1 sha1 1e8d28a4627ed7f83faf1d57f5b11645

----

/etc/ha.d/haresources

haresources on both the machines:

ip-10-144-75-85 updateEIP nginx

updateEIP and nginx are shell script that I wrote and stored under /etc/init.d/.

updateEIP

#!/bin/bash

# description: this script associates $eip to this instance.
# it assumes you have JDK and AWS API-tools installed.
# location of these are given as $JAVA_HOME and $EC2_HOME
# author: Nishant Neeraj

export EC2_HOME=/home/ec2
export JAVA_HOME=/usr/java/default

eip="50.17.213.152"
pk="/mnt/pk-2ITPGLG6XXXXXXXXXXXXQUEK2PUOVFJB.pem"
cert="/mnt/cert-2ITPGLG6XXXXXXXXXXXXQUEK2PUOVFJB.pem"

function updateEIP(){
        instance="$(curl -s http://169.254.169.254/latest/meta-data/instance-id)"
        echo "Instace ID is: ${instance}"

        echo "Assingning $eip to ${instance}..."
        /home/ec2/bin/ec2-associate-address -K ${pk} -C ${cert} -i ${instance} ${eip}

        echo "done!"
}

param=$1

if [ "start" == "$param" ] ; then
  echo "Starting..."
  updateEIP
  exit 0
elif [ "stop" == "$param" ] ; then
  echo "stopping..."
  exit 0;
else
  echo "no such command $param"
  exit 1
fi

nginx

#/bin/bash

function start(){
  echo "starting nginx..."
  /usr/local/nginx/sbin/nginx 
}

function stop(){
  echo "stoping nginx..."
  /usr/local/nginx/sbin/nginx -s stop
}

param=$1

if [ "start" == "$param" ] ; then
  start
  exit 0
elif [ "stop" == "$param" ] ; then
  stop
  exit 0
else
  echo "no such command: $param"
  exit 1

----

Start services:
on main,

service heartbeat start
/etc/init.d/nginx start

on aux,

service heartbeat start

You can tail -f /tmp/ha-debug on these nodes to watch things rolling.

Test: Time to test. Note that we are just watching nodes, not Nginx service. So, we need to make heartbeat service on 'aux' look like as if 'main' server is down.

Keep tailing the debug file in 'aux' machine. This will show you the transition. Now, it's time to kill 'main' node. On main, so this:

service heartbeat stop
/etc/init.d/nginx stop

You can see the debug file on 'aux' shows that 'aux' is taking over 'main'. Now, to see how service switches back to main node when it comes up. Start just the heartbeat service, you will see: a. aux: EIP gets detached. (not really, but you can), b. aux: nginx stops, c. main: EIP is assigned, d. main: Nginx is started.

Note: While we flip EIPs, you may get disconnected from SSH connection. So, keep looking into AWS web console to get new assigned public DNS for node which we revoked the EIP from. And use EIP to connect to the node which assigned it.

Debug Logs: Here is how log on auxiliary machine look like

heartbeat[9133]: 2012/11/21_15:12:44 info: Received shutdown notice from 'ip-10-144-75-85'.
heartbeat[9133]: 2012/11/21_15:12:44 info: Resources being acquired from ip-10-144-75-85.
heartbeat[9133]: 2012/11/21_15:12:44 debug: StartNextRemoteRscReq(): child count 1
heartbeat[10055]: 2012/11/21_15:12:44 info: acquire local HA resources (standby).
heartbeat[10055]: 2012/11/21_15:12:44 info: local HA resource acquisition completed (standby).
heartbeat[9133]: 2012/11/21_15:12:44 info: Standby resource acquisition done [foreign].
heartbeat[9133]: 2012/11/21_15:12:44 debug: StartNextRemoteRscReq(): child count 1
heartbeat[10056]: 2012/11/21_15:12:44 info: No local resources [/usr/share/heartbeat/ResourceManager listkeys ip-10-36-5-11] to acquire.
heartbeat[10081]: 2012/11/21_15:12:44 debug: notify_world: setting SIGCHLD Handler to SIG_DFL
harc[10081]:    2012/11/21_15:12:44 info: Running /etc/ha.d/rc.d/status status
mach_down[10097]:    2012/11/21_15:12:44 info: Taking over resource group updateEIP
ResourceManager[10123]:    2012/11/21_15:12:45 info: Acquiring resource group: ip-10-144-75-85 updateEIP nginx
ResourceManager[10123]:    2012/11/21_15:12:45 info: Running /etc/init.d/updateEIP  start
ResourceManager[10123]:    2012/11/21_15:12:45 debug: Starting /etc/init.d/updateEIP  start
Starting...
Instace ID is: i-6ff07d10
Assingning 50.17.213.152 to i-6ff07d10...
ADDRESS    50.17.213.152    i-6ff07d10
done!
ResourceManager[10123]:    2012/11/21_15:12:58 debug: /etc/init.d/updateEIP  start done. RC=0
ResourceManager[10123]:    2012/11/21_15:12:58 info: Running /etc/init.d/nginx  start
ResourceManager[10123]:    2012/11/21_15:12:58 debug: Starting /etc/init.d/nginx  start
starting nginx...
ResourceManager[10123]:    2012/11/21_15:12:58 debug: /etc/init.d/nginx  start done. RC=0
mach_down[10097]:    2012/11/21_15:12:58 info: /usr/share/heartbeat/mach_down: nice_failback: foreign resources acquired
mach_down[10097]:    2012/11/21_15:12:58 info: mach_down takeover complete for node ip-10-144-75-85.
heartbeat[9133]: 2012/11/21_15:12:58 info: mach_down takeover complete.
heartbeat[9133]: 2012/11/21_15:13:16 WARN: node ip-10-144-75-85: is dead
heartbeat[9133]: 2012/11/21_15:13:16 info: Dead node ip-10-144-75-85 gave up resources.
heartbeat[9133]: 2012/11/21_15:13:16 info: Link ip-10-144-75-85:eth0 dead.
...
heartbeat[9133]: 2012/11/21_15:19:59 info: Heartbeat restart on node ip-10-144-75-85
heartbeat[9133]: 2012/11/21_15:19:59 info: Link ip-10-144-75-85:eth0 up.
heartbeat[9133]: 2012/11/21_15:19:59 info: Status update for node ip-10-144-75-85: status init
heartbeat[9133]: 2012/11/21_15:19:59 info: Status update for node ip-10-144-75-85: status up
heartbeat[9133]: 2012/11/21_15:19:59 debug: StartNextRemoteRscReq(): child count 1
heartbeat[9133]: 2012/11/21_15:19:59 debug: get_delnodelist: delnodelist=
heartbeat[10262]: 2012/11/21_15:19:59 debug: notify_world: setting SIGCHLD Handler to SIG_DFL
harc[10262]:    2012/11/21_15:19:59 info: Running /etc/ha.d/rc.d/status status
heartbeat[10278]: 2012/11/21_15:19:59 debug: notify_world: setting SIGCHLD Handler to SIG_DFL
harc[10278]:    2012/11/21_15:19:59 info: Running /etc/ha.d/rc.d/status status
heartbeat[9133]: 2012/11/21_15:20:00 info: Status update for node ip-10-144-75-85: status active
heartbeat[10294]: 2012/11/21_15:20:00 debug: notify_world: setting SIGCHLD Handler to SIG_DFL
harc[10294]:    2012/11/21_15:20:00 info: Running /etc/ha.d/rc.d/status status
heartbeat[9133]: 2012/11/21_15:20:00 info: remote resource transition completed.
heartbeat[9133]: 2012/11/21_15:20:00 info: ip-10-36-5-11 wants to go standby [foreign]
heartbeat[9133]: 2012/11/21_15:20:01 info: standby: ip-10-144-75-85 can take our foreign resources
heartbeat[10310]: 2012/11/21_15:20:01 info: give up foreign HA resources (standby).
ResourceManager[10323]:    2012/11/21_15:20:01 info: Releasing resource group: ip-10-144-75-85 updateEIP nginx
ResourceManager[10323]:    2012/11/21_15:20:01 info: Running /etc/init.d/nginx  stop
ResourceManager[10323]:    2012/11/21_15:20:01 debug: Starting /etc/init.d/nginx  stop
stoping nginx...
ResourceManager[10323]:    2012/11/21_15:20:01 debug: /etc/init.d/nginx  stop done. RC=0
ResourceManager[10323]:    2012/11/21_15:20:01 info: Running /etc/init.d/updateEIP  stop
ResourceManager[10323]:    2012/11/21_15:20:01 debug: Starting /etc/init.d/updateEIP  stop
stopping...
ResourceManager[10323]:    2012/11/21_15:20:01 debug: /etc/init.d/updateEIP  stop done. RC=0
heartbeat[10310]: 2012/11/21_15:20:01 info: foreign HA resource release completed (standby).
heartbeat[9133]: 2012/11/21_15:20:01 info: Local standby process completed [foreign].
heartbeat[9133]: 2012/11/21_15:20:18 WARN: 4 lost packet(s) for [ip-10-144-75-85] [17:22]
heartbeat[9133]: 2012/11/21_15:20:18 info: Other node completed standby takeover of foreign resources.
heartbeat[9133]: 2012/11/21_15:20:18 info: remote resource transition completed.
heartbeat[9133]: 2012/11/21_15:20:18 info: No pkts missing from ip-10-144-75-85!
heartbeat[9133]: 2012/11/21_15:20:20 WARN: 1 lost packet(s) for [ip-10-144-75-85] [22:24]
heartbeat[9133]: 2012/11/21_15:20:20 info: No pkts missing from ip-10-144-75-85!
heartbeat[9133]: 2012/11/21_15:20:28 WARN: 3 lost packet(s) for [ip-10-144-75-85] [24:28]
heartbeat[9133]: 2012/11/21_15:20:28 info: No pkts missing from ip-10-144-75-85! 
watch debug logs, watch header

You may want to use curl -I to ensure if switching occures. Here is what I see when I kill main node, aux node takes overs, and finally main node comes back:

~$ curl -I 50.17.213.152
HTTP/1.1 200 OK
Server: nginx/1.2.5
Date: Wed, 21 Nov 2012 15:10:39 GMT
Content-Type: text/html
Content-Length: 0
Connection: keep-alive
Set-Cookie: JSESSIONID=j1qov13qkfca1pxm6usm3ulyi;Path=/
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-Whom: node_1

~$ curl -I 50.17.213.152
HTTP/1.1 200 OK
Server: nginx/1.2.5
Date: Wed, 21 Nov 2012 15:13:38 GMT
Content-Type: text/html
Content-Length: 0
Connection: keep-alive
Set-Cookie: JSESSIONID=1ujszsyow5rc0ws4v2rir06sk;Path=/
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-Whom: node_2

~$ curl -I 50.17.213.152
HTTP/1.1 200 OK
Server: nginx/1.2.5
Date: Wed, 21 Nov 2012 15:22:09 GMT
Content-Type: text/html
Content-Length: 0
Connection: keep-alive
Set-Cookie: JSESSIONID=khbf8ovc6nr1rwr4o3hzmflt;Path=/
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-Whom: node_1

Conclusion: So we have basic HA configuration ready, we need to add toppings to this setup to be able to monitor services and respond them. You need to add a Cluster Resource Management (CRM) layer over it to be useful.