As part of some recent work, I needed to build a deployable installer package for an application named Zscaler. This application does not use an installer package, nor can it be installed as a drag-and-drop app. Instead, it uses a third party installer application to install.
This is exactly the kind of situation where I want to write an AutoPkg recipe to handle building a deployable installer package for me. As part of that, I had two bits of good news:
- There was a publicly available download URL for the Zscaler installer app.
- Zscaler has instructions for installing from the command line, so I could wrap up the installer application inside an installer application and use a postinstall script to run the installation process.
I had one bit of bad news:
The installer process included options for adding things like the Zscaler cloud instance which the app should talk to following the installation as well as various other options which probably shouldn’t be hardcoded into an Autopkg recipe. I especially shouldn’t be hardcoding my own organization’s credentials into a recipe which I was planning to share with other folks.
Normally, sensitive information is something I want to only have in an AutoPkg recipe override. Recipe overrides are locally-stored files that allow you to change certain input variables in AutoPkg recipes. Since the recipe overrides are stored locally on the Mac which is running AutoPkg and not shared with any other resources, the sensitive information is only made available to the AutoPkg installation running on that specific Mac. I’ve used this approach previously for the following:
Sensitive URLs: https://derflounder.wordpress.com/2017/06/12/autopkg-recipes-for-apple-enterprise-connect/
Signing AutoPkg-generated installer packages: https://derflounder.wordpress.com/2017/11/10/adding-installer-package-code-signing-to-autopkg-workflows/
This time though, I didn’t see a way to pass an AutoPkg recipe override’s variables to a postinstall script. I did have one idea though, which was using AutoPkg’s FileCreator processor to create a customized postinstall script. I had previously used the FileCreator processor in other AutoPkg recipes to create postinstall scripts, but those scripts were self-contained and didn’t use variables from the AutoPkg recipe.
That said, you never know what AutoPkg can do until you try it and sure enough the FileCreator processor was able to pass recipe variables as part of creating a file. For more details, please see below the jump.
I was able to leverage the ability to pass variables to create this script:
I then created a recipe override and added the following demo values from the Zscaler command line options page:
- cloudName: zscalertwo.net
- deviceToken: 123456789
- policyToken: 987654321
- userDomain: safemarch.com
The installer package postinstall script generated by this recipe override had the following contents:
In turn, this meant that only the Zscaler command-line options with actual values were run as part of the postinstall script:
Being able to pass variables this way means that the AutoPkg Zscaler .pkg recipe can be used by anyone. Whoever needs to plug in custom variables can do so as part of a recipe override, which allows them to keep their organization-specific information safe while still leveraging AutoPkg’s ability to automatically build installers for deployment.
This technique also has wider applications for anyone who needs to build custom postinstall scripts as part of an AutoPkg recipe because it means that customizable postinstall scripts can be generated on a per-override basis. For example, if you needed to support packaging for multiple organizations, it’s possible to have one core .pkg recipe along with a FileCreator-generated script which is flexible enough to accommodate whatever variables a particular override provides.
Going back to the example of Zscaler, if I needed to support three different organizations, all I would need is the one Zscaler .pkg recipe and three overrides. The overrides would have the different organization’s individual settings and running the overrides would result in three installers with organization-specific settings in the individual installer’s postinstall script.
For folks wanting to take a look at examples, I’ve posted .download, .pkg and .jss recipes for Zscaler to GitHub at the following locations:
https://github.com/autopkg/rtrouton-recipes/tree/master/Zscaler
https://github.com/autopkg/rtrouton-recipes/blob/master/JSS/Zscaler.jss.recipe