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\ Instant.app/Contents/Info SUFeedURL
https://www.shinywhitebox.com/store/appcast.php?p=14
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.