Thought Leadership.

Introducing JSSImporter for Autopkg

  • Allister Banks
  • Jan 06, 2014

Autopkg is a project born out of the need to automate one of the more tedious tasks that face Mac Admins: figuring out when a piece of software has been updated, downloading it, and doing whatever it takes to make that software ‘live’ in your distribution or management system of choice. You can run the autopkg tool on a regular basis to have it do all of the above for you for certain supported products by using the recipes provided or ones you make yourself.

Munki was designed more recently than some other software distribution systems, and started out with the concept of ‘tracks’ or phases a piece of software will go through before it is offered to all of the clients participating in the system. Autopkg can integrate with it by simply copying the downloaded package into the repo, among other actions that have the potential of offering the software to clients immediately.

JAMF’s Casper Suite has many similar features, but as it was built under different circumstances it has other considerations and steps one would use when approaching the same set of tasks. Autopkg does not consider one software distribution system more special than another, and presents an open framework for folks to integrate with as they see fit. I have taken it upon myself to publish a ‘processor’ python file which, along with standard prefs for leveraging the JSS API, can not only ‘upload’ the fetched package to the JSS’s distribution point, but can also configure a smart group(as of version 9 of the JSS API) and/or a self-service policy which therefore makes the software immediately ready for testing. Optionally, one could use categories to group uploads by product type, and/or target any pre-existing static group for the policy to serve(which should also work on version 8.)

jss-autopkg-addon release

To get started testing and evaluating it, please recognize that there were specific design decisions taken into account for this integration. We’re mimicking Munki’s pipeline-to-testing, where admins need to do as little as possible to have the software automatically imported and made ‘live’ in the system. Here’s a high-level workflow:
Once everything is installed, preferences are set to point to the locally-mounted jss distribution point, the url of the jss, and provide a user with api write access to modify the desired objects.

defaults write com.github.autopkg JSS_REPO /Volumes/JSS_Dist_Point/Packages
defaults write com.github.autopkg JSS_URL https://test.jss.private:8443
defaults write com.github.autopkg API_USERNAME apiUser
defaults write com.github.autopkg API_PASSWORD apiPassword

The autopkg tool is then run, pointed at a product’s jss-specific recipe(e.g. autopkg run AdobeFlashPlayer.jss.) Categories are created by product name to arrange the imported software(which you can turn off or customize if you’d wish.) The software is prepared (along with optimizations so it works in more scenarios in certain cases,) and copied to the distribution point.
Then, in an effort to ‘do no harm’, we create a smart group that is scoped to all of the computers in inventory that are not at this version of the software(in case users have already installed it.) It also creates a self-service policy with that group added to it by default(although it can optionally be statically scoped to any group name.) Therefore it doesn’t get ‘pushed’, just imported and is ready for testing unless you have other plans of how to more optimally put it in production for your organization.

For an installation guide, take a look at the autopkg wiki and other resources including the MacTech articles and MacSysadmin presentation Greg Neagle gave this past year.

After getting autopkg set up, the most current ‘release’ version of my processor can be downloaded and installed from here. (Direct link to the package)

Having the jss-specific tools installed doesn’t do anything without the actual recipes to build the packages, so I’ve created about two dozen to get started with. I have pushed those to github as well, which makes them trivial to fetch using the autokpg tool itself.

autopkg repo-add

Many of these rely on the main autopkg recipes repo as a ‘parent’, so without having to do the munki-specific setup instructions on the previously linked autopkg wiki, make sure you get it working as described in their documentation. I’m definitely in need of testers and feedback when it comes to the ways folks want the workflow sculpted to their software deployment methods, so please do let me know what you think!

Leave a Reply

+ nine = 18