Skip to main content
Question

whereis jamf binary

  • April 11, 2016
  • 4 replies
  • 81 views
M
Forum|alt.badge.img+9

Hi JAMF NATION

I am In the process of upgrading our JSS from 9.73 -> 9.9 (testing done on 9.82)

We have a number of scripts that reference the full jamf binary path at /usr/sbin/jamf
I received advice to remove the full binary path within the scripts and just use jamf.

In our dev environment machines running 9.82 binary fail to run the scripts correctly as it doesnt know where the jamf binary is since the upgrade on the client.

if I run whereis jamf in terminal it is unable to find out where the binary is located.
But I can run jamf policy etc without the full path from terminal...

The machine was historically on 9.73 so perhaps has cached the path of /usr/sbin/jamf ? which now doesn't exist since binary upgrade.

Will i need to add @rtrouton check binary script to all my scripts that reference the jamf binary? will this only affect machines upgrading or will it also be an issue for machine being built directly to 9.9?

You help is much appreciated!

    4 replies

    K
    Forum|alt.badge.img+13
    • kerouak
    • Valued Contributor
    • April 11, 2016

    its /usr/local

    T
    Forum|alt.badge.img+15
    • thoule
    • Contributor
    • April 11, 2016

    The command is: 

    bash-3.2# which jamf
/usr/local/bin/jamf

    That's slightly tricky as /usr/local/bin/jamf is actually a symlink that points to /usr/local/jamf/bin/jamf However you should use the path provided by the which statement as that is likely to be more stable than referencing the binary directly.

    I don't recommend using just 'jamf' alone in the script - use the path /usr/local/bin/jamf as some scripts may not have the path environment variable.

    If you are referencing CasperCheck which looks for the binary, then yes that needs to be updated. Rich has an updated version with the paths fixed.

    D
    Forum|alt.badge.img+6
    • drew_duggan
    • Employee
    • April 11, 2016

    Hey @myronjoffe,

    With 10.11, Apple introduced System Integrity Protection (SIP) for added security to the OS. One of the things this did was lock out third-party developers from the /usr/sbin/ directory. So, 9.8 actually saw the jamf binary moved to the /usr/local/jamf/bin/jamf (as well as the jamfAgent that had to be moved as well).

    On machines running 10.7 thru 10.10 with the 9.8 binary, you should see that the new binary location is active, but there's also a link in the old /usr/sbin/ redirecting any jamf binary actions to the new locale when necessary. Machines running 10.11 wouldn't have redirect link since third-party developers no longer have access to that directory. This likely explains the behavior you're seeing here.

    So, if you have the paths hardcoded in your script(s), you'd need to get those updated to reflect this. Hope this helps, but if you have any other questions feel free to throw them back out here or reach out to JAMF Support, and they should be able to help as appropriate.

    Thanks!

    M
    Forum|alt.badge.img+9
    • myronjoffe
    • Author
    • Valued Contributor
    • April 11, 2016

    Thanks @drew.duggan long time ;)

    The problem is one of the scripts is a network access control script. That locks down the machine when updating as it refs the old jamf path and we can't add the new full path of the binary before upgrading as it doesn't exist. Seems like I will use troutons binary check.

    Terms & ConditionsCookie settingsAccessibility statement