In my previous post on iShowU Instant, I provided an overview of the request made of me and the deployment considerations this raised. In this post, I'll look at using AutoPkg to handle a vendor provided .dmg that provides more than one software item.

The .download recipe

Authoring this was fairly routine. The steps I took were:

  • Manually download and install software on a test machine.
  • Determine most appropriate means of checking for updated software.
  • Determine Code Signing Identities.

There are many ways of using AutoPkg to check for updated software (to those who regex, I salute you). A simple and reliable means of doing so is providing an update feed to the SparkleUpdateInfoProvider processor. If the developer has implemented such a feed, the URL can often be obtained from the application Info.plist. To get this here, I ran this command:

> defaults read /Applications/iShowU\ SUFeedURL

Then, we need to determine the Code Signing Identities. The process of doing so differs whether you are dealing with an .app or a .pkg. We need to check both, and the steps for doing so are documented on the AutoPkg wiki.

That should be all the information we need to put together a reliable .download recipe. You can view the production recipe here

The .munki recipe

This required slightly more work. Given that I had never thought about using a .munki recipe to handle multiple items before, I found this quite daunting. After asking for pointers on the Mac Admins Slack, I was reminded that the munkitools recipes do this, and so inspected those for tips.

The key here was the realization that I could define as many Input variables as I liked and could invoke a single processor multiple times. In this case, I defined several Input keys to set some sane defaults for handling the import of the two iShow U Instant items to my Munki repo, then called the MunkiImporter processor on both items. Of note is that I used the additional_makepkginfo_options function to add the 'iShowU Audio Capture' item as an update_for the 'iShowU Instant' item. You can see the production recipe here.

Automate and test, test, test

After testing these recipes locally, I committed and pushed them to my recipe repository. I then moved to my organisational AutoPkg machine. I updated my installed repositories, and as I have Trust Verification enabled, made an override for the .munki recipe. I then added this override to my nightly AutoPkg schedule. The next day, I had the expected items sitting in the testing catalog of my Munki repository, ready for...testing.

In Part 3 of this "series", I'll look at how this application can be licensed using Munki and outset.