Automating Manual munki Imports with autopkg – Part 3: Pro Tools

In previous posts (macOS erase & install, Autodesk Maya), I discussed how I created recipes for importing different software titles that I’d previously processed manually.

In this third part, my focus is on Pro Tools. The challenge with automating this task is that any given release includes in the downloaded DMG the Pro Tools install as a PKG as well as both the required Codecs and HD Driver PKG installers. These supporting installs are tied to the specific Pro Tools release and which must be installed before Pro Tools. The core question then was using the available processors, could I create the necessary Pro Tools munki item while simultaneous making the applicable Codecs and HD Driver versions a part of the item’s requires array?

TL;DR – you can reassign any collected autopkg output variable to any other desired variable for later use.

See more info past the jump.

Unlike with my previous posts in this series, the main Pro Tools software and its component parts are all distributed as PKGs within the same, single DMG. Additionally, all receipts and software are properly versioned. As a result, the only real challenge is associating the specific component versions with the specific Pro Tools release to ensure that if a patch is available these are also installed (if needed). Since these items are located within the same DMG file, all applicable recipes can use this one file for processing.

.pkg Recipes

To make this extensible for other admins beyond my intended .munki recipes, I created 3 .pkg recipes to handle finding the appropriate PKG within the larger DMG, verifying the expected certificate authority names, and copying the PKG out of the DMG for easier processing later.

The only difference between the recipes is that with Pro Tools given the downloaded DMG contains the version in the filename, I use the collected found_filename variable collected by FileFinder to extract this version with the shared VersionSplitter processor:

<dict>
    <key>Comment</key>
    <string>With a successful code signature check, get the version from the filename</string>
    <key>Arguments</key>
    <dict>
        <key>version</key>
        <string>%found_filename%</string>
        <key>index</key>
        <integer>-2</integer>
        <key>split_on</key>
        <string>_</string>
    </dict>
    <key>Processor</key>
    <string>com.github.homebysix.VersionSplitter/VersionSplitter</string>
</dict>

These recipes can be found via the links below:

.munki Recipes

There’s nothing at all special about the Codecs or HD Driver import .munki recipes. They just import these normal PKGs into a munki_repo. It’s only the Pro Tools recipe that’s interesting.

First, there are two input variables to define the configured munki item names for the Pro Tools Codecs and HD Driver. This ensures that whatever an admin defines name-wise in the Codecs and HD Driver .munki recipes can be defined in this recipe as well.

<key>PROTOOLS_CODECS_NAME</key>
<string>ENTER CODECS MUNKI ITEM NAME HERE</string>
<key>PROTOOLS_DRIVER_NAME</key>
<string>ENTER DRIVER MUNKI ITEM NAME HERE</string>

Second, we define the minimum and maximum OS versions in the pkginfo input dictionary. This is subject to change, and requires referring to this Avid KB article: https://avid.secure.force.com/pkb/articles/en_US/Compatibility/Pro-Tools-System-Requirements. Though only specific versions are supported (as of this writing, 10.13.6, 10.14.6, 10.15.3, and 10.15.5) defining the upper and lower boundaries is helpful for preventing munki from downloading the installer at all for incompatible OSs. This isn’t 100% required however, as you’ll see in a moment.

Given that munki only defines a supported OS range, there’s some extra work that needs to be done to help ensure that only Macs running one of the supported OS releases are able to install Pro Tools. If you happen to have Jamf, a .jss recipe could define a policy with these specific versions in the os_requirements variable (example here), but unfortunately we don’t have that option within a munki item’s pkginfo file. To work around this, I utilize a preinstall_script to check for specific OS versions. If the installed macOS version is not in the list, the script returns an exit status of 1 and does not continue to install the software (click here for that code excerpt). I also include an autopkg PROTOOLS_MACOS_SUPPORTED_LIST input variable so admins can update this list as needed (versions separated by spaces).

