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

Last week, I led a lab in which participants got hands on with Imagr. I will hopefully be able to distribute the materials I used (the disk image is nearly 2GB, so I need to find a way of it not bankrupting me!), but in the meantime, here are the slides. Thanks to everyone who attended, I hope you had as much fun as I did.

Sometimes it is useful to know whether a Munki client is on your corporate network - you might have a package or script that will only work when able to access an internal resource, or you might just want statistics on which users are accessing your internal infrastructure and external infrastructure. ...

It’s the time of year where we start to think about upgrading our machines to the latest version of OS X. There are several ways of doing this, but assuming your users are unable to perform the upgrade themselves via the App Store (if they’re running as a standard user or your policies prohibit the use of the App Store), you might be wondering how you can use your management tool to get your machines upgraded and make sure they stay enrolled in your management tool. We’re fortunate that we have a standard packaging format on OS X that virtually all management tools can install, so this is the most universal way of distributing software. Greg Neagle wrote createOSXinstallPkg a few years ago that has several nice features for mac admins: It wraps up an OS X Installer into a standard package. It allows you to add in additional packages - perhaps you want to make sure your admin user is installed or make sure that a version of Munki that is compatible with the new OS is installed. ...

I’ve been asked a few times over the last few weeks about how you can have multiple services (for example, Munki and Sal) running on the same port on the same server - how we used to do Virtual Hosting when we ran our apps on the host OS. My usual four word answer has been ‘use a proxy container’. How you actually do that has been undocumented - this post hopes to recitfy that. ...

I’m very happy to announce that I will be speaking at the first Mac Admin & Developer Conference UK, held in our very own London on February 9th and 10th, 2016. In addition to some fantastic speakers (I have no idea how they let me in), it’s being sponsored by London Apple Admins (who will be meeting next in early September - we are looking for people who would like to give a short 15-20 minute presentation - get in touch if you’re interested).