Macbook Pro using Nexus One + Android 2.2 (Froyo) + T-mobile 3G:

Macbook Pro using ATT DSL:

[ author makes no claim on scientific nature of this testing ]

http://thisweekin.com/thisweekin-startups/twist-interview-with-100-things/

As always, great story telling from Calacanis.

[cci lang="bash"]
#! /bin/sh
# Author: Sandeep Ghael
# put these contents at: /etc/init.d/red5
# change red5 directory path below as necessary
RED5_DIR=/usr/share/red5

start()
{
echo “Starting Red5 Service”
sudo su root -c “cd $RED5_DIR; ./red5.sh > /var/log/red5.log &”
return
}

stop()
{
echo “Shutting down red5″
sudo su root -c ‘killall red5 java’
return
}

case “$1″ in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
*)
echo “Usage: {start|stop|restart}”
exit 1
;;
esac
exit $?
[/cci]

disk_usage.rb

This script will email foo@example.com when the disk space left on either sda1 and sda2 falls below 5GB. The threshold is just a variable you can change. You can also add to or remove from the list of sda devices you want to monitor using the disks array.

[cci lang="ruby"]
#!/usr/bin/env ruby

require ‘rubygems’
require ‘send_gmail’

TO_EMAIL = ‘foo@example.com’

filesys = `df -h`

disks = [1,2]

