I’m pleased to announce that Imagr 1.1.1 is out! Why am I so happy? This is the first release that’s made up nearly all of community contributions. So many thanks to everyone who has helped out with code, documentation and filing bugs. And if you’re going to be at MacDevOps:YVR in a few weeks, we’ll be taking a look at how to use some of these new features. Find out more about this release over on GitHub.

For one reason or another, I may need to stay out of the US for a bit this year, but that doesn’t mean I’m not going to be giving any talks - no siree! In June, I’m going to be heading over to Vancouver for MacDevOps:YVR where I will be leading a workshop that will take you through getting started with Imagr, and I will also be sitting on a panel that is focusing on configuration management. ...

I’ve been wanting to write this post ever since Rich Trouton wrote a similar one after MacADUK, but I finally got the kick to finally write it after I saw this job advert. That’s right, they want an experienced Mac admin who is willing to work for around what McDonald’s pay a trainee manager. If you are indeed starting out in your career supporting OS X, know that you don’t have to settle for appalling renumeration like that! Ok, rant mode over. Here is the post I wish I’d read before I started doing all this 8 years ago. ...

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 ...