Now, whenever a new box is deployed, the SSH keys of all the technical contacts on your Brightbox account are automatically pre-installed for the default ‘rails’ user. To add your own SSH key, edit your user profile within the control panel and paste in your SSH public key using the editor at the bottom.

Remember, this only affects newly provisioned boxes – as the it’s done during the box build stage. Removing or adding technical contacts in the control panel at a later date will not automatically change any access control on existing boxes.

This is generally considered to be best practice where ever a server is geographically located, however, it may  cause a problem if you are hosting a  geographically specific web application.

If your web application requires a different time-zone such as CET, BST or PST, or Daylight Saving Time is giving you a headache,  take a look at our Wiki page for a timely introduction to the subject of time-zones on Brightboxes.

Today I’m pleased to announce a new revision of the Brightbox Deployment Gem, version 2.3.6. This release fixes some of the issues reported to us by our users, along with a few extra features.

The documentation on the wiki has been updated with the new fixes and features. If you have any tips or find any errors just let us know.

NEW FEATURES

Apt Package Dependencies

Just as you can currently define gems your application relies on and have them automatically installed onto your servers, you can now do the same with apt packages. Define them in your deploy.rb and they’ll be installed before installing your required rubygems, which means you can use it to install apt packages that gems depend on. As an example, the nokogiri gem depends on a couple of apt packages.

depend :remote, :apt, "libxml2-dev"
depend :remote, :apt, "libxslt1-dev"
depend :remote, :gem, "nokogiri", ">= 0"

Intermediate SSL Certificates

Support for Intermediate SSL Certificates in Apache has been added, meaning you no longer need to manually edit the Apache config files directly. Just add one line to your deploy.rb and the gem now takes care of updating the Apache config for you. An example SSL configuration:

set :ssl_certificate, "my_cert.pem"
set :ssl_key, "my_cert.key"
set :ssl_intermediate, "intermediate.crt"

See the wiki page for Adding SSL Support to Apache for more information.

Deploy.local.rb

A common issue we’ve seen with is setting the deploy password. If you put it in deploy.rb, then it inevitably ends up in your source control repository, which is a bad idea. A workaround we’ve suggested in the past is to have a deploy.local.rb file, which isn’t tracked by source control, and load that from within your deploy.rb file. This allows you to have the password (or any other sensitive settings) defined, but kept outside your source control.

As part of this release, the gem now has official support for a deploy.local.rb file. If it exists, the gem will load it in for you.

For more information see the Advanced Gem Settings page on the wiki.

Disable (re)generating webserver config

If you’ve made manual changes to your webserver (apache or nginx) configuration, then you don’t want an accidental deploy:setup to overwrite your configs. Up until now you just had to avoid running the command, but now there’s a setting to disable it for you.

set :generate_webserver_config, false

FIXES AND ENHANCEMENTS

• Max Age setting now accepts a number as well as a string
• deploy:initial reloads Apache so the new config is loaded

Every Brightbox runs Ubuntu, which is an operating system built on top of the GPL Linux kernel. Our infrastructure is built upon Xen, Apache, Nginx, MySQL, Nagios and many other open source software projects; not least of which are Ruby and Rails themselves.

But whilst we benefit from this software, without contribution, free software is nothing, so we contribute anything we can. The most obvious of these are the Brightbox deployment gem and its associated server-side tools. These are extensions to Capistrano that help you get your application onto your Brightbox as quickly and easily as possible.

We also have our apt repository where we repackage a number of free software projects to make configuring your Brightbox as easy as possible. More details on the repository are available on the wiki, but the most notable are our Passenger and Ruby Enterprise Edition packages.

However, nowadays, the real place for sharing your code is on Github. We have a number of projects available there, ranging from the tiny to the large.

These include:

• Flashing rails

  A rails plugin that makes it simple to display flash messages in your views in a consistent manner.

• Rujitsu

  A simple gem that collects together a number of convenience methods and various helpers.

• RSpec-rails extensions

  A gem that tidies up specifying your code with RSpec-Rails.

• Object Factory

  Brightbox’s very own answer to Factory Girl or Machinist that lets you build your test data with minimal configuration and no fixtures.

• Altered Beast and Redmine.

  We have taken our own forks of two popular Rails applications. David’s version of Altered Beast handles the Brightbox forums and Redmine handles our internal bug tracking and task lists.

• Warren and Bigwig

  Last, but by no means least, we have Warren and Bigwig. These are our wrappers to AMQP and RabbitMQ.

  We use RabbitMQ internally to deliver messages across our various infrastructure systems and needed a simple way to interface our ruby code to Rabbit (which is implemented in Erlang).

  This led to Warren, our wrapper over the AMQP protocol that make it simple to post messages onto the queue.

  In order to receive and act on those messages, we also built Bigwig (no prizes for spotting the rabbit references there), which takes those messages and responds. Bigwig matches each incoming message against a set of plugins, each plugin being small and focused on a particular task. Unrecognised messages are discarded, ensuring that rogue commands can’t wreak havoc upon our network.
  UPDATE: It turns out that Bigwig isn’t quite ready yet, as a big chunk has been rewritten. We’ll get it out there as soon as we can.

As these are all free software projects, please take a look inside and poke around. Any suggestions, improvements, patches or forks will be gratefully received. Also, stay tuned for an announcement on a major project we are looking to start in the next couple of weeks.

Update 2: We’ve also put the code for Isitruby19.com onto Github, under an MIT licence. Please go to the forum if you have any questions.

So, resorting to the good old pen and paper, I tried just sketching out a couple of ideas.

Three minutes and two pages later, there it was :)

From rough sketch to finished “box” took 4 steps (and another 4 minutes):

1. “Scanned” in the sketch by taking a photo on my mobile (Sony Ericsson K800i)
2. Sent the photo to my Mac via Bluetooth
3. Increased the brightness/contrast in Photoshop to make the lines clearer (flickr)
4. Imported the image into Illustrator and used the “Trace” command to simplify the edges and convert to vector (flickr)

Done. Not bad for 10 minutes work or so?

Of course, the question I hear all the time is “when?”. “When will you be going live?”. We’ve not got an exact date and we won’t be publishing a date until we’re ready to go and we’ve got a way to take payments :) Right now, David is working on the ordering/admin system that will be built into the main Brightbox website so customers will be able to order machines and have them automatically provisioned (we already have Ruby scripts to do this). We also want beta users to have at least a month to have a play around and do their own testing.

So, right now, we’re currently looking at a full launch early September.

Jason Fried (37signals) was right and I should have listened:

..we don’t have release dates. It’s a great way to make sure things are never late.

Also, in response to some good early feedback, John’s been working on a deployment gem that will make it super simple to deploy your Ruby on Rails apps to Brightbox.