disks.each do |i|
r = filesys[/sda#{i}\s+[\d\.]+[MG]\s+[\d\.]+[MG]\s+([\d\.]+[MG])/,1]
message = “Low disk space on /sda#{i}: only #{r.to_i}GB remaining”
hsh={:to=>TO_EMAIL, :subject=>’Low disk space warning!’, :body=>message}
SendGMail.send_gmail(hsh) if r.to_i < 5 or r[/M$/]
puts message if r.to_i < 5 or r[/M$/]
end
[/cci]

load_check.rb

This script will use the uptime command to get the avarage load. I’m just using the 1min and 5min averages. If the 1min average load is over 9 or the 5min average load is over 4, bar@example.com will get an email.

[cci lang="ruby"]
#!/usr/bin/env ruby

require ‘rubygems’
require ‘send_gmail’

TO_EMAIL = ‘bar@example.com’

uptime = `uptime`

load_1min = uptime.split(” “)[8].chop()
load_5min = uptime.split(” “)[9].chop()

message = “Load on server is 1min/5min avg: #{load_1min} / #{load_5min} ”

hsh={:to=>TO_EMAIL, :subject=>’Load warning!’, :body=>message}
SendGMail.send_gmail(hsh) if (load_1min.to_i > 9) or (load_5min.to_i > 4)
[/cci]

You may have noticed an included module “send_gmail” and a call to “SendGMail” in the previous scripts. Since I use Gmail for all my outbound emails, the underlying alert system needs a way to make calls to the Gmail servers. Problem solved using this nifty little Ruby Gmailer script I found on at http://codingfrenzy.alexpmay.com/2007/12/sending-gmail-from-standalone-ruby.html.  I did make a few modifications to the script, so I’m including it here. You’ll want to set your gmail account/domain info if you do use this mailer.

send_gmail.rb

[cci lang="ruby"]
#!/usr/bin/env ruby

require ‘rubygems’

gem ‘actionmailer’
require ‘action_mailer’
require ‘openssl’
require ‘net/smtp’

module SendGMail

@user_name=’someone@example.com’
@domain=’example.com’
@password=’password’

def SendGMail.send_gmail(hsh)

raw_attachments=hsh.fetch(:raw_attachements, [])
if hsh.has_key?(:raw_attachment)
raw_attachments.push(hsh[:raw_attachment])
end

mail=TMail::Mail.new
mail.to=hsh[:to]
mail.date=Time.now
mail.from=@user_name
mail.subject=hsh[:subject]

main=mail
main=TMail::Mail.new
main.body = hsh[:body]
main.set_content_type(‘text/plain’, nil, ‘charset’=>’utf-8′)
mail.parts.push(main)

for raw_attachment in raw_attachments
part = TMail::Mail.new
transfer_encoding=raw_attachment[:transfer_encoding]
body=raw_attachment[:body]
case (transfer_encoding || “”).downcase
when “base64″ then
part.body = TMail::Base64.folding_encode(body)
when “quoted-printable”
part.body = [body].pack(“M*”)
else
part.body = body
end

part.transfer_encoding = transfer_encoding
part.set_content_type(raw_attachment[:mime_type], nil, ‘name’ => raw_attachment[:filename])
part.set_content_disposition(“attachment”, “filename”=>raw_attachment[:filename])
mail.parts.push(part)
end

mail.set_content_type(‘multipart’, ‘mixed’)
ActionMailer::Base.deliver(mail)

end

ActionMailer::Base.smtp_settings = {
:address => ‘smtp.gmail.com’,
:domain => @domain,
:authentication => :plain,
:port => 587,
:user_name => @user_name,
:password => @password
}

Net::SMTP.class_eval do
private
def do_start(helodomain, user, secret, authtype)
raise IOError, ‘SMTP session already started’ if @started
check_auth_args user, secret if user or secret

sock = timeout(@open_timeout) { TCPSocket.open(@address, @port) }
@socket = Net::InternetMessageIO.new(sock)
@socket.read_timeout = 60 #@read_timeout
@socket.debug_output = STDERR #@debug_output

check_response(critical { recv_response() })
do_helo(helodomain)

raise ‘openssl library not installed’ unless defined?(OpenSSL)
starttls
ssl = OpenSSL::SSL::SSLSocket.new(sock)
ssl.sync_close = true
ssl.connect
@socket = Net::InternetMessageIO.new(ssl)
@socket.read_timeout = 60 #@read_timeout
@socket.debug_output = STDERR #@debug_output
do_helo(helodomain)

authenticate user, secret, authtype if user
@started = true
ensure
unless @started
# authentication failed, cancel connection.
@socket.close if not @started and @socket and not @socket.closed?
@socket = nil
end
end

def do_helo(helodomain)
begin
if @esmtp
ehlo helodomain
else
helo helodomain
end
rescue Net::ProtocolError
if @esmtp
@esmtp = false
@error_occured = false
retry
end
raise
end
end

def starttls
getok(‘STARTTLS’)
end

def quit
begin
getok(‘QUIT’)
rescue EOFError, OpenSSL::SSL::SSLError
end
end
end
end

[/cci]

One pain point I encountered with Snow Leopard is getting everything compiled for true 64bit, and then getting the appropriate bindings for MySQL or Postgres to work with frameworks like Rails (Ruby) or Django (Python). I work with both, so by the end of the post you’ll be prepared to use both DB servers for either framework.

Step 1: Install MySQL from source

We refer here, again to the excellent tutorial from HiveLogic:

http://hivelogic.com/articles/compiling-mysql-on-snow-leopard/

After completing the install, set up your root password:

[cci lang="bash"]

$ mysqladmin -u root password NEWPASSWORD

[/cci]

Step 2: Install PostgreSQL from source

As for Postgres, I found these instructions found on InvisionPower as a good basis to start my install from.

http://community.invisionpower.com/topic/292849-installing-postgresql-server-on-mac-os-x-snow-leopard/

Couple of note regarding Postgres.

1) the instructions in the link above seem to provide a dead link for the Postgres source. You can try this curl command instead of theirs:

[cci lang="bash"]
$ curl http://ftp9.us.postgresql.org/pub/mirrors/postgresql/source/v8.4.1/postgresql-8.4.1.tar.gz -O
[/cci]

2) Make sure to compile as a 64 bit application, using the “ARCH=x86_64″ and other flags specified during your “make” step.

