-
Notifications
You must be signed in to change notification settings - Fork 38
Introduction
The JSSImporter processor adds the ability for AutoPkg to upload packages to a Jamf Pro distribution point, and create scripts, extension attributes, computer groups and policies in a Jamf Pro server (the server formerly known as "JSS"), allowing you to fully-automate your software testing workflow.
This project began from Allister Banks' original jss-autopkg-addon project, but has since diverged considerably completely to add greater customization options while maintaining the existing functionality.
Getting your software testing workflow constructed using AutoPkg and JSSImporter can be daunting. This document will go over the various configuration and usage information you will need for success. Start with the Installation and Setup page and work down the list.
See also:
- Jamf And AutoPkg by Graham Pugh, JNUC, 2019.
- Integrating AutoPkg and Casper with JSSImporter by Shea Craig, MacAdmins Conference at Penn State, 2015.
While JSSImporter has a lot of options for crafting the workflow best suited to your organization's needs, there are best practices expressed in the AutoPkg organization's jss-recipes repo that drive the design of JSSImporter.
The workflow used in the AutoPkg org's jss-recipes repo goes something like this:
.jss
recipes use .pkg
recipes as parents - these produce standard Apple package (pkg) files. This ensures that a pkg can be uploaded to the distribution points. The resulting package file name includes the software's name and version number (e.g. Firefox-38.0.5.pkg
).
The package file's metadata includes any OS version restrictions that govern that product's installation.
The .jss
recipe specifies the category for the package file itself, which is chosen from among a limited set of approved categories. (See the list of categories in the Style guide below.) If the category doesn't exist, it will be created.
JSSImporter uploads the package file to all configured distribution points.
A SmartGroupTemplate.xml
file tells JSSImporter to create or update a smart group called [SoftwareName]-update-smart
. The criteria of this group are:
- the computer has the software in question installed
- the version does not match the newest version that AutoPkg found
- the computer is a member of a group called
Testing
(which is created and maintained manually by the Jamf admin)
The standard SmartGroupTemplate.xml
file is available in the example_templates
folder of the JSSImporter repo. Note that this needs to be available to AutoPkg before running any .jss
recipe. We recommend copying it into your RecipeOverrides
folder.
No groups other than the smart group mentioned above are created or modified.
- A
PolicyTemplate.xml
file tells JSSImporter to create a single Self Service policy for each product, calledInstall Latest [SoftwareName]
. The policy:- installs the latest package file.
- is scoped to the smart group mentioned above.
- includes a Self Service icon and description.
- category is
Testing
. This groups policies together under theTesting
category on the Policies page of the Jamf Pro web interface to separate and distinguish them from other policies. If theTesting
category doesn't exist, it will be created. - has an execution frequency of "Ongoing" to allow multiple runs should tests fail. However, following a successful installation, the Self Service policy performs a recon run, which will drop the computer out of the smart group, thus preventing further executions until the next update is made available. This also enables reuse of the same policy without needing to "Flush All" the policy logs.
The standard PolicyTemplate.xml
file is available in the example_templates
folder of the JSSImporter repo. Note that this needs to be available to AutoPkg before running any .jss
recipe. We recommend copying it into your RecipeOverrides
folder.
Icon files also need to be copied to the RecipeOverrides
folder.
In the rare case of needing an Extension Attribute to determine whether a package is out-of-date, and thus used to determine membership in the smart group, these Extension Attributes will be created and/or updated. A separate [SoftwareName]-ExtensionAttribute.xml
file is required for this. This is most commonly the case with apps that either don't live in /Applications
, are not an app bundle at all (e.g. Java), or report different version numbers for CFBundleShortVersionString
and CFBundleVersion
(Jamf only uses CFBundleVersion
for inventory).
The AutoPkg organization's jss-recipes repo is a community project which adheres to the best practices generally agreed upon by the community. Other Mac Admins may provide their own .jss
recipes, and they are encouraged to follow the same guidelines so that the resulting policy & smart groups are compatible.
JSSImporter's goal is to allow you to, with AutoPkg, automate the drudgery of managing a testing workflow. It is not meant to deploy software straight to production machines. It is not meant as a way to bootstrap all of a JSS's policies.
There is a lot you can do with the Jamf Pro API, and JSSImporter's code is an illustration of how to go about doing this. If you are trying to do something beyond what these recipes cover, you will most likely need to create your own .jss
recipes, which may be best suited to a private repository so as not to produce unexpected effects if used by others. This usually involves establishing your own workflow, and writing the policy and smart group templates to support that. Implementing individual recipes becomes largely editing a handful of values in copies of these templates, 90% of which end up being the same.
Other questions not addressed here? Join us in the #jss-importer channel on the Mac Admins Slack.