Anthony’s Mac Labs Blog

Posted 2014 November 27

AutoPkg Itself

The rest of this article assumes you have a basic understanding of AutoPkg and how its recipes work. If you need an introduction (or a refresher), there have been excellent presentations at two recent Mac Admin conferences by the primary project contributors Greg Neagle and Tim Sutton (MacAdmins Conference at PSU link, MacSysAdmin link)—I recommend watching both, but note that there is lots of Casper-specific stuff in the MacSysAdmin session. You can also take advantage of the new GUI tool AutoPkgr from the Linde Group to get set up quickly, even if you do not end up using it to manage your AutoPkg setup.

The Trick That Makes This Work

Both DeployStudio workflows and AutoDMG templates store the path to installation payload items but do not make other checks like file size or checksums. As long as the filename and location within the file system remains the same, you can have AutoPkg update the payload without having to alter your workflow or template.

AutoDMG

With AutoDMG, it can be very simple. If an AutoPkg recipe of any kind generates something that AutoDMG can use (i.e. dmg with pkg installer, dmg with self-contained app, pkg installer, self-contained app), you can have your AutoDMG template point to the place in the AutoPkg cache where the recipe stores that item. The only place where you might get tripped up is if the item in question has a filename that varies with the version number. Check to see if a recipe override can allow you to use a more generic name or if processing it one more step than otherwise necessary (e.g., from something contained in a dmg to a standalone pkg installer) provides the same ability. If that still doesn't work, you can use one of the DeployStudio recipes (more on this in a moment) to generate a generically-named package installer.

For example, here's the Additional Packages portion of an AutoDMG template that uses installers both from a static repository and the AutoPkg cache:

<key>AdditionalPackages</key>
    <array>
        <string>/path/to/Installers/clearReg.pkg</string>
        <string>/path/to/Installers/create_tech.pkg</string>
        <string>/path/to/AutoPkg/Cache/
com.github.jazzace.pkg.EpsonPrinterDrivers/EpsonPrinterDrivers.pkg</string>
        <string>/path/to/AutoPkg/Cache/
com.github.hansen-m.download.Fetch/downloads/Fetch.dmg</string>
    </array>

Note: Paths should all be on one line; they are broken up here due to space considerations.

The first two packages in this example are manually created; they skip registration on first boot and add an admin account (via CreateUserPkg). They will only be updated manually, so they can be stored in any locally-accessible location I choose (I have an Installers folder for this). The next package is generated by my recipe to extract the EpsonPrinterDriver installer from the dmg (downloaded via a parent recipe from Nate Felton) and give it a static name. (The dmg that Apple provides has the version number appended, hence the need for an extra step in order to provide a static path for the AutoDMG template.) The final one is an example of a common drag-and-drop app where the name of the dmg does not vary from version to version.

So, in summary, I determine which recipes I need to use in order to get a static path, I run those recipes, I add that software to my AutoDMG template from the AutoPkg cache, and then I ensure that AutoPkg has run (or is manually run) shortly before I build a new image.

DeployStudio

DeployStudio requires a little more discipline. The payload from AutoPkg must be placed in a specific folder in the DeployStudio repository. This has led me to create recipes with a new extension, .ds, whose sole purpose is to copy a package generated (or retrieved) by a parent recipe into the Packages folder of my DeployStudio recipe. I've included a template in my AutoPkg recipes repo that will let you create the recipes that apply to your situation. In most cases, the parent recipe will be a .pkg.recipe (which you may have to create if only a .download.recipe exists). Just as with AutoDMG, once you have the recipes you need, run them once to populate your DeployStudio repository and then edit your workflows and/or package groups to use those names.

While the template is fairly well documented, let me highlight a few important details. The DS_NAME input variable is what your package will be called, regardless of version (this is how I assure that the package will end up with a predictable name). I have tried to minimize unnecessary copying by using the conditional processor StopProcessingIf. The only trick with StopProcessingIf in this template is that you need to determine which flag tells you whether or not a new version was found in the parent recipe. In general, if the package was extracted, the flag to check will be download_changed; if the package was created (e.g., from an app bundle), the flag will be new_package_request. When the package is updated, the items get copied to /Volumes/DSServer/Users/Shared/Deploy/Packages, but since your personal repository is probably not located there, you'll want to set up a recipe override.

As a side note, DeployStudio can also copy files in a workflow, so you could use similar techniques to create your own family of recipes (say, .dsfiles.recipe). I'm not sure anyone will, but it is a testament to the flexibility of the tool that this is completely possible with limited technical skill.

Update Completed

So no matter which tools you are using — Munki, Casper, AutoDMG, DeployStudio — there's a way to leverage AutoPkg to keep your software updated without all the manual work to which you have become accustomed.

Updated 2014-12-01 (small correction, re: AutoPkg presentations). Originally posted on the University of Calgary Integrated Arts Media Labs web site.