3) when creating and setting user/group info, I found an error in the 8th command line instructions. The original command references a group “_postgres” before it has been created. Do this instead:

Enough changes were required to make things compile and work on my new system, that I’ll simply transcribe my exact steps here:

[cci lang="bash"]
$ sudo mkdir /usr/local/src
$ cd /usr/local/src

$ sudo su

$ curl http://ftp9.us.postgresql.org/pub/mirrors/postgresql/source/v8.4.1/postgresql-8.4.1.tar.gz -O
$ tar -zvxf postgresql-8.4.1.tar.gz
$ rm postgresql-8.4.1.tar.gz
$ cd postgresql-8.4.1

$ ./configure –prefix=/usr/local/postgresql-8.4.1

$ ARCH=x86_64 CFLAGS=”-arch x86_64″ LDFLAGS=”-arch x86_64″ make
$ make install

$ ln -s /usr/local/postgresql-8.4.1 /usr/local/pgsql
$ echo “PATH=/usr/local/pgsql/bin:$PATH” >> ~/.profile
$ source ~/.profile
$ mkdir /usr/local/pgsql/data/

$ dscl . list /Users UniqueID
[/cci]

I use ” dscl . list /Users UniqueID | grep <##>” to find the first available number past 75. For me it was 80.

[cci lang="bash"]
$ dscl localhost create /Local/Default/Users/_postgres
$ dscl localhost create /Local/Default/Users/_postgres PrimaryGroupID 0
$ dscl localhost create /Local/Default/Users/_postgres UniqueID 80
$ dscl localhost create /Local/Default/Users/_postgres UserShell /bin/bash
$ dscl localhost passwd /Local/Default/Users/_postgres
$ dscl localhost create /Local/Default/Users/_postgres NFSHomeDirectory /var/home/_postgres
$ mkdir -p /var/home/_postgres
$ chown -Rf _postgres /var/home/_postgres
$ dscl localhost create /Local/Default/Groups/_postgres
$ dscl localhost create /Local/Default/Groups/_postgres UniqueID 80
$ dscl localhost append /Local/Default/Groups/_postgres GroupMembership _postgres
$ chown -Rf _postgres:_postgres /var/home/_postgres

$ defaults write /Library/Preferences/com.apple.loginwindow.plist Hide500Users -bool TRUE
$ chown -R _postgres /usr/local/postgresql-8.4.1/
[/cci]

I did not exit su at this point, as suggested in the original InvisionPower article. I needed to be su to change to user “_postgres”.

[cci lang="bash"]
$ su – _postgres
$ /usr/local/pgsql/bin/initdb -E UTF8 -D /usr/local/pgsql/data/
$ /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data/ -l /usr/local/pgsql/data/postgresql.log start
[/cci]

Now test creating a new DB:

[cci lang="bash"]
$ /usr/local/pgsql/bin/createdb test
$ /usr/local/pgsql/bin/psql test
[/cci]

Type \q to quit.

[cci lang="bash"]
$ exit
$ sudo su
$ rm -rf /var/home
$ dscl localhost delete /Local/Default/Users/_postgres NFSHomeDirectory
$ dscl localhost passwd /Local/Default/Users/_postgres
$ exit
[/cci]

At this point your server is installed and tested. The InvisionPower post provides a great script that you can use to start/stop/restart the server from the command line. See the bottom of their article.

Tweak the CLI

If you have any hair on your chest (apologies to my female readers), you’re going to be using the command line a lot.  Let’s make the CLI more friendly for daily use.  I used this excellent thread from StackOverflow to compose my .profile file:  http://stackoverflow.com/questions/3746/whats-in-your-bashrc.

Things are a bit confusing in MacOS X world, since there is a .profile file in your home directory, but there is also a bashrc file in /private/etc.  As far as I can tell, best practice is to put user specific stuff in .profile, and put global stuff in /private/etc/bashrc.

