Archive
Setting up AutoPkg, AutoPkgr and JSSImporter on an Amazon Web Services macOS EC2 instance
One of the outcomes of the recent Amazon Web Service’s Insight conference was AWS’s announcement that, as of November 30th, macOS EC2 instances were going to be available as on-demand instances or as part of one of AWS’s reduced cost plans for those who needed them long-term.
There are a few differences about AWS’s macOS offerings, as opposed to their Linux and Windows offerings. macOS EC2 instances are set up to run on actual Apple hardware, as opposed to being completely virtualized. This means that there are the following dependencies to be aware of:
- macOS EC2 instances must run on dedicated hosts (AWS has stated these are Mac Minis)
- One macOS EC2 instance can be provisioned per dedicated host.
AWS has also stipulated that that dedicated hosts for macOS EC2 instances have a minimum billing duration of 24 hours. That means that even if your dedicated host was only up and running for one hour, you will be billed as if it was running for 24 hours.
For now, only certain AWS regions have EC2 Mac instances available. As of December 20th, 2020, macOS EC2 instances are available in the following AWS Regions:
- US-East-1 (Northern Virginia)
- US-East-2 (Ohio)
- US-West-2 (Oregon)
- EU-West-1 (Ireland)
- AP-Southeast-1 (Singapore)
The macOS EC2 instances at this time support two versions of macOS:
macOS Big Sur is not yet supported as of December 20th, 2020, but AWS has stated that Big Sur support will be coming shortly.
By default, macOS EC2 instances will include the following pre-installed software:
- ENA drivers
- EC2 macOS Init
- EC2 System Monitoring for macOS
- Systems Manager SSM Agent for macOS
- AWS Command Line Interface (AWS CLI) version 2
- Xcode Command Line Tools
- Homebrew
For folks looking to build services or do continuous integration testing on macOS, it’s clear that AWS went to considerable lengths to have macOS EC2 instances be as fully-featured as their other EC2 offerings. Amazon has also either made it possible to install the tools you need or just went ahead and installed them for you. They’ve also included drivers for their faster networking options and made it possible to manage and monitor Mac EC2 instances using AWS’s tools just like their Linux and Windows EC2 instances.
That said, all of this comes with a price tag. Here’s how it works out (all figures expressed in US dollars):
mac1 Dedicated Hosts (on-demand pricing):
$1.083/hour (currently with a 24 hour minimum charge, after which billing is by the second.)
$25.99/day
$181.93/week
$9493.58/year
Now, you can sign up for an AWS Savings Plan and save some money by paying up-front for one year or three years. Paying for three years, all cash up front is the cheapest option currently available:
$0.764/hour
$18.33/day
$128.31/week
$6697.22/year
Now some folks are going to look at that and have a heart attack, while others are going to shrug because the money involved amounts to a rounding error on their existing AWS bill. I’m mainly going through this to point out that hosting Mac services on AWS is going to come with costs. None of AWS’s existing Mac offerings are part of AWS’s Free Tier.
OK, so we’ve discussed a lot of the background but let’s get to the point: How do you set up AutoPkg to run in the AWS cloud? For more details, please see below the jump.
Resizing an AWS macOS EC2 instance’s boot drive to use all available disk space
I’ve started working with Amazon Web Service’s new macOS EC2 instances and after a while, I noticed that no matter how much EBS drive space I assigned to a EC2 instance running macOS, the instance would only have around 30 GBs of usable space. In this example, I had assigned around 200 GBs of EBS storage, but the APFS container was only using around 30 GBs of the available space.
After talking with AWS Support, there’s a fix for this using APFS container resizing. This is a topic I’ve discussed previously in the context of resizing boot drives for virtual machines. For more details, see below the jump.
Creating, managing and using Apple File System snapshots for startup drive backups
Starting with macOS High Sierra, Time Machine on Apple File System-formatted (APFS) startup drives gained the ability to create APFS snapshots. These snapshots capture the state of the startup volume at a particular point in time and can be used by Time Machine to restore files, folders or the whole startup volume. These snapshots are stored on the startup volume, but are not the same as the previous local backups that Time Machine used on Hierarchical File System Plus (HFS+) formatted drives.
On HFS+ formatted drives, Time Machine local backups are stored in an invisible directory named .MobileBackups on the root level of the startup drive.
This .MobileBackups directory is mountable as /Volumes/MobileBackups and you can access the backed-up files stored inside by navigating via the command line or Finder window.
On APFS formatted drives, the /.MobileBackups directory and /Volumes/MobileBackups are no longer available. Instead, Time Machine is now using APFS snapshots to store a read-only copy of the state of your Mac’s startup drive at the time when that snapshot was taken. These snapshots are invisible to the file system, so unlike HFS+, there isn’t a directory or file location which you can access to get access to the snapshot-stored backups.
Snapshots include all files and directories stored on the startup drive at the time that the individual snapshot was made. When available, these snapshots can be used to restore the following:
- Individual files
- Individual directories
- Multiple files at once
- Multiple directories at once
- All files and directories at once
If the startup drive was encrypted at the time the snapshot was made, the snapshot will itself be encrypted. This allows the restoration of an encrypted startup drive without needing to decrypt or re-encrypt the relevant startup drive. For more details, please see below the jump.
Mounting Time Machine local snapshots as read-only volumes
Starting with macOS High Sierra, Time Machine on Apple File System-formatted (APFS) boot drives gained the ability to create APFS snapshots. These snapshots are stored on the boot volume, but are not the same as the local backups that Time Machine uses on HFS+-formatted drives.
On HFS+ formatted drives, Time Machine local backups are stored in an invisible directory named .MobileBackups on the root level of the boot drive.
In turn, this .MobileBackups directory is mountable as /Volumes/MobileBackups and you can access the backed-up files stored inside by navigating via the command line or Finder window.
On APFS-formatted drives, the /.MobileBackups directory and /Volumes/MobileBackups are no longer available. Instead, Time Machine is now using APFS snapshots to store a read-only copy of the state of your Mac at the time when that snapshot was taken. These snapshots are invisible to the file system, so unlike HFS+, there isn’t a directory or file you can access. Instead, you now need to use the mount_apfs command’s -s option to mount APFS snapshots as read-only volumes.
For more details, please see below the jump.
Re-syncing local account passwords and Secure Token on FileVault-encrypted Macs running macOS Mojave
As part of FileVault on Apple File System, Apple introduced a new account attribute called Secure Token. As mentioned in a previous post, Secure Token can present some interesting problems for Mac admins who work with FileVault-encrypted laptops. Among the potential complications are these scenarios:
- “I changed the password for my local account, but only the old password is being taken at the FileVault login screen.”
- “We’ve lost the password to the only local user account with a Secure Token, so now we can’t enable any other accounts on this Mac for FileVault.”
Usually, this happens because the local account password in question was changed outside of the Users & Groups preference pane in System Preferences and now Secure Token and the account password are out of sync with each other.
Up until the past few days, the only fix I knew of for that situation was to back up the data and wipe the drive. However, it looks like there is a workaround for encrypted Macs which fixes the password problem and sorts out Secure Token in these scenarios. In both cases, a personal recovery key will be needed as the way to authorize the needed changes. For more details, please see below the jump.
Unable to enable FileVault on macOS Mojave
As part of FileVault on Apple File System, Apple introduced a new account attribute called Secure Token. Secure Token can present some interesting complications for Mac admins and among them is this scenario:
“The laptop is decrypted, but we can’t re-enable FileVault now.”
Usually, this happens because the account password was changed outside of the Users & Groups preference pane in System Preferences and now Secure Token and the account password are out of sync with each other.
Up until today, the only fix I knew of for that situation was to back up the data and wipe the drive. However, it looks like there is a workaround that fixes the password problem and sorts out the Secure Token attribute for the account on a decrypted laptop. For more details, please see below the jump.
T2, FileVault and brute force attack protection
Apple recently released an overview document for its new T2 chip, which includes how the new T2 chip-equipped Macs have new protections against brute force attacks. This protection only applies if FileVault is enabled and is similar in concept to how iOS devices set with passcodes are protected against brute force attacks.
On iOS, if an incorrect passcode is entered more than five times, a one minute delay is set.
After the sixth try, the delay is now five minutes and the delays get longer from there until the device has the 10th wrong passcode entered and the device wipes.
On Apple iOS devices with a Secure Enclave, those delays are enforced by the Secure Enclave processor. Similarly, the T2 chip-equipped Macs also have a Secure Enclave processor which is managing access attempts and introducing delays.
For Macs with Secure Enclave, the enforcement looks like this:
- 30 unlock attempts via using the password at the login window or target disk mode
- 10 unlock attempts via using the password in Recovery Mode
- 30 unlock attempts for each enabled FileVault recovery mechanism
- iCloud recovery
- FileVault personal recovery key
- FileVault institutional recovery key
The maximum number of unlock attempts is 90, regardless of the mix of methods used. After 90 attempts, the Secure Enclave processor will no longer process any requests to do the following:
- Unlock the volume
- Decrypt the volume
- Verify the password / recovery key
Delays are also imposed on macOS between attempts.
So what happens after 90 attempts? Does the Mac lock forever and become a paperweight?
After checking with AppleCare Enterprise, the answer is that the Mac will not be a paperweight, but that the Mac’s boot drive will need to be erased before it can be used again. This approach helps make sure that the Mac is still usable, but also ensures that the encrypted data stored on the boot drive is no longer recoverable.
For more information about brute force protection for encrypted iOS and macOS devices, I recommend checking out Apple’s currently available white papers:
Reclaiming drive space by thinning Apple File System snapshot backups
As part of a recent clean-up of my Apple File System-formatted (APFS) boot drive, I deleted a number of files. However, I noticed that deleting files did not free up nearly as much space as I thought it should. When I investigated, I noticed that my boot drive had a number of Time Machine snapshots stored on it.
A quick way to reclaim space from a particular snapshot immediately would be to delete the snapshot using the tmutil command line tool, using the command shown below:
tmutil deletelocalsnapshots snapshot-name-here
However, I didn’t want to delete backups if I could avoid it since I might need something stored in one of them. After some research, I was able to find a tmutil command that did what I needed. For more details, please see below the jump:
Slides from the “Managing FileVault 2 on macOS High Sierra” Session at MacAD UK 2018 Conference
For those who wanted a copy of my FileVault 2 management talk at MacAD UK 2018, here are links to the slides in PDF and Keynote format.
PDF – http://tinyurl.com/MacADUK2018pdf
Keynote – http://tinyurl.com/MacADUK2018key
Hat tip to the attendee who brought to my attention that fdesetup sync is not supported on encrypted APFS boot drives. I’ve now updated the slides to reflect that it works on macOS High Sierra for HFS+ drives only.
HFS+
APFS
Secure Token and FileVault on Apple File System
As part of Apple File System’s FileVault encryption on mac OS High Sierra, Apple introduced Secure Token. This is a new and undocumented account attribute, which is now required to be added to a user account before that account can be enabled for FileVault on an encrypted Apple File System (APFS) volume. To help make sure that at least one account has a Secure Token attribute associated with it, a Secure Token attribute is automatically added to the first account to log into the OS loginwindow on a particular Mac.
Once an account has a Secure Token associated with it, it can then create other accounts which will in turn automatically be granted their own Secure Token.
For the consumer user, this usually takes the following form:
- Secure Token is automatically enabled for the user account created by Apple’s Setup Assistant.
- The Setup Assistant-created user account with Secure Token then creates other users via the Users & Groups preference pane in System Preferences. Those accounts get their own Secure Token automatically.
However, Active Directory mobile accounts and user accounts created using command line tools do not automatically get Secure Token attributes associated with these accounts. Without the Secure Token attribute, those accounts are not able to be enabled for FileVault.
Update 1-20-2018: @mikeymikey has pointed out an exception to the rule:
Instead, the sysadminctl utility must be used to grant Secure Token to these accounts as a post-account creation action. In that case, the sysadminctl utility must be run by a user account with the following pre-requisites:
- Administrative rights
- Secure Token
For more details, please see below the jump.
Der Flounder 
Recent Comments