app['rds_database'][environment]['rds_name']

If I wanted to test if this value is set I couldn’t safely just say:

if app['rds_database'][environment]['rds_name']

because in some cases

if app['rds_database']

or

if app['rds_database'][environment]

may be nil .

If ether of those were nil and I execute

if app['rds_database'][environment]['rds_name']

I would get an exception like:

NoMethodError: undefined method `[]' for nil:NilClass

I have been doing something like:

if app['rds_database'] && app['rds_database'][environment] && app['rds_database'][environment]['rds_name']

But that was starting to make me sick to my stomach. I like my Ruby fine and DRY

So I scoured the Internet (well googled a bit) and found a couple of good Stack Overflow posts like How to access an element deep in an array of arrays without getting ‘undefined method’ error and Looking for a Good Way to Avoid Hash Conditionals in Ruby.

But most of them were ways to Monkey Patch the Hash Object or use new operators that are loaded by Gems.

One of them was pretty simple and was pretty DRY. Though some commentors called it an indiscriminate use of  rescue and EEEEVVVVIIILLLLL.

But it seems to me to be a very discriminate use of rescue, as any case where the rescue happens, I want it to return nil:

if (app['rds_database'][environment]['rds_name'] rescue nil)

The parenthesis aren’t needed, but I think it makes it clearer whats going on. Especially if you say something like:

return unless (app['rds_database'][environment]['rds_name'] rescue nil)

So I’m going to give that a try for a while.

The post Avoiding a series of tests with Ruby Hashes of Hashes that might have nil before the leaf hash first appeared on Cognizant Transmutation.

• Mar 3, 2010 Added call to script ec2-set-defaults that is normally called on ec2 init that sets the locale and apt sources for EC availability Zone

Introduction

Opscode has officially released 0.8.x of Chef. It is now even more fabulous. I’ve been using the pre-release version for the last couple of months and it is rock steady and very powerful. I’ll be having a post soon on how I used it to deploy a pretty complicated cloud stack with multiple Rails/Mysql/Nginx/Unicorn/Postfix apps for front-ends, and a back end made up of a mix of a Clojure/Swarmiji distributed processing swarm, HBase/Hadoop, Redis, RabbitMQ.

But first, I needed to upgrade my Amazon EC2 AMIs for the officially released Chef 0.8.x. I also wanted to try the EBS Boot image as a basis for the AMI.

This is an update to my earlier post, Creating an Amazon EC2 AMI for Opscode Chef 0.8, but now using the official Opscode 0.8.x Gems instead of building your own Gems. A lot of the content is the same, but you can consider this mostly superceding the older one except where mentioned otherwise. This version will use the EBS Boot AMIs as per Eric Hammond’s Tutorial Building EBS Boot AMIs Using Canonical’s Downloadable EC2 Images. Much of this is blog post is taken from Eric’s blog post but in the context of creating a Chef Client base AMI and a Chef Server. Note that Opscode now has their own AMIs, including ones for Chef 0.8.4, but as of this writing, they do not have AMIs for Amazon us-west.

Setup

Prerequisites

On your host development machine (ie your laptop or whatever machine you are developing from) you should have already installed:

• ec2-api-tools and ec2-ami-tools (these assume you have a modern Java run time setup)
• chef-0.8.4 or later chef client gem (which implies the entire ruby 1.8.x and rubygems toolchain)

Set some Shell variables on host machine

Just to make using these instructions as a cookbook, we’ll have some shell variables that you can set once and then all the instructions will use the variables so you can just cut and paste the instructions into your shell.

keypair=id_runa-staging-us-west
fullpath_keypair=~/.ssh/runa/id_runa-staging-us-west
availability_zone=us-west-1a
instance_type=m1.large
region=us-west-1

# Pick one of these two AMIs (Note that it will be different for different Amazon Regions)
# 32bit AMI
origin_ami=ami-fd5100b8
#64bit AMI
origin_ami=ami-ff5100ba

Start up an instance and capture the instanceid

instanceid=$(ec2-run-instances \
  --key $keypair \
  --availability-zone $availability_zone \
  --instance-type $instance_type \
  $origin_ami \
  --region $region  |
  egrep ^INSTANCE | cut -f2)
echo "instanceid=$instanceid"

Wait for the instance to move to the “running” state

while host=$(ec2-describe-instances --region $region "$instanceid" |
  egrep ^INSTANCE | cut -f4) && test -z $host; do echo -n .; sleep 1; done
echo host=$host

This should loop till you see something like:

$ echo host=$host
host=ec2-184-72-2-93.us-west-1.compute.amazonaws.com

Upload your certs

This assumes that your Amazon certs are in ~/.ec2

rsync                            \
 --rsh="ssh -i $fullpath_keypair" \
 --rsync-path="sudo rsync"      \
 ~/.ec2/{cert,pk}-*.pem         \
 ubuntu@$host:/mnt/

Connect to the instance

ssh -i $fullpath_keypair ubuntu@$host

Update the Amazon ec2 tools on the instance

export DEBIAN_FRONTEND=noninteractive
echo "deb http://ppa.launchpad.net/ubuntu-on-ec2/ec2-tools/ubuntu karmic main" |
  sudo tee /etc/apt/sources.list.d/ubuntu-on-ec2-ec2-tools.list &&
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 9EE6D873 &&
sudo apt-get update &&
sudo -E apt-get dist-upgrade -y &&
sudo -E apt-get install -y ec2-api-tools

Set some parameters on instance shell environment

Again this makes it easier to cut and paste the instructions.

codename=karmic
release=9.10
tag=server
region=us-west-1
availability_zone=us-west-1a
if [ $(uname -m) = 'x86_64' ]; then
  arch=x86_64
  arch2=amd64
  # You will need to set the aki and ari values base on the actual base AMI you used
  # It will be different for different regions.  These are set for us-west-1
  ebsopts="--kernel=aki-7f3c6d3a --ramdisk=ari-cf2e7f8a"
  ebsopts="$ebsopts --block-device-mapping /dev/sdb=ephemeral0"
else
  arch=i386
  arch2=i386
  # You will need to set the aki and ari values base on the actual base AMI you used
  # It will be different for different regions. These are set for us-west-1
  ebsopts="--kernel=aki-773c6d32 --ramdisk=ari-c12e7f84"
  ebsopts="$ebsopts --block-device-mapping /dev/sda2=ephemeral0"
fi

Download and unpack the latest released Ubuntu server image file

This contains the output of vmbuilder as run by Canonical.

imagesource=http://uec-images.ubuntu.com/releases/$codename/release/unpacked/ubuntu-$release-$tag-uec-$arch2.img.tar.gz
image=/mnt/$codename-$tag-uec-$arch2.img
imagedir=/mnt/$codename-$tag-uec-$arch2
wget -O- $imagesource |
  sudo tar xzf - -C /mnt
sudo mkdir -p $imagedir
sudo mount -o loop $image $imagedir

Bring the packages on the instance up to date

# Allow network access from chroot environment
sudo cp /etc/resolv.conf $imagedir/etc/

# Fix what I consider to be a bug in vmbuilder
sudo rm -f $imagedir/etc/hostname

# Add multiverse
sudo perl -pi -e 's%(universe)$%$1 multiverse%' \
$imagedir/etc/ec2-init/templates/sources.list.tmpl

# Add Alestic PPA for runurl package (handy in user-data scripts)
echo "deb http://ppa.launchpad.net/alestic/ppa/ubuntu karmic main" |
sudo tee $imagedir/etc/apt/sources.list.d/alestic-ppa.list
sudo chroot $imagedir \
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys BE09C571

# Add ubuntu-on-ec2/ec2-tools PPA for updated ec2-ami-tools
echo "deb http://ppa.launchpad.net/ubuntu-on-ec2/ec2-tools/ubuntu karmic main" |
sudo tee $imagedir/etc/apt/sources.list.d/ubuntu-on-ec2-ec2-tools.list
sudo chroot $imagedir \
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 9EE6D873

# Upgrade the system and install packages
sudo chroot $imagedir mount -t proc none /proc
sudo chroot $imagedir mount -t devpts none /dev/pts

cat <<EOF > /tmp/policy-rc.d
#!/bin/sh
exit 101
EOF
sudo mv /tmp/policy-rc.d $imagedir/usr/sbin/policy-rc.d

chmod 755 $imagedir/usr/sbin/policy-rc.d
DEBIAN_FRONTEND=noninteractive

# It seems this has to be done to set up the Locale & apt sources
sudo -E chroot $imagedir /usr/bin/ec2-set-defaults

# Update the apt sources and packages
sudo chroot $imagedir apt-get update &&
sudo -E chroot $imagedir apt-get dist-upgrade -y &&
sudo -E chroot $imagedir apt-get install -y runurl ec2-ami-tools

Install Chef Client and other customizations

Install Ruby and needed packages

sudo -E chroot $imagedir apt-get -y install ruby ruby1.8-dev libopenssl-ruby1.8 rdoc ri irb \
build-essential wget ssl-cert git-core rake librspec-ruby libxml-ruby \
thin couchdb zlib1g-dev libxml2-dev emacs23-nox

Install Rubygems

Rubygems will be installed from source since debian/ubuntu try to control rubygems upgrades. If you don’t care you can install it via apt-get install rubygems

cd $imagedir/tmp
wget http://rubyforge.org/frs/download.php/69365/rubygems-1.3.6.tgz
tar zxf rubygems-1.3.6.tgz
cd rubygems-1.3.6
sudo -E chroot $imagedir ruby /tmp/rubygems-1.3.6/setup.rb
cd ..
sudo rm -rf rubygems-1.3.6
sudo -E chroot $imagedir ln -sfv /usr/bin/gem1.8 /usr/bin/gem
sudo -E chroot $imagedir gem sources -a http://gems.opscode.com
sudo -E chroot $imagedir gem sources -a http://gemcutter.org
sudo -E chroot $imagedir gem install chef

Use Opscode Chef Solo Bootstrap to configure the Chef Client

The following will set up all the default paths and directories as well as install and configure runit to start and monitor the chef-client. Originally I shied away from runit, but this time I’m going as Opscode Vanilla as possible and they like runit.

Create the solo.rb file

All of the following files should be done in $imagedir as we are going to have to run this as chroot to $imagedir

Create $imagedir/solo.rb with an editor and put in the following:

file_cache_path "/tmp/chef-solo"
cookbook_path "/tmp/chef-solo/cookbooks"
recipe_url "http://s3.amazonaws.com/chef-solo/bootstrap-latest.tar.gz"

Create the chef.json file

Create $imagedir/chef.json with the following. (set the server_fqdn to the chef server you are using):

{
  "bootstrap": {
    "chef": {
      "url_type": "http",
      "init_style": "runit",
      "path": "/srv/chef",
      "serve_path": "/srv/chef",
      "server_fqdn": "chef-server-staging.runa.com"
    }
  },
  "run_list": [ "recipe[bootstrap::client]" ]
}

Run the chef-solo command

sudo -E chroot $imagedir chef-solo -c solo.rb -j chef.json \
  -r http://s3.amazonaws.com/chef-solo/bootstrap-latest.tar.gz

I had to run it 3 times before it completed with no errors.
After it does work, clean up the chef-solo stuff:

sudo rm $imagedir/{solo.rb,chef.json}

Update the client config file

The Chef Solo Client bootstrap process creates an /etc/chef/client.rb that is not ideal for Amazon EC2. The following will replace that:

mkdir -p /etc/chef
chown root:root /etc/chef
chmod 755 /etc/chef

Put the following in /etc/chef/client.rb:

# Chef Client Config File
# Automatically grabs configuration from ohai ec2 metadata.

require 'ohai'
require 'json'

o = Ohai::System.new
o.all_plugins
chef_config = JSON.parse(o[:ec2][:userdata])
if chef_config.kind_of?(Array)
  chef_config = chef_config[o[:ec2][:ami_launch_index]]
end

log_level        :info
log_location     STDOUT
node_name        o[:ec2][:instance_id]
chef_server_url  chef_config["chef_server"]

unless File.exists?("/etc/chef/client.pem")
  File.open("/etc/chef/validation.pem", "w", 0600) do |f|
    f.print(chef_config["validation_key"])
  end
end

if chef_config.has_key?("attributes")
  File.open("/etc/chef/client-config.json", "w") do |f|
    f.print(JSON.pretty_generate(chef_config["attributes"]))
  end
  json_attribs "/etc/chef/client-config.json"
end

validation_key "/etc/chef/validation.pem"
validation_client_name chef_config["validation_client_name"]

Mixlib::Log::Formatter.show_time = true

Finish creating the new image

Clean up from the building of the image

sudo chroot $imagedir umount /proc
sudo chroot $imagedir umount /dev/pts
sudo rm -f $imagedir/usr/sbin/policy-rc.d

Copy the image files to a new EBS volume, snapshot and register the snapshot

size=15 # root disk in GB
now=$(date +%Y%m%d-%H%M)
prefix=runa-chef-0.8.4-ubuntu-$release-$codename-$tag-$arch-$now
description="Runa Chef 0.8.4 Ubuntu $release $codename $tag $arch $now"
export EC2_CERT=$(echo /mnt/cert-*.pem)
export EC2_PRIVATE_KEY=$(echo /mnt/pk-*.pem)

volumeid=$(ec2-create-volume --region $region --size $size \
  --availability-zone $availability_zone | cut -f2)

instanceid=$(wget -qO- http://instance-data/latest/meta-data/instance-id)

ec2-attach-volume --region $region --device /dev/sdi --instance "$instanceid" "$volumeid"

while [ ! -e /dev/sdi ]; do echo -n .; sleep 1; done

sudo mkfs.ext3 -F /dev/sdi
ebsimage=$imagedir-ebs
sudo mkdir $ebsimage
sudo mount /dev/sdi $ebsimage

sudo tar -cSf - -C $imagedir . | sudo tar xvf - -C $ebsimage
sudo umount $ebsimage

ec2-detach-volume --region $region "$volumeid"
snapshotid=$(ec2-create-snapshot --region $region "$volumeid" | cut -f2)

ec2-delete-volume --region $region "$volumeid"

# This takes a while
while ec2-describe-snapshots --region $region "$snapshotid" | grep -q pending
  do echo -n .; sleep 1; done

ec2-register \
  --region $region \
  --architecture $arch \
  --name "$prefix" \
  --description "$description" \
  $ebsopts \
  --snapshot "$snapshotid"

Afterward

That will get you an AMI that you can now use as a chef-client. You can use the directions from the section Creating a Chef Server from your new Image in the previous article: Creating an Amazon EC2 AMI for Opscode Chef 0.8.

The post Using the Official Opscode 0.8.x Gems to build EC2 AMI Chef Client and Server first appeared on Cognizant Transmutation.

The Apple Support article: Mac OS X Server 10.5.6 or later: MySQL libraries available for download is the main tip, but you’ll need to get the actual latest version, not necessarily the version specified in the article. I downloaded MySQL-49 Binary which is actually mysql  Ver 14.12 Distrib 5.0.82, for apple-darwin10.0.

This is a bit scary as the installation process is to untar the binary right on top of the actual /usr filesystem. I don’t know for sure if its totally right… and 64 bit and there’s no going back.

The prcoess is after you download the binary run the following command as root/sudo (and remember the -C / says to untar it starting at the root of the filesystem, so its going to overwrite things in /usr):

tar -xzvf MySQL-49.binaries.tar.gz -C /

The post Installing Ruby Mysql Gem on Snow Leopard Server first appeared on Cognizant Transmutation.

Runa.com, the startup where I am CTO, is looking for great developers to join our small agile team. We’re an early stage, pre-series-A startup (presently funded with strategic investments from two large corporations). Runa offers a SaaS to on-line merchant that allows them to offer dynamic product and consumer specific promotions embeded in their website. This will be a very large positive disruption to the online retailing world.

Techie keywords: clojure, hadoop, hbase, rabbitmq, erlang, chef, swarm computing, ruby, rails, javascript, amazon EC2, emacs, Macintosh, Linux, selenium, test/behavior driven development, agile, lean, XP, scalability

If you’re interested, email  jobs@runa.com

If you want to know more, read on!

What do we do

Runa aims to provide the top of the long tail thru the middle of the top 500 online retailers with tools/services that companies like amazon.com use/provide. These smaller guys can’t afford or don’t have the resources to do anything on that scale, but by using our SaaS services, they can make more money while providing customers with greater value.

The first service we’re building is what we call Dynamic Sale Price.

It’s a simple concept – it allows the online-retailer to offer a sale price for each product on his site, personalized to the individual consumer who is browsing it. By using this service, merchants are able to –

• Increase conversion (get them to buy!) and
• Offer consumers a special price which maximizes the merchant’s profit

This is different from “dumb-discounting” where something is marked-down, and everyone sees the same price. This service is more like airline or hotel pricing which varies from day to day, but much more dynamic and real-time. Further, it is based on broad statistical factors AND individual consumer behavior. After all, if you lower prices enough, consumers will buy. Instead, we dynamically lower prices to a point where statistically, that consumer is most likely to buy.

How we do it

Runa does this by performing statistical analysis and pattern recognition of what consumers are doing on the merchant sites. This includes browsing products on various pages, adding and removing items from carts, and purchasing or abandoning the carts. We track consumers as they browse, and collect vast quantities of this click-stream data. By mining this data and applying algorithms to determine a price point per consumer based on their behavior, we’re able to  maximize both conversion (getting the consumer to buy) AND merchant profit.

We also offer the merchant comprehensive reports based on analysis of the mountains of data we collect. Since the data tracks consumer activity down to the individual product SKU level (for each individual consumer), we can provide very rich analytics.  This is a tool that merchants need today, but don’t have the resources to build for themselves.

The business model

For reference, it is useful to understand the affiliate marketing space. Small-to-medium merchants (our target audience) pay affiliates up to 40% of a sale price. Yes, 40%. The average is in the 20% range.

We charge our merchants around 10% of sales the Runa delivers. Our merchants are happy to pay it, because it is a performance-based pay, lower than what they pay affiliates, and there is zero up-front cost to the service. In fact, the above mentioned analytics reports are free.

We’re targeting e-commerce PLATFORMS (as opposed to individual merchants); in this way, we’re able to scale up merchant-acquisition. We have 10 early-customer merchants right now, with about 100 more planned to go live in the next 2-3 months. By the end of next year, we’re targeting about 1,000 merchants and 10,000 merchants the following year. Our channel deployment model makes these goals achievable.

At something like a 5 to 10% service charge, and a typical merchant having between 500K to 1M in sales per year, this is a VERY profitable business model. That is, of course, if we’re successful… but we’re seeing very positive signs so far.

Technology

Most of our front-end stuff (like the merchant-dashboard, reports, campaign management) is built with Ruby on Rails. Our merchant integration requires browser-side Javascript magic. All our analytics (batch-processing) and real-time pricing services are written in Clojure. We use RabbitMQ for all our messaging needs. We store data in HBase. We’re deployed on Amazon’s EC2.

Here are a few blog postings about what we’ve been up to –

Distributed Clojure system in production
Using messaging for scalability
Capjure: a simple HBase persistence layer
Clojure in production
Experience installing Hbase 0.20.0 Cluster on Ubuntu 9.04 and EC2

We’ve also open-sourced a few of our projects –

swarmiji – A distributed computing system to write and run Clojure code in parallel, across CPUs
capjure – Clojure persistence for HBase

Culture at Runa

We’re a small team, very passionate about what we do. We’re focused on delivering a ground-breaking, disruptive service that will allow merchants to really change the way they sell online. We work start-up hours, but we’re flexible and laid-back about it. We know that a healthy personal life is important for a good professional life. We work with each other to support it.

We use an agile process with a lot of influences from the “Lean”:http://en.wikipedia.org/wiki/Lean_software_development and “Kanban”:http://leansoftwareengineering.com/2007/08/29/kanban-systems-for-software-development/ world. We use “Mingle”:http://studios.thoughtworks.com/mingle-agile-project-management to run our development process. Everything, OK mostly everything is covered by automated tests, so we can change things as needed.

We’re all Apple in the office – developers get a MacPro with a nice 30″ screen, and a nice 17″ MacBook Pro.  We deploy on Ubuntu servers.  Aeron chairs are cliché, yes; but, very comfy.

The environment is chilled out… you can wear shorts and sandals to work…  Very flat organization, very non-bureaucratic… nice open spaces (no cubes!). Lunch is brought in on most days! Beer and snacks are always in the fridge.

We’re walking distance to the San Antonio Caltrain station (biking distance from the Mountain View Caltrain/VTA lightrail station).

What’s in it for you

• Competitive salaries, and lots of stock-options
• Cutting edge technology stack
• Fantastic business opportunity, and early-stage (= great time to join!)
• Developer #5 – means plenty of influence on foundational architecture and design
• Smart, full bandwidth, fun people to work with
• Very comfortable, nice office environment
• We have a “No Assholes” policy

OK!

So, if you’re interested, email us at jobs@runa.com

No recruiters please!

We would prefer folks who are already in the Bay Area (but if you not local and are really great let’s talk!)

The post Want to work at a Startup with Cool Tech? (HBase, Clojure, Chef, Swarms, Javascript, Ruby & Rails) first appeared on Cognizant Transmutation.

There are other issues using this technique. To quote Flinn:

Achtung! Monkey patching with the above will expose your create method without using an actual post. Imho no big deal, others might be more cautious (CAPTCHAis always an option), ymmv.

See his original article for details on how to use it generally. 

The problem with the monkeypatch that he wrote up is that Rails 2.2.2 changed the function that was monkeypatched so the patch stopped working. Below is code that will work on both pre and post 2.2.2 Rails:

module ActionController
  class AbstractRequest

    def request_method

      if Rails::VERSION::STRING < "2.2.2"

        @request_method ||= begin

          method = (parameters[:_method].blank? ? @env['REQUEST_METHOD'] : parameters[:_method].to_s).downcase

          if ACCEPTED_HTTP_METHODS.include?(method)

            method.to_sym

          else

            raise UnknownHttpMethod, "#{method}, accepted HTTP methods are #{ACCEPTED_HTTP_METHODS.to_a.to_sentence}"

          end

        end

      else

        method = @env['REQUEST_METHOD']

        method = parameters[:_method] unless parameters[:_method].blank?

        HTTP_METHOD_LOOKUP[method] || raise(UnknownHttpMethod, "#{method}, accepted HTTP methods are #{HTTP_METHODS.to_sentence}")
      end

    end

  end
end
The post Cross Domain RESTful AJAX with jQuery and Rails 2.2.2 first appeared on Cognizant Transmutation.
]]>
					
					https://www.ibd.com/howto/cross-domain-restful-ajax-with-jquery-and-rails-222/feed/
			1
		
		
		156	
		
		
		https://www.ibd.com/ruby-rails/quarkruby-consume-non-rails-style-rest-apis/
		
		
		Wed, 31 Dec 2008 01:09:41 +0000
				
		
		
		
		http://blog2.ibd.com/?p=87

					It seems that most “RESTful” APIs in the wild are well, pretty wild. They don’t meet the strict requirements of the pure CRUD/REST of ActiveResource. The article in QuarkRuby:  Consume non rails-style REST APIs shows how to create a nice ruby wrapper around ActiveResource so you can adapt to any arbitrary REST / http interface on the Internet.

The post QuarkRuby: Consume non rails-style REST APIs first appeared on Cognizant Transmutation.
]]>
										It seems that most “RESTful” APIs in the wild are well, pretty wild. They don’t meet the strict requirements of the pure CRUD/REST of ActiveResource.

The article in QuarkRuby:  Consume non rails-style REST APIs shows how to create a nice ruby wrapper around ActiveResource so you can adapt to any arbitrary REST / http interface on the Internet.
The post QuarkRuby: Consume non rails-style REST APIs first appeared on Cognizant Transmutation.
]]>
					
		
		
		87	
		
		
		https://www.ibd.com/how-the-world-works/installing-a-git-client-on-a-shared-host-with-no-compiler/
					https://www.ibd.com/how-the-world-works/installing-a-git-client-on-a-shared-host-with-no-compiler/#comments
		
		
		Sat, 29 Nov 2008 05:51:22 +0000
				
		
		
		
		
		
		
		
		http://blog2.ibd.com/?p=50

					We are using Git to manage our deployments, but have some clients that use shared hosting services that don’t have git installed (in particular Hostgator.com). Most of these shared hosting services do allow ssh shell access but don’t have compilers available on the shared hosting account. So I couldn’t just build git on the shared hosting account. Many hosting services…

The post Installing a git client on a shared host with no compiler first appeared on Cognizant Transmutation.
]]>
										

We are using  Git to manage our deployments, but have some clients that use shared hosting services that don’t have git installed (in particular Hostgator.com).



Most of these shared hosting services do allow ssh shell access but don’t have compilers available on the shared hosting account. So I couldn’t just build git on the shared hosting account.

Many hosting services do offer webdav access to the account’s filesystem. I tried pushing git trees to the target filesystem over https/webdev, but couldn’t get it to work even if I first copied a bare git directory to the target.
This left me with the thought that maybe I could build git on another host that I controled that had the same type of Linux environment that was running the target shared host environment. Once I built it in the environment I controled, I could then copy it to the shared hosting account and use it via ssh shell access.


In the particular case of Hostgator, they were running CentOS 5.2.Thus I needed a CentOS 5.2 machine to build Git on. I didn’t have one lying around, but I do have an Amazon EC2 account!

(You should be able to modify this to work with other Linux versions pretty easily.)
Create a CentOS 5.2 instance on Amazon EC2
Used the Amazon Machine Image ami-0459bc6d described in CentOS 5 i386 Base AMI posting which includes instructions on how to instantiate and update to CentOS 5.2.
I used the fabulous  ElasticFox extension to Firefox to instantiate and run the base image.
Documentation on using ElasticFox can be found at Elasticfox Getting Started Guide. Documentation on using Amazon EC2 can be found at Amazon EC2 Getting Started Guide.
I won’t repeat those instructions here, you’ll have to get the Amazon EC2 basics from those docs.
One you have the base ami-0459bc6d instance running, there are a few things you must do to to the stock CentOS 5.1 image to get it ready to build git:
Update the CentOS image from 5.1 to 5.2
yum -y upgrade
reboot
Install gcc
yum install gcc
Install zlib-devel package
Noticed that zlib-devel was needed by the git install process when I first tried to run configure on the git distribution.
yum install zlib-devel
Install curl-devel
Needed if you want to use http/https/webdav access to git repositories.
yum install curl-devel
Build Git from Source
Once you have got your CentOS 5.2 system running, you can build git from the source tree.
Download git
wget http://kernel.org/pub/software/scm/git/git-1.6.0.4.tar.gz
Unpack the Git source tree
tar xvzf git-1.6.0.4.tar.gz
Create a build target path
You will need to have a build target directory path on your build machine that is the same as the path to your home directory on your target virtual host account. In this example we’re calling it

/home/clientname.
Replace clientname with the name of your home directory on hostgatore which is usually the same as your domainname.
This is where the build/install process will end up “installing” the compiled and other run time files:
mkdir /home/clientname
Run Configure on source tree
Change directory on the build machine to the top of the git source tree. (Where you unpacked the tar file git-1.6.0.4.tar.gz it does not have to be in /home/clientname)
cd git-1.6.0.4
Configure and set the prefix to the home directory that is your home directory on the target virtual host.
./configure --prefix=/home/clientname/git_root
Build the code and have it be installed in the directory that you defined in the –prefix line above

make

make install

Assuming all goes well, it will build the code in the directory
git-1.6.0.4
and install everything in the directory
/home/clientname/git_root
It will automatically create the git_root directory but you have to have created /home/clientname
Tar it up and scp it to target
cd /home/clientname
tar cvzf git_root.tgz git_root
scp git_root.tgz userid@clienturl:

Unpack it on target
ssh userid@clienturl
tar xvzf git_root.tgz

Set up environment to use the newly installed git
Add the path to the newly created bin to your path:
Edit your startup file such as ~/.bash_profile and add:
PATH=/home/clientname/git_root/bin:$PATH
You have to log out and log back in or source .bash_profile to update the path. You can also type that line into your current session at the prompt and have it immediately active.
Use Git as normal!
I found that I can now use Git as normal except that with Hostgator they seemed to be blocking the git protocol or something. I could not say:
git clone git://github.com/rberger/project.git
But I could say:
git clone git@github.com:rberger/project.git
(assuming I had my ssh keys setup to access github as git)
or
git clone http://github.com/rberger/project.git
Note that you do not say ./git. We are assuming that you added git to your path and you can just say git and it will find the executables via the $PATH
If you didn’t want to change $PATH, you could  give a full path like:
/home/clientname/git_root/bin/git clone git@github.com:rberger/project.git
Save your CentOS 5.2 Amazon Image
If you want to, you can save the CentOS 5.2 customized image you created on Amazon EC2.
Ssh into the root account on your running CentOS amazon instance, copy your Amazon EC2 certificate and private key to the home directory of root on the running CentOS instance and run the following commands:
Build the new AMI
Replace cert-your_cert_sig.pem, your-private-key-sig and your-amazon-userid with the appropriate values for your EC2 certificate.
ec2-bundle-vol -d /mnt --cert cert-your_cert_sig.pem --privatekey pk-your-private-key-sig.pem -u your-amazon-userid -s 3096


The -s 3096 tells it to create an image that is 3GB big. You may have to make it bigger if the command fails. You can check that this is the problem by adding the –debug flag to the above command.
Stash the image into your S3 account
Use your own ws-access-key-id and aws-secret-access-key
ec2-upload-bundle -b centos-5.2-git -m /mnt/image.manifest.xml -a aws-access-key-id -s aws-secret-access-key
Git to your hearts content!
Here is the gzipped tar file of git built to run on hostgator. I don’t know if it will work in any other directory than the one it was built for though.
git_root.tgz
The post Installing a git client on a shared host with no compiler first appeared on Cognizant Transmutation.
]]>
					
					https://www.ibd.com/how-the-world-works/installing-a-git-client-on-a-shared-host-with-no-compiler/feed/
			15
		
		
		50