Automating AutoPkg and JSSImporter setup

As part of building my autopkg-conductor solution for automating AutoPkg runs, I also wanted to automate the setup of AutoPkg and JSSImporter. My colleague Graham Pugh has written a setup script for his environment, which I was able to adapt and extend for my own needs. For more details, please see below the jump.

Automating AutoPkg runs with autopkg-conductor

About two weeks ago, I noticed I had an SSL error cropping up with one of my AutoPkg recipes:

[Errno socket error] EOF occurred in violation of protocol (_ssl.c:590)

When I investigated what it meant, I wound up at this lengthy issue opened for Python’s requests module. In the end, it seemed to boil down to four issues:

1. I was running AutoPkg on macOS Sierra 10.12.6.
2. The recipe I was running used a processor which called Python’s urllib2 library.
3. Python’s urllib2 library was calling the OS’s installed version of OpenSSL to connect to a server using TLSv1.2 .
4. The version of OpenSSL included with 10.12.6 does not support TLSv1.2 for the urllib2 library.

When I looked into the situation on macOS High Sierra 10.13.5, Apple had addressed the problem by replacing OpenSSL with LibreSSL. Among other improvements, LibreSSL allowed Python’s urllib2 library to be able to connect to servers using TLSv1.2. Problem solved!

Until I ran into another problem.

I had been using AutoPkgr as my way of managing AutoPkg and scheduling AutoPkg runs. However, when I set up AutoPkgr on a 10.13.5 VM and scheduled my AutoPkg nightly run, nothing happened except my CPU spiked to 100% and AutoPkgr locked up with the pinwheel of patience.

OK, maybe it was something with my VM. No problem, set up a new macOS 10.13.5 VM.

Same problem.

Maybe it was because I was trying to run the VM on VMware’s ESXi? Set up a new VM running in VMware Fusion. Same problem.

Maybe AutoPkgr was getting confused by Apple File System? I set up a 10.13.5 VM which used an HFS+ boot volume. Same problem, replicated on both ESXi and Fusion.

No matter what I tried, trying to run recipes using AutoPkgr on macOS 10.13.x resulted in the following:

• The VM’s CPU spiking to 100%
• AutoPkgr locking up with the pinwheel of patience
• My AutoPkg recipes not running

I was able to eliminate AutoPkg itself as being the issue, as running recipes from the command line using AutoPkg worked fine. With that information in mind, I decided to see if I could replicate what I most liked about using AutoPkgr into another form. In the end, my needs boiled down to three:

1. I wanted to be able to run a list of AutoPkg recipes on a scheduled basis. These recipes would be .jss recipes for uploading to a Jamf Pro server.
2. I wanted to be able to post information about those AutoPkg recipes to a Slack channel
3. I wanted all the error messages from an AutoPkg run, but I didn’t care about all the information that came from a successful AutoPkg run.

With that, I decided to draw on some earlier work done by Sean Kaiser, a colleague who had written a script for managing AutoPkg in the pre-AutoPkgr days. For more details, please see below the jump.

Adding installer package code-signing to AutoPkg workflows

As part of building an AutoPkg workflow to create installer packages, one of the requirements I was given was that any packages that weren’t already signed by the vendor needed to be signed using a Developer ID Installer signing certificate.

Signing installer package is not usually an outcome of most AutoPkg workflows, since code signature verification can be used at the download end to make sure that the application is what it is supposed to be. However, there were several good reasons for adding a package signing step to the workflow, including:

1. It is now necessary to sign packages before you’ll be able to use them as part of NetInstall sets
2. The InstallApplication MDM command requires that macOS installer packages be signed with an appropriate certificate

After some research and testing, I was able to incorporate installer package signing into my AutoPkg workflow and am now able to automatically sign installer package as they’re generated by my package creation workflows. For more details, see below the jump.

AutoPkg recipes for Apple Enterprise Connect

To help keep on top of software updates, I’ve been using AutoPkg in combination with AutoPkgr and JSSImporter for a while now to upload new software updates to Jamf Pro. However, I recently ran into a challenge when I wanted to build an AutoPkg recipe for Apple’s Enterprise Connect.

AutoPkg recipes usually rely on the vendor having a publicly accessible way to get downloads via HTTP or HTTPS. Apple does not have a publicly accessible download URL for Enterprise Connect and in fact discourages customers from sharing the download link. The fact that there was a download link meant that I could write AutoPkg recipes but at the same time I couldn’t include the URL needed to download the latest update as part of the recipe .

After some thinking and research into AutoPkg’s functionality, I found a way to create AutoPkg recipes for Enterprise Connect while at the same time not sharing Apple’s download URL. For more details, see below the jump.

Deploying and licensing EndNote X8

As previously discussed, a number of folks in my shop use Clarivate Analytics’s EndNote bibliography software. Clarivate Analytics provides EndNote X8 with an installer application, but I need an installer package in order to easily deploy it to my customers. EndNote X8 was initially problematic in that regard, but I was able to write AutoPkg recipes for EndNote X8 to handle converting Clarivate Analytics’s installer application into a deployable installer package, including a recipe that would automate uploading the latest EndNote installers to my Casper server.

 

Once AutoPkg was able to provide an EndNote X8 installer package for deployment, the remaining hurdle was that the EndNote X8 installer from AutoPkg installs an unlicensed copy of EndNote and I needed to have installed copies of EndNote automatically use my shop’s EndNote site license.

 

Fortunately, EndNote X8’s volume license can be deployed just like EndNote X7’s volume license. The volume license is stored in as an invisible file named .license.dat in /Applications/EndNote X8  and it has a format that looks like this:

Company Name
1234567890
V2ZMQT6556P8WMH38MTQ6YSM8UXCCRYQ5MDS4WJGLKMP7RGSWECBCMT77556P8WCE8KMTQ6YSMNXJCCRYQ59MD9WJGLKMCSESSWECBCMB76556P8WCU3NMTQ6YSMLUYCCRYQ5MET8WJGLKMPSMJSWECBCM57F556P8WCU3CMTQ6YSM9DECCRYQ59XSCWJGLKMPNE9SWECBCMB79556P8WCH8KMTQ6YSMDXECCRYQ5MTSMWJGLKMPYRMSWECBCB7W7556P8W

Note: The Company Name part may show up twice in your .license.dat file.

With some additional testing, I found that I could remove an existing .license.dat file (if one was present) and replace it with my shop’s site license’s .license.dat file. That allowed me to use the EndNote X8 installer produced by AutoPkg by having Casper install it, then apply our site license file as a post-installation action. For more details, see below the jump.

Preparing EndNote X8 for deployment using AutoPkg

As previously discussed here, one of the software packages used in my shop is Clarivate Analytics’ EndNote bibliography software.

Recently, EndNote X8 was released. When the new version’s installer was downloaded, it was discovered to be an installer application, which can pose problems for deployment.

By itself, the change to an installer application may not have been a huge problem as long as it had options for running the installation process from the command line. However, when I checked with EndNote support about the new installer, I was told that there was no option for installing EndNote X8 on a Mac using the command line.

Since the EndNote X8 installer does not have the option of command line installation, the only real option I thought I had was to install EndNote X8, then re-package it as either a drag-and-drop install or an installer package. However, when I dug deeper into the installer, I discovered a .zip file buried inside the installer.

When expanded, this .zip file proved to be a complete install of EndNote X8.

When I ran the EndNote X8 installer, it appeared to be performing the following functions:

1. Checking for Endnote updates
2. Extracting the .zip file into a new EndNote X8 folder

3. Moving the new EndNote X8 folder into /Applications

4. Launching the EndNote X8 application, which automatically loads the EndNote X8 Customizer screen if EndNote hasn’t been configured.

For more details, see below the jump.

Diagnosing and fixing code signing issues for applications installed by installer packages

As part of making sure my customers have the latest version of their applications available, I use AutoPkg, JSSImporter, and AutoPkgr to ensure that as new software updates are released, they are automatically uploaded to my shop’s Casper server.

As part of this process, some applications need to be converted by AutoPkg from using the drag-and-drop installation method provided by the vendor to now being installed using an installer package.

In the case of certain applications, the process of packaging can change an application which is fine when installed via a drag-and-drop installation method to one which is broken when installed via an installer package. This is due to Apple’s pkgbuild tool erroneously stripping certain metadata used by the application’s code signing. If an application is set to check for that metadata as part of its code signature verification process, this can result in the application reporting that it’s been damaged and not launching.

An example of this which I’ve run across is Labtiva’s Papers.app, a reference library application designed to collect, organize and enable citation of scientific journal articles and other reference materials. The Papers.app installation method provided by Labtiva is a drag-and-drop install, where the customer is supposed to copy the application from a disk image and into a convenient location (like /Applications.)

 

When the application is installed by copying it into place, there are no problems with the application and it launches normally.

When Papers.app is packaged, then installed via an installer package, an error message will appear at first launch to report that the application is damaged.

 

Why the difference? In the case of Papers.app, the verification of the application’s code signing appears to include verification of certain metadata which pkgbuild appears to remove as part of the packaging process. For more details, see below the jump.