Scripting help for a raw newbie

[kyoung]

I got what is basically a generic script off JN to use to find a contraband file on users laptops. Since I am just starting to develop this solution I have made the script available to a test laptop with a policy triggered by a reoccurring check in. I am running the scrip and watching the results at the test laptop by using "sudo jamf policy" at the command line. The script runs and returned this:

1 What do I need to do to the script to get it to fill in a "Script result:" value at the command line so I can monitor the trial results while I am at the local test machine?

2 How do I get that info back to the jss for reporting to me or if it is automatically sent back to the JSS already where is it stored?

The script:

Thanks for any guidance.

[alexjdale]

Anything you "echo" back out will show up in the policy log after "Script result:" Your script returns nothing if Minecraft is not found. You could add an "else" branch that would echo "Does not have minecraft" if you always want something logged.

The example you have given appears to be designed for an extension attribute, though. I see a couple other things that could be problems, but I don't have Minecraft installed to test it.

[iJake]

I would also not assume that the home folder is the same as the username. It should be but things happen.

currentUser=$(stat -f %Su "/dev/console")
homeFolder=$(dscl . read "/Users/$currentUser" NFSHomeDirectory | cut -d: -f 2 | sed 's/^ *//'| tr -d '
')

As @alexjdale mentioned, you have this designed to be an Extension Attribute but running as part of a policy. You can leave the script as it is and move it to an EA or have the action to take be part of this script and then leave it as a policy.

[kyoung]

You sir are an eagle eyed techno stud. It was set up for being an EA but I do not have the experience to know what that means. I saw an icon in "Computer Management" for "Scripts" and the form to fill out in "Extension Attributes" has a place to create a script there as well. What is the difference? Where would I use one method but not the other? (I am so green I don't know how to include your handle in this reply.)

[thoule]

Scripts are script which you run on a computer based on policy or rules. Maybe a script to force a reboot, then run it every day at midnight? Create a script, then deploy it with Smart Group/Policy.

Extension Attributes are a way to get more info about a computer. These are run whenever inventory is updated on a computer (usually once a day). I have an EA to determine if Apple Software Updates are available and one to determine the version of an anti-virus program installed for example. Whatever is included in the "<result>" tags is returned so you can see it when you look at the computer in the JSS. See (https://jamfnation.jamfsoftware.com/extensionAttributes.html) for a public list of shared extension attributes.

[mm2270]

Extension Attributes (EAs) are custom database fields. Basically, information that gets populated and added to the Mac's inventory record each time the Mac submits inventory. Most Extension Attributes are populated via a script like the one you posted, though they can be other things like manual input. EAs allows you to do advanced searches on that information, or build Smart Groups based on the info, for example. Although there is the concept of "active EAs" meaning Extension Attributes that actually take an action besides just passing information back to the JSS, most people aren't using that process and are instead using EAs as data collection scripts.

Regular scripts are more for policies or imaging configurations, something you want to run to affect something on the Mac based on a trigger, like check-in or whatever, or run post imaging.

That's the basic difference between them. Hope that helps.

[kyoung]

Those explanations help a bunch. Thank you very much.

The next question is what are the things I would need to do to make a script suitable for an EA and what do I do to make a script for a "Script"?

[mm2270]

Well, generally speaking, for a script to work as an EA script, it needs to include an echo line somewhere in the script (usually at the end) that uses the format of

echo "<result>some string or variable here</result>"

Essentially, a string or a variable that's generated within the script will be wrapped in the <result> and </result> tags and echoed. The jamf binary picks this information up when the script is run and uploads that info to the JSS for that computer record, for that specific EA field.
I would say the number 1 mistake made by newcomers to Casper is forgetting to wrap the information in those tags. If the jamf binary does not see that, it won't pick anything up and the EA will remain blank in the computer record.

In regular scripts run in a policy, usually there is an action taken, such as changing an account from "standard" to "admin" or maybe the other way around, or applying a setting using defaults or removing a file, placing a file, etc. Basically its almost endless what a regular script can do. EAs are typically for collecting data as mentioned, whereas scripts will do something to the machine. They can be used just to echo back information, but there isn't a lot of use in just doing that with a script run in a policy.

[kyoung]

I think I have got an EA that is working the way I want it too with that criteria used to populate a smart group. Thanks you very much.

Are there facilities in Casper that give me some of the flexibility in timing and frequency of running the EA that I can get from a policy?

[roiegat]

The EA runs when the inventory is done (sudo jamf recon). Typically this is done once a day. But you can can create a policy to update inventory more often if you wish.