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.
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
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.