Firstly, thanks if you came to my talk and putting up with me! You can get my slides and code from the GitHub repository.
It seems like Yosemite introduced an undocumented change that requires any packages that are added an OS X installer (e.g. Netinstall or createOSXinstallPkg) be distribution style packages, or you get a nasty failure acompanied by one of the most unhelpful error messages ever.
To fix this, first-boot-pkg now builds distribution style packages.
I’m delighted to say that the first (first meet that isn’t “let’s go to the pub and get drunk”, anyway!) London Apple Admins meetup is happening on the 3rd September at The Red Herring in St Pauls. I’d like to take all of the credit for organising it, but it was down to the hard work of Ben Toms. The theme this time is “this is what I’m working on at the moment”, so I’ll be talking about my new favourite toy, Docker.
If you’ll be in or around London on the 3rd September, please get yourself a ticket (they’re free) and come and have a beer or two whilst listening to some awesome talks by London based Mac Admins.
As a sysadmin, I’m forever testing things. Rather than destroy my own machine, I like to do this in Virtual Machines. My preferred virtualisation solution is VMware Fusion, but unfortunately it’s not very easy to deploy out of the box. You need to do a little bit of work to get it into a package that you can import into Munki, but fortunately the process is well documented on VMware’s site.
The next piece of ‘non standard’ software I need is Homebrew. The installation method listed on their site is to run a terminal command as the current user. The first part of this is obviously fine – Munki has several methods to run scripts (payload free packages, nopkg), but it runs everything as root. Fortunately, as I’m deploying my own machine, I can make some assumptions about where Homebrew will be installed. The first assumption I can make is that there will only be one user on the machine, and the second is that I’m going to be logged in most of the time (as my laptop is encrypted, it’s either off or logged in).
I’m going to utilise a
nopkg pkginfo file to perform the installation. The first part of our script to install Homebrew is to make sure that a user (me!) is logged in. Homebrew doesn’t like being owned by root, so first we need to make sure that there is a user logged in.
1 2 3 4 5 6 7 8
So now we know that there’s a user logged in, and who that user is. Time to install Homebrew as the current user.
1 2 3 4 5 6 7 8
As we’re using a
nopkg with Munki rather than a payload free package, we’ve not left any receipts, so Munki doesn’t know if Homebrew is installed. We’re going to use an installs array to tell Munki what to look for when determining whether Homebrew is installed or not.
1 2 3 4 5 6 7 8 9
You might be crying “but Homebrew needs the Xcode Command Line Tools installed!” – and you’d be 100% correct. You have the option of importing the downloaded package into Munki, but I have adapted Tim Sutton’s script into a
nopkg. To find out what’s installed, I ran fseventer and chose a random file to act as my installs array. I’ve posted the pkginfos for both the Xcode CLI tools and all of the Homebrew installs on Github.
Earlier this year, I professed my love of Boxen – the personal automation solution based on Puppet released by Github. Indeed, it served me well for quite some time, but I began to find myself spending more time fixing Boxen than actually getting things done. As Boxen was designed for internal use at Github, it set some things up how they liked them – which wasn’t necesarily how I liked them. Sysadmins have similar needs to developers, but not exactly the same.
Then I updated Boxen. All of my modules were out of date, so I spent a good couple of hours updating all of them so they worked again. Ugh.
So I started looking at moving to my own solution. One of my major irritations when using Boxen was that it didn’t really handle updating your apps – you got whatever version the module author decided to install and then you had to hope that there was an updatng mechanism built in. I’ve said before that there is no better method of getting software onto your Mac then Munki, so the first decison was straightforward. The rest took a little thought.
The six P’s
My first requirement was that I shouldn’t need to run anything to get my configuration to apply. Boxen requires that you run the
boxen command periodically across each of your Macs to get the configuration applied. This wasn’t always practical. I needed something that would run in the background and keep itself up to date.
As I said before, I really disliked how Boxen installs software. Munki does a much better job, and AutoPkg makes it trivial to make sure you have the latest software version. Being a sysadmin, I need more than simple drag and drop apps and packages though – I make extensive use of Homebrew to install command line tools like Packer, so I needed to come up with a way of installing these with Munki.
However, Munki isn’t the best tool for managing my configuration. I’ve been using Puppet to manage the Macs I look after for nearly three years now, and I wanted to base my system on it as I’ve already done a lot of the work with making OS X specific modules. I also wanted to use the modules made for Boxen as much as possible (some made too many assumptions about where they were running, so couldn’t be re-used.
So to recap:
- Munki for software deployment.
- Puppet must run in the background periodically
- The configuration must update itself – I don’t want to have to sync code across machines.
- Where possible, re-use existing Puppet modules
Over the next few posts, I’ll go over the different parts of this solution, how I put it together and how you might be able to use this.