Software Updates for remote Macs encrypted with Filevault2?

easyedc
Valued Contributor II

So we've finally moved from a monolithic rebuild every time we needed to update from one OS release to another. Now I'm scratching my head as to patch management for our now FileVault 2 encrypted Macs? I'm testing the process for patching 10.8.2 to .3 and it will require a reboot. Per company policy this should run overnight to minimize production outage time. With the reboot, running via a policy remotely, it will just hang out at the FileVault login screen. I'm scratching my head as to how I should do this. If I were doing it via command line from my desk, I'd run through the fdesetup authrestart process manually, but that's not an option for our operations team.

Thoughts?

1 ACCEPTED SOLUTION

easyedc
Valued Contributor II

I brought this up at the JNUC last week and @rtrouton and a few others mentioned that what I'm trying to do doesn't work. There is a feature request out there to add what I'm trying to do to the Casper Suite.

Edit: link to feature request
https://jamfnation.jamfsoftware.com/featureRequest.html?id=1255

View solution in original post

8 REPLIES 8

gregneagle
Valued Contributor

Do it at logout, or when no user is logged in. Yes, it will reboot afterwards and sit at the FV authentication screen (or shut down), but the update will be done. Your users can then power up and login.

aamjohns
Contributor II

It seems like fdesetup authrestart process is your only choice to do what you want.

I use a similar process with PGP encrypted machines. When the processes are completed I then add an administrative bypass command through script that will bypass the PGP auth screen and allow the machine to boot to the logon screen.

So it appears the equivalent would be to run the fdesetup authrestart. When you say your operations team cannot do this, why not? If your company wants overnight maintenance, they might have to do this.

I hope it works out.

Aaron.

JPDyson
Valued Contributor
So it appears the equivalent would be to run the fdesetup authrestart. When you say your operations team cannot do this, why not? If your company wants overnight maintenance, they might have to do this.

Because maybe, since he's a Casper user, he has more than a dozen machines to consider...

All joking aside, the authrestart option is good for single cases, but since it's interactive, completely unfeasible for any large-scale deployments requiring reboot. You either need to settle for delayed reboots or rebooting to poa.

gregneagle
Valued Contributor

Still not understanding the actual issue here.

Consider this scenario:

FIleVault 2-protected machine is sitting at the loginwindow (no user is logged in).
Policy or softwareupdate runs and installs the 10.8.3 update, and reboots the machine.
Machine sits at FV2-unlock screen. After a while it shuts down.
Next morning, user powers it up and uses it.

Where is the problem?

easyedc
Valued Contributor II

Sorry. Old post that I'm finally catching up on. @gregneagle, our issue is that given the FV2 is preboot, I don't believe Casper can grab an inventory to report a) the successful OS X Update or b) allow remote access if additional work needs to be performed.

gregneagle
Valued Contributor

"given the FV2 is preboot, I don't believe Casper can grab an inventory to report "

Casper will (presumably) grab the inventory later, when the machine is booted. If not, Casper should be fixed.

"or b) allow remote access if additional work needs to be performed."

Yes. This is true. All things have trade-offs.
So you won't be able to do anything else until a user starts the machine up.
In my environment it has not yet been a big deal.

mm2270
Legendary Contributor III

Regarding the first issue, the jamf binary should kick in pretty soon after booting up and capture new inventory, especially if the Mac had been shut down in the evening the night before and a user is booting it up in the AM of the next day.

That said, we developed something for special cases where we can deploy a package that installs a simple LaunchDaemon and script. The daemon calls the script at boot, and the script just runs a recon after booting up and then deletes itself and the daemon, so a one time use self destructing process. Maybe consider that if you're really concerned you won't capture inventory.
Lastly, installing something like an OS update actually does update the operating system to report the new version even before a reboot. Its true, try it out. Install 10.8.5 on a Mac running an older version of Mountain Lion, say from the command line installer and don't reboot once its done, then run sw_vers -productVersion and you'll see it reports 10.8.5 as the OS. So if you design it correctly, you should be able to have your installs done, then collect inventory at the end, with maybe a script activated at the very end of the process, then reboot the Mac.

Edit: Corrected embarrassing typo : o

easyedc
Valued Contributor II

I brought this up at the JNUC last week and @rtrouton and a few others mentioned that what I'm trying to do doesn't work. There is a feature request out there to add what I'm trying to do to the Casper Suite.

Edit: link to feature request
https://jamfnation.jamfsoftware.com/featureRequest.html?id=1255