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

[DBrowning]

just installed 9.8 on my test server. When I logged in for the first time I got a notification stating: "Script contains invalid reference to /usr/sbin/jamf"

Does this mean they have moved where the command is?

[mm2270]

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.

[DBrowning]

Read release notes? who does that?

Thanks.

[scottb]

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.

[ooshnoo]

I read them

[Chris_Hafner]

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?

[Aziz]

@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

[Chris_Hafner]

@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.

[Aziz]

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

[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.

[yellow]

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?

[mm2270]

@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.

[yellow]

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.

[Aziz]

@yellow

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

[mm2270]

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.

[yellow]

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.

[mm2270]

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.

[DBrowning]

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.

[yellow]

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

[mm2270]

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

[Aziz]

Here's another screenshot:

optional image ALT text

[georgecm12]

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

[mm2270]

@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.

[dmw3]

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

[mm2270]

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.

[dmw3]

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?

[mm2270]

@dmw3 Click the link from your image posted that's labeled "Update policies here" It should bring you straight to the Policies page. Our Policies page has all categories collapsed by default. I just clicked "Show All" and scanned the list for any policies that had a triangle next to the name. Those are the ones its referencing and would need to be either fixed, or, if they are already fixed, have the messages cleared from them. You need to go into each policy to clear the message.

If you aren't seeing any triangles next to any policy names, well, I'm not sure what to say about that. I guess I'd probably open a case with JAMF support to find out what to do next. It should be indicating which policies need to be fixed though.

[dmw3]

@mm2270 Thanks for the reply, no indication, red triangles or other icon to indicate which policy needs fixing.

Time to call JAMF support.

[joshuasee]

I also ran into the no triangles problem, noticed that another tech logged in to the same JSS did see them. They eventually appeared for me as well. Try adjusting the window width before login or another browser.

[jevans76]

I have the same issue.

Click the "Update policies here" link which takes me to the policies page, but no indication of which policy is causing the issue?

Don't think it is a browser issue, as an issue I had with a script did display properly from the same browser instance?

[snovak]

@Abdiaziz

Wait, we can't write to utilities anymore? Great... Now where is Adobe going to put all of their uninstallers?!

[Aziz]

@snovak

Same with the Creative Cloud Packager. They'll probably just create a folder in /Applications/

[bpavlov]

Didn't someone mention the other day that the documentation was wrong and that you can indeed write to /Application/Utilities but you cannot modify or touch any of the Apple apps contained within?

[Aziz]

@bpavlov @snovak

You are correct, I just tested it and it worked. Looks like Adobe is fine for now!

[Chris_Hafner]

They should put them where I do...

/Library/Application Support/JAMF/Waiting Room/

;-)

[snovak]

Better yet:

/Users/{Admin Account}/.Trash

[Chris_Hafner]

Hah, no way. Those uninstaller are worth their weight in gold! ;-)

[mm2270]

@bpavlov Yes, that was Rich Trouton who pointed that out. Apple's documentation was vague and, well, wrong. I was also confused by this. Only the Apple installed apps in Utilities are protected by SIP. The Utilities folder itself is not.

Still, I hope Adobe takes this as an opportunity to rethink where they are putting their uninstallers. (I know they probably won't, but we can hope) Uninstallers shouldn't be going into Utilities anyway, maybe /Library/Application Support/ would be a better place for its 'stuff'. You know, kind of like every other developer does.

[simon_heers]

About Policies referencing the old binary, but there are no policies to update/dismiss the message.
https://jamfnation.jamfsoftware.com/discussion.html?id=17278