Update: New cookbook, Lion and more!
- Company issued Macbook Pro
- Personal Macbook Air
- Family Macbook Pro
Note that while I do use this on my work laptop, Opscode has a different set of recipes to set up development and internal company workstations. At some point there may be a post on the Opscode Blog.
Before I get started with Chef itself, I have to install a few things to “bootstrap” the systems to be ready. I’m not going to include the commands to install all these “pre-requisites”, as you can learn how to do that from their respective web sites.
Xcode 3.2 (or 4.0)
I wish I could purchase a Macbook with Xcode preinstalled. In fact, I would pay $50 to have this over iLife on new machines, so the $5 cost for version 4 is really minor. However, I don’t have any use for whatever 4.0 has to offer, since I only want Xcode because its the most sane way to get GCC and friends on OSX.
Ruby Version Manager
I want to use Ruby 1.9.2 instead of the default that comes with OSX, and RVM makes it easy to do that. I also like the gemset feature, which allows me to sandbox and play with various configurations of RubyGems.
I generally just install the latest released Chef gem from RubyGems.org once I have Ruby installed.
Once Chef itself is installed, it’s time to get cooking! I have the following already set up:
- Opscode Community userid.
- Opscode Hosted Chef organization.
- Chef Repository
Let’s take a look at what I put into the Chef Repository to configure my workstations. First, I created the repository and the listed components, then I upload everything to my Opscode Hosted Chef organization.
I have a number of cookbooks for my personal repository, but the relevant ones for workstations are:
I wrote the dmg cookbook to automatically install OSX applications that are delivered to users via DMGs. After writing cookbooks for skype, and tunnelblick, I noticed some common patterns and abstracted those out to a lightweight resource and provider, “dmg_package”. This does the heavy lifting of:
- Retrieve a .dmg file from a remote URL.
- Mount the disk image.
- Copy the .app directory to /Applications.
- Unmount the disk image.
The homebrew cookbook was written by Graeme Mathieson, and it will install Homebrew in /usr/local and use it as the default package provider on OSX.
Both the dmg and homebrew cookbooks were downloaded to my local chef-repo with the “vendor” pattern supported by knife.
The workstation cookbook consists of a number of recipes. Many of them contain commands lifted from Pivotal Labs experimental GitHub repository, wschef. I don’t use any of the scaffolding they wrote in that repository, but I grabbed lots of the executes. However, that repository does not have any mention of a license, so I haven’t published the workstation cookbook I use. I can publish the recipe I wrote, which will be part of the cookbook when the license of their recipes is sorted out.
I use two roles on my workstations that tell Chef what recipes to apply. First, is role[mac_os_x]:
Next is the actual workstation recipe.
Chef is data driven, and I have written a data bag item for my workstation. It simply lists the gems, dmg’s and packages to install with the above recipe.
I run Chef as my normal user, so it will need to be able to write out cache and other files in a location my user has write access. I replace “workstation_hostname” for the node name depending on the host. For example, doppelbock is the hostname and node name of my Macbook Air.
I use the following run list on my workstations.
Upload Chef Repository
Now that all the victims are assembled, it is time to upload the Chef repository, copy the configuration file and validation certificate and run Chef.
Then I simply run ‘chef-client’ as my normal user and my laptop is configured. It does take some time because several of the DMGs are large, and homebrew compiles from source. All in all, it took about 1 hour to do the initial run of Chef on my Macbook Air 13” when I first set it up.