Arguments
The following Arguments/ Input Variables are required for the JumpCloud AutoPkg Processor to complete a successful run.
The JC_API variable can be set as an environment variable. The API key is set as a key in the com.github.autopkg preference file located at ~/Library/Preferences/com.github.autopkg.plist.
After installing the latest version of AutoPKG, add your JumpCloud API key to the AutoPkg:
defaults write ~/Library/Preferences/com.github.autopkg.plist JC_API yourApiKey
Note: Your API key is stored on a local system when the above command is used, evaluate whether or not this meets the security requirements of your organization. Receipts for each package are generated by default, those receipts will contain your a copy of your API key.
If the JC_API key is not set, the JC-AutoPkg-Importer will prompt for an API key each time AutoPkg is invoked. AutoPkg recipe receipts will not contain your API Key if the JC_API key is not set with the defaults command above.
The JC-AutoPkg-Importer supports MTP API Keys. The the importer will display all JumpCloud Orgs tied to the MTP API key and ask that you select a organization.
The JC_ORG variable can be set as an environment variable. This variable can be left blank. The ORG ID is set as a key in the com.github.autopkg preference file located at ~/Library/Preferences/com.github.autopkg.plist. The JC-AutoPkg-Importer will automatically set this variable if the API Key is tied to a single JumpCloud Tenant.
After installing the latest version of AutoPKG, add your JumpCloud API key to the AutoPkg:
defaults write ~/Library/Preferences/com.github.autopkg.plist JC_ORG yourOrgID
Note: Your ORG ID is stored on a local system when the above command is used, evaluate whether or not this meets the security requirements of your organization. Receipts for each package are generated by default, those receipts will contain your a copy of your ORG ID.
This input variable is the name of the smart group built using system insights. In the example above AutoPkg-%NAME%-%version% should build a smart group (and command) with the name of the given software package and version. Ex. AutoPkg-Firefox-72.02. The %NAME% and %version% variables are XML variables of AutoPkg recipes which allow for dynamic naming of groups and commands within JumpCloud.
The following XML code block demonstrates how a JC_SYSGROUP could be generated with the "Custom" prefix. The Firefox recipe with this JC_SYSGROUP would create a group and command titled "Custom-AutoPkg-Firefox-72.02" for example.
<key>Process</key>
<array>
<dict>
<key>Processor</key>
<string>JumpCloudImporter</string>
<key>Arguments</key>
<dict>
<key>JC_DIST</key>
<string>AWS</string>
<key>AWS_BUCKET</key>
<string>jcautopkg</string>
<key>JC_SYSGROUP</key>
<string>Custom-AutoPkg-%NAME%-%version%</string>
<key>JC_TYPE</key>
<string>auto</string>
</dict>
</dict>
</array>This input variable is used when building commands, the id of a command runner may be passed into this variable field. By default the root user account is assigned to the commands built with this processor.
The default value for this argument is "000000000000000000000000" which corresponds to the root user.
There are three valid values which can be passed into each the JC_TYPE field: self, auto or update. The "Self" JC_Type is the default behavior.
self: This type of AutoPkg run builds a group and command based on the JC_SYSGROUP variable. Given that System Insights is required to query systems for applications, a JC_TYPE of self would not invoke System Insights for this task. Manual assignment of systems would be required.
auto: This type of AutoPkg run queries systems in your organization and cross references the title and version of applications on systems with the title of software from an AutoPkg recipe. For example running the Firefox recipe would query JumpCloud systems for the following: Does the system have Firefox? Is the installed version of Firefox up to date (based on the recipe definition)?
If a system does not have Firefox or if a system has an out-of-date version of Firefox, it would be added to the group. Systems assigned to this group and corresponding command are scheduled to run the command once. After the command runs, the system is removed from the the group.
update: This type of AutoPkg run builds a system group (if it does not exist) and only adds systems which currently have the AutoPkg app installed. Those systems who's version of the app are out of data are kept in the system group. This run type can remove systems without the specified app from the system group if the group exists and systems without the group are in that group. Admins who only wish to update systems with an app can use the update type to run app updates.
manual: This type of AutoPkg run builds a command and skips the group creation steps. This type of AutoPkg run is provided for users who wish to do all system assignments manually.
The JumpCloud System Insights Application Name variable is used in conjunction with the JC_TYPE variable. It's required to use this variable on recipes with the auto or update JC_Type. When specified, the importer will query applications on devices with this value. The value is case-sensitive and must match a name of application as it's listed in the system insights applications endpoint without the .app text. For example, the application Google Chrome is listed as "Google Chrome.app" when creating a recipe override to update chrome on devices, the JC_SI_APP_NAME for that override would be 'Google Chrome'. Systems with Google Chrome would be identified by the text in this variable value.
During the beta development of this processor only "AWS" (Amazon Web Services) can be passed into this field. Other distribution endpoints have not yet been developed.
The default value for this argument is "AWS". Until other distribution type functionality is built into the processor, only AWS S3 buckets can be used.
This is the bucket name required for AWS. the default value is "jcautopkg" if that bucket name does not exist, the processor will fail. The credentials specified in AWS Distribution Points should have access to your AWS Bucket, if the bucket is unreachable the processor will fail.
The following override block specifies "myS3BucketName" as the destination bucket for a recipe override.
<key>Process</key>
<array>
<dict>
<key>Processor</key>
<string>JumpCloudImporter</string>
<key>Arguments</key>
<dict>
<key>JC_DIST</key>
<string>AWS</string>
<key>AWS_BUCKET</key>
<string>myS3BucketName</string>
<key>JC_SYSGROUP</key>
<string>AutoPkg-%NAME%-%version%</string>
<key>JC_TYPE</key>
<string>auto</string>
</dict>
</dict>
</array>Commands can be scheduled on a recurring or time based trigger. This variable type enables AutoPkg commands to be installed on a rotating 15 min basis or every day at noon for example. When repeating commands are built with the JC AutoPkg Importer, they are triggered immediately and again on the recurring schedule.
This variable is set to False by default, if the JC_Trigger is set to true, the recipe will look for the JC_REPEAT_TYPE and JC_REPEAT_CRON variables to set the repeating triggers on the generated command. The following key pair is required to set repeating triggers on commands.
<key>JC_TRIGGER</key>
<true/>This variable controls the command's scheduled repeat type. If the JC_TRIGGER variable is set to true, the JC_REPEAT_TYPE variable is required.
Valid argument input: minute, hour, day, week, month
This variable should contain a crontab formatted string to set the repeating type numerical value and time of day trigger. If the JC_TRIGGER variable is set to true, the JC_REPEAT_CRON variable is required.
Valid argument examples:
A recipe override with the following process block would schedule the auto generated command to run every 5 mins.
<key>Process</key>
<array>
<dict>
<key>Processor</key>
<string>JumpCloudImporter</string>
<key>Arguments</key>
<dict>
<key>JC_DIST</key>
<string>AWS</string>
<key>AWS_BUCKET</key>
<string>jcautopkg</string>
<key>JC_SYSGROUP</key>
<string>AutoPkg-%NAME%-%version%</string>
<key>JC_TYPE</key>
<string>auto</string>
<key>JC_TRIGGER</key>
<true/>
<key>JC_REPEAT_TYPE</key>
<string>minute</string>
<key>JC_REPEAT_CRON</key>
<string>0 */5 * * * *</string>
</dict>
</dict>
</array>Schedule command to run hourly
<key>JC_TRIGGER</key>
<true/>
<key>JC_REPEAT_TYPE</key>
<string>hour</string>
<key>JC_REPEAT_CRON</key>
<string>0 0 */1 * * *</string>Schedule weekly run of command, on Thursdays to run at Noon on the system clock.
<key>JC_TRIGGER</key>
<true/>
<key>JC_REPEAT_TYPE</key>
<string>week</string>
<key>JC_REPEAT_CRON</key>
<string>0 00 12 * * 4</string>Schedule weekly run of command, Mondays, Tuesdays, Wednesdays, Thursdays and Fridays at Noon on the system clock.
<key>JC_TRIGGER</key>
<true/>
<key>JC_REPEAT_TYPE</key>
<string>week</string>
<key>JC_REPEAT_CRON</key>
<string>0 00 12 * * 1,2,3,4,5</string>