PatchBot & API Error 409

[ryonriley]

My company is in the process of setting up PatchBot (https://github.com/Honestpuck/PatchBot) for all of our Jamf Pro cloud instances.

Per the checklist, I've set up all of the necessary policies (both computer and patch), and am using Firefox as my test case. I made the Firefox.pkg override, and created the Firefox.ptch recipe using the new package argument, and made the corresponding override.

Problems: when running the autopkg.sh script, we're running into issues with both of the custom processors, JPCImporter and PatchManager.

• JPCImporter fails with a 409 error. It times out after the 10 attempts to update the package.

2021-01-08 11:29:17 DEBUG package update attempt 11
2021-01-08 11:29:18 DEBUG Attempt failed with code: 409
2021-01-08 11:29:18 DEBUG URL: https://***.jamfcloud.com/JSSResource/packages/id/166

• PatchManager also fails with a 409 error and doesn't update the patch policies. The script just halts at line 190 after the 409 is returned.

2021-01-08 11:33:52 DEBUG Got patch policy with version : 84.0 : and we are : 82.0.3 :
2021-01-08 11:33:52 DEBUG About to change PP: https://***.jamfcloud.com/JSSResource/patchpolicies/id/5

Both of these 409 errors happen on the PUT of each script.

JPCImporter:

ret = requests.put(url, auth=auth, headers=hdrs, data=data)

PatchManager:

ret = requests.put(url, auth=self.auth, data=data)

I've verified that our API user has full Administrator privileges per this article, so permissions are not the issue.

Thanks for any help you can provide in advance! @honestpuck

[honestpuck]

@ryonriley The problem with 409 errors when accessing the Jamf Pro API is well-known. Graham Pugh has developed a method of API access that uses the APBALANCEID cookie to make sure you hit the same server with subsequent API requests. Unfortunately I cannot test that method personally as my employer is a premium Jamf Pro customer and we don't get that cookie.

Some time later this year I will beg a trial instance off Jamf so I can develop and test an improved version that uses the cookie. Until then I'm afraid I have little to offer as I can't replicate the problem (I have tried. I run PatchBot 5 times a week.) For JPCImporter you might try increasing the delay between attempts to something huge to see if the problem goes away.

[ryonriley]

Thanks for taking a look at it and the insight, @honestpuck! It's unfortunate the API errors haven't fixed by now, but I digress..

In any case, I've tried a few different ways to combat this issue:

1. Increased the delay between update attempts to 2 minutes, 3 minutes, 5 minutes, 10 minutes, 20 minutes, and 30 minutes. Still receiving the same 409 error.
2. Increased the delay before the initial update attempt to 30 minutes. Still receive a 409 error.

My next course of action will be using a combination of Graham's JamfUploader and your JPCImporter processors to leverage the cookie approach. I will report back with the results.

[ryonriley]

To follow up on this for anyone reading: I've updated the JPCImporter post-processor to @honestpuck's JPCImporter v3 which leverages the cookie-based approach, and am still receiving the HTTP 409 conflict.

Potential solutions I've tried:

1. Set the delay between initial package upload and updating the package to 10 minutes via sleep(600), no luck.
2. Set the delay between package update attempts to 2 minutes via sleep(120), no luck.

JPCImporter logs:

This is driving me crazy, but I haven't lost hope yet.

[ryonriley · Accepted solution]

I finally figured it out. Whew!

The answer was much simpler than I had imaged. So, when I was getting to the package update part of the JPCImporter post processor script, it kept failing with the 409. Upon investigating the script, I realized that I didn't have an Applications category on my Jamf Pro instance, hence why the package couldn't be updated. I suppose Jamf was interpreting this mistake as the package is "older" than the one we just uploaded, thus throwing the 409 HTTP conflict error.

The Resolution
All I had to do was create the Applications category on the Jamf Pro instance, then run the script again. Issue resolved.