PDF document link: http://tinyurl.com/PSUMac2013PDF

Keynote slides link: http://tinyurl.com/PSUMac2013key

However, the limitations of the OS X install environment mean that there are a number of installers that won’t install correctly. In particular, packages that rely on pre- or postflight scripts to perform important tasks may fail to run properly in the OS X install environment.
To help work around this limitation, I’ve developed First Boot Package Install.pkg, an installer package that enables other packages to be installed at first boot.

It’s designed for use with createOSXinstallPkg with the goal of allowing installer packages that can’t run in the OS X Install environment to be used as part of a createOSXinstallPkg deployment workflow. See below the jump for the details.

Using First Boot Package Install.pkg’s pre-built installer package

1. Download the First_Boot_Package_Install.zip file from the installer directory in my GitHub repo

2. Once downloaded and unzipped, right-click on the package and choose Show Package Contents.

3. Go to Contents: Resources: fb_installers

4. Add one installer package to each numbered directory. The number of the directory indicates the install order, with 00 being the first.

NOTE: createOSXinstallPkg has an upper limit of 350 MBs of available space for added packages. This is sufficient space for basic configuration, payload-free or bootstrapping packages, but it’s not a good idea to add Microsoft Office or similar large installers to this installer.

As needed, more numbered directories may be added to the fb_installers directory. For numbers less than 10, make sure to label the directory with a leading zero (For example, 06).

Note: If installing more than 100 packages, be aware that this was beyond the scope of my testing. I recommend adding another leading zero where appropriate.

5. Once finished adding installers to the numbered directories, First Boot Package Install.pkg is ready to be added to a deployment workflow.

What’s supposed to happen

The installer package is designed to install packages in the desired order, then remove all traces. All actions occur before the OS X login window appears.

What the end-user sees

After the OS X install completes, it restarts and stays at the gray Apple loading screen for as long as it takes for the packages to install.

Once the install completes, the Mac automatically restarts and boots up normally to the login window.

When First Boot Package Install.pkg is installed via createOSXinstallPkg, it does the following:

1. Copies First Boot Package Install.pkg/Contents/Resources/fb_installers to /Users/Shared/fb_installers

2. Installs /Library/LaunchDaemons/com.company.firstbootpackageinstall.plist

3. Installs /var/firstbootpackageinstall.sh

After OS X is installed by createOSXinstallPkg and reboots, the following process occurs:

1. The com.company.firstbootpackageinstall LaunchDaemon triggers /var/firstbootpackageinstall.sh to run.

2. /var/firstbootpackageinstall.sh stops the login window from loading and checks for the existence of /Users/Shared/fb_installers.

If /Users/Shared/fb_installers is not found, the following actions take place:

A. The login window is allowed to load

B. /Library/LaunchDaemons/com.company.firstbootpackageinstall.plist is deleted

C. /var/firstbootpackageinstall.sh is deleted

If /Users/Shared/fb_installers is present, the following actions take place:

A. The packages are installed, using the numbered subdirectories to set the order of installation

B. Once installation has finished, /Users/Shared/fb_installers is deleted

C. The Mac is restarted

D. On restart, the “if /Users/Shared/fb_installers is not found” actions occur and all remaining traces of First Boot Package Install.pkg are removed from the Mac.

All First Boot Package Install.pkg components and scripts are available at my GitHub repo:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/first_boot_package_install/

The Iceberg project files are also available via the link above if you want to build a customized First Boot Package Install.pkg for your own environment.

The second new check looks for Apple’s com.apple.java.JavaPlugin2_NPAPI Java browser plug-in identifier. In this case, the Apple Java plug-in was re-enabled using the procedure in the following Apple KBase article: http://support.apple.com/kb/HT5559

This update also removes the Oracle Java browser plug-in version check from 10.6.x’s XProtect. Both new Apple Java version checks and the Oracle Java browser plug-in version check are in the 10.7.x and 10.8.x XProtect. See below the jump for the details.

