graham gilbert

Mac administration and assorted nerdity

Managing Munki Catalogs With Trello

| Comments

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.

You can grab the script from’s GitHub account, or if you’re Docker inclined there’s a container that has everything you need.

Migrating scriptRunner to Outset

| Comments

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 .sh, .rb or .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.

Creating Business Units and Groups in Sal Using a CSV

| Comments

Obviously I’m a little biased, but I love Sal. But, it can be a little tedious to get everything set up the first time if you have hundreds of Business Units and Machine Groups. I’ve quietly ignored the problem for a while, but then I saw this tweet pop up in my feed:

What say I Mr Bruienne? Like the man from Del Monte, I say YES!

The plan

We’re going to use a few of the parts that make Django and Docker awesome. We will:

  • Make a custom management command that will read in a CSV
  • The command will make the Business Units and Groups if they don’t exist
  • We’re than going to run it in a temporary Docker container when we’re ready to do the actual import. This is one of the strengths of Docker – we can spin up a linked container that will operate on the main database, but won’t interfere with your container serving the app.

First-boot-pkg Updated for Yosemite

| Comments

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.