During your testing of macOS Monterey (betas or today after it’s release), you might receive a prompt like that shown above.
Well, does this mean that the “JamfManagementService” needs an update? Nope! and, to be clear, this is something you’ll likely see even if you don’t use Jamf.
Below is some information on this message, what triggers it, and how to start to uncover what on your macOS devices are triggering it.
- 1 So, what triggers it?
- 2 So, does this mean that the “JamfManagementService” includes Python 2 code?
- 3 Ok, so we just change to /usr/bin/python3?
- 4 How do we start to uncover what is calling Python 2?
- 5 /usr/bin/python is what we need to avoid?
- 6 Is there anything that can help us to track down Python 2 triggering items in Jamf Pro?
- 7 We’ve triple checked, but are still seeing some prompts?
So, what triggers it?
The prompt is triggered by a process calling: /usr/bin/python
The /usr/bin/python binary is Python 2, which was sunset 2020-01-01.
So, does this mean that the “JamfManagementService” includes Python 2 code?
This blog purposely has the title “…..” needs to be updated.
As the “…..” is the parent or calling process, (which if you’ve dealt with PPPCP before should be a familiar thing).
The prompt and the top of the article was due to an Extension Attribute within Jamf Pro, which itself was calling the Python 2.
In fact, it was the old Extension Attribute for jamJAR.
So, the jamf binary was running a recon.. which in turn called the Extension Attribute which had a shebang of: /usr/bin/python
The same Extension Attribute, also triggered the following prompt, at another time:
And, also the below prompt, at yet another time:
This last prompt was caused by jamJAR. Let me try to explain the events that lead to the above prompt.
- Munki ran and installed/uninstalled a title
- jamJAR‘s postflight saw a title was installed/uninstalled during the Munki run, and ran a recon via the jamf binary.
- The recon in turn called the old jamJAR Extension Attribute which had a shebang of: /usr/bin/python.
The reason this shows as “Python” is that the parent process at the start of the above, was the Python 3 which ships with Munki.
Similarly, the image at the top of this blog is due to a Jamf Pro policy starting the process listed above. So it then becomes the parent process.
Ok, so we just change to /usr/bin/python3?
There are a few changes between Python 2 and Python 3, which will whatever is running under Python 2 to be amended for Python 3.
And, whilst on macOS there is a file at /usr/bin/python3, it’s a stub only. Calling this will prompt to install Xcode’s command line tools.
One option, is to rewrite the item into another language. This is what we did with jamJAR’s Extension Attribute.
Another option, may be to use another version Python being shipped to devices. Like Munki‘s Python 3 or ship your own via something like relocatable Python.
How do we start to uncover what is calling Python 2?
Well, under the user account that saw the prompt you can check for the contents of the file:
This is a per user plist, so would be something you’d need to check under the user account which saw was presented with the prompt.
The file won’t exist if nothing has prompted for that user and below is an example of the content:
So, this helps us to track things down, but this is the parent process as mentioned above.
This can be troublesome as it might not be 100% clear as to what the parent process called to trigger the prompt.
It could even be something within a bash script, such as this.
/usr/bin/python is what we need to avoid?
If a script etc is calling just python, this can trigger this prompt too.
As when calling python, you’re calling /usr/bin/python. As shown below:
$ which python
Also, if /usr/bin/env python is being called, then the OS is being directed to traverse the directories shown in $PATH for a file named “python” and to then use that. Which will be Python 2
Is there anything that can help us to track down Python 2 triggering items in Jamf Pro?
Yes, there is. Enter jamf-migrator.
You can enable the options shown below, and then export Computer Scripts and Extension Attributes as XML locally which can then be checked to see if they contain references to /usr/bin/python and /usr/bin/env python.
We’ve triple checked, but are still seeing some prompts?
I suspect that this might be a common frustration for some time.
There may well be some processes which lead to /usr/bin/python or /usr/bin/env python being called, and this might take some time to uncover.
Also, /usr/bin/python and /usr/bin/env python might well be being called from within a pkg’s preinstall or postinstall script.. or a process which they themselves call.
In those instances, I’d suggest reaching out to people within macadmins Slack, as a a problem shared is a problem halved.