As of 5-11-2013, /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist on 10.6.8 looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>JavaWebComponentVersionMinimum</key>
	<string>1.6.0_45-b06-451</string>
	<key>LastModification</key>
	<string>Fri, 10 May 2013 19:07:37 GMT</string>
	<key>PlugInBlacklist</key>
	<dict>
		<key>10</key>
		<dict>
			<key>com.apple.java.JavaAppletPlugin</key>
			<dict>
				<key>MinimumPlugInBundleVersion</key>
				<string>13.9.5</string>
				<key>PlugInUpdateAvailable</key>
				<true/>
			</dict>
			<key>com.apple.java.JavaPlugin2_NPAPI</key>
			<dict>
				<key>MinimumPlugInBundleVersion</key>
				<string>13.9.5</string>
				<key>PlugInUpdateAvailable</key>
				<true/>
			</dict>
			<key>com.macromedia.Flash Player.plugin</key>
			<dict>
				<key>MinimumPlugInBundleVersion</key>
				<string>11.6.602.171</string>
			</dict>
		</dict>
	</dict>
	<key>Version</key>
	<integer>64</integer>
</dict>
</plist>

As of 5-11-2013, /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist on 10.7.5 and 10.8.3 looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>JavaWebComponentVersionMinimum</key>
	<string>1.6.0_45-b06-451</string>
	<key>LastModification</key>
	<string>Fri, 10 May 2013 19:07:37 GMT</string>
	<key>PlugInBlacklist</key>
	<dict>
		<key>10</key>
		<dict>
			<key>com.apple.java.JavaAppletPlugin</key>
			<dict>
				<key>MinimumPlugInBundleVersion</key>
				<string>14.7.0</string>
				<key>PlugInUpdateAvailable</key>
				<true/>
			</dict>
			<key>com.apple.java.JavaPlugin2_NPAPI</key>
			<dict>
				<key>MinimumPlugInBundleVersion</key>
				<string>14.7.0</string>
				<key>PlugInUpdateAvailable</key>
				<true/>
			</dict>
			<key>com.macromedia.Flash Player.plugin</key>
			<dict>
				<key>MinimumPlugInBundleVersion</key>
				<string>11.6.602.171</string>
			</dict>
			<key>com.oracle.java.JavaAppletPlugin</key>
			<dict>
				<key>MinimumPlugInBundleVersion</key>
				<string>1.7.21.12</string>
				<key>PlugInUpdateAvailable</key>
				<true/>
			</dict>
		</dict>
	</dict>
	<key>Version</key>
	<integer>2038</integer>
</dict>
</plist>

To help manage the new settings, I’ve updated my xprotect_re-enable_java_6_and_7.sh script:

The script has been tested on 10.6.8, 10.7.5 and 10.8.3, so it should cover all current OSs that use Apple’s XProtect malware protection.

The script and launchdaemon are available here on my GitHub repo: https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/xprotect_re-enable_java_6_and_7

For a description of what I’ll be talking about, please see the Managing FileVault 2 on Mountain Lion session description. You can see the whole list of speakers here on the Sessions page.

Here’s the script I wrote to solve my particular problem.

#!/bin/bash

# At the prompt, enter the IP address
# or DNS name of the machine you want
# to connect to.

echo -n "Enter IP Address or Domain Name: "
read ipaddress

# At the prompt, enter the username
# of the account you want to log in
# with.

echo -n "Enter Username: "
read username

# At the prompt, enter the command that
# you want to run on the remote machine.

echo -n "Enter the command you want to run on the remote machine: "
read command

echo ""
echo ""

# Error checking to verify that the correct
# information has been entered. If incorrect
# info has been entered, selecting No will
# exit the script.

echo "Is the information below correct?"
echo ""
echo "Remote machine: $ipaddress"
echo "Username: $username"
echo "Command: $command"
echo ""
echo "If it is correct, select Yes"
echo ""
select yn in "Yes" "No"; do
    	case $yn in
        	Yes) echo "OK, the script will continue."; break;;
        	No ) echo "To avoid errors, the script will need to be restarted. Exiting the script."; exit 0;;
    	esac
done
echo ""
echo ""

# Check to see if the command needs to be
# run with root privileges. If root privileges
# are needed, the SSH connection will force 
# pseudo-tty allocation, which allows the command
# to be run via sudo

echo "Does this command need to run with root privileges? Once you select Yes or No, the command will run on the remote machine."
echo "Note: You will be prompted if authentication is required. If running the command as root, you may be prompted twice."
echo ""
select yn in "Yes" "No"; do
    	case $yn in
        	Yes) echo ""; ssh -t $username@$ipaddress "sudo $command"; break;;
        	No ) echo ""; ssh $username@$ipaddress "$command"; break;;
    	esac
done

#Exiting the script
echo ""
echo ""
echo "Finished running the remote command"
exit 0

The script is also available on my GitHub repo at the following location:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/running_commands_remotely_with_ssh

