A massive thanks to everyone who came to my talk today, and thanks to everyone who helped out with the Q&A at the end. All of the code I used in the talk is up on GitHub and here are the slides. Hopefully the video will convey how much fun it actually was - it could have been a disaster, so I’m hugely grateful to everyone who contributed to the discussion at the end.
Thanks for everyone that came to my talk today, it was fun to finally show off what I’ve been working on for the last year or so. I’m sure the video will be up soon, but in the meantime, here are the slides from the talk.
Over the past few weeks, I’ve had the same conversation over and over: people telling me that once they get started using Munki, their next step will be to start using AutoPkg. I gave each person the same response: “you’re doing it wrong”. AutoPkg a has a reputation of being difficult to use. This is totally unjustfied. You don’t need to be using Munki for it to be useful, you don’t need to set it up to run automatically via Jenkins or a LaunchDaemon. If you need to get software into a package, AutoPkg is the easiest way. ...
Setting up everything you need for Sal can be difficult, especially if you only have an OS X server available. Thankfully, Sal is built on top of a very common Python framework, Django. And even more thankfully, you can run Django on a whole host of PaaS providers, including Heroku. Heroku has a very generous free tier that will easily handle a small Sal installation, so let’s get started. Heroku toolbelt If you’ve never used Heroku before, you’re going to need to head over to their site and sign up for a free account. Whilst you’re there, you’re also going to need to install their toolbelt. Grab the package and follow their instructions for linking it to your account. ...
There are some packages that can’t be deployed to an unbooted OS, such as when building an image with AutoDMG. If you are using Greg Neagle’s createOSXinstallPkg, the OS X installer environment doesn’t have everything a full OS X install has. For times like this, you need to install the packages at first boot. For a long time, I’ve used Rich Trouton’s First Boot Package Install, however I found myself repeating things quite a bit and having a folder full of first boot packages. ...
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. ...