There’s been a lot of talk in the Mac admin community recently about AutoPkg (http://autopkg.github.io/autopkg/). This tool, currently being developed by Greg Neagle and Tim Sutton, allows for the use of “recipes” to download and package different software found on the Internet. This ability takes a lot of the work out of locating software, downloading it, and then packaging it, something a Mac admin may do multiple times a week. AutoPkg automates all of that. And, if you are a user of Munki, there are even recipes in AutoPkg that will import directly into Munki and update the catalogs.
As a prerequisite for AutoPKG to work, you need to have the command line version of git installed. If you’ve installed XCode, then you have git. If not, you can get git by downloading either a GUI GitHub tool like this one here, or download the command line version of git here.
Once you have git installed, go ahead and download the AutoPkg installer file from this location. Now that it is downloaded, go ahead and run the AutoPkg installer. This will install the AutoPkg software in the proper locations on the machine. Once completed, fire up Terminal and you can verify the software is properly installed by running the following command:
That will give you the current version installed on the system. Now that AutoPkg is installed, you may want to create a directory in a common location, like the root of the drive or in the /Users/Shared folder, to hold the output from AutoPKG. By default AutoPkg stores it’s output inside the user’s Library folder at ~/Library/AutoPkg/Cache. This location can be changed by adjusting the CACHE_DIR in the preferences. I like to store it at the root of the drive in a folder named Autopkg_Done.
chmod 777 /Autopkg_Done
Now that you have the CACHE_DIR created, you’ll need to tell AutoPkg about it. This is done with the following command:
defaults write com.github.autopkg CACHE_DIR /path/to/cache/dir
So, in our example, the command we’d use is this:
defaults write com.github.autopkg CACHE_DIR /Autopkg_Done
NOTE: AutoPKG stores its preferences in the user’s Preferences folder (~/Library/Preferences/com.github.autopkg.plist). Because of this, any new user on the machine that will need to use AutoPKG will need to have the CACHE_DIR set and will need to download the recipe repositories (more on this in a minute).
With AutoPkg installed, and the CACHE_DIR set, all we have left is to tell it about some recipe repositories. AutoPkg utilizes git repositories that hold recipes for building different packages. Like using a recipe to bake a cake, AutoPkg uses these recipes to build the different files.
As of this writing, there are four repositories that I am aware of. They are:
We need to tell AutoPkg about these repositories. This is accomplished with the following command line:
autopkg repo-add <repoURL>
So for the four repositories above, we would use the following:
autopkg repo-add https://github.com/Jaharmi/autopkg_recipes
autopkg repo-add http://github.com/autopkg/recipes.git
autopkg repo-add https://github.com/hjuutilainen/autopkg-recipes
autopkg repo-add http://github.com/keeleysam/recipes
Now that we have our repositories in AutoPkg, we are free to run one of the recipes. We can see what recipes we have access to with the following:
If all went right, you should see a list of the recipes that your AutoPkg installation knows about. To run one, simply use the following:
autopkg run <recipe>
For example, to run Adobe Flash Player:
autopkg run AdobeFlashPlayer.pkg
That will download the Flash Player and create a PKG file for deployment inside of our CACHE_DIR (/Autopkg_Done in our case). We can navigate through the folders there to find a pristine Flash installer package that we can now deploy to our machines.
There’s plenty more to know about AutoPkg, including how to import directly into Munki during a build. Check out the wiki for more information on Munki integration, or if you want help with installation and config, go here.
Next up, we’ll setup Jenkins, a continuous integration server that will eventually allow us to build packages while we sleep