Slides from the “Storing our digital lives: Mac filesystems from MFS to APFS” session at MacADUK 2017
For those who wanted a copy of my filesystem talk at the MacADUK 2017 conference, here are links to the slides in PDF and Keynote format.
Keynote – http://tinyurl.com/MacADUK2017key
I don’t normally try to foretell the future but there is one change for Mac admins that I’m pretty sure will happen:
The coming of Apple File System (APFS) will mark the end of disk imaging on Macs.
For those not familiar with disk imaging, a disk image is a computer file containing the contents and structure of a disk volume. Mac disk images are applied to hard drives using the Apple Software Restore (asr) command line utility to erase the destination drive and then block-copy the data from the disk image onto the destination drive.
Mac deployment practices have generally fallen into one of three categories:
Monolithic imaging is the practice of building a Mac with the desired operating system, desired software, and desired configuration settings, then creating a disk image which includes all the contents of that Mac’s boot drive, including the operating system, installed software, and settings.
Once that disk image is created, the image is then applied to multiple other Macs to make them just like the original Mac.
Modular imaging is the practice of creating a disk image that contains only the base OS (as well as necessary OS updates from Apple).
Once that disk image is created, the image is applied to multiple other Macs. Desired software and desired configuration settings are then installed onto the newly-imaged Mac as post-imaging deployment tasks.
Thin imaging is technically not an imaging practice, as no disk image is involved. Instead, the assumption is that Macs from Apple come with a pre-installed OS and that OS should be used instead of wiping it and replacing it with a new copy from a disk image.
In this scenario, a deployment workflow is run which installs the desired software and desired configuration settings onto the Mac. If a Mac needs to be wiped and re-setup, a fresh copy of the OS is installed via the Recovery environment or similar OS installation process and then the thin imaging deployment workflow is re-run.
Imaging using asr has been around for a long time (I first began using it back in the Mac OS X 10.2.x days) but there have been strong hints that those days are coming to an end. The most visible of these was this tweet from the makers of DeployStudio:
While the makers of DeployStudio don’t speak for Apple, a statement like this matches up with what I’ve heard from other Mac admins who have independently received similar messages as part of their communication with Apple. Apple hasn’t commented publicly one way or the other, so unfortunately I can’t be more specific than that.
If imaging isn’t available, what are the alternatives? Apple has been encouraging the use of Apple’s Device Enrollment Program, which leverages a company, school or institutions’ mobile device management (MDM) service. In this case, you would need to arrange with Apple or an Apple reseller to purchase Macs that are enrolled in your organization’s DEP.
When a DEP-enrolled Mac is started for the first time (or started after an OS reinstall), it is automatically configured to use your organizations’ MDM service and the device checks in with the MDM service. The MDM service then configures the Mac as desired with your organization’s software and configuration settings. A good example of what this process may look like can be seen here.
What if you don’t have DEP, or you don’t have MDM? In that case, you may still be able to leverage a thin imaging deployment workflow, which installs the desired software and desired configuration settings onto the Mac’s existing OS. To get an existing OS though, you would need to install it via the Recovery environment or a similar OS installation process.
Planning for the future
Today, imaging works and our deployment workflows are what they are. What should be done to prepare for the future?
If you’re already using DEP with MDM to set up your Macs:
- Congratulations! You’re good to go with a Apple-supported deployment workflow that should work fine for the foreseeable future.
If you’re not using DEP with MDM to set up your Macs:
- If DEP is an option for your organization and you have an existing MDM service, investigate using Apple’s DEP service to set up your Macs for deployment. You may find that DEP doesn’t work for you in its current form, but now is the time to find that out and work with Apple to get those parts fixed.
- If DEP isn’t an option for your organization (because you aren’t using MDM and/or you aren’t in a country where DEP is supported) and you aren’t using a thin imaging deployment workflow now, I recommend investing the time and effort to start using a thin imaging workflow. In particular, if you are using monolithic imaging to set up your Macs, it is time to stop and transition to an alternate way of deploying Macs before that imaging method abruptly stops working.
When will we know how long imaging has left? My recommendation will be to watch what Apple reveals at this summer’s WWDC 2017 conference and pay particular attention to any device management or APFS developments that are being announced, as those announcements should likely provide the best information.
I’ll be speaking at Mac Admin & Developer Conference UK 2017, which is taking place in London from February 7th – 8th, 2017. My session will be an overview of Apple’s past and present filesystems, with an introduction to Apple File System (APFS) and a discussion of its current state of development..
You can see the entire list of speakers at http://www.macad.uk/macad2017-speakers/
Slides from the “Storing our digital lives: Mac filesystems from MFS to APFS” session at MacTech Conference 2016
For those who wanted a copy of my filesystem talk at MacTech Conference 2016, here are links to the slides in PDF and Keynote format.
I’ll be speaking at MacTech Conference 2016, which is taking place from November 16-18, 2016 in Los Angeles at the Westin Hotel LAX. My session will be an overview of Apple’s past and present filesystems, with an introduction to Apple File System (APFS) and a discussion of its current state of development.
You can see the entire list of MacTech Conference speakers at http://conference.mactech.com/speakers/.
The documentation from MacSysAdmin 2016 is now available, with the session slides and videos being accessible from the link below:
The videos of my sessions are available for download from here:
- What’s new in File System: http://docs.macsysadmin.se/2016/video/Day2Session1.mp4
- Going from Physical to Virtual – Creating, hosting and managing OS X VMs with VMware Fusion and ESXi: http://docs.macsysadmin.se/2016/video/Day3Session6.mp4
As part of the various announcements at WWDC 2016 in June 2016, Apple announced that there would be a new filesystem named Apple File System (APFS) being released in 2017. As part of the functionality of APFS, encryption is being natively supported by APFS as a primary feature of the filesystem.
Encryption and APFS
APFS supports the following levels of encryption:
- No encryption – no data is encrypted
- One key per volume (for encrypting both metadata and data) – This is equivalent to how FileVault 2 works today
- Multi-Key encryption
- – Metadata encryption
- – Per-File encryption
- – Per-Extant encryption
What was not overtly stated as part of the presentation is that while Apple may continue to name the encryption “FileVault”, it will work differently than FileVault 2 does today. The reason for this is that FileVault 2 is using encrypted Core Storage volumes to provide full-volume encryption. Core Storage is built on top of HFS+ and it does not appear that Core Storage will be transitioning to APFS. Instead, it appears that Core Storage will remain an HFS+ – specific solution.
As of this date, I haven’t yet seen how APFS encryption works in practice, but one thing is clear – The move away from Core Storage is a fundamental change for how encryption will be handled for Macs, with the following areas being affected:
- How Macs become encrypted
- How to unlock the encryption
- How to decrypt an encrypted Mac
- How to repair problems affecting an encrypted Mac
In short, everything currently documented for handling encrypted Macs will likely become obsolete and new documentation will need to be written for APFS’ encryption solution.
What does this mean for FileVault 2?
With APFS already being available as a developer preview, I don’t anticipate Apple making any more changes to how FileVault 2 works. I believe that Apple is putting FileVault 2 into maintenance mode where (hopefully) bugs will be fixed but development otherwise has stopped in favor of developing APFS’ encryption.
In terms of FileVault 2 management, Apple may choose to add functionality in Sierra to Apple’s fdesetup management tool for FileVault 2 but I believe that any changes will be enhancement to existing functionality in fdesetup instead of adding new functionality. A good example of this is Sierra’s changes to fdesetup authrestart.