Torquebox 3.0.beta1 and Rails 4

Since the recent release of Torquebox 3.0.beta1 and Rails 4, I have been itching to convert one of our lab projects to the latest and greatest.  The Torquebox folks have done their usual great job documenting the getting started steps for various typical developer scenarios.  The RVM instructions did the trick for me on Mac OS X 10.8.4 and this Java version:

java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)

Hiccup #1: 500 Error when visiting http://localhost:8080/posts

Illegal key size: possibly you need to install Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for your JRE

My standard Oracle provided download with the 1.7 JRE came with standard export versions of the  JCE modules.  This stack overflow post (thank you Stack Overflow! Again!) explained the issue. C Deepak’s comment provided the JRE 1.7 link: jce-7-download.  The README.txt provides an overview of the installation steps.  On my OS X box:

# find the java home on your machine and cd into it
cd `echo $JAVA_HOME`
cd jre/lib/security

# make a backup of the originals
sudo mv local_policy.jar local_policy.jar.original
sudo mv US_export_policy.jar US_export_policy.jar.original

# copy the downloaded and expanded zip files 
sudo cp ~/Downloads/UnlimitedJCEPolicy/US_export_policy.jar .
sudo cp ~/Downloads/UnlimitedJCEPolicy/local_policy.jar .

# restarted torquebox with Control-C and error cleared
torquebox run

I will update this post as I move along in the upgrade in case any other issues surface.

References

  1. Torquebox Documentation for 3.0.beta1: “Getting Started
  2. Stack Overflow on Java Security: Illegal key size or default parameters?

 

Vagrant, Ubuntu, and Postgres 8.4 for Ruby on Rails Development

In our organization, we produce an enterprise rails application that can be installed on multiple platforms (redhat 5/6, windows, mac os x) and use multiple database backends (P, MSSQL, mysql, Oracle at last count).  This poses reasonably big challenges for developers, but truly gigantic ones for our QA and continuous delivery pipeline.

We have focused in on a jRuby architecture delivered through Jenkins, Puppet, and Vagrant virtual machines to help ease the pain of these challenges and allow us to produce disposable versions of our reference environments at all stages of the pipeline from development to final pre-prod acceptance testing, and even out into the field through proof of concepts (POC) and sales efforts.

As developers, we rely heavily on the database drivers and migrations that Ruby on Rails places between our web application and the particular database we are using.   In the course of our testing, we sanity test our commits on P first, then the other supported databases.  While a single development machine might be able to install some of these databases locally (except Oracle or MSSQL on the Mac), once you get into multiple versions it is nearly impossible to get them all up and running reliably.  Enter vagrant!

Prerequisites

This workflow requires Vagrant v. 1.2 or greater, Virtual Box vs 4.2.10 or greater (4.2.14 was sadly broken).  It uses an Ubuntu box with one of the smallest footprints since the demands on this database server are going to be light: Ubuntu Lucid 32.  A list of available Vagrant boxes can be found at www.vagrantbox.es.  Our goal was to get an older 8.4 edition of Postgres, so the slightly dated nature of the lucid box meant that the default apt-get package installation was pegged to the older 8.4 version of Postgres just like we hoped.

Building the Vagrant Box

At the end of this process, you will be able to package up a new vagrant box with 8.4 running on an empty database, but to get there we need to build the box.  My puppet skills are still too rudimentary to accomplish all of this through a puppet initialization file, unfortunately, but I hope to update this project soon with a pure puppet work flow.  Skip to the section “Deploying the Finished Postgres Server” if you just was to use the image linked to this post and get the server up and running.

Step 1: Create a project directory and initialize the vagrant box

Step 2. Edit the vagrant file to forward ports and reduce the memory footprint

Step 3. Manually configure the Ubuntu server for localhost:5433 access by Rails applications or clients

Wrapping Up

At this point, you have a single command that will bring up your postgres 8.4 server.  You can destroy and recreate it as many times as you like.  Upload the finished box and share it with your development team.  Rails database.yml file can connect to it once it is running using port 5433.

Future steps for this workflow include an all Puppet configuration of the firewall, postgres, and locale settings.  I have about 70% of that done, but am missing a few key Puppet concepts to complete the job so get in touch if you want to collaborate.  With a puppet work flow, all the twitchy command line stuff would be replaced by a source controlled configuration script eliminating the need to package the configured box and working directly from the lucid32 base.

References

As usual, a number of blogs and gists helped me get through this workflow, but no one post got me all the way to bingo hence this post.  Special thanks go to:

  1. Mario Zaizar, “How to install Postgresql 8.4 in a Vagrant box”, http://blog.crowdint.com/2011/08/11/postgresql-in-vagrant.html, visited 29 June 2013. Note: the last steps (2 and on) in this blog are not valid for postgres 8.4 because they undo the automatic cluster setup included in the package installation.
  2. jschoolcraft, ”how-to-install-postgresql-on-an-ubuntu-1004-vagrant-box.markdown”, https://gist.github.com/jschoolcraft/1963369, visited on 29 June 2013.  As with Zaizar’s post, the later parts of the blog with manual running of pg_createcluster were invalid for my lucid32 box which completed that step as part of package installation.  Running it again caused some problems so I had to start over with a fresh box and omit those steps.

Historicus

Since 2001, I have owned and managed Historicus, Inc., a new media studio producing websites and database driven web applications for museums, universities, and publishers. In late 2012, I decided to change the rhythm of my professional life and joined an enterprise rails project.

The resources, team dynamics, and challenges of enterprise rails projects have expanded my horizons as a programmer and allowed me, as I hoped it would, to sharpen and deepen what skills I have in Ruby on Rails development, continuous integration and delivery, and agile programming practices.

This blog is a drop in replacement for the  corporate portfolio of the previous Historicus, Inc. site.  I can still be reached through its contact form, but the contents here will be primarily notes arising out of my day to day programming experience.  As we all know, solving a problem once — like using vagrant to manage multiple versions of postgres for testing purposes — does not mean you will remember it the second time.

And who has not felt the gratitude of a google search ending at a well written blog entry solving just the problem you are facing at that moment.  Like most blogs, this will no doubt be 99.9% for myself, but giving back just a little to all the other bloggers is worth a try.