To edit bashrc, use the sudo command and enter your password.

[cci lang="bash"]

$ sudo nano /private/etc/bashrc

[/cci]

Since I want colorized prompt for all users, my /private/etc/bashrc file looks like

[cci lang="bash"]
# System-wide .bashrc file for interactive bash(1) shells.
if [ -z "$PS1" ]; then
return
fi

WHITE=”\[\033[1;37m\]”
GREEN=”\[\033[0;32m\]”
CYAN=”\[\033[0;36m\]”
GRAY=”\[\033[0;37m\]”
BLUE=”\[\033[0;34m\]”
BLACK=”\[\033[0;1m\]”
RESET=’\[\033[00m\]‘

export PS1=”${GREEN}\u${CYAN}@${BLUE}\h:${CYAN}\w${GREEN} >$ ${RESET}”

export CLICOLOR=1
export LSCOLORS=ExFxCxDxBxegedabagacad

# Make bash check its window size after a process completes
shopt -s checkwinsize
[/cci]

The next time you open a command prompt things will be more readable.

Now lets edit your user specific .profile file :

[cci lang="bash"]
$ nano ~/.profile
[/cci]

and make the contents as such:

[cci lang="bash"]
export HISTCONTROL=erasedups
export HISTSIZE=10000

bind ‘set match-hidden-files off’

alias cds=”cd;clear”
alias cd..=”cd ..”
alias ..=”cd ..”
alias …=”cd ../..”
alias ….=”cd ../../..”
alias ll=”ls -al”

export PATH=”/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:$PATH”
[/cci]

This sets some bash history parameters, and my personal aliases for commonly used commands. YMMV. We’ll continue to tweak the .profile file as we continue, but for now let’s proceed to installing databases (Next Post)

In the next few post, I’ll be documenting the steps I took on my box.  FYI, my box is an Intel based (Core 2 Duo) White MacBook 13″, 2Ghz with 4GB of Ram.  The screen shots are from the same steps done on an iMac with similar specs.

Step 1:  Backup all data

Any upgrade process is fraught with catastrophic risk, so please back up all your data.  You should already be using something like Time Machine, so make sure its has done a recent backup of your critical data directories.  For something like an upgrade, I prefer to also use  a tool like “SuperDuper!” which makes a clone (entire disk snapshot) to another drive.  This assumes you have an extra drive laying around, but drives are cheap and your work is not.  So take the extra precaution and feel safe knowing you can always just pop in your cloned disk and it’s as if nothing happened.

Step 2:  Install Snow Leopard

Well, duh!  But one key thing to note when doing either a clean, or non-clean install of Snow Leopard is to make sure you are installing all the necessary SDK packages that will allow you to compile other packages like Python or MySQL successfully for 64bit.  We’ll get to that in a bit.

First the routine stuff: Pop in the Snow Leopard disk.  Hold down the “option” key during the boot to have your Mac ask you what disk to install from.  (see image)

Choose the Mac OS X Install disk.  As mentioned, we are doing a clean install, so we’ll first format the drive clean (you did do Step 1, right?).  Choose “Disk Utility” before the install starts.  Choose your drive, and click on the “Erase” tab.  Format the drive “Mac OS Extended (Journaled), and name the drive whatever (“iMac2″ is my imaginative name).

Running through the rest of the installer is pretty straightforward.  If you are particular and want to save a few MB, you can click on “customize” during the process and un-check all the languages that you are not going to use.  The install process took about 30 mins to complete.

Step 3:  Update OS X

The latest version of Mac OS X, as of this entry, is 10.6.1.  Let the OS software update manager do its thing.

Step 4:  Install additional XCode SDK packages

After updating and restarting the computer, open the installer disk and find the “Optional Installs” directory.  Open the XCode installer.  XCode will provide some very basic builing tools for 10.6.. stuff like gcc and the appropriate header files to build just about anything from source.  One thing that is absolutely essential is including “Mac OS X 10.4 Support” (see last image).  This is not clicked on by default. I’ve found that some source packages won’t build if they cannot find header files provided by this support package.

Step 5:  Install Git and Subversion

If you do any serious development, of any sort, you’re going to be using version control (if you are sane).

The new school kids are using Git, but there are still plenty of things hosted with Subversion.  So besides needing either to source control your own projects, you’re going to want these tools to grab latest code (i.e. trunk) for lots of cool stuff like Python, Ruby Gems, etc.

Install Git

For various reasons, you are probably better off compiling Git from source.  Don’t worry, it’s not painful at all, but does assume some familiarity with using the Terminal/ Command line interface.  If you can follow instructions, you can do this.

Follow these awesomely documented instructions from HiveLogic: http://hivelogic.com/articles/compiling-git-on-snow-leopard/

One thing to note:  you can grab the most recent stable version of Git, instead of the exact one mentioned in the HiveLogic article.  Check the repo here and find the latest version  http://kernel.org/pub/software/scm/git/ (use the .tar.bz file).  Also since you just clean installed this computer, you probably don’t have TextMate, so use “nano” from terminal to edit your .profile file as needed

After you confirm that Git is installed correctly, you can also installed GitX which is a great Git “repo browser” specifically for OS X.  You can grab it here:  http://gitx.frim.nl/ .  You probably won’t use it anytime soon, but you’ll thank me later.

Install Subversion

This is the easiest step here, because it’s already done for you!  Mac OS comes with Subversion, and while it’s not the very latest version, it will work just fine.  Type “which svn” to see that Subversion lives at “/usr/bin/svn”.   “svn –version” shows “version 1.6.2″

—

In “Ultimate Snow Leopard Web Development machine” Part 2, we’ll cover setting up your CLI and installing databases!

Below are the setup instructions.

1. Copy the contents below into a file named mysql-backup.sh placed in the root account home (on Ubuntu it’s ‘/root’). For simplicity, I’m using the root account, but on your production servers, you may want to create a dedicated “backupuser” account that executes these actions.
   
   
   [cci lang="bash"]

   #!/bin/sh

   DATE=`date “+%Y-%m-%d-%I-%M-%S”`
   BACKUP_DIR=”mysqlbackups”

   #DO NOT CHANGE ANYTHING BELOW THIS LINE
   DUMP=”mysqldump”
   REMOTE=”"

   usage() {
   echo Usage:
   echo “\t$0 [options]”
   echo
   echo “Where options is as follows:”
   echo “\t-r\t–remote\t\tThe remote host to copy the DB backup to (mandatory)”
   echo “\t-u\t–user\t\t\tDatabase user name; defaults to the current linux user”
   echo “\t-d\t–database\t\tDatabase name; defaults to the database user name”
   echo “\t-p\t–password\t\tDatabase password; if none is specified you will be prompted to enter one”
   echo “\t-R\t–remote–destination\tThe directory on the remote host to upload the DB backup to; defaults to ~/$BACKUP_DIR”
   echo “\t-L\t–local–destination\tThe directory on local host to save the DB backup; defaults to $HOME/$BACKUP_DIR”
   }

   while [ "$1" != "" ]; do
   case $1 in
   -h | –help ) usage
   exit
   ;;
   -u | –user ) shift
   USER=$1
   ;;
   -d | –database ) shift
   DB=$1
   ;;
   -p | –password ) shift
   PASS=$1
   ;;
   -r | –remote ) shift
   REMOTE=$1
   ;;
   -R | –remote-destination ) shift
   REMOTE_DIR=$1
   ;;
   -L | –local-destination ) shift
   LOCAL_DIR=$1
   ;;
   esac
   shift
   done
   if [ "$REMOTE" = "" ]; then
   usage
   exit
   fi

   LOCAL_DIR=${LOCAL_DIR:=”$HOME/$BACKUP_DIR”}
   REMOTE_DIR=${REMOTE_DIR:=”~/$BACKUP_DIR”}
   USER=${USER:=`whoami`}
   DB=${DB:=$USER}
   DEST=”$LOCAL_DIR/$DB.$DATE.bz2″

   mkdir -p $LOCAL_DIR 2>/dev/null
   if [ "$PASS" ]; then
   `$DUMP -u$USER -p$PASS $DB | bzip2 > $DEST`
   else
   `$DUMP -u $USER -p $DB | bzip2 > $DEST`
   fi
   scp $DEST $REMOTE:$REMOTE_DIR

   [/cci]

   
   

