Modifing extension attributes scripts to prepare for Yosemite

ericjboyd
Contributor

Hi All,

I am going through my Extension Attribute scripts to prepare for 10.10
I have used rtroutons filevault2 EA as my template for scripts than are version specific.

eg:

osversionlong=`sw_vers -productVersion`
osvers=${osversionlong:3:1}

and using :

if [[ ${osvers} -ge 7 ]]; then

how should I rescript this?

3 ACCEPTED SOLUTIONS

mm2270
Legendary Contributor III

Doesn't need to be, at least at first glance. We'll have to see if anything else would need to be reworked to account for possible changes in Yosemite, but the snippets you posted are simply getting the middle digit of the OS version, like "8" from Mountain Lion, "9" from Mavericks. etc. The second part simply looks to see if that digit is equal to or greater than "7", since FileVault 2 didn't exist on earlier OS X versions.

Edit: Sorry, I take that back. Since with 10.10, the middle "digit" is actually two numbers, the code above would only pull "1" not "10" and the EA wouldn't work. You may want to consider using the clunkier but more reliable method of using echo + cut, like so:

osversionlong=`sw_vers -productVersion`
osvers=$(echo $osversionlong | cut -d. -f2)

echo $osvers

View solution in original post

chriscollins
Valued Contributor

or:

osvers=$(sw_vers -productVersion | awk -F. '{print $2}')

View solution in original post

rtrouton
Release Candidate Programs Tester

I actually did a clean-up of my FileVault 2 check scripts about a month or so ago and fixed the OS check for the FileVault 2 extension attribute so that it would work properly on 10.10. The latest version is available from here:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/filevault_2_encryption_che...

View solution in original post

13 REPLIES 13

mm2270
Legendary Contributor III

Doesn't need to be, at least at first glance. We'll have to see if anything else would need to be reworked to account for possible changes in Yosemite, but the snippets you posted are simply getting the middle digit of the OS version, like "8" from Mountain Lion, "9" from Mavericks. etc. The second part simply looks to see if that digit is equal to or greater than "7", since FileVault 2 didn't exist on earlier OS X versions.

Edit: Sorry, I take that back. Since with 10.10, the middle "digit" is actually two numbers, the code above would only pull "1" not "10" and the EA wouldn't work. You may want to consider using the clunkier but more reliable method of using echo + cut, like so:

osversionlong=`sw_vers -productVersion`
osvers=$(echo $osversionlong | cut -d. -f2)

echo $osvers

ericjboyd
Contributor

You are right. However in Yosemite the result is 1 instead of 10.
Then the script fails the greaterthan 7 test.

mm2270
Legendary Contributor III

See my original post updated. I realized that after I posted. An alternate method is mentioned.

chriscollins
Valued Contributor

or:

osvers=$(sw_vers -productVersion | awk -F. '{print $2}')

rtrouton
Release Candidate Programs Tester

I actually did a clean-up of my FileVault 2 check scripts about a month or so ago and fixed the OS check for the FileVault 2 extension attribute so that it would work properly on 10.10. The latest version is available from here:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/filevault_2_encryption_che...

ericjboyd
Contributor

Rich:
on line 170, please edit : echo "FileVault 2 Encryption Not Enabled"
to echo "<result>FileVault 2 Encryption Not Enabled</result>"

rtrouton
Release Candidate Programs Tester

Fixed, thanks for the catch.

ericjboyd
Contributor

Rich: I submitted a pull request that kills the running of the script if the OS is <10.7 first.

rtrouton
Release Candidate Programs Tester

@ejboyd,

I saw the pull request, but I'm not convinced it's a needed change. That said, feel free to modify the script in your own shop to meet your needs.

mm2270
Legendary Contributor III

Just a note. I'm not certain what you submitted as a pull request, but in my own experience (and the experience of others) its actually not possible to kill an Extension Attribute script in the same way you can do with a normal script. All that happens is a blank value is returned along with inventory for that EA. That may or may not be what you expect. Seems the jamf binary doesn't treat EA scripts the same way as other scripts, so simply putting in an exit line will not leave any existing value in place. It still uploads a value to update the computer record; it will just be blank.

In this case, maybe thats fine since if the Mac is < 10.7 you wouldn't want it to report anything, but I personally would just have it report something like "Not Applicable"
Just my 2¢.

ericjboyd
Contributor

I have a couple PPC machines that took > 5 minutes to run the script. If the mac is <10.7 it still tries to set the variables.
Once I moved the following to the top of the script, running recon took next to no time to run that EA and provide a valid response.

osvers=$(sw_vers -productVersion | awk -F. '{print $2}')
if [[ ${osvers} -lt 7 ]]; then
  echo "<result>FileVault 2 Encryption Not Available For This Version Of Mac OS X</result>"; exit 0
fi

mm2270
Legendary Contributor III

Yeah, well that makes sense b/c you are actually setting up a result and echoing it back and then exiting. I wasn't necessarily referring to how long the EA script should take to run, more about the results that get returned.
For example, I have an EA script that uses the API to pull the management account in use on the Mac. Since the API is inaccessible from outside when a Mac reports into the Limited Access JSS, I tried having the script simply exit and not return any result, but that doesn't work. It blanks out the results in the record, so I had to work up other workarounds for that.

In your case, it makes sense it was taking a while to finish since the rest of the commands were trying to get information that didn't apply to that Mac. But the way you have it now makes the most sense.

sean
Valued Contributor

Hate to say 'I may have mentioned this warning some time back' regarding scripting in advance for 10.10....................., but ;)

https://jamfnation.jamfsoftware.com/discussion.html?id=3333