<key>PROTOOLS_MACOS_SUPPORTED_LIST</key>
<string>10.13.6 10.14.6 10.15.3 10.15.5</string>

preinstall_script:

#!/bin/bash

# Verify installed macOS version

# Method inspired by:
# https://stackoverflow.com/questions/12768265/bash-compare-a-string-vs-a-list-of-strings

OSVERS=$(/usr/bin/sw_vers -productVersion)
# Set blank value
SUPPORTED=""
SUPPORTED_VERS=( %PROTOOLS_MACOS_SUPPORTED_LIST% )
VERS_LIST=$(/usr/bin/printf '%s\n' "${SUPPORTED_VERS[@]}")

# Compare installed OS version to supported version list
for v in $VERS_LIST; do
    if [[ "$v" = "$OSVERS" ]]; then
        SUPPORTED="yes"
        break
    fi
done

# Verify result
if [ "$SUPPORTED" = "yes" ]; then
    /bin/echo "VERIFIED: macOS version ${OSVERS} is listed in the supported OS list."
    exit 0
else
    /bin/echo "FAILED: macOS version ${OSVERS} is not in the supported OS list."
    exit 1
fi

If you prefer a non-autopkg version instead:

Another small piece involves a postinstall_script which removes the Avid Link LaunchAgent. We don’t use this, and IIRC a couple of years ago we experienced significant issues with AirPlay mirroring when Avid Link was running. As a result, this ensures Avid Link is never launched on user login:

#!/bin/bash

# Remove Avid Link LaunchAgent
AGENT="/Library/LaunchAgents/com.avid.avidlink.plist"

if [ -f "$AGENT" ]; then
    /bin/rm -f "$AGENT"
fi

exit

The last core piece to make this Pro Tools recipe work and properly associate the munki item name and specific versions involve running several processors, like the shared PackageInfoVersioner processor, multiple times. As a result, on each subsequent processor run the previously used output variables get overwritten with the new values. This means that each pertinent output variable would have to be reassigned in order to be used at the end when actually importing the Pro Tools installer. Up until this point, I (and many admins) hadn’t needed to deal with reassigning variables, but the solution is actually surprisingly simple.

Recently, another Mac Admin, @jazzace, gave a great presentation on this and other autopkg findings as part of the PSU Mac Admin Campfire series (click here for the video) and simply put, autopkg variables are arbitrary. Effectively, any previously used variable (ex. version) can be reassigned to any other custom variable as part of a processor’s arguments.

For example, the processor excerpt below takes an already collected Pro Tools version and after unpacking the Codecs PKG assigns this version to a protools_vers variable before subsequently collecting the Codecs PKG version and assigning that to the version variable. You can find more info about this on the autopkg wiki: https://github.com/autopkg/autopkg/wiki/Defining-Custom-Variables.

