Posted on 09-03-2014 11:50 AM
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?
Solved! Go to Solution.
Posted on 09-03-2014 11:59 AM
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
Posted on 09-03-2014 12:13 PM
Posted on 09-03-2014 02:45 PM
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:
Posted on 09-03-2014 11:59 AM
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
Posted on 09-03-2014 12:10 PM
You are right. However in Yosemite the result is 1 instead of 10.
Then the script fails the greaterthan 7 test.
Posted on 09-03-2014 12:11 PM
See my original post updated. I realized that after I posted. An alternate method is mentioned.
Posted on 09-03-2014 12:13 PM
or:
osvers=$(sw_vers -productVersion | awk -F. '{print $2}')
Posted on 09-03-2014 02:45 PM
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:
Posted on 09-03-2014 05:57 PM
Rich:
on line 170, please edit :
echo "FileVault 2 Encryption Not Enabled"
to
echo "<result>FileVault 2 Encryption Not Enabled</result>"
Posted on 09-03-2014 07:18 PM
Fixed, thanks for the catch.
Posted on 09-05-2014 10:46 AM
Rich: I submitted a pull request that kills the running of the script if the OS is <10.7 first.
Posted on 09-05-2014 10:54 AM
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.
Posted on 09-05-2014 11:06 AM
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¢.
Posted on 09-05-2014 11:24 AM
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
Posted on 09-05-2014 11:30 AM
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.
Posted on 09-09-2014 01:19 AM
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