9.8 is out...

we had a LOT of problems installing on a split DMZ/JSS/MySQL environment. Eventually had to turn off clustering and then I was able to upgrade both DMZ and Internal JSS to 9.8

Upgraded 9.72 to 9.8 on Windows server ( 2008R2 ).
Worked perfectly, first time I've done an upgrade on windows without major grief !

Upgraded 9.72 to 9.8 (ubuntu 14.04) and Apple Remote Desktop (ARD) can no longer run jamf commands. I get an error saying "/bin/bash: line 1: jamf: command not found". Posted in another thread about this as well. Is there any way to submit a bug report that I'm not seeing?

JAMF moved the binary in the last version to get ready for SIP in El Capitan. I think it's in /usr/local now. Are you specifying the full path to the binary?

Hi @skoonin

Are you referencing the full path to the binary or just calling jamf and hoping the system knows where to look?

To do a policy update try

sudo /usr/local/bin/jamf policy

and see what happens.

yea using the full path works, however this is not ideal. seems that the path variables for 9.8 need to be updated

that is a user/admin responsibility, update your .bashrc .cshrc etc files.

To me personally if a software vendor changes the path to the files they use, it is in fact the software vendors responsibility to update the path, or at least put symlinks in place pointing to the new location.

Just my two cents

@skoonin , @bbelew

I do apologize for the issues the binary location move has caused for some scripts; the move is not something we just did arbitrarily, however, and it was documented in the 9.8 Release Notes on pages 4 and 7.

The location change is due to the System Integrity Protection (SIP) being implemented in OS X 10.11 El Capitan.
This change will limit what sorts of processes can run from which locations, and one of the locations that has restrictions on it is /usr.
In 9.8, the change was made in preparation for the change that is coming in El Capitan.

The location of the following files has moved in 9.8 due to this:

/usr/sbin/jamf has moved to /usr/local/jamf/bin/jamf

/usr/sbin/jamfAgent has moved to /usr/local/jamf/bin/jamfAgent

The binary and jamfAgent on the client's side, will be moved to its new location the first time the computer checks in to the JSS after the upgrade to 9.8.

We have included a symlink so typing in the usual sudo jamf verbgoeshere should work, but it seems to not always work with scripts (and certainly won’t work if your script is calling the full path of /usr/sbin/jamf or /usr/sbin/jamfAgent) and older versions of Recon will not work with the symlink either.

In those cases, we will need to manually update the scripts that are not working and, for older versions of Recon, we’d simply need to upgrade to the latest version.

In addition, because of the change coming to 10.11, we highly recommend getting your environment updated to at least 9.8 before upgrading any OS X devices to 10.11 just to ensure that the binary move goes as smoothly as possible.

If you have additional questions or would like some more in depth (or environment/script specific info), please get in touch with your Technical Account Manager by either giving them a call, e-mailing support@jamfsoftware.com, or using the My Support section of JAMF Nation.

Thanks!
Amanda Wulff
JAMF Software Support

I'm with Todd, no way for the "vendor" to "read the admin's mind" on what and if change. : )

C

@amanda.wulff

Hi Amanda,

Thanks for the info. The issue I have seen is not a script related issue, but connected to Apple Remote Desktop. Up until 9.8, I could easily send commands to computers by just using the jamf command (eg. jamf recon) and run as the root user. In 9.8, this does not work in ARD and the full path to the binary is needed (eg. /usr/local/jamf...)

Seems that the upgrade of the binary on machines also should be updating all the appropriate PATH variables in the OS, no?

@skoonin

In theory, yes, the symlink should work, but it's possible that it may not when using ARD or with non 9.8 versions of Recon or Remote.
Unfortunately, I'm not terribly familiar with the inner/backend workings of ARD, and am not certain how it normally handles symlinks for things like that.

In those cases, a potential workaround may be pushing out a small script that adds the new path of the binary & jamfAgent to the system path, however, that is not something we've tested here and I can't guarantee it would work (so would recommend, if you try, only push it to a handful of test machines to verify that it works as expected), but it may still be something to try.

In regards to the binary upgrade also updating the appropriate system path variables, that would be something that I'd recommend opening up as a Feature Request.

Thanks!
Amanda Wulff
JAMF Software Support

ok thanks. I'll submit a feature request, although this seems that is should be a requirement?

just stranger that locally on the systems the binary works as expected, so the path is in there somehow. but in ARD the response is "/bin/bash: line 1: jamf: command not found"." So, it somehow pulls from a different PATH variable.

There's a thread going about ARD and environment variables:

https://jamfnation.jamfsoftware.com/discussion.html?id=16970#responseChild99805

@skoonin

It works locally because we did put in a symlink with 9.8 to compensate for /usr/local/bin/jamf and /usr/local/bin/jamfAgent not usually being part of the default system path; it just seems that some scripts (that do not have the full /usr/sbin/jamf path typed out, and just call the jamf binary as jamf dothething) and some programs are having issues with recognizing it.

While we do know that it doesn't work with pre-9.8 versions with our apps, why it doesn't work with versions of other apps would be something that would likely require opening up a case so your Technical Account Manager could look into it further, or checking any documentation you may have for the program to see if there is any mention as to how it handles symlinks.

Edit to add: Or you could take a peek at the thread @rtrouton posted about two seconds before I hit post. There is some good info there and it looks like the template he posted should get ARD working for you again.

Thanks!
Amanda Wulff
JAMF Software Support