<dict>
    <key>Comment</key>
    <string>Get the Pro Tools Codecs filename and assign the DMG path to dmg_path</string>
    <key>Arguments</key>
    <dict>
        <key>dmg_path</key>
        <string>%found_filename%</string>
        <key>pattern</key>
        <string>%dmg_path%/Codec Installers/*.pkg</string>
    </dict>
    <key>Processor</key>
    <string>FileFinder</string>
</dict>
<dict>
    <key>Comment</key>
    <string>Unpack the Codecs PKG so we can get the version</string>
    <key>Arguments</key>
    <dict>
        <key>flat_pkg_path</key>
        <string>%dmg_path%/%dmg_found_filename%</string>
        <key>destination_path</key>
        <string>%RECIPE_CACHE_DIR%/unpack</string>
    </dict>
    <key>Processor</key>
    <string>FlatPkgUnpacker</string>
</dict>
<dict>
    <key>Comment</key>
    <string>Assign the previously collected Pro Tools version to protools_vers and collect the Codecs PKG version</string>
    <key>Arguments</key>
    <dict>
        <!-- vv ARBITRARY VARIABLE REASSIGNMENT vv -->
        <key>protools_vers</key>
        <string>%version%</string>
        <!-- ^^ ARBITRARY VARIABLE REASSIGNMENT ^^ -->
        <key>package_info_path</key>
        <string>%RECIPE_CACHE_DIR%/unpack/AvidCodecsLE_component.pkg/PackageInfo</string>
    </dict>
    <key>Processor</key>
    <string>com.facebook.autopkg.shared/PackageInfoVersioner</string>
</dict>

Completing this subsequent times allows using these custom variables in the later MunkiImporter processor step:

<dict>
    <key>Comment</key>
    <string>Assign the previously collected HD Driver version to driver_vers and import into munki.</string>
    <key>Arguments</key>
    <dict>
        <key>driver_vers</key>
        <string>%version%</string>
        <key>additional_makepkginfo_options</key>
        <array>
            <string>--displayname</string>
            <string>%DISPLAY_NAME% %protools_vers%</string>
            <string>--pkgvers</string>
            <string>%protools_vers%</string>
            <string>--requires</string>
            <string>%PROTOOLS_CODECS_NAME%-%codecs_vers%</string>
            <string>--requires</string>
            <string>%PROTOOLS_DRIVER_NAME%-%driver_vers%</string>
        </array>
        <key>pkg_path</key>
        <string>%RECIPE_CACHE_DIR%/%NAME%-%protools_vers%.pkg</string>
        <key>repo_subdirectory</key>
        <string>%MUNKI_REPO_SUBDIR%</string>
    </dict>
    <key>Processor</key>
    <string>MunkiImporter</string>
</dict>

The resulting imported Pro Tools munki item correctly lists in the pkginfo file both the version-specific Codecs and HD Driver as required munki items, only installs on systems running supported macOS versions, and deals with the bothersome Avid Link LaunchAgent!

These recipes can be found via the links below:

Using the Pro Tools .munki Recipe

Per the Pro Tools recipe description:

  1. Create a recipe override of this recipe.
  2. Go to the Avid website and download the Pro Tools for Mac DMG.
  3. Copy the downloaded DMG onto your Mac running autopkg in the folder specified in the PATH variable. Don’t include a trailing ‘/’.
  4. Specify the desired Pro Tools display name in the DISPLAY_NAME variable. The collected version will be appended to the name.
  5. Specify the munki item name for the HD Driver as listed in your munki repo in the PROTOOLS_DRIVER_NAME. This name and the detected PKG version of the HD Driver in the .dmg will be added to the requires array for Pro Tools.
  6. Specify the munki item name for the Codecs as listed in your munki repo in the PROTOOLS_CODECS_NAME input variable. This name and the detected PKG version of the Codecs in the .dmg will be added to the requires array for Pro Tools.
  7. Refer to Avid’s KB article on supported macOS versions (https://avid.secure.force.com/pkb/articles/en_US/Compatibility/Pro-Tools-System-Requirements) and update the PROTOOLS_MACOS_SUPPORTED_LIST accordingly. This will use the defined supported versions to compare with the installed version via a preinstall_script. If a supported version is not found, an exit status of 1 is produced and the item is not installed.
  8. Run the recipe.
  9. Profit.

Looking Ahead

As mentioned in previous posts, you could take this a step further by incorporating something like the SMBMounter Shared Processor to point your autopkg instance to a shared network folder with Pro Tools DMG file, rather than a folder directly on your system or one that’s already mounted.

Additionally, there is room for other admins to build .jss, .filewave, and other recipes with the .pkg recipes as the ParentRecipe. And while a .jss recipe could more easily ensure that only supported macOS versions were able to install Pro Tools, there is room for someone else to determine if it would be better/easier to configure a single policy which includes the Codecs, HD Driver, and Pro Tools installers (ordered to ensure the codecs and driver are installed first) or with each in separate policies activated via custom triggers.

If you found any of these insights helpful, give this post a like! Otherwise, post your questions and comments below.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s