Script contains invalid reference to /usr/sbin/jamf... in 9.8

Yes, look over the 9.8 release notes. Its mentioned right on the first page or so.
You probably should always look over release notes before installing a new version.

Read release notes? who does that?

Thanks.

New location for jamf binary—The jamf binary is now located in /usr/local/jamf/bin/jamf. (The previous location was /usr/sbin/jamf.) The location is updated automatically during the upgrade to v9.8. Action is required if existing packages, scripts, or extension attributes reference the previous location of the binary. For detailed information, see the Functionality Changes and Other Considerations section.

I read them

For those of you who know more than I (Most of you). I'm using /usr/local/bin/jamf Is there any reason I shouldn't and instead use the documented /usr/local/jamf/bin/jamf?

@Chris_Hafner

Apple is restictng write access to a lot of places which also includes /sbin/. This is called System Integrity Protection or SIP.

With yesterday JSS 9.8 update, the JAMF binary was moved from /usr/sbin/jamf to /usr/local/jamf/bin/jamf.

optional image ALT text

@Abdiaziz Absolutely! I'm just wondering if there is any technical reason why I would want to use

/usr/local/jamf/bin/jamf

vs

/usr/local/bin/jamf

The second is an alias, that's all. Call this a question of best practice.

Ahh gotcha!

I was attempting to use "/usr/local/jamf" this morning but kept getting "No Such File or Directory". Reverted to "/usr/local/jamf/bin/jamf" instead. YMMV

@Chris_Hafner

Heh, what? It's late in my afternoon... I'm pretty sure I know what you mean but I figured I should check anyways ;-)

EDIT: Thanks! On that note, I think I will use the full path.

Slightly curious why not put a symlink from the old location to the new one as part of the binary replacement as clients get upgraded from older versions of the binary?

@yellow If you mean why isn't JAMF placing a symlink to /usr/local/jamf/bin/jamf into /usr/sbin/, its for the same reason they can't just put the jamf binary into /usr/sbin/ That location will be off limits to anything but Apple processes under OS X 10.11. So they can't actually place a synlink there.

Ah, I see. I guess that makes sense. I've not read much on SIP and 10.11 yet.

I guess for now I'm trying to find the references to the old location that I'd thought I eradicated in the JSS, but am still told they exist.

Policies contain invalid references to /usr/sbin/jamf
Update policies here

Still looking for them and cannot find them. Anyone know if there's a reference to WHERE in a log? I can't seem to find any references to it in the release or resources docs.

@yellow

I have references to /usr/sbin, but none to /usr/sbin/jamf and I still get that message.

Ah, I see. So, I think this is actually a bug in 9.8. I'm working on a 9.8 JSS myself and I corrected the 2 locations that the JSS is telling me the old reference was in, but it keeps telling me they exist each time I log in. Its the same locations too, so its not like its finding something new. I'm going to see if bouncing the server will remove those messages. For some reason it keeps thinking they are there, so there must be some way to clear them, but I haven't found it yet.

If I figure out how to remove the messages after making the corrections, I'll post back.

So I went through all my policies and there is indeed no policy with an overt reference to /usr/sbin/jamf, nor /usr/sbin. The closest I have as an execute command is /usr. But I still get the notification. I went through all my shell scripts as well, but guess I need to do it again just to be sure I didn't miss a reference somewhere.

The way I understand it and have seen it is, you'll see a small triangle next to any policies, scripts or otherwise that contain the invalid references to the old binary location. I've also gone through all of them and made sure they are now correct, but continue to see the alert message. So something isn't getting updated to remove those alerts it seems.
Again, I'm going to see if a full reboot fixes it, but honestly, we shouldn't need to do that to get rid of those messages. I appreciate that the upgrade lets us know exactly what to fix, but JAMF needs to improve how it responds after making the corrections. Hopefully in 9.81.

My guess is since 10.11 is being released on Wednesday, 9.81 will probably be available that morning. I'm hoping that will resolve this issue.

All references purged, for sure from policies, packages, and scripts. Rebooted. Still have the notification.

@yellow Well, thanks for saving me the trouble. :) Looks like something JAMF needs to address then.

Here's another screenshot:

optional image ALT text

@yellow (et. al.): The notification doesn't clear automatically once the scripts have been updated. You have to manually clear the notification yourself.

@georgecm12 Thanks. I will take a closer look, but I didn't recall seeing a way to clear the messages. But I may have just missed it.

@mm2270 The notifications on our JSS cleared after a restart of the server.

OK, so there is a way to dismiss the warnings, but its not done automatically after making the edits. I can't confirm at this point if a reboot actually does clear them, but its possible it does based on the post from @dmw3 above?
In any event, when you locate the highlighted items that need attention and go into them, there is a "Dismiss" button up at the top of whatever you are in that you can click to clear the alert, but its on a one by one basis. No way to clear them all at once that I can see. For example, I went into a script I know I had edited that was still saying it had an invalid reference to the binary. I confirmed it was correct and up top it stated "Script contains invalid reference to /usr/sbin" with a "Dismiss" button on the far right side. Clicking that will let you clear the message (after confirming in a pop up dialog)

Hope that helps some others who were confused by this as well.

Even with fixing and clearing the scripts notifications, we are still left with a notification about policies. There is no indication which if any or all are needed to be checked unlike the scripts which were hilighted as to which needed to be fixed.
Any ideas?