Normally, to access Apple’s documentation on a command-line tool, you would use man toolname_here or toolname_here help. asr has both of those, but it also has a separate command that reveals additional asr options not mentioned in the regular man or help pages.

With asr help, you get the following output:

Usage: asr  
   is one of the following:
    asr help | version
    asr restore --source  --target  []
    asr restore --source asr:/// --file  []
    asr server  --source  --config  []
    asr imagescan --source  [--filechecksum] [--nostream] [--SHA1]
   is in bytes but may end with a scale factor (b, k, m, g)

common  are any of:
      --source  path or url to disk image file, mountpoint, or
                        web accessible disk image
      --puppetstrings   print out messages in format good for machine parsing
      --verbose         display verbose output
      --debug           display debug output

restore  are any of:
      --target  path to volume or mountpoint
      --erase           formats target volume
      --format  target format when erasing (defaults to source)
      --noprompt        don't require confirmation on erase
      --noverify        don't checksum results
      --buffers    number of buffers to use in block copy
      --buffersize   size of buffers to use in block copy
      --csumbuffers   number of buffers for the checksum if different
      --csumbuffersize  size of buffers for the checksum if different
      --timeout      max wait for stream in multicast client mode

server  are any of:
      --interface  Use 'if' as the interface for the server's
                       outgoing stream
      --config  server configuration file in plist format

imagescan  are any of:
      --filechecksum calculate file checksum
      --nostream     don't reorder file for multicast streaming
      --SHA1         add a SHA-1 checksum to the image

However, when you run FULL_USAGE=1 asr help, you get the following output:

Usage: asr  
   is one of the following:
    asr help | version
    asr restore --source  --target  []
    asr restore --source asr:/// --file  []
    asr server  --source  --config  []
    asr imagescan --source  [--filechecksum] [--nostream] [--SHA1]
    asr partition --target  [--testsize ]
                           [--retestsize ] [--recoverysize ]
    asr freeze --target  [--testsize ]
                        [--retestsize ] [--recoverysize ]
    asr thaw --target  [--recovery] [--modifyrecovery]
    asr adjust --target  [--settype ]
   is in bytes but may end with a scale factor (b, k, m, g)

common  are any of:
      --source  path or url to disk image file, mountpoint, or
                        web accessible disk image
      --puppetstrings   print out messages in format good for machine parsing
      --verbose         display verbose output
      --debug           display debug output

restore  are any of:
      --target  path to volume or mountpoint
      --hidden          restore to the hidden customer software partition
      --erase           formats target volume
      --format  target format when erasing (defaults to source)
      --noprompt        don't require confirmation on erase
      --noverify        don't checksum results
      --buffers    number of buffers to use in block copy
      --buffersize   size of buffers to use in block copy
      --csumbuffers   number of buffers for the checksum if different
      --csumbuffersize  size of buffers for the checksum if different
      --timeout      max wait for stream in multicast client mode

server  are any of:
      --interface  Use 'if' as the interface for the server's
                       outgoing stream
      --config  server configuration file in plist format

imagescan  are any of:
      --filechecksum calculate file checksum
      --nostream     don't reorder file for multicast streaming
      --SHA1         add a SHA-1 checksum to the image

There are now four additional options listed:

    asr partition --target  [--testsize ]
                           [--retestsize ] [--recoverysize ]
    asr freeze --target  [--testsize ]
                        [--retestsize ] [--recoverysize ]
    asr thaw --target  [--recovery] [--modifyrecovery]
    asr adjust --target  [--settype ]

The question I don’t know the answer to is “What do these options do?”

I’ve seen asr adjust used to correct an incorrectly set Recovery HD partition, but I’m not familiar with what asr freeze and asr thaw do.

Do you know? Let me know in the comments.

One nice thing about this tool from my perspective is that it’s designed to be independent of any server-based resources. To the best of my knowledge, this is the first tool I’ve seen that allows FileVault encryption to be enforced on a machine entirely from the machine’s own resources. See below the jump for the details.

Building

You can build the latest version of the application using the Xcode project files available from the GitHub repository. There’s also a already-built application available for download from the GitHub repo.

Installation

This application can be installed anywhere on the Mac, though the GitHub project page recommends either /Applications or /Applications/Utilities. For the purposes of my testing, I put it into /Applications.

If you want to hide the application from your users, I’d recommend putting it into a location like /var/root.

Operation

The application was designed to be run by a Mac OS X loginhook. This allows it to be launched when a user logs in, but also runs the application with root privileges. Running this application with root privileges is important because fdesetup requires root privileges to run.

