Update: This post is old and outdated. I’ll have another post in 2015 about workstation management with Chef.
This post is a rewrite of the original, and now has an accompanying Chef Repository where all the code I talk about is available.
The current incarnation of this repository lives in the more general private Chef Repository I use for my home network, since I manage more than just workstations with Chef. I have used the main recipe (workstation::default) with great success on several Mac OS X systems: Macbook Pro, iMac, and Macbook Air running various versions between 10.6 and 10.8. I recently used it to configure a replacement Macbook Pro for work, and then again after upgrading to Mountain Lion.
Also known as “bootstrapping Chef”, the system needs to be set up to run Chef.
- Opscode Hosted Chef is my Chef Server
- I run everything as a non-privileged user
I use the Opscode full-stack installer on all my systems, including OS X, because it includes everything Chef needs, including Ruby.
Whether you’re unpacking a brand new Mac, or using an existing system, use this command:
Symbolic links are created for Chef’s binaries in
Mountain Lion Note: I did this on Lion before upgrading to Mountain Lion. Apple removed X11 from Mountain Lion, and the installer opens an xterm, so I don’t know how/if this works the same on a brand new Mountain Lion system.
Next, create a configuration file for the Chef Server, and copy the validation key into place. If this is a new Mac, you’ll need to get your validation key copied to the system.
1 2 3
I am using Opscode Hosted Chef, and this is my
The path options are so Chef writes its files in a location my user
has write access.
1 2 3 4 5 6 7
I have made the repository available on GitHub.
Normally, systems that are configured with Chef wouldn’t have the Chef Repository on them. For the purpose of this post, clone the repository to the local system. Presumably, one might do further development to it.
Before we upload it and run Chef, let’s explore what is included.
The repository contains two data bags with a single item each. One is for the local user, the other is for the workstation setup.
The USERNAME should be changed to the local user that is being configured on the workstation. To ensure that the correct value is used, run the following and use the value returned.
Thus, I use
jtimberman for my systems.
The user data bag item is used in two cookbooks, users and workstation. This is described below under Cookbooks.
The workstation data bag item contains various data about the workstation itself, software that should be installed, property list files dropped off, etc. The JSON file in the repository contains several examples. Modify this as required for your own system.
There are three roles.
This is the role I apply on all my systems, not just workstations. Aside from the contents of the role file in the repository, I also set attributes across my systems for a variety of other purposes like postfix, munin, ntp and so forth. For the workstation setup purposes, it contains the attributes I use for installing Ruby under Rbenv, and the gems I want available on all my systems that aren’t project specific (I use bundler for those).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Edit the list of gems as required for your preferences. The ones included in the role are what I find useful or required for my day to day work on Chef and Chef-related projects (like opscode-cookbooks).
The base role does not have a run list. It is included instead by OS specific roles that I apply to Ubuntu or OS X systems respectively. As this is a post for my OS X workstations, let’s look at that role next.
mac_os_x role is applied on all my OS X systems. Of note, it
includes the base role, and the homebrew recipe. The homebrew cookbook
includes a package resource provider that replaces the Chef default
for OS X, macports, with homebrew.
1 2 3 4 5 6 7
This role probably doesn’t need to be edited.
This is the role of interest, which contains the workstation specific run list and attributes.
The role itself is very long, so I won’t include it here. You can view it in the repository.
Do note that
recipe[mac_os_x::firewall] requires root access, and
will prompt for the sudo password (and pause the whole run until entered).
mac_os_x settings as required for your own preferences.
Edit other attributes as required for software you wish to use or
The repository uses a number of cookbooks, most of which are published on the Chef Community site as well. I’m not going to describe all the cookbooks in this post, just the ones that are most relevant for workstation setup.
On OS X,
build-essential will install
Kenneth Reitz’s OS X GCC installer
– XCode is not required. Of course, you may have other reasons why
you want to have XCode, and that is outside the scope of this
repository. If so, remove the build-essential recipe from the roles.
The homebrew cookbook uses Homebrew as the default package provider on OS X. The default recipe will install Homebrew, Git with homebrew, and ensure that the formulae are updated.
IMPORTANT NOTE Homebrew recently “broke”
(in my opinion) the
brew info. I manually patched my local copy of Library/Homebrew/cmd/info.rb after discovering
this halfway through setup of my new system.
The git cookbook installs git using
the Git OS X installer,
and the git binary will be
/usr/bin/git. This is redundant with git
installed from homebrew, but at some point I had issues and I don’t
remember if they were resolved. If you wish to use git from homebrew,
The ruby_build and rbenv cookbooks are by Fletcher Nichol, and are
quite excellent for installing per-user Rubies of a specific version,
and gems using the
rbenv_gem LWRP. The
base role has the
attributes set up for how I like this, YMMV.
I use an older, modified version of Opscode’s
users cookbook, pre
users_manage LWRP. The recipe adds capability for distributing
arbitrary files, such as dotfiles for users. To use this, create a
“files” section of the users data bag item. The USERNAME.json item
includes examples of this. Each file needs to be copied to
cookbooks/users/files/default/USERNAME/ as the source file name used
in the data bag item.
The workstation cookbook has a recipe that does all the work of reading the workstation data bag item and setting up the system per the data available.
The README.md in the cookbook contains detailed information about its use, and the data bag item already has the structure to get started.
plists array is used, then each plist file should be copied
My mac_os_x cookbook has two LWRPs that I use elsewhere in this repository:
mac_os_x_plist– drops off property list (plist) files in
mac_os_x_userdefaults– writes OS X user settings with the
The plist files used by
mac_os_x_plist should be added in the
files/default directory of the cookbook where the resource is used
in a recipe.
mac_os_x::settings recipe will read the
node['mac_os_x']['settings'] attribute for user defaults to apply.
mac_os_x cookbook’s README for more information.
The following are application specific cookbooks that I use:
The iTerm2 cookbook will set up iTerm 2 and optionally add tmux integration. I wrote about this awhile back.
We use Vagrant extensively at Opscode, which requires VirtualBox. This recipe will install it per the attributes set in the workstation role.
Install GitHub for Mac with the ghmac cookbook. Local setup for it is on your own.
I have 1password in here because I used to install it from the zip file, but I may remove this at some point since I install it from the Mac App Store now.
Note that the versions of these apps may be old, but they have Sparkle.framework or can otherwise update themselves to newer versions easily. Click the buttons, it’s cool.
I don’t have a recipe for managing application installation through the Mac App Store. It’s really not that hard to fire up the app and click the “Install” button next to the apps you want though. Seriously, it would take longer to figure out a command-line or API way to do this, if it’s even possible. Just click the button.
The other cookbooks in the repository are there as dependencies and may or may not be used specifically.
Upload Repository, Run Chef
Once it is cloned, all the components need to be uploaded to the Chef
Server with Knife. As that is installed with Chef, it will be
available. The knife config file and user key do need to be copied to
.chef in the chef-repo. If necessary, download them from Opscode
Hosted Chef (or your Chef Server).
1 2 3 4
Make your changes to the data bags and roles. I’ll wait here.
Then, upload everything.
1 2 3 4 5 6
Finally, run Chef!
1 2 3 4 5 6
These aren’t necessarily questions anyone asked, but a more preemptive FAQ :).
This seems heavyweight, why all this effort?
As a sysadmin, I want to do something once and automate it afterward. That includes all the stuff I need to do to have a useful, usable work environment. This means that when I get a new computer, or have to wipe and reinstall (rare, but happens), I can get back to a productive environment very quickly.
I have three OS X systems I use regularly (work laptop, personal laptop, family iMac). Having them in a Chef Server gives me access to information about these systems easily with knife.
Also, this post is focused specifically on OS X, however this setup works pretty much as is on Linux. I simply don’t use Linux as a desktop OS, but I do have “workstation-like” systems that I SSH into, and this is generally fine for those.
Why Chef Server? Why not Chef Solo?
Honestly, I don’t actually use Chef Solo except as a way to setup a Chef Server. Since I use Chef Client/Chef Server so often, it is second nature for me to do it. You’re free to adapt this to work with Solo.
Will you support Windows with this repository?
No. I don’t use Windows as a workstation/desktop anymore.
It might just work on Windows though. It did once, but I haven’t tried in a few months.
I want to make this moar awesome, will you merge my pull request?
Thank you. I appreciate that you want to help me, or other members of the community. However I consider this pretty much “feature complete”, as it meets all my needs, and I don’t plan to merge any pull requests.
For individual cookbooks, they have their own repositories linked from their pages on the Chef Community site.
Why do you have redundancy or inconsistent use?
Such as plist file location, dmg installation, etc.
Because: Reasons. This codebase has been developed over ~2 years. It works for me.
How can I get help?
You can email me. However, as I said before this is a free time project, so I might not respond right away. If you’re an Opscode Hosted or Private Chef customer, please contact Opscode support. Finally, community based support is available through our community resources.
If this is a topic of interest to you, I’d also like to point out a few similar projects that may be interesting. They have inspired me and things I have implemented in my own setup, so thank you Ben, Corey and Matthew and Brian at Pivotal!