Introduction - Honestpuck/PatchBot GitHub Wiki

AutoPkg is an automation framework for macOS software packaging and distribution, oriented towards the tasks one would normally perform manually to prepare third-party software for mass deployment to managed clients, to quote it’s website.

At it’s core it is used to build the packages, however people have written add-ons to perform other tasks such as integrating with Munki or uploading to a Jamf repository. These rely on adding new recipe steps, or processors as AutoPkg calls them.

PatchBot can be considered as a set of three custom processors for AutoPkg, found here, and a set of auxiliary tools, found here.

The first thing PatchBot does is build the packages and upload them to Jamf Pro. At the same time it saves the package details in a policy called TEST-<title>. In a previous version this delivered the test version to the testers but now it’s just a database record.

PatchBot then runs a script that takes the report plist from AutoPkg and uses it to send messages to a special channel in Teams. That’s so humans can know what’s going on.

Once packages are uploaded it’s time to start patch management. This requires a high quality patch definition feed for the Jamf Pro patch management system. I buy Kinobi from Mondada and believe it’s easily a value proposition. Seriously, I cannot overstate how well a bunch of Aussies do it. It’s incredibly finicky and tedious and throwing not much money at somebody else to do it is incredibly appealing when they do such a good job. They have also released the server software they use to open source. There is an open source community alternative that I’m sure works fine for some.

The first step in patch management is to find the version definition for our new package and get it pointed to the package, then update a patch policy Test <title>. This patch policy is scoped to a single group regardless of the application, I call mine Package Testers. The patch policy has a self service deadline of two days. PatchBot also tells us the results with another set of messages to Teams.

The second step in patch management is to move a package from test into production. This is done seven days after it is moved into test using a production patch policy, called Stable <title> scoped to all computers and a self service deadline of seven days. Both the delay before moving patches into production and the self service deadlines are easily changed.

At this point PatchBot updates the install policy for the application so it uses the new version. I’m sure you’re not surprised it has a third script to send the results to our Teams channel.

It’s now done. We have a patch package in production and an updated install policy. At no stage have we had to do a thing. The only human intervention we might need is halting the shift from test to production if our testers discover a broken package. That’s as easy as editing the self service description for the Test patch policy.

PatchBot is described in a number of blog posts:

• PatchBot - Zero-Touch Packaging and Patch Management
• PatchBot - Zero Touch Patch Management #2
• PatchBot #3
• PatchBot #4

You no longer need to alter the .pkg recipe override as described in the first blog post. Details on running JPCImporter as an AutoPkg post processor are at https://macintoshguy.wordpress.com/2020/07/31/patchbot-update/

You can find the components in three GitHub repositories

• PatchBotProcessors Three custom processors for AutoPkg
• PatchBotTools The other components
• PatchBotExamples Three example recipes