The Geeky Gordo

Today I will start a new short series of posts around JAWA, the Jamf Automation + WebHook Assistant. This first post will be a little intro, along with setting up our story arc and the workflow idea I needed to solve. 

The What & The Why

JAWA was born out of a need to provide an easy way for Jamf admins to receive and process webhooks from Jamf Pro, along with a way to automate some of the workflows admins need to run. A couple of consulting engineers within Jamf banded together and wrote JAWA to run on small Linux servers in the cloud. And yes, if you couldn’t guess by the name, they are all big Star Wars fans.

JAWA is a Python Flask app running on Linux that can interact with Jamf Pro, Okta, and more, including creating custom webhooks and timed automations using crontab. JAWA provides a way for admins to connect multiple services within an organization. Just because it is written to primarily interact with Jamf Pro doesn’t mean JAWA could not be a webhook receiver for other SaaS applications.

The How (installation of JAWA)

I won’t go into all of the requirements to run JAWA since they are covered on the GitHub page. You can host JAWA internally or grab a server at someplace like AWS or Azure, or any other cloud hosting provider. As pointed out on the GitHub page, you will need a publicly trusted full-chain certificate for this to work seamlessly. 

Along with the certificate, I would recommend setting up DNS so that your server is accessible via an FQDN just to make it easier to remember. This also makes getting the certificate easier, especially if you use AWS and turn your server off like I do. When you do that, the IP address may change, necessitating a change to the DNS (make sure the TTL on your DNS is really low, like every 5 minutes).

Once you’ve made sure all of the server requirements are fulfilled, like installing Python 3.7+ with PIP, make sure your certificate is in the current directory you are in, and then run the installer. The links on the GitHub page will download the installer script and execute it with the proper bash commands.

It is recommended that when installing JAWA, you do not install it to your home folder but instead somewhere like /usr/local/jawa or some other location. I know I ran into issues when installing it to the home folder on my AWS server.

Once the installation is complete, you should have an “animated” Jawa image on your screen. I told you these guys were Star Wars fans.

Now that Jawa is installed, you can open up a web browser and navigate to the FQDN/IP of your server to verify that it is up and operational and to finish the configuration of JAWA to point to your Jamf Pro instance. You will need the URL of your Jamf Pro server and credentials for a Jamf Pro administrator.

After entering that information, your JAWA instance is now “connected” to your Jamf Pro instance. Whenever you come back to JAWA you will use that same Jamf Pro user information to login to JAWA.

You should now be at the JAWA Dashboard page. From here you have the ability to create webhooks for Jamf Pro, Okta, custom webhooks, or a timed automation.  When creating a Jamf Pro automation, JAWA will create the bits and pieces in Jamf Pro that are necessary for that webhook. 

When creating a webhook, you provide a script for JAWA to run whenever it receives a webhook from Jamf Pro. For example, if you simply wanted to export the contents of the webhook when it is triggered, you could use a very simple Python script like:

#!/usr/bin/python3

import sys

import json

webhook_content = sys.argv[1]

data = json.loads(webhook_content)

print(data)

Tie that to a Computer  Check-in webhook or a Mobile Device Check-in, and the next device that checks in will dump the webhook data to the log-in JAWA (available under the “Extras” menu item).

That is a basic explanation of how to “test” JAWA to ensure it will work and spit data out. The power is in what you craft in the script. You can pull data out of the webhook data and then use that to perform some action, like feed data to another system or trigger something else based on the info. The uses are limitless.

The Story Arc

I was presented with a problem by one of my customers. They needed to report on the usage of their caching servers in the field. They were already gathering the data as an Extension Attribute but wanted the data to update more frequently than every inventory. As you probably know, generating an inventory update can be very chatty and cause a lot of other things to happen on the Jamf Pro server (like recalculating all Smart Groups). In a larger environment (say over 500 devices), this can cause some stress. Also, there’s no easy way to generate an inventory update more frequently than once a day. 

In came JAWA and the use of the Custom Webhook functionality. In the next post I will explain the vision we had to gather this data and how we accomplished it.