EA to list site?

#!/bin/sh

# This script uses the client's serial number to make an API call so we can store its assigned site.

serialNo=$(system_profiler SPHardwareDataType | grep 'Serial Number (system)' | awk '{print $NF}')

site=`curl -H "Content-Type: application/xml" -u read:readonly https://yourorg.com:8443/JSSResource/computers/serialnumber/$serialNo/subset/general -X GET | sed -e 's,.*<name>([^<]*)</name>.*,1,g'`
echo "<result>$site</result>"

We typically move anything that takes more than .01 seconds into two pieces. A script to run the API command and output the Site to a file (once a day policy) and then an EA to scoop up the Site from the file. For security reasons we move the API credentials and URL to Script Parameters.

#!/bin/sh

# Parameters
apiUser="$4"
apiPass="$5"
jssURL="$6"

# Get UDID of computer
udid=$( ioreg -rd1 -c IOPlatformExpertDevice | awk '/IOPlatformUUID/ { split($0, line, """); printf("%s
", line[4]); }' )

# Get Site
siteName=$( /usr/bin/curl -s -u ${apiUser}:${apiPass} ${jssURL}/JSSResource/computers/udid/${udid} | /usr/bin/xpath '/computer/general/site/name[1]/text()' 2>/dev/null )

# Send Site to file to get  picked up by EA on next Inventory Update
if [[ $siteName ]]; then
   echo "${siteName}" > /Library/Company/APIscripts/checkSite.txt
else
   echo "NotAvailable" > /Library/Company/APIscripts/checkSite.txt
fi

exit 0

Thanks, and thanks especially for the idea of moving the credentials. I'd found the 1st script, but didn't want to stick a PW into it... hadn't occurred to me to do it the other way. I'd REALLY like a way to simply do it without having to script the thing, but that's one of those "hey, already in the database!" issues that makes me scratch my head :)

Meanwhile, think I may have figured out a way to pull the computer's .ou from AD via adquerry (we use Centrify), but taking a closer look.

I just want to clarify that those aren't actually my credentials. They're just there to symbolize a read-only account.

I like @donmontalvo 's way of doing it. I was just too lazy to do it that way at the time.

@Taylor.Armstrong I can confirm those were not @Asnyder's credentials. #tongueInCheek

Using parameters for sensitive/confidential stuff is not my idea, it's Jamf's recommendation.

We do our scripting using flat files, then when we move it into Jamf Pro we hide that stuff.