So I'm using a policy with a trigger of Login so it's basically a LaunchAgent ... does the command get stored somewhere on the client so I can verify that it made it there? Where do the output and errors go ... jamf.log or do I need the script to redirect everything?
Solved
Where does "File and Processes" get stored and logged?
+9Best answer by sdagley
@mfcfadmin The Files and Processes command is not stored as a persistent file on the client Mac, it's just transitory as the Jamf binary downloads and runs it. By default the only output of that command will be in the policy log on our JSS, and not in the jamf.log file on the client (I've never tried a re-direct in the command itself, so I can't say if that would work). If you're doing something complex enough that you're looking for a log then it's probably more appropriate to create a Script and use a Script payload in a Policy to run it.
+25@mfcfadmin The Files and Processes command is not stored as a persistent file on the client Mac, it's just transitory as the Jamf binary downloads and runs it. By default the only output of that command will be in the policy log on our JSS, and not in the jamf.log file on the client (I've never tried a re-direct in the command itself, so I can't say if that would work). If you're doing something complex enough that you're looking for a log then it's probably more appropriate to create a Script and use a Script payload in a Policy to run it.
+9So the guts of the script is:
/usr/bin/dscl . merge /Groups/lpadmin GroupMembership "$USER"
and the output seems to be:
<main> attribute status: eDSPermissionError
<dscl_cmd> DS Error: -14120 (eDSPermissionError)
command seems fine when sudo'ed in Terminal ... not sure if Apple barfing when running as true root.
+9So the guts of the script is:
/usr/bin/dscl . merge /Groups/lpadmin GroupMembership "$USER"
and the output seems to be:
<main> attribute status: eDSPermissionError
<dscl_cmd> DS Error: -14120 (eDSPermissionError)
command seems fine when sudo'ed in Terminal ... not sure if Apple barfing when running as true root.
So it seems to be better to do the output and error redirecting inside the script with something like
exec >> "$LogFile" 2>&1
rather trying to work in that field ... especially seems to dislike ampersands.
And since the script is running as root, it's better to use this old trick
W=$(w -h 2>/dev/null | grep -E ' console ' | sed -e 's/ .*//')
to determine who's logged into console.
+9One of the concerns I had was that Apple tends to not allow scripts to run as root so in the past I've had to have the script parse things using perl and then call a compiled binary to do the stuff as root. The Files & Processes doesn't seem to be under those restrictions ... for now.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.