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

In the previous two parts, we went over how to get a basic Puppet Server up and running in Docker and how to deploy your modules using r10k. This time we’ll assign some configuration to our nodes using Hiera. For a full explanation of what Hiera is, see the Puppetlabs documentation, but essentially, you are using a series of directories and files that are named in a particular way, and then specifying which is the most speccific to your node. ...

As previously mentioned, Sal now has an API. You might be wondering what you can do with this wondrous API. This is a simple example of using it to automate building packages to enrol Macs into Sal. The basic workflow of this script is: Use the API to get a list of all Machine Groups in Sal - this will return JSON (a markup language that is easily parsable with languages like Python) Download the Sal postflight scripts Download the latest Facter installer For each machine group, build a package that will install all of the packages and then set the correct Sal preferences. You can find the script in this Gist. I’m not going to go through the script line by line, but we’ll cover how to configure it. ...

I’ve been wanting to get stuck in with a simple Swift project for a while, but couldn’t think of anything suitable for a first project (Imagr was originally going to be that project, but I don’t think it would ever have been made if I chose Swift), until I saw Dr Graham R Pugh’s Do Not Disturb application. I thought it was an excellent idea that could be made even better by being a manu bar app. ...

As some of you may know, yesterday was my last day at pebble.it. Since I announced I was leaving, I’ve been getting asked this pretty regularly, so I thought I’d answer it here. My new job uses Munki extensively, and I expect to be using Sal there. As such, development of Sal will continue. I no longer have commit access to the Sal Software organisation, so I’ve forked the project and have set up Sal Open Source as an organisation on GitHub - hopefully this will be the last time anything needs to change. I’ll be moving the preference domain in version 0.4.0 of the client side scripts to com.github.salopensource.sal - once again, this should be the last time things need to change. ...