Since this is a process that’s more easily shown than explained, I’ve made a video showing the process from the user’s perspective.

Note: The video has been edited to artificially reduce the amount of time it took to encrypt. Run time of the pre-edited video was 9 minutes.

Management

The application has four command line switches that can be used to tell it how to run:

-FVSDoNotAskForSetup YES / NO – suppresses prompting the user to enable FileVault 2 encryption. The default is NO

-FVSForceSetup YES / NO – Sets the FileVault 2 encryption to use /Library/Keychains/FileVaultMaster.keychain as an institutional recovery key. The default is NO

-FVSUseKeychain YES / NO – Sets the FileVault 2 encryption to use /Library/Keychains/FileVaultMaster.keychain as an institutional recovery key. The default is YES

-FVSCreateRecoveryKey YES / NO – Sets the FileVault 2 encryption to generate and use an alphanumeric individual recovery key. The default is YES

FileVault Setup can also be managed by MCX or by the defaults command. FileVault Setup accepts four defaults:

FVSDoNotAskForSetup: suppresses prompting the user to enable FileVault 2 encryption, default is NO / FALSE

FVSForceSetup: Sets the FileVault 2 encryption to use /Library/Keychains/FileVaultMaster.keychain as an institutional recovery key, default is NO / FALSE

FVSUseKeychain: Sets the FileVault 2 encryption to use /Library/Keychains/FileVaultMaster.keychain as an institutional recovery key, default is YES / TRUE

FVSCreateRecoveryKey: Sets the FileVault 2 encryption to generate and use an alphanumeric individual recovery key, default is YES / TRUE

The settings are stored in the following domain: ca.sfu.its.filevaultsetup

Running FileVault Setup without any command line switches or other management will mean it will run with the following configuration:

/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSDoNotAskForSetup NO -FVSForceSetup NO -FVSUseKeychain YES -FVSCreateRecoveryKey YES

In this case, FileVault 2 encryption set up is not forced. For the recovery keys, FileVault Setup will have fdesetup both generate an alphanumeric individual recovery key and set /Library/Keychains/FileVaultMaster.keychain as an institutional recovery key.

Recovery Keys

As mentioned above, in its default configuration FileVault Setup will try to set up two recovery keys by using a properly configured /Library/Keychains/FileVaultMaster.keychain as the institutional recovery key and also generate an alphanumeric individual recovery key.

To make sure that the individual recovery key is recorded for later reference, FileVault Setup will generate a plist file containing the individual recovery key and store it in the following location:

/private/var/root/fdesetup_output.plist

The plist itself will look similar to this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>EnabledDate</key>
	<string>2013-04-29 22:17:00 -0400</string>
	<key>HardwareUUID</key>
	<string>00000000-0000-1000-8000-000C29CEF923</string>
	<key>HasMasterKeychain</key>
	<true/>
	<key>LVGUUID</key>
	<string>9807169C-24E6-4DDC-975A-71D078D73390</string>
	<key>LVUUID</key>
	<string>2BF1F4CA-5E97-4A6B-820A-A87F1DEA5B1D</string>
	<key>PVUUID</key>
	<string>0B0DE25B-8D24-4E31-B1B0-0831455C3A65</string>
	<key>RecoveryKey</key>
	<string>QFDA-9W5V-K2W3-93MR-Y7T8-DPZ5</string>
	<key>SerialNumber</key>
	<string>VMWVk2F+NYrG/tkLIignnJaiw</string>
</dict>
</plist>

If you want to use only the institutional recovery key, you would need to ensure that there is a properly configured FileVaultMaster.keychain stored in /Library/Keychains, then use FVSUseKeychain YES and FVSCreateRecoveryKey NO:

Example command:

/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSUseKeychain YES -FVSCreateRecoveryKey NO

If you want to use only the individual recovery key, you would need to ensure that there is not a FileVaultMaster.keychain stored in /Library/Keychains, then use FVSUseKeychain NO and FVSCreateRecoveryKey YES.

Example command:

/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSUseKeychain NO -FVSCreateRecoveryKey YES

Testing FileVault Setup

My testing was focused on forcing FileVault 2 encryption and using the command-line switches to tell FileVault Setup what to do. As part of that, I set up the following loginhook:

#!/bin/sh

FVSETUP=/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup
DISKUTIL="/usr/sbin/diskutil"
LOGGER="/usr/bin/logger"


# check_encryption_state taken
# from the Cauliflower Vest wiki's
# loginhook script:
# http://code.google.com/p/cauliflowervest/wiki/LoginHook

check_encryption_state() {
  ${DISKUTIL} cs list | grep -q -e 'Conversion\ Status.*Pending'
  if [[ ${?} -eq 0 ]]; then
    ${LOGGER} "Disk encryption pending, skipping."
    exit 0
  fi

  ${DISKUTIL} cs list | grep -q -e 'Conversion\ Status.*Complete'
  if [[ ${?} -eq 0 ]]; then
    ${LOGGER} "Disk encryption complete, skipping."
    exit 0
  fi

  ${DISKUTIL} cs list | grep -q -e 'Conversion\ Status.*Converting'
  if [[ ${?} -eq 0 ]]; then
    ${LOGGER} "Disk encrypting or decrypting, skipping."
    exit 0
  fi
}


# If the FileVault Setup binary is present,
# proceed with encryption. If not, exit the
# script.

if [[ ! -f "$FVSETUP" ]]; then
 ${LOGGER} "FileVault Setup not installed on Mac in specified location"
 exit 0
fi

if [[ -f "$FVSETUP" ]]; then
 ${LOGGER} "FileVault Setup present on Mac"

# Check to see if the Mac is encrypted
# or already encrypting. The application
# also checks for this, but I added this
# to help speed up the loginhook script's
# end if needed

 check_encryption_state
 
   # Replace YOUR_LOCAL_ADMIN_ACCOUNT with 
   # an account that you want to be able
   # to login to the Mac without triggering
   # the encryption to run.

  if [[ $1 == "root" || $1 == "YOUR_LOCAL_ADMIN_ACCOUNT" ]]; then
   ${LOGGER} "Exiting encryption setup for user account: $1"
   exit 0
   else

    # If the Mac isn't encrypted, run FileVault Setup

    "${FVSETUP}" -FVSForceSetup YES -FVSOptionsHere
    ${LOGGER} "Enabling encryption on this Mac."    
  fi
 else
  exit 0
fi

While I used this login hook for my testing, I also tried a much simpler loginscript:

#!/bin/sh

/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES

I was able to replicate my earlier encryption results, but the pause at the loginwindow (for the loginhook script to run) was a few seconds longer.

From my testing, here’s the commands that will worked along the ones that will generate errors. The errors will be coming from fdesetup or CoreStorage and are the result of FileVault Setup being asked to initialize an unsupported FileVault 2 configuration:

Successful FileVault 2 enablement

With no recovery keychain in /Library/Keychains, FileVault Setup forced FileVault 2 enablement and generated an individual recovery key as the Mac’s only recovery key with the following command:

/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES -FVSUseKeychain NO -FVSCreateRecoveryKey YES

With FileVaultMaster.keychain stored in /Library/Keychains, FileVault Setup forced FileVault 2 enablement and set the FileVaultMaster.keychain as the Mac’s only recovery key with the following command:

/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES -FVSUseKeychain YES -FVSCreateRecoveryKey NO

With FileVaultMaster.keychain stored in /Library/Keychains, FileVault Setup forced FileVault 2 enablement and set both the FileVaultMaster.keychain and an individual recovery key with the following command:

/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES

With FileVaultMaster.keychain stored in /Library/Keychains, FileVault Setup forced FileVault 2 enablement and set the FileVaultMaster.keychain as the Mac’s only recovery key with the following command:

/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES -FVSCreateRecoveryKey NO

Unsuccessful FileVault 2 enablement

With FileVaultMaster.keychain stored in /Library/Keychains, FileVault Setup gave a fdesetup error 18 with the following command:

/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES -FVSUseKeychain NO

With no recovery keychain on the Mac, FileVault Setup gave a fdesetup error 19 with the following command:

/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES -FVSUseKeychain YES -FVSCreateRecoveryKey NO

With no recovery keychain on the Mac, FileVault Setup gave a fdesetup error 19 with the following command:

/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES -FVSCreateRecoveryKey YES

With no recovery keychain on the Mac, FileVault Setup gave a fdesetup error 19 with the following command:

/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES

With no recovery keychain on the Mac, FileVault Setup gave an error 15 with the following command:

/path/to/FileVault\ Setup.app/Contents/MacOS/FileVault\ Setup -FVSForceSetup YES -FVSUseKeychain NO -FVSCreateRecoveryKey NO

This last error is because FileVault Setup was being asked to set up FileVault 2 encryption without a recovery key. This does not work; you must have a recovery key when encrypting a Mac with FileVault 2.

Running FileVault Setup on an already-encrypted Mac

One of the nicer features of this application is that it can detect if the Mac has already been encrypted with FileVault 2. If it’s launched on a Mac that’s encrypted, it displays a message that FileVault 2 has already been enabled. Once you click the OK button to acknowledge the message, FileVault Setup then quits.

At the login window, FileVault Setup will not appear when triggered by the loginhook on an already-encrypted Mac. Instead, the app will silently quit in the background.

Conclusion

If you’re looking for a way to enforce FileVault 2 on your Macs and don’t have access to server resources, FileVault Setup is a great addition to your set of tools. It will give you the ability to encourage encryption on your machines or force it, depending on your security needs.

It also gives you the ability to prepare a machine and deploy it to your users without encrypting it first, as the loginhook will ensure that encryption gets turned on at the first login.

Fortunately, Apple makes it reasonably easy to boot into single-user mode on a FileVault 2-encrypted system. Here’s how to boot into single-user on a FileVault 2-encrypted system:

1. Hold down Command-S after powering the system.

2. The Mac will be begin booting into single user, then the FileVault 2 pre-boot login screen will appear.

3. Authenticate at the FileVault 2 pre-boot login screen by selecting an account and providing the account’s password.

4. The Mac will then unlock and continue booting into single-user mode.

To show what this looks like, I’ve made a short video showing the process. In this instance, I booted into single-user mode and performed a disk check using fsck, then continued with the rest of the boot process.

This was going to be an issue at my workplace, as we have a couple of applications that rely on Java applets running through the browser. To help fix this and manage the Safari Java whitelist, I’ve written a couple of scripts. These scripts are designed to add websites to Safari’s Java whitelist without overwriting existing entries. For more details, see below the jump.

safari_java_whitelist_firstboot – This script is designed to be a firstboot script. It sets the Safari Java whitelist settings in your Mac’s default user template and for all existing users. Currently, it will add two servers to the Safari Java whitelist settings.

#!/bin/sh

# Adding two websites to Safari's Java whitelist in your Mac's default user template and for all existing users.
# Code adapted from DeployStudio's rc130 ds_finalize script, from the section where DeployStudio is disabling the iCloud and gestures demos

# Determine OS version
osvers=$(sw_vers -productVersion | awk -F. '{print $2}')

# Get today's date

TODAY=$(date "+%FT%TZ")

# Get Java plug-in info
JAVA_PLUGIN=`/usr/bin/defaults read "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info" CFBundleIdentifier`

# Checks first to see if the Mac is running 10.6 or higher. 
# If so, the script checks the system default user template
# for the presence of the Library/Preferences directory.
#
# If the directory is not found, it is created and then the
# Java whitelist settings are created.

if [[ ${osvers} -ge 6 ]];
then
  for USER_TEMPLATE in "/System/Library/User Template"/*
  do
     if [ ! -d "${USER_TEMPLATE}"/Library/Preferences ]
      then
        /bin/mkdir -p "${USER_TEMPLATE}"/Library/Preferences
     fi
     if [ -d "${USER_TEMPLATE}"/Library/Preferences ]
      then

         # Add Server1 to Java whitelist

         /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.Safari "WhitelistedBlockedPlugins" -array-add '{"PluginHostname" = "server1.name.here"; "PluginIdentifier" = "'$JAVA_PLUGIN'"; "PluginLastVisitedDate" = "'$TODAY'"; "PluginName" = "Java Applet Plug-in"; "PluginPageURL" = "https://server1.name.here"; "PluginPolicy" = "PluginPolicyNeverBlock";}'

         # Add Server2 to Java whitelist

         /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.Safari "WhitelistedBlockedPlugins" -array-add '{"PluginHostname" = "server2.name.here"; "PluginIdentifier" = "'$JAVA_PLUGIN'"; "PluginLastVisitedDate" = "'$TODAY'"; "PluginName" = "Java Applet Plug-in"; "PluginPageURL" = "https://server2.name.here"; "PluginPolicy" = "PluginPolicyNeverBlock";}'
        
     fi
  done
fi


# Checks first to see if the Mac is running 10.6 or higher.
# If so, the script checks the existing user folders in /Users
# for the presence of the Library/Preferences directory.
#
# If the directory is not found, it is created and then the
# Java whitelist settings are created.

if [[ ${osvers} -ge 6 ]];
then
  for USER_HOME in /Users/*
  do
    USER_UID=`basename "${USER_HOME}"`
    if [ ! "${USER_UID}" = "Shared" ] 
    then 
      if [ ! -f "${USER_HOME}"/Library/Preferences ]
      then
        /bin/mkdir -p "${USER_HOME}"/Library/Preferences
        chown "${USER_UID}" "${USER_HOME}"/Library
        chown "${USER_UID}" "${USER_HOME}"/Library/Preferences
      fi
      if [ -d "${USER_HOME}"/Library/Preferences ]
      then

         # Add Server1 to Java whitelist

         /usr/bin/defaults write "${USER_HOME}"/Library/Preferences/com.apple.Safari "WhitelistedBlockedPlugins" -array-add '{"PluginHostname" = "server1.name.here"; "PluginIdentifier" = "'$JAVA_PLUGIN'"; "PluginLastVisitedDate" = "'$TODAY'"; "PluginName" = "Java Applet Plug-in"; "PluginPageURL" = "https://server1.name.here"; "PluginPolicy" = "PluginPolicyNeverBlock";}'

         # Add Server2 to Java whitelist

         /usr/bin/defaults write "${USER_HOME}"/Library/Preferences/com.apple.Safari "WhitelistedBlockedPlugins" -array-add '{"PluginHostname" = "server2.name.here"; "PluginIdentifier" = "'$JAVA_PLUGIN'"; "PluginLastVisitedDate" = "'$TODAY'"; "PluginName" = "Java Applet Plug-in"; "PluginPageURL" = "https://server2.name.here"; "PluginPolicy" = "PluginPolicyNeverBlock";}'

        # Fix permissions on com.apple.Safari.plist

         /usr/sbin/chown "${USER_UID}" "${USER_HOME}"/Library/Preferences/com.apple.Safari.*

      fi
    fi
  done
fi

# Remove setup LaunchDaemon item

srm /Library/LaunchDaemons/com.company.safari_java_whitelist_firstboot.plist

# Make script self-destruct

srm $0

safari_set_java_whitelist_at_login – The script will add two servers to the Safari Java whitelist settings. If the servers are already in the whitelist, it will note that in the log, then exit.

To make this work, I’ve written a script and launch agent combination. The LaunchAgent runs the script on login to any user account with the logging-in user’s privileges and permissions.

#!/bin/sh

# Get today's date
TODAY=$(/bin/date "+%FT%TZ")

# Determine OS version
osvers=$(sw_vers -productVersion | awk -F. '{print $2}')

# Get Java plug-in info
JAVA_PLUGIN=`/usr/bin/defaults read "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info" CFBundleIdentifier`

# Check com.apple.Safari.plist for Server1 address
SERVER1_WHITELIST_CHECK=`/usr/bin/defaults read $HOME/Library/Preferences/com.apple.Safari WhitelistedBlockedPlugins | grep PluginHostname | awk '{print $3}' | grep server1.name.here | tr -d '";'`

# Check com.apple.Safari.plist for Server2 address
SERVER2_WHITELIST_CHECK=`/usr/bin/defaults read $HOME/Library/Preferences/com.apple.Safari WhitelistedBlockedPlugins | grep PluginHostname | awk '{print $3}' | grep server2.name.here | tr -d '";'`

if [[ ${osvers} -ge 6 ]]; then
  if [[ -n ${SERVER1_WHITELIST_CHECK} ]]; then

        # Server1 settings are present
	    /usr/bin/logger "${SERVER1_WHITELIST_CHECK} is part of the Java whitelist in Safari. Nothing to do here."
    else	    
		# Add Server1 to Java whitelist
        /usr/bin/defaults write $HOME/Library/Preferences/com.apple.Safari "WhitelistedBlockedPlugins" -array-add '{"PluginHostname" = "server1.name.here"; "PluginIdentifier" = "'$JAVA_PLUGIN'"; "PluginLastVisitedDate" = "'$TODAY'"; "PluginName" = "Java Applet Plug-in"; "PluginPageURL" = "https://server1.name.here"; "PluginPolicy" = "PluginPolicyNeverBlock";}'
        /usr/bin/logger "server1.name.here has been added to the Java whitelist in Safari."
  fi

  if [[ -n ${SERVER2_WHITELIST_CHECK} ]]; then

		# Server2 settings are present
		/usr/bin/logger "${SERVER2_WHITELIST_CHECK} is part of the Java whitelist in Safari. Nothing to do here."
     else		
        # Add Server2 to Java whitelist
		/usr/bin/defaults write $HOME/Library/Preferences/com.apple.Safari "WhitelistedBlockedPlugins" -array-add '{"PluginHostname" = "server2.name.here"; "PluginIdentifier" = "'$JAVA_PLUGIN'"; "PluginLastVisitedDate" = "'$TODAY'"; "PluginName" = "Java Applet Plug-in"; "PluginPageURL" = "https://server2.name.here"; "PluginPolicy" = "PluginPolicyNeverBlock";}'
        /usr/bin/logger "server2.name.here has been added to the Java whitelist in Safari."
  fi

fi

exit 0

Of the two approaches, I recommend using the safari_set_java_whitelist_at_login script and LaunchAgent. The reason is that the script will then run for all users (both current and future) and the script itself can be updated as needed to add or remove items.

Both scripts are available here on my GitHub repo:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/safari_java_whitelist

Credit goes to @aurica for figuring out the needed defaults commands.

Since the process I developed is ultimately about getting the OS X VM’s vmdm file up to the ESXi server, then building a new VM on the ESXi server to use that vmdk file, this is an easier technique because it allows us to skip using VMware Standalone Converter altogether. Instead, this procedure will use the vmware-vdiskmanager tool included with VMware Fusion and the VMware vSphere Client application. See below the jump for details.

Converting the OS X VM’s vmdk file

1. Open Terminal

2. Run the following command, inserting the correct VMWare Fusion vmdk file source and new vmdk destination:

/Applications/VMware\ Fusion.app/Contents/Library/vmware-vdiskmanager -r /path/to/vmware_fusion.vmwarevm/vmware_fusion.vmdk -t 4 /path/to/esxi.vmdk

3. Once the conversion process has completed, you will see that the conversion process has created two files:

filename.vmdk

filename-flat.vmdk

This is normal and ESXi will need both of these files.

4. Store both files somewhere where you can access them from Windows with the VMware vSphere Client application.

5. Quit out of Terminal.

Using VMware vSphere Client to create a new VM and upload the converted vmdk files

1. Launch VMware vSphere Client and log into the ESXi server.

2. If the ESXi server is using a self-signed SSL certificate, a warning will appear. Click the Ignore button to continue.

3. The ESXi administration console should appear.

4. Select File: New: Virtual Machine… to create a new VM.

5. In the Configuration window, select Custom. This option is needed because we need to set this VM to initially have no disk associated with it.

6. In the Name and Location window, name the new VM as desired. In this case, I’m naming it troutont-vm2.

7. In the Storage window, select the datastore where you want to store the new VM.

8. In the Virtual Machine Version window, use the default option of Virtual Machine Version: 8.

9. In the Guest Operating System window, select the following options:

Guest Operating System: Other

Version: Apple Mac OS X 10.7 (64-bit)

10. In the CPUs window, select the desired number of cores.

11. In the Memory window, select the desired memory configuration.

12. In the Network window, select the desired number of network cards.

13. In the SCSI Controller window, leave it at the default selected SCSI controller.

14. In the Select a Disk window, choose the Do not create disk option.

15. In the Ready to Complete window, verify everything looks OK and hit the Finish button.

The new VM should now be listed. The next step is now to upload the converted vmdk files and associate them with the VM.

16. In your ESXi server settings, select the Configuration tab then click on Storage.

17. In Storage, select your datastore and right-click to select Browse Datastore…

18. In the list of folders that appears, select the folder name that corresponds to the newly-created VM.

19. Select the Upload button (highlighted in red below.)

20. Select the filename.vmdk and filename-flat.vmdk files and upload them individually.

21. Click the Yes button at the Upload/Download Operation Warning window.

The files will then upload.

Once both files are uploaded, you should see only the filename.vmdk file showing in the Datastore Browser window.

Configuring the VM to use the uploaded vmdk

22. Click on the VM and select Edit virtual machine settings under the Get Started tab.

23. Click the Add… button in the Virtual Machine Properties window.

24. For Device Type, select Hard Disk

25. In the Select a Disk window, choose the Use an existing virtual disk option.

26. Select the datastore with the newly-created VM and hit the Open button.

27. Select the uploaded .vmdk file inside the VM and hit the OK button.

28. In the Advanced Options window, leave the settings at the default configuration.

29. In the Ready to Complete window, verify everything looks OK and hit the Finish button.

30. The new hard disk should now be listed. Hit the OK button to close the Virtual Machine Properties window.

With the uploaded VM removed, the new VM can be booted to verify that it is working correctly.