There are many ways of managing configuration profiles on OS X - you can use MDM, Munki or any one of the other many great tools. My preferred method however is using Puppet. By using Puppet, I get access to it’s templating features, and I can let others in my team adjust exposed settings through Hiera. This post will walk you through the development of a a simple Puppet module and how to test it on an OS X virtual machine. ...

First off, thanks for coming (if you did indeed come - if you didn’t, you can go away). All of the code I used in my talk is up on Github, and you can grab the slides as well if you feel so inclined.

If you are just starting with this series, it is highly recommended you start with Part 1. The last part of this series is making it work in a Docker container. This is not a Docker tutorial - please head over to Docker’s getting started pages to get yourself set up with the Docker Toolbox. All done? Let’s crack on with first creating our Dockerfile. ...

It’s been a lot of work, but I’m pleased to say that Imagr has grown up and as I now consider it to have everything I originally intended it to have, I’m calling this a 1.0.0 release. You can get hold of it on GitHub, and if you want to get started with it, there is a load of information on the Wiki.

If you are just starting with this series, it is highly recommended you start with Part 1. Last time around we got our app returning something useful to Imagr. This time around we’ll make our second endpoint - the one that will create the machine’s individual Munki manifest on the server. Our fictional setup is making use of the default manifests Munki looks for - eventually it will request the machine’s serial number if no client identifier is set. Our manifest will contain three other included manifests: One for the site where the machine is located. One for the machine’s build. A general one for all machines (the site default). ...

If you are just starting with this series, it is highly recommended you start with Part 1. Last time we built a basic app that will ask for a username and password to access it. Now we’re going to add in some other data that will eventually be sent by Imagr to let our script be dynamically generated. ...

Some may wonder why you would go to the trouble of dynamically generating first boot scripts. I mean, how many can you need? Let’s say you have ten sites, each with five builds - that fifty first boot scripts to maintain already. It’s entirely possible that they’re all the same, so you could use Imagr’s ability to use a script from a central URL. But you also may need to make slight tweaks depending on what type of machine it is and where it is located. Over the next few posts, we are going to build an app using the Flask framework that will: Read in headers sent by Imagr to return a dynamically generated first boot script Create a Munki manifest for the Mac Wrap up the application into a Docker image so it can be easily deployed ...

It’s been 246 days and 290 commits since I started working on Imagr, and today is it’s 0.0.5 release. It’s been a while since I blogged about Imagr, so in case you have forgotten that I make it, go and take a look!

In my environment, we have software that needs to be deployed at the same time across all of our sites. Previously, this meant someone had to pull their computer out on a Sunday and promote the item from the testing catalog to the production catalog. Which is fine, but to be honest I’d rather be doing something else on a Sunday! So I started looking at how to automate this process. First I looked at force_install_after_date, but this install the item at a specified time in the client’s local time - I needed this to be installed at the same time globally. Next was Munki’s date condition and using installable_conditon in the item’s pkgsinfo file similarly to how we shard our updates - but despite the time object looking like it’s UTC, it’s still just the client’s local time. ...

A few months ago at PSU, Tom Burgin and Jeremy Baker spoke about using Authorization Plugins. I sat there watching this talk thinking about how cool it would be to use this method for Crypt. And then I had a go at it. And it was hard. So I put it to one side. Then in November, I met up with Tom at MacTech. He very kindly donated a few hours of his time to get me started with re-writing Crypt as an authorization plugin in Swift. ...