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

Munki 2.4.0 brought the option to have Munki follow http redirects (my first contribution to Munki). This allowed you to set Munki to follow redirects to either just HTTPS URLs or all urls. This allows you to get quite clever about where your Munki content is hosted. For example, I have one piece of software that is quite large, and needs to be downloaded by many remote workers as soon as it is released. Whilst I could stand up a server infrastructure to cope with the demand, there are cloud providers such as Amazon’s CloudFront that will handle this all much better than I ever could. Of course, this is only available to clients running Munki version 2.4.0 or higher, so I am going to use my configuration management tool of choice (Puppet) to only use this feature on clients that support it, whilst allowing legacy clients to still get the update from the Munki server as they always have done. ...

Sharding is traditionally associated with databases - splitting up your dataset to make it more manageable. When using the term in this instance we are taking about splitting up our computers - there are several reasons you might want to do this. You might want to split them up for similar performance reasons - if you’re deploying large software updates your server might not be able to cope with all your clients pulling it at once. You might want a way to roll changes out to certain groups of machines. Facebook spoke about sharding at macbrained in May 2015, but they weren’t clear on how they use it (edit: they actually first spoke about it at MacSysAdmin). A few people were pretty interested in using this method of rolling out changes to their machines, but it was Victor Vrantchan who came up with a method of deriving a value between one and 100 based on the machines serial number (edit: this was based on Facebook’s and Google’s code. Elliot Jordan also came up with something similar for Casper). Using this condition as a base and a similar Facter Fact I’ve started using the method outlined below to release changes to the macs I look after. ...