Extension Attribute not populating on some machines

sburrows
New Contributor III

I have come across a weird issue and I am now stumped and hoping someone here can help me out.

We have an extension attribute that is checking to see if Google updates is turned off using the following code:

#!/bin/sh
VALUE=`defaults read com.google.Keystone.Agent checkInterval`
echo "<result>$VALUE</result>"

If this value is returned as 0 we know that Google updates are turned off. We have a Smart Group that is set up to see if this value is anything other then 0. A policy is scoped to this smart group to run a script to turn off the updates.

So I currently have a handful of machines that are reporting no value at all for this EA, which is causing the policy to apply every time it checks in. 200+ machines are reporting this value fine. If I run the script directly on the device it shows the expected value, but the EA value always returns blank in the JSS. All my other extension attributes seem to be populating fine for these machines.

Anyone have any ideas? We are running 9.7. The machines affected are running 10.9.5, 10.10.2, or 10.10.3

1 ACCEPTED SOLUTION

mm2270
Legendary Contributor III

When you use defaults with just defaults read <plist domain>, its using the account that's running the script for the location to look in. In your case above, that would be root. In other words, without using a full path to the plist for the defaults read command, it assumes something like:

defaults read /private/var/root/Library/Preferences/com.google.Keystone.Agent checkInterval

which is probably why its not returning anything.

If you're looking to read a value in the logged in user account, you'd need to use a different syntax, i.e. get the logged in user's name and path to their home directory, then set the path to the plist.

If you're looking to read a value in a global plist, you'd need to specify the path to it, like

defaults read /Library/Preferences/com.google.Keystone.Agent checkInterval

View solution in original post

5 REPLIES 5

mm2270
Legendary Contributor III

When you use defaults with just defaults read <plist domain>, its using the account that's running the script for the location to look in. In your case above, that would be root. In other words, without using a full path to the plist for the defaults read command, it assumes something like:

defaults read /private/var/root/Library/Preferences/com.google.Keystone.Agent checkInterval

which is probably why its not returning anything.

If you're looking to read a value in the logged in user account, you'd need to use a different syntax, i.e. get the logged in user's name and path to their home directory, then set the path to the plist.

If you're looking to read a value in a global plist, you'd need to specify the path to it, like

defaults read /Library/Preferences/com.google.Keystone.Agent checkInterval

sburrows
New Contributor III

Thanks mm2270 for the explanation. It seems like that is what is happening. I'll have to mess around with my extension attribute to get the path for the currently logged in user.

sburrows
New Contributor III

Thanks again mm2270! I am now using the following code to populate my extension attribute:

#!/bin/sh
consoleUser=`ls -l /dev/console | cut -d " " -f4`
VALUE=`defaults read /Users/$consoleUser/Library/Preferences/com.google.Keystone.Agent checkInterval`

echo "<result>$VALUE</result>"

This is now showing the desired results for the currently logged in user. We must have had an old script that changed this value for the root user, therefore those other machines were showing the expected value.

mm2270
Legendary Contributor III

@Burrows Glad that helped and you got it working!

Naveen_R
New Contributor II

This post is almost 5 years old but still it helped me to fix one of the critical issue that was bugging me from many days in our JAMF environment.

A big Thank You @BurrowsI and @mm2270 :)