A new feature in VMware Fusion 8 Professional is the ability to create a new VM on an ESXi 6.x server. This new functionality gives Fusion users on OS X another tool for managing VMs on VMware’s ESXi hypervisor and complements the ability to copy VMs between VMware Fusion and VMware ESXi 5.5.x and 6.x.
There are a few things to know about if you want to create an OS X VM to an ESXi server running 6.x, so I’ve put together a procedure for those who want to leverage Fusion 8.x Pro to create new OS X VMs on ESXi. See below the jump for the details.
Apple announced on Saturday, August 8th that the FIPS 140-2 validations for the cryptographic modules used by iOS 8 and OS X 10.10.x have now been completed. This is significant news for folks who want to use FileVault 2 in government and regulated industries (such as financial and health-care institutions.)
For folks who haven’t heard of it before, FIPS 140-2 is an information technology security accreditation program run jointly by the US and Canadian governments. This program is used by private sector vendors to have their cryptographic modules certified for use in US and Canadian government departments and private industries with regulatory requirements for security.
As part of the announcement, Apple has released KBase articles and guidance for security offices who deal with encryption:
OS X Yosemite: Apple FIPS Cryptographic Modules v5.0 – http://support.apple.com/kb/HT205017
Crypto Officer Role Guide for FIPS 140-2 Compliance OS X Yosemite v10.10 – https://support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT205017/APPLEFIPS_GUIDE_CO_OSX10.10.pdf
According to Apple, the OS X Yosemite Cryptographic Modules, Apple OS X CoreCrypto Module v5.0 and Apple OS X CoreCrypto Kernel Module v5.0, require no setup or configuration to be in “FIPS Mode” for FIPS 140-2 compliance on devices running OS X Yosemite v10.10.
FileVault 2 is listed as being FIPS 140-2 Compliant as part of the Crypto Officer Role Guide for FIPS 140-2 Compliance OS X Yosemite v10.10 documentation, in the Compliant Applications and Services section.
For more information about the validation certification, please see below the jump.
As part of releasing the developer betas for OS X 10.11, Apple announced that El Capitan would be the end of the line for the Java 6 runtime and tools provided by Apple, with the clear statement that developers should be moving on to Oracle’s Java tools.
To completely replace Apple’s Java 6 tools, Oracle’s Java JDK (Java SE Development Kit) will need to be installed. This is because the Oracle Java JRE (Java Runtime Environment) on OS X is a browser plug-in for running Java via a web browser and does not include capabilities for running Java desktop apps or command line tools.
By default though, the Oracle JDK does not set several options to advertise the capabilities provided by the JDK to Java apps, which may cause applications that need those capabilities to fail to launch. The capabilities are actually present in the JDK, but those options need to be set before applications will recognize them as available.
To fix this, we need to add the following options to Oracle’s Java JDK:
In turn, enabling these options means they need to be added to the list of JVMCapabilities stored in the following plist file:
For more details, see below the jump.
Every so often, source code for an application gets lost, mislaid or not given to a customer. In that case, the application’s user may need to do a lot of work to decompile the application and see if the source code can be recovered from the application itself.
I recently had a colleague ask about a similar situation with an Automator application, where they had the Automator application itself but didn’t have access to the Automator workflow that created it.
After some testing, here’s how we were able to access the workflow using only the compiled application.
1. Save a copy of the Automator application to a convenient location.
2. Right-click on the application and select Show Package Contents.
3. Save a copy of Contents/document.wflow to a convenient location.
4. Rename document.wflow to preferred_file_name_here.workflow.
5. When prompted, confirm that you want to change the extension from .wkflow to .workflow.
At this point, you should be able to open the newly-renamed .workflow document in Automator and examine the workflow.
Update 8-1-2015: Steve Hayman pointed out that there’s an even easier way. For details, see below the jump.
On OS X 10.10.x and later, disabling Gatekeeper does not mean it is permanently off. After a set amount of time (currently 30 days), Gatekeeper will automatically re-enable itself with the Allow apps downloaded from: Mac App Store and identified developers setting.
I was able to track down which part of the OS this was coming from and it looks like it’s defined as part of syspolicyd:
After doing some research, it looks like Gatekeeper’s automatic re-enablement function can be disabled by running the following command with root privileges:
defaults write /Library/Preferences/com.apple.security GKAutoRearm -bool false
This would allow Gatekeeper to be set to Allow apps downloaded from: Anywhere and have it stay that way.
For those who want to set this with a management profile, I’ve created a .mobileconfig file and posted it here on Github:
Update – 7-31-2015: My colleague Tom Burgin points out that this may not be manageable via a profile after all, due to the way Apple has set the value that it’s reading:
If a management profile isn’t being respected, the defaults command listed above is the way to apply this to machines.
I’ve filed a bug report about this. For those interested in duping this bug, the bug report ID is 22094327. I’ve also cross-posted it to OpenRadar:
When building a presentation in Keynote, I often use Apple’s icons and other images included in OS X to illustrate my slides. This is because Apple’s already done a lot of work creating high-res images for OS X and it’s often helpful to use Apple’s own artwork when illustrating how something works. However, this artwork can also be hard to find as it can be buried deep within applications and other resource files. To help me get this artwork all together in one place, I’ve developed a script to search OS X for icons and other relevant images in various file formats, copy them when found, then organize the copied artwork. For more information, see below the jump.
As part of my work with packaging, I’ve built a few Automator-based applications to assist me and other Mac admins.
Along with building the applications themselves, I wanted to provide custom icons for these apps. This would help them be instantly distinguishable from other Automator applications and also help make them look more polished.
I recently decided to change out the application icon for Payload-Free Package Creator, as its icon had been created on Mavericks and now appeared a little dated when used on Yosemite. With input from my colleague Elliot Jordan, the new icon for Payload-Free Package Creator now looks like this.
For more information on how I went from this PNG file to an icon set for the application, please see below the jump.