As you might know, I’m a bit of a fan of Munki and Puppet for managing the Macs I look after. Around a year ago, I really wanted to be able to automate my own setup across my own Macs the same way. I was forever finding that the particular git repository or app wasn’t on the Mac I was working on. Then there came the time when I wanted to do a clean install - that was easily a day down the drain there! ...

Many organisations need to bind their Macs to AD. There are quite a few options however, that need to be changed. It’s quite a straightforward process to automate this with Munki, although you do have a few options to consider. First off, how are you going to deliver the actual bind script? You have the option of a no-pkg pkginfo file, with the script directly in the pkginfo plist. Whilst the script is now easily editable in the pkginfo, it does pose a security issue in that the catalog is kept in /Library/Managed Installs/catalogs, which will contain your script. Along with your AD bind account’s details. Whoops! Prepare the Bind! My preferred way of deploying the bind script is with a payload-free package made with The Luggage. My bind script is nothing special, it was originally borrowed from DeployStudio. You can find the script and the Makefile on my macscripts repo. If you need a primer on The Luggage, I wrote about it in August 2013. You just need to edit the variables at the top of the script to suit your environment and build the package. So you’ve got the machine bound to AD. Great. What happens if the binding doesn’t go to plan? Or a well meaning tech manages to unbind the machine, but can’t manage to re-bind it? Or even worse, the user manages to unbind it themselves? We need to make Munki check that the Mac is still bound to AD. ...

We’ve already got a fairly decent plugin - it shows us how many machines we have that aren’t able to run 10.9. However, quite a few people won’t have any machines that fall into this category, and just want to know when one manages to sneak under the radar, so let’s hide the plugin if we don’t need to see it. Previously on Lost In the first part, you might remember that we had to tell Sal how much space our plugin needed. Well, we’re going to cover the eventuality of it not needing any space. First off, mavcompatibility.py. ...

And now, time for the shocking second part of our series on how to write plugins for Sal. In the previous part, we got our basic widget working. This time, we’re going to link it up so we can get lists of those pesky non-10.9 compatible Macs when we click on the button. It’s a list, Jim When displaying the list of machines, Sal will call the filter_machines function in your plugin. I’m sure you don’t want to disappoint, so here’s that function added on to the plugin we wrote last time. ...

Writing a plugin for Sal isn’t hard. In fact, I’d go so far as to say it’s easy. We’re going to make a plugin that will flag up any machines that aren’t compatible with Mavericks, by using Tim Sutton’s script. To start off with, you’re going to need to get that script onto your Macs at /usr/local/munki/conditions. I’d personally use Puppet for that, but if you’re a purely Munki shop, you’ll be using a package. And handily, I’ve made one. ...

At pebble.it, we always wanted to have an easy dashboard to look at to visualise the information we could collect from Puppet and Munki. We tried a few options, but didn’t like any of them, so we made our own. Say hi to Sal - the Munki Puppet. It’s a multi-tenanted reporting solution for Munki and optionally, Facter. You can find all of the details over on GitHub, including installation instructions and a package to send out to your clients. ...

Have you ever wished you didn’t have to take calls from your users to unlock various parts of System Preferences? That standard users could unlock Energy Saver or Date and Time preferences? Well dear reader, this is the article for you. If, for some strange reason you can’t be bothered to read this overly long article (I do love to procrastinate), you can head over to my macscripts repo on GitHub for the scripts and resulting pkginfo files I’ve made for this. ...

I just pushed up version 0.5 of Crypt - the release details are over at GitHub. This is the last version that will be compatible with the current version of Crypt-Server - which has also been updated to be compatible with Django 1.5. This is fully tested (in my environment!) with Mavericks, so go forth and escrow FileVault keys.

A couple of weeks ago, I had a chat with Ed Marczak for the AFP548 Podcast. We discussed packaging, community and convincing clients that they shouldn’t stab themselves in the leg. Go listen.

Sometimes we are asked by clients to set a default desktop picture for new users - sometimes we are deleting home directories on logout, so need to warn the users, other times the client just wants their corporate wallpaper to be the default. If you are lazy and don’t want to read this post then the script that changes the desktop picture is on GitHub. Whatever, here’s what we used to do: ...