Ok, so we just change to /usr/bin/python3? Similarly, the image at the top of this blog is due to a Jamf Pro policy starting the process listed above. 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. The recon in turn called the old jamJAR Extension Attribute which had a shebang of: /usr/bin/python.jamJAR‘s postflight saw a title was installed/uninstalled during the Munki run, and ran a recon via the jamf binary.Munki ran and installed/uninstalled a title.
Let me try to explain the events that lead to the above prompt. The same Extension Attribute, also triggered the following prompt, at another time: which in turn called the Extension Attribute which had a shebang of: /usr/bin/python In fact, it was the old Extension Attribute for jamJAR. The prompt and the top of the article was due to an Extension Attribute within Jamf Pro, which itself was calling the Python 2. This blog purposely has the title “….” needs to be updated.Īs the “….” is the parent or calling process, (which if you’ve dealt with PPPCP before should be a familiar thing). So, does this mean that the “JamfManagementService” includes Python 2 code? The /usr/bin/python binary is Python 2, which was sunset. The prompt is triggered by a process calling: /usr/bin/python 7 We’ve triple checked, but are still seeing some prompts?.6 Is there anything that can help us to track down Python 2 triggering items in Jamf Pro?.5 /usr/bin/python is what we need to avoid?.4 How do we start to uncover what is calling Python 2?.3 Ok, so we just change to /usr/bin/python3?.2 So, does this mean that the “JamfManagementService” includes Python 2 code?.
0 kommentar(er)
