If your new to or just need to learn more about AWS.. this is a great slide presentation I stumbled across

Situation

An ITM6 Unix (UX) or Linux (LZ) agent detects that its remote filesystems are unavailable, a “stale” connection.

Automate an action to remount it if possible

Methodology

Two (2) ITM situations are created where

1. detects the mount point has become stale
   
2. the other is triggered by the “correlated situation” condition of #1 being tr
   

Situation #1 : Detect “Stale” remote FS

Simple enough – if “Space Available” fails collection, there is an issue

Situation #2 : Remount Situation

Formula Conditions

Use the “Situation Comparison” for a condition against the situation above

Take Action

Note: the lines are strung together on one line in the Take Action field, to make it more legible here, newlines are after the semicolons

f=”&{Linux_Disk.Mount_Point}” ;
u=`umount -f $f 2>&1 && echo $f`;
m=`mount $f 2>&1 && echo $f`;
echo -e “umount: $u\nmount:$m” | mail -s “ITM ACTION: Remount $f” junkmail@JdsMedia.net

Reference: http://help.mosso.com/article.php?id=180

Your script is calling for the “REMOTE_ADDR” and receives the IP of a server in front of one of our back-end servers. The web facing server is then passing the scripts output without giving the expected REMOTE_ADDR of the visitor. In order for your scripts to recognize that they are on a cluster and log the correct IP of your visitors, you will need to replace and add the code below.

For PHP:
Locate any lines of code that are similar to this snippet of code,
$_SERVER['REMOTE_ADDR'];
And replace it with this snippet of code,
$_SERVER['HTTP_X_CLUSTER_CLIENT_IP'];

For ASP:
Locate any lines of code that are similar to this snipper of code,
Request.ServerVariables(“REMOTE_ADDR”)
And replace it with this snipper of code,
Request.ServerVariables(“HTTP_X_CLUSTER_CLIENT_IP”)

My fix for this required a unix shell (if you’re on a Windows look at installing cygwin on your system.

# Ftp your web content down to your local system

$ for file in `find <path_to_files> -exec grep -l REMOTE_ADDR {} \;`; do base=`basename $file`; sed ‘s/REMOTE_ADDR/HTTP_X_CLUSTER_CLIENT_IP/g’ $file > /tmp/$base; grep HTTP_X_CLUSTER_CLIENT_IP /tmp/$base >/dev/null 2>&1 && grep REMOTE_ADDR $file && echo “Updated $base” && mv
/tmp/$base $file; done

# Then simply upload the changed files to your system.

Instead of copying a large tar file over ssh then extracting, take care of the whole process with one command:

PUSH METHOD:

cat  tarfile | ssh –C user@remotehost “(cd targetdirectory && tar –xf -)”

This will stream the tarfile over a compressed ssl tunnel and the other side will only extract if the target directory exists. The “cd targetdirectory” piece I used as a good prevention to blowing files all over an undesired/unexpected location.

PULL METHOD:

ssh -C user@remotehost”cd sourcedirectory; tar -cvf – dir_or_file” > outputfile

This is the opposite method, obviously.  Please note, the output of the SSH needs to be redirected to an output file.