2. Make the file executable:
   
   [cci lang="bash"]
   chmod 755 mysql-backup.sh
   [/cci]
   
   
3. If you don’t have one already, create an ssh key pair for the account that will be running the cron (‘root’ in mycase). I set the key type to RSA / 2048 bits. When prompted for a password by the keygen creator, leave it blank.
   
   [cci lang="bash"]
   ssh-keygen -t rsa -b 2048
   [/cci]
   
   
4. Now take the id_rsa.pub key that was created in the previous step ( by default, it is placed in ~/.ssh/ ) and put it on the remote machine that we want to copy the backups to. It will need to be placed in a specific file called “authorized_keys” in the ‘.ssh’ directory of the user you will be ssh-ing in as. Thus, if you are ssh-ing into the remote machine as “jsmith”, put the key in a file called “authorized_keys” in /home/jsmith/.ssh/. The key should be placed into ‘authorized_keys’ as one line. Make sure to also enable passwordless ssh on the remote box, else the script won’t automatically be able to scp the file over.
   
   You can test this users ability to ssh into the remote machine without being prompted by a password using simple ssh test:
   
   [cci lang="bash"]
   ssh jsmith@[remoteserver.com]
   [/cci]
   
   Only continue to the next step when you get password-less ssh working!
   
   
5. Next, create a cronjob to execute the script periodically. As root, you can use the “crontab -e” command to edit/create a crontab account. I’ve chosen every hour, on the 15th minute:
   
   [cci lang="bash"]
   15 */1 * * * sh /root/mysql-backup.sh -r [username]@[offsite.com] -u [dbusr] -p [dbpass] -d [dbname] -R [remote server path]
   [/cci]
   
   
6. You may want to confirm that your server time is correct, as the backup file names will be date stamped with their time of creation. Also confirm that the backup files made it into the local and remote machine directories. And ofcourse, test the integrity of the created backup files by untaring/ un-bzipping them and restoreing them in a scratch database.
   
   

To save disk space, this script will automatically bzip the sql dump file. Your mileage will vary depending on how big your database is, but on a small webapp I can usually run this thing hourly, 24/7 and only use 1% of the available drive space after a year. Point being that you can backup as often as your disk space allocation will allow… and usually it will allow for more than you can imagine. One thing to note is that this script may not be the best strategy for high-volume sites, since it assumes you will lock the database while doing the dump.

Below are the setup instructions.

1. Copy the contents below into a file named pg-backup.sh placed in the root account home (on Ubuntu it’s ‘/root’). For simplicity, I’m using the root account, but on your production servers, you may want to create a dedicated “backupuser” account that executes these actions.
   
   
   [cci lang="bash"]

   #!/bin/sh

   DATE=`date “+%Y-%m-%d-%H-%M-%S”`
   BACKUP_DIR=”pgbackups”

   #DO NOT CHANGE ANYTHING BELOW THIS LINE
   DUMP=”pg_dump”
   REMOTE=”"

   usage() {
   echo Usage:
   echo “\t$0 [options]”
   echo
   echo “Where options is as follows:”
   echo “\t-r\t–remote\t\tThe remote host to copy the DB backup to (mandatory)”
   echo “\t-u\t–user\t\t\tDatabase user name; defaults to the current linux user”
   echo “\t-d\t–database\t\tDatabase name; defaults to the database user name”
   echo “\t-p\t–password\t\tDatabase password; if none is specified you will be prompted to enter one”
   echo “\t-R\t–remote–destination\tThe directory on the remote host to upload the DB backup to; defaults to ~/$BACKUP_DIR”
   echo “\t-L\t–local–destination\tThe directory on local host to save the DB backup; defaults to $HOME/$BACKUP_DIR”
   }

   while [ "$1" != "" ]; do
   case $1 in
   -h | –help ) usage
   exit
   ;;
   -u | –user ) shift
   USER=$1
   ;;
   -d | –database ) shift
   DB=$1
   ;;
   -p | –password ) shift
   export PGPASSWORD=$1
   ;;
   -r | –remote ) shift
   REMOTE=$1
   ;;
   -R | –remote-destination ) shift
   REMOTE_DIR=$1
   ;;
   -L | –local-destination ) shift
   LOCAL_DIR=$1
   ;;
   esac
   shift
   done
   if [ "$REMOTE" = "" ]; then
   usage
   exit
   fi

   LOCAL_DIR=${LOCAL_DIR:=”$HOME/$BACKUP_DIR”}
   REMOTE_DIR=${REMOTE_DIR:=”~/$BACKUP_DIR”}
   USER=${USER:=`whoami`}
   DB=${DB:=$USER}
   DEST=”$LOCAL_DIR/$DB.$DATE.bz2″

   mkdir -p $LOCAL_DIR 2>/dev/null
   `$DUMP -U $USER $DB | bzip2 > $DEST`
   ssh $REMOTE mkdir -p $REMOTE_DIR 2>/dev/null
   scp $DEST $REMOTE:$REMOTE_DIR

   [/cci]

   
   

2. Make the file executable:
   
   [cci lang="bash"]
   chmod 755 pg-backup.sh
   [/cci]
   
   
3. If you don’t have one already, create an ssh key pair for the account that will be running the cron (‘root’ in mycase). I set the key type to RSA / 2048 bits. When prompted for a password by the keygen creator, leave it blank.
   
   [cci lang="bash"]
   ssh-keygen -t rsa -b 2048
   [/cci]
   
   
4. Now take the id_rsa.pub key that was created in the previous step ( by default, it is placed in ~/.ssh/ ) and put it on the remote machine that we want to copy the backups to. It will need to be placed in a specific file called “authorized_keys” in the ‘.ssh’ directory of the user you will be ssh-ing in as. Thus, if you are ssh-ing into the remote machine as “jsmith”, put the key in a file called “authorized_keys” in /home/jsmith/.ssh/. The key should be placed into ‘authorized_keys’ as one line. Make sure to also enable passwordless ssh on the remote box, else the script won’t automatically be able to scp the file over.
   
   You can test this users ability to ssh into the remote machine without being prompted by a password using simple ssh test:
   
   [cci lang="bash"]
   ssh jsmith@[remoteserver.com]
   [/cci]
   
   Only continue to the next step when you get password-less ssh working!
   
   
5. Next, create a cronjob to execute the script periodically. As root, you can use the “crontab -e” command to edit/create a crontab account. I’ve chosen every hour, on the 15th minute:
   
   [cci lang="bash"]
   15 */1 * * * sh /root/pg-backup.sh -r [username]@[offsite.com] -u [dbusr] -p [dbpass] -d [dbname] -R [remote server path]
   [/cci]
   
   
6. You may want to confirm that your server time is correct, as the backup file names will be date stamped with their time of creation. Also confirm that the backup files made it into the local and remote machine directories. And ofcourse, test the integrity of the created backup files by untaring/ un-bzipping them and restoreing them in a scratch database.
   
   

Hope this was helpful! I’ll be back next week with a similar script solution for MySQL users.