One of the pop-up windows you get on first login to Yosemite is the Diagnostics & Usage pop-up window. This window requests permission for the following:
- Send diagnostics and usage data to Apple
- Share crash data with non-Apple developers
I’ve been suppressing this window without setting those diagnostic reporting settings, but Mac admins may also want to apply those settings as part of building their machines. Thanks to investigative work by Tim Sutton, it looks like it’s possible to control those settings by setting the correct values in the /Library/Application Support/CrashReporter/DiagnosticMessagesHistory.plist file.
<key>AutoSubmitVersion</key> <integer>4</integer> <key>AutoSubmit</key> <false/> <key>ThirdPartyDataSubmitVersion</key> <integer>4</integer> <key>ThirdPartyDataSubmit</key> <false/>
For more details, see below the jump.
When I updated to 10.10.1 yesterday, as part of the restart process I noticed that I was seeing the Diagnostics pop-up window appear on login.
I had previously suppressed this window as part of setting up this machine, but it looks like the LastSeenBuddyBuildVersion value in /Users/username/Library/Preferences/com.apple.SetupAssistant.plist had the build number for 10.10.0 stored and it needed to be updated with the build number of 10.10.1 in order to suppress the Diagnostics pop-up window again.
Fortunately, this can be addressed by setting up an automated run of my iCloud / Diagnostics suppression script with Casper. This should automatically update the LastSeenBuddyBuildVersion value in /Users/username/Library/Preferences/com.apple.SetupAssistant.plist with the build number for the current version of 10.10.x. For more details, see below the jump.
I’ve updated the create_vmware_osx_install_dmg.sh script which I had previously posted about here. The script now includes support for Yosemite, so the script can now be run on 10.7 – 10.10 to create custom OS X 10.7.x, 10.8.x, 10.9.x and 10.10.x installers for VMware Fusion and VMware ESXi. See below the jump for the details.
Using OS X 10.8′s fdesetup tool and non-enabled admin accounts to enable users for FileVault 2 on Mavericks and Yosemite
Back in OS X 10.8.x, one of the newly-created fdesetup tool’s functions was to enable users for FileVault 2. To do so, you needed to provide both the username and password of either a previously enabled account or an admin account, as well as the password of the account you want to add.
One interesting twist was that the admin user in question did not themselves need to be enabled for FileVault 2. In my testing on 10.8.x, I found that an admin user could authorize the enabling of other accounts even if the admin account wasn’t enabled. An admin account could also enable itself using this process, by being both the authorizing admin account and the account being enabled.
In Mavericks and later, this behavior changed. If you’re using Mavericks or Yosemite, the fdesetup tool included with those operating systems now prevents non-enabled admin users from enabling other non-enabled users.
That seemed to close the book on non-enabled admin accounts being able to enable users for FileVault 2, until Google’s Macintosh Operations Team posted a script that they said would make a Mac unbootable.
As part of the discussion about that script, something really interesting was discovered. For more details, see below the jump.
I’ve noticed that the Server.app installers for Mavericks and Mountain Lion have now vanished from my list of Purchases in the App Store, and searching for “OS X Server” will only give you the option of Server.app 4.0 for Yosemite. However, Server.app 2.2.5 for Mountain Lion and Server.app 3.2.2 for Mavericks are still available. You just need the right Mac App Store URL.
As of November 1, 2014, here are the Mac App Store URLs for Server.app 2.2.5 for OS X 10.8.5 and Server.app 3.2.2 for 10.9.5:
- Server.app 2.2.5: https://itunes.apple.com/us/app/os-x-server-2.2.5/id537441259?mt=12
- Server.app 3.2.2: https://itunes.apple.com/us/app/os-x-server-3.2.2/id714547929?mt=12
To help safeguard against a day where they may not be available at all, I recommend downloading a copy of the Server.app installer packages from the MAS.
A new feature that appeared in VMware Fusion 7 Pro was its new ESXi management. This included the ability to upload VMs from Fusion directly to an ESXi server. However, when I tried to upload OS X VMs something seemed to go wrong. The upload would work, but the OS X VM would then hang on boot.
Non-OS X VMs were uploading fine, so the problem was specific to OS X VMs. Since I could still build OS X VMs using the Windows vSphere client, I didn’t invest a lot of time into solving this issue. Fortunately, Calum Hunter was more motivated in this regard and found a solution.
There are a few things to know about if you want to upload an OS X VM to an ESXi server running 5.5, so I’ve put together a procedure for those who want to leverage Fusion 7 Pro to upload OS X VMs. See below the jump for the details.
Apple has been warning folks for the past few OS releases that the /etc/hostconfig file was going away and it looks like they decided that Mavericks was the hostconfig file’s last hurrah.
As of OS X Yosemite, /etc/hostconfig is no longer installed as part of the OS.
Thanks to Dan O’Donnell for the heads-up: