AutoPkg recipes for macOS Sierra, OS X El Capitan and OS X Yosemite OS installers now available

Now that Apple has made direct download links available for older OS installers, I’ve written AutoPkg .download and .pkg recipes for the following macOS installers:

• macOS Sierra
• OS X El Capitan
• OS X Yosemite

 

These recipes will download the disk images linked to the relevant KBase articles, extract the installer packages stored inside the disk images and rename the disk images and installer packages with the OS name and version number.

One thing to be aware of is that the downloaded installers do not themselves install the relevant version of macOS or OS X. Instead, they install the Install.app for that version of macOS or OS X into the /Applications directory.

The AutoPkg recipes are available via the links below:

• macOS Sierra: https://github.com/autopkg/rtrouton-recipes/tree/master/macOSSierra
• OS X El Capitan: https://github.com/autopkg/rtrouton-recipes/tree/master/OSXElCapitan
• OS X Yosemite: https://github.com/autopkg/rtrouton-recipes/tree/master/OSXYosemite

Building customized postinstall scripts for AutoPkg recipes

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:

1. There was a publicly available download URL for the Zscaler installer app.
2. 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.

Using AutoPkg 1.1’s recipe template creation option

As part of the release of AutoPkg 1.1, a new-recipe feature was added to help with recipe creation.

It will create a generic recipe file with the following keys added:

• Description
• Identifier
• Input
• MinimumVersion (by default, MinimumVersion will be set for AutoPkg 1.0)
• Process

Under the Process keys, there are additional keys created by default:

• Arguments
• Processor

As an example, here’s the recipe file which is created when the following command is run:

autopkg new-recipe ~/Desktop/MyGreatApplication.download.recipe

For more details, please see below the jump.

Oracle Java JDK, OpenJDK, Java 11 and macOS

With Java 8 approaching the end of its lifecycle, Oracle has made some changes to the Oracle JDK license that will affect Java 11’s JDK. As of Oracle Java JDK 8, you can use the JDK for free in the following circumstances:

• Development
• Testing
• Prototyping
• Production

As of Oracle Java JDK 11, you can use the JDK for free in the following circumstances:

• Development
• Testing
• Prototyping

Notice that Production has dropped off the list? If you use Oracle Java JDK 11 for production use, Oracle is now expecting payment. For the complete details, please see the license agreement (relevant sections highlighted below):

If you don’t want to or can’t pay Oracle, what are the available options?

1. Keep using Oracle Java JDK 8

Oracle will continue to provide updates for Java 8 until January 2019, so a short-term solution is to keep using JDK 8 until support ends. This is only a short term solution however. If you want to continue using Java 8 past January 2019, you may need to start paying Oracle in order to get access to continuing Java 8 support.

2. Migrate from Oracle Java JDK to OpenJDK

In addition to its commercial offering, Oracle has an open-source Java available named OpenJDK. As of Java 11, Oracle will be providing functionally identical JDK builds to both the commercially licensed Oracle JDK and the open-source OpenJDK. For more details, please see below the jump:

Phantom groups, MySQL queries and Jamf Pro 10.7

On September 13th, Jamf released a new KBase article for Jamf Pro customers who hosted Jamf Pro themselves instead of hosting in Jamf Cloud:

On-Prem Jamf Pro Customers Upgrading to 10.7.0: https://www.jamf.com/jamf-nation/articles/552/on-prem-jamf-pro-customers-upgrading-to-10-7-0

In the KBase article, Jamf provides a couple of MySQL commands to run:

select computer_group_id,criteria,criteria_display from smart_computer_group_criteria where criteria not in (select computer_group_name from computer_groups) and search_field="Computer Group";

select computer_group_id,criteria,criteria_display from smart_computer_group_criteria where binary criteria not in (select binary computer_group_name from computer_groups) and search_field="Computer Group";

If either query returned data, the KBase directs you to contact Jamf Support. This was my output:

What had happened? For more details, please see below the jump.

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.