A number of Mac admins need to provide the Xcode Command Line Tools for the Macs in their environments, either as part of building machines or afterwards. To help with this task, I’ve developed a script that will download and install the Xcode Command Line Tools on Macs running 10.7.x and higher. See below the jump for more details.
With the release of Yosemite, Apple has continued to add functionality to fdesetup, a valuable command-line tool for enabling, administering and disabling Apple’s FileVault 2 encryption. This tool gives Mac administrators the following command-line abilities:
- Enable or disable FileVault 2 encryption on a particular Mac
- Use a personal recovery key, an institutional recovery key, or both kinds of recovery key.
- Enable one or multiple user accounts at the time of encryption
- Get a list of FileVault 2-enabled users on a particular machine
- Add additional users after FileVault has been enabled
- Remove users from the list of FileVault enabled accounts
- Add, change or remove individual and institutional recovery keys
- Report which recovery keys are in use
- Perform a one-time reboot that bypasses the FileVault pre-boot login
- Report on the status of FileVault 2 encryption or decryption
I’ll be taking you through all of the capabilities mentioned above, with a focus on showing exactly how they work. See below the jump for details.
One of the requirements when enabling an account for FileVault 2 is that the account’s own password must be provided in order for the account to be enabled. This is because the account’s password is used to generate a unique derived key via PBKDF2. This key is necessary for the account to unlock FileVault 2’s encryption, so the account’s password must be provided in order to enable an account.
Apple recognized that there would be situations where Mac admins would need to set up FileVault 2 for a person where the admin would not have the password for that person’s user account. To avoid the immediate need to enter a password, fdesetup has a -defer flag in Mountain Lion, Mavericks and Yosemite that can be used with fdesetup‘s enable verb to delay enabling FileVault 2 until after the current (or next) user logs out. With the -defer flag, the user will be prompted for their password at their next logout or restart. The recovery key information is not generated until the user password is obtained, so the -defer option requires a file location where this information will be written to as a plist file.
The property list file will be created as a root-only readable file and contain information similar to what’s show below.
Note: For security reasons, the plist file with the recovery key information should not stay on the encrypted system. Please copy it to a safe location and then securely delete this plist file from the encrypted system.
Run the following command with root privileges to defer enabling FileVault 2 and specify the account you want:
fdesetup enable -user username -defer /path/to/filename.plist
If there is no user account specified with the -user option, then the current logged-in user will be enabled for FileVault 2. If there is no user specified and no users are logged in when the command is run, then the next user that logs in will be chosen and enabled.
If you don’t want to specify the account, run the following command with root privileges:
fdesetup enable -defer /path/to/filename.plist
On logout, the user will be prompted to enter their account password.
Once entered, FileVault 2 will be enabled and the recovery information plist file will be created. Once the enabling process is complete, the Mac will restart.
An important thing to keep in mind about the –defer option is that it enables one single user account at the time of turning on FileVault 2 encryption. The –defer option does not enable multiple user accounts and cannot be used to enable accounts once FileVault 2 encryption has been turned on.
In Yosemite, Apple added new options for fdesetup‘s -defer flag. These new options now allow Mac admins to set a deferred enablement with the following options:
- Enforce FileVault 2 enablement at logout
- Enforce FileVault 2 enablement at login
- Enforce FileVault 2 enablement at both login and logout
For more information, see below the jump.
Over the weekend of January 24th, Adobe released Adobe Flash Player 22.214.171.1246 to fix a critical vulnerability. This update was available for installation via the Flash auto-update, but there was nothing available for a manual download. This lack of a separate download meant that Mac admins didn’t have a way to get an installer for distribution to the Macs in their environments.
Adobe has stated that a manual download will be available during the week of January 26, but for the moment, it appears that the auto-update mechanism is the only way Adobe is distributing this update.
Update 1-26-2015: A 126.96.36.1996 installer is now available on the Adobe Flash Player Distribution site (not linked because you gain access to the site after getting a valid Adobe Flash Player Distribution License Agreement in place.)
Update 2 – 1-26-2015: The AutoPkg download recipe for Adobe Flash has been updated to now download and decode the install_all_mac_pl_sgn.z file from Adobe’s Flash Player update feed for Macs. If you’re using AutoPkg, update your repos and you should get the changes. For more information on the actual recipe changes, see here.
One of the changes that Apple has introduced with Yosemite is a more straightforward way to recover from login problems at the FileVault 2 pre-boot login screen.
When a FileVault 2-encrypted Mac sits for more than a minute with an account selected at the FileVault 2 pre-boot login screen, a message like the one below should appear:
If you’re having a problem entering your password, press and hold the power button on your Mac to shut it down. Then press it again to start it up in the Recovery OS.
If the instructions are followed, the Mac will boot from the Mac’s recovery partition on the next startup and go into a Reset Password wizard.
In the Reset Password wizard, there are currently three options available.
- I forgot my password
- My password doesn’t work when logging in
- My keyboard isn’t working when typing my password to login
Each option will do different things, so let’s take a look at each. For more details, see below the jump.
With Oracle’s Java 8, there’s been some confusion as to whether Java 8 runs on Mac OS X 10.7.5. This issue was lent additional urgency in the wake of Oracle’s announcement that they will begin auto-updating Java 7 users to Java 8 starting in January 2015.
The root of the confusion lies in the fact that Oracle has listed two different sets of system requirements on their website for Macs running Java 8 on Mac OS X.
The first set is available via Oracle’s general Java system requirements page. This page states that Java 8 requires the following:
- Intel-based Mac running Mac OS X 10.8.3+, 10.9+
- Administrator privileges for installation
- 64-bit browser
- Intel-based Mac running Mac OS X 10.7.3 (Lion) or later.
- Administrator privileges for installation
- 64-bit browser
In short, the question of Java 8 support for 10.7.x depended on which system requirement page was correct. For more details, see below the jump.
On December 8th, 2014, Apple posted a KBase article showing a way to hide user accounts in Yosemite that was different than the methods available in previous versions of OS X.
In Yosemite, you can add an IsHidden user attribute to the user’s account record and set a specific value in order to hide or unhide the account:
- Hide: Set the IsHidden user attribute’s value to 1
- Unhide: Set the IsHidden user attribute’s value to 0
It’s also possible to unhide a hidden account by deleting the IsHidden user attribute from the user’s account record. For more details, see below the jump.