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.
Head over to the releases page on AutoPkg’s GitHub repository and download the latest version (0.3.0 at the time of writing). It’s an Apple package, so double click it and get it installed. If you have Gate Keeper enabled, you’ll need to right-click on the package and choose to install it from there, as it’s not been signed.
AutoPkg is useless without recipes. Fortunately, there are hundreds that have already been made by the community.
We’ll add the set of recipes maintained by AutoPkg’s authors, which contains some of the most common software. Open up a terminal window and enter :
You’ll see AutoPkg downloading and adding the recipes to your Mac.
1 2 3 4 5 6 7 8
Using the thing
Let’s see what recipes we just added. Still in your terminal, enter:
You’ll see a whole load of output like:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
The naming convention in AutoPKG is SoftwareName.output. For for example, to run a recipe that downloads Google Chrome and adds it to Munki, you would use the GoogleChrome.munki recipe, but if you just wanted to download it an make a package, you’d use the GoogleChrome.pkg recipe. It just so happens that making a package of Chrome is exactly what we want to do.
Back into your terminal and enter:
The AutoPkg robot will churn away and you’ll get some output similar to:
1 2 3 4 5 6 7 8 9
And when it’s all finished, you’ll be left with a nice package that you can use anywhere you’d use finely crafted packages – ARD, AutoDMG or even Casper if you’re that way inclined (although Allister Banks has been working on a way of automating importing packages into the JSS – see his recent talk for more on that subject).
Doing it all again
What happens next time you want to build an updated package?
What happens if Google changes the URL AutoPkg uses to download Chrome? Fortunately we’re using the community provided recipes, and if something’s broken they usually get fixed pretty quickly. We just need to tell AutoPkg to update the installed recipes.
And then we’re able to build our package safe in the knowledge that someone else has done all of the hard work for us.
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.
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.
Now we need to get a copy of Sal and configure it. Assuming you keep your code in ~/src:
1 2 3
Now we need to make a copy of sal/example_settings.py
And edit sal/settings.py in your favourite editor to your liking (probably time zone at least).
Heroku uses git for deployment, so we need to commit our changes.
We’re nearly there! Time to create our environment on Heroku
Of course we haven’t pushed Sal to Heroku yet. Let’s fix that.
You’ll see Sal being pushed up to Heroku and Sal’s requirements being installed. A Postgres database will also automatically be created for you. The database will be empty though, so let’s populate it with what we need.
When asked, you certainly do want to create a super user. Use a strong username and password as this is the admin for your Sal application.
One last command to run:
Your Sal installation is ready to use:
As said earlier, the free version does have some limits. The most important with Sal is the number of rows you can have in the free database (10,000), so the more information you collect from each machine (Facter Facts and Munki Conditions), the larger your database is. It’s a measley $9 a month to upgrade your database to 10 million rows, so it’s easy to scale your database. For more information on upgrading your Heroku environment see their documentation.
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.
So, I made my own. The main features of first-boot-pkg are:
- It is designed with scripting and automation in mind, with options able to be configured with a configuration plist or via options on the command line (or a mixture of both)
- It will re-try failed packages a specified number of times (in case of Active Directory not being available, for example)
- Will wait for the network to be available before installing (optional, can be disabled if desired just in case your package is going to let the Mac get onto the network)
If you’re happy with using Git, I’d recommend just making a clone of the repository and doing a
git pull to keep the script updated. If the thought of all those gits and pulls makes you run away, you can download a zip of the project.
This script makes use of Per Olofsson’s LoginLog for displaying the log file whilst the script is running, so massive thanks to him for releasing it.