Have you heard of Docker, but think it all sounds a bit mystical and exotic? Then this is the post for you! Before we begin, you’re going to need a machine (or a VM, either on your machine or on a server) with Ubuntu 14.04 LTS installed on it. You can install Docker on many other operating systems, but I use Ubuntu, so we’re using that. Your Ubuntu box will also need a real IP address – if you are using VMware Fusion, this will be a Bridged Network Adapter – adjust the terminology if you’re using a different virtualization tool. You don’t need to worry about giving your machine a static IP unless you want to – Macs will NetBoot just fine when they’re on the same subnet.
Last time we saw our heroes, there was the unfuffilled promise of making small NetInstall sets. Now is the time to deliver on that promise. We’re going to make a small NetInstall that will open up Terminal.app.
If you’ve not read the previous post (and have got AutoNBI), go and do it now. I’ll wait. All done?
Another day, another tool made by Mr Bruienne! A while back, Pepijn released AutoNBI – a tool for automating the creation of NetInstall sets. At the time, it was filled away in the “this is cool, but isn’t this what System Image Utility does?” section. Then I saw his NetInstall running at MacTech (are you seeing a theme here?). It had this really simple DeployStudio like imagaing app – it was really cool. And suddently it made sense why you can replace the
Packages directory with AutoNBI – a NetInstall is a really stripped down OS X environment, so it it much easier to distribute and use – we’re looking at around 1.8GB for my current NetInstall vs 5-6GB for a normal NetBoot.
This time we’ll take a look at how to use AutoNBI to make a standard NetInstall – in a future post we’ll look at some of the more cool things you can do with AutoNBI.
Ok, stop talking, let’s do this.
We’re going to need AutoNBI to start off with. Open up your Terminal and:
The current development version has some new features in it that we’re going to use, so we’re going to switch to it:
Prepare the build!
We’re ready to go (assuming you’ve got an OS X installer – you do, right?). Still in your terminal:
What did we just do? The
-s option is simply pointing at our Install OS X Yosemite.app – if you have it somewhere else, point AutoNBI there.
-d is our destination directory and
-n is the name of our NetInstall.
-e is telling AutoNBI to make the NetInstall enabled.
So the next time there’s a new OS X Installer, you can have an updated NetInstall in seconds, not minutes.
Over the past few months, I’ve been trying to take small pieces of our workflow and see if we can expand on the number of people able to manage it. We’ve got AutoPkg populating our Munki repositories without any manual intervention, but we still need to edit pkgsinfo files to move items through development to testing to production catalogs. Sure, there are existing tools like MunkiWebAdmin or MunkiAdmin, but they either still require knowledge of how Munki works or full access to the repository via a file share of some sort. And we obviously already have a tool for assigning software to machines in Sal+ – we needed something that can speed this incredibly common task.
Then I cast my mind back to a conversation I had with Pepijn Bruienne at PSU last year about his workflow using Trello to promote items in his Munki repository. So, after pestering him for some information, I devised a workflow that matched how we worked.
“So how does it work”, I hear you cry
We have five lists on our “Munki Package Management” Trello board. Essentially when the script runs, it inspects the items in our Munki catalog and if they’re not already in the Trello board, it adds them to the correct list (we ignore anything that’s already in production. All promotions to production are done using this tool now).
We also have lists called “To Development”, “To Testing” and “To Production”. Moving items into these lists will be caught by the script next time it runs, and moved to the appropriate catalog.
When items finally make it to Production, we add them to a dated Production list. This allows us to have a full history of when things are added to Production and who has moved it through each stage. We’re also big users of Slack, so we hooked up it’s Tello integration to post a message to our notficiations channel to let our team know when items are added into Munki.
A while back, Nate Walck wrote scriptRunner. It’s a tool that can run a script either every time a user logs in or just the one time. It has served the test of time, but last year Joe Chilcote released Outset. It has all of the functionality of scriptRunner, but it can also install packages at the Mac’s first boot, and run scripts as root at either the first boot or every boot. This comes into it’s own when you’re trying to do things like skipping the iCloud screens on 10.10 using Rich Trouton’s script – this script needs to run after every OS update, so it makes sense to run this every time the Mac boots.
If you’ve been using scriptRunner and want to move to Outset, you have two options:
- Just move your scripts into the appropriate Outset directories and hope your users don’t mind the ‘once’ scripts running a second time.
- Or, you could pre-populate Outset’s ‘once’ plist so it won’t try to run a script previously run by scriptRunner again.
The first option isn’t acceptable to me, so I wrote a script that will populate Outset’s plist. It’s up on my Github. One caveat is that Outset requires that your scripts end
.py. scriptRunner didn’t care about this. When you’re moving your scripts into the Outset directory, you will need to ensure your scripts have the correct extension. This script will read the first line and try to work out what kind of script it is if the file doesn’t have the right extension – if it can’t work it out, it will append
.sh to the filename.
scriptRunner had a few options you could configure. The first is where your actual scripts live – you will need to edit line 8 of the script to where you put your scriptRunner scripts. Secondly, you might have changed the name of the plist scriptRunner uses – edit line 11 if you did this.
Now all that remains is to put this script into
/usr/local/outset/login-once. A Luggage Makefile that will make a package that will do this is included in the repository.
I’ve assumed that you can move your scripts into the new Outset directories using your configuration management tool (Munki, Puppet, Capser, whatever), but if you need a tool that can do this for you (with the previously stated caveat about the file extensions of the scripts), you’ll find a script that can be dropped into Outset’s firstboot directory.