Archive
Running Java 7 in a VMware Fusion 10.8.x VM
As mentioned previously, I’ve moved the majority of my testing to OS X VMs running in either VMware Fusion or VMware ESXi. However, there has been one component of my build testing that I still needed actual Macs for: testing Oracle’s Java 7 updates. The reason for this is that Java 7 crashes when run inside of a VMWare Fusion VM.
Oracle has certified the following virtualization solutions as being Oracle JDK 7 and JRE 7 Certified System Configurations:
Certified:
Not certified:
VMware virtualization solutions
Microsoft virtualization solutions
Unfortunately, that meant unless Oracle or VMware stepped up, Java 7 wasn’t going to run inside an OS X VM. Fortunately, VMware stepped up. There is now a script available from VMware to patch liblwawt.dylib in the Java 7 Runtime Environment. The patch addresses the Java 7 crashing issue, allowing Java 7 Update 17 to run normally in an OS X 10.8.3 VM.
The patch is specific to 10.8.x VMs and does not work in 10.7.x VMs at this time.
I’ve posted a copy of the Python script that applies the patch here on my GitHub repo:
https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/vmware_fusion_java_7_patch
I’ve also built a payload-free package to run the script:
Migrating OS X VMs to a VMware ESXi server
I’ve started using ESXi servers more and more for hosting my test Macs, both here and at work. As part of that, I’ve found it to be considerably easier for me to build the VM inside of VMware Fusion on my Mac and move it to ESXi, then build it from scratch on my ESXi server.
That said, I’ve found the process for moving OS X VMs has not been straightforward. When I first tried moving 10.8.x VMs, I tried both VMware’s OVF Tool and VMware’s Standalone Converter, but neither initially appeared to provide me with the ability to transfer working OS X 10.8.x VMs.
In the end, I was able to find a way to use VMware’s Standalone Converter to transfer 10.8.x VMs, but the process involves some extra steps on the ESXi server’s end.
The process I’ve developed involves using a Windows 7 VM running inside of VMware Fusion, with the VMware Standalone Converter application installed. One thing to note before proceeding further is that I did not try this with a vSphere server. All my work has been done with VMware’s free ESXi server, so it may be that there’s an easier way to do this with vSphere. See below the jump for details.
Setting the default boot drive from the boot volume menu
This has been previously documented in a few places, but I just ran across this handy way to set the default boot drive from the boot volume menu.
When you start up a Mac holding down the Option key, the boot volume menu appears and displays all available bootable volumes. When you select a drive by clicking on it or selecting it with the arrow keys on your keyboard, it’ll boot from that drive until the next reboot. At the next reboot, unless you hold down the Option key again, the Mac will boot from whatever drive was set in the Startup Disk preference pane to be the default boot drive.
However, there’s also a way to change the default boot volume from the boot volume menu. In this case, once you got to the boot volume menu, you can let go of the Option key, then hold down the Control key. At that point, you should see the upward arrow icon that points at the currently selected drive turn into a circular arrow.
Once you select that drive and boot from it, it will now also be set as the Mac’s default boot drive.
Automatically enable the Java web plug-ins setting in Safari 6.0.3 and later
One of the features of Apple’s Safari 6.0.3 update is that it turns off the automatic execution of Java applets through Safari, even if the Java browser plug-in is otherwise enabled.
Safari 6.0.3 does allow for the automatic execution of Java applets to be re-enabled through the browser. However, if it’s been a while since a Java applet was launched, then automatic execution of Java applets is once again automatically disabled.
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. Fortunately, I already had a fix for this issue; it just needed to be updated with some additional commands.
To make this work, I’ve written a script and launch agent combination. The script will perform a couple of tasks:
1. Set the com.apple.WebKit.JavaPlugInLastUsedTimestamp plist key in ~/Library/Preferences/.GlobalPreferences.plist
2. Enable the Enable applet plug-in and Web Start Applications setting in the Java Preferences application.
#!/bin/sh
# DYNAMICALLY SET THE UUID FOR THE BYHOST FILE NAMING
if [[ `ioreg -rd1 -c IOPlatformExpertDevice | grep -i "UUID" | cut -c27-50` == "00000000-0000-1000-8000-" ]]; then
MAC_UUID=`ioreg -rd1 -c IOPlatformExpertDevice | grep -i "UUID" | cut -c51-62 | awk {'print tolower()'}`
elif [[ `ioreg -rd1 -c IOPlatformExpertDevice | grep -i "UUID" | cut -c27-50` != "00000000-0000-1000-8000-" ]]; then
MAC_UUID=`ioreg -rd1 -c IOPlatformExpertDevice | grep -i "UUID" | cut -c27-62`
fi
# Enable Java browser plug-ins in Safari 6.0.3 and later
# for the current user by setting the com.apple.WebKit.JavaPlugInLastUsedTimestamp
# key in ~/Library/Preferences/.GlobalPreferences.plist
/usr/libexec/PlistBuddy -c "Delete :com.apple.WebKit.JavaPlugInLastUsedTimestamp" $HOME/Library/Preferences/.GlobalPreferences.plist
/usr/libexec/PlistBuddy -c "Add :com.apple.WebKit.JavaPlugInLastUsedTimestamp real $(( $(date "+%s") - 978307200 ))" $HOME/Library/Preferences/.GlobalPreferences.plist
/usr/bin/plutil -convert xml1 $HOME/Library/Preferences/.GlobalPreferences.plist
# Set the the "Enable applet plug-in and Web Start Applications" setting in
# the Java Preferences for the current user.
/usr/libexec/PlistBuddy -c "Delete :GeneralByTask:Any:WebComponentsEnabled" $HOME/Library/Preferences/ByHost/com.apple.java.JavaPreferences.${MAC_UUID}.plist
/usr/libexec/PlistBuddy -c "Add :GeneralByTask:Any:WebComponentsEnabled bool true" $HOME/Library/Preferences/ByHost/com.apple.java.JavaPreferences.${MAC_UUID}.plist
/usr/libexec/PlistBuddy -c "Delete :GeneralByTask:Any:WebComponentsLastUsed" $HOME/Library/Preferences/ByHost/com.apple.java.JavaPreferences.${MAC_UUID}.plist
/usr/libexec/PlistBuddy -c "Add :GeneralByTask:Any:WebComponentsLastUsed real $(( $(date "+%s") - 978307200 ))" $HOME/Library/Preferences/ByHost/com.apple.java.JavaPreferences.${MAC_UUID}.plist
/usr/bin/plutil -convert xml1 $HOME/Library/Preferences/ByHost/com.apple.java.JavaPreferences.${MAC_UUID}.plist
# Forces preferences to be re-read
/usr/bin/killall cfprefsd
The LaunchAgent runs the script on login to any user account with the logging-in user’s privileges and permissions.
You can find the updated script here on my GitHub repo:
Checking for accounts with Remote Management rights
Something a number of Mac admins need to know about the Macs in their environment is being able to detect which accounts have remote management rights on a particular Mac. Crafty users can be inventive about finding ways to grant themselves remote management rights, so admins need to be just as perceptive about identifying which accounts have remote management rights.
To help with the task of identifying which accounts have remote management rights, I’ve written a script to detect which local accounts had remote rights on a particular Mac.
#!/bin/sh
# Determines if the Remote Management settings are set
# for "All Users" or for "Only these users:" in System
# Preferences' Sharing preference pane
ARD_ALL_LOCAL=`/usr/bin/defaults read /Library/Preferences/com.apple.RemoteManagement ARD_AllLocalUsers`
# Lists all local user accounts on the Mac with a UID
# of greater or equal to 500 and less than 1024. This
# should exclude all system accounts and network accounts
#
# List is displayed if the "All Users" setting is
# set in the Remote Management settings.
ALL_ID500_PLUS_LOCAL_USERS=`/usr/bin/dscl . list /Users UniqueID | awk '$2 >= 500 && $2 < 1024 { print $1; }'`
# Lists all user accounts on the Mac that have been given
# explicit Remote Management rights. List is displayed if
# the "Only these users:" setting is set in the Remote
# Management settings.
REMOTE_MANAGEMENT_ENABLED_USERS=`/usr/bin/dscl . list /Users naprivs | awk '{print $1}'`
if [ "$ARD_ALL_LOCAL" = "1" ]; then
result=$ALL_ID500_PLUS_LOCAL_USERS
elif [ "$ARD_ALL_LOCAL" = "0" ]; then
result=$REMOTE_MANAGEMENT_ENABLED_USERS
fi
# Displays list of accounts that have
# been given Remote Management rights
echo $result
I’ve posted the script here on my GitHub repo:
https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/check_for_remote_management_accounts
I’ve also modified it for use as an Casper Extension attribute. I’ve posted it here on my GitHub repo:
https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Extension_Attributes/check_for_remote_management_accounts
Managing Adobe Flash browser plug-in settings for Apple’s XProtect malware protection
As a follow-up to my earlier post about managing XProtect’s ability to block Java browser plug-ins , a Mac admin named scifiman sent me a launchdaemon and script to manage Adobe Flash using a similar method. Thanks, scifiman!
<?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>Label</key> <string>com.company.xprotect_re-enable_adobe_flash</string> <key>ProgramArguments</key> <array> <string>sh</string> <string>/Library/Scripts/xprotect_re-enable_adobe_flash.sh</string> </array> <key>QueueDirectories</key> <array/> <key>RunAtLoad</key> <true/> <key>StartInterval</key> <integer>900</integer> <key>WatchPaths</key> <array/> </dict> </plist>
#!/bin/sh
# This script is a modified version of rtrouton's re-enable_java_6_and_7 script.
# This script will check the current Adobe Flash browser plug-in
# version and compare it against the minimum version allowed by
# Apple's XProtect malware protection. If the minimum Flash version
# allowed by XProtect does not allow the current version of the Flash
# browser plug-in on the Mac, the script will alter the Mac's
# /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist
# file to set the minimum version allowed to match the current version
# of the Mac's Flash browser plug-in. This allows the Mac's current Flash
# browser plug-in to run in Safari without being blocked.
#
# Original script is from here:
# https://gist.github.com/scifiman/5109047
#
osvers=$(sw_vers -productVersion | awk -F. '{print $2}')
# javaVendor=`/usr/bin/defaults read "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info" CFBundleIdentifier`
CURRENT_FLASH_BUILD=`/usr/libexec/PlistBuddy -c "print :CFBundleShortVersionString" /Library/Internet\ Plug-Ins/Flash\ Player.plugin/Contents/Info.plist`
XPROTECT_FLASH_BUILD=`/usr/libexec/PlistBuddy -c "print 
lugInBlacklist:10:com.macromedia.Flash\ Player.plugin:MinimumPlugInBundleVersion" /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist`
#
# Check to see if Xprotect is blocking Adobe's Flash browser plug-in and re-enable the plug-in if needed.
# Changes in this section are from Pepijn Bruienne's re-enable_java_6 script: https://github.com/bruienne
#
if [[ -e /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist ]]; then
if [ ${CURRENT_FLASH_BUILD} != ${XPROTECT_FLASH_BUILD} ]; then
/usr/bin/logger "Current Flash build (${CURRENT_FLASH_BUILD}) does not match the minimum build required by Xprotect (${XPROTECT_FLASH_BUILD}). Setting current version as the minimum build."
/usr/libexec/PlistBuddy -c "Set lugInBlacklist:10:com.macromedia.Flash\ Player.plugin:MinimumPlugInBundleVersion $CURRENT_FLASH_BUILD" /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist
/usr/bin/plutil -convert xml1 /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist
/bin/chmod a+r /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist
else
/usr/bin/logger "Current Flash build is ${CURRENT_FLASH_BUILD} and Xprotect minimum build is ${XPROTECT_FLASH_BUILD}, nothing to do here."
fi
fi
exit 0
The script has been tested on 10.6.8, 10.7.5 and 10.8.2, so it should cover all current OSs that use Apple’s XProtect malware protection.
Scifiman’s original gist is available here:
https://gist.github.com/scifiman/5109047
I’m hosting a copy of the script and launchdaemon here on my GitHub repo:
Using Apple Remote Desktop Admin to help script ARD kickstart options
Apple Remote Desktop is a tool that just about every Mac admin uses at some point. The client is built into OS X and it’s usually straightforward to turn on. It also includes a command line tool called kickstart which can be used to configure the Apple Remote Desktop client. The kickstart tool is useful because you can use it to script your configuration. That said, if you have a complex ARD configuration, getting the kickstart options correct can be tricky.
One way to help with this is to have Apple Remote Desktop Admin do the kickstart configuration work for you. See below the jump for the details.
Opening Finder windows from the Terminal
While working on the command line in Terminal, I occasionally need to open up a new Finder window so that I can take a look at something in the Finder. When this happens, the open command provides a useful shortcut to do so.
To open a new Finder window from the current directory in the Terminal, you would run the following command:
open .
For example, if you have navigated to the Pictures directory in your home folder, running this command would cause the Pictures directory to open in a new Finder window.
If you want to open a Finder window using Terminal for an alternate directory, you would run the following command:
open /path/to/directory
For example, if you wanted to access the XProtect.meta.plist file stored in the /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources directory, you could run this command to open the /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources directory in a new Finder window:
open /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources
Managing Java browser plug-in settings for Apple’s XProtect malware protection
In response to a number of recent Java exploits, both Apple and Mozilla have begun blocking vulnerable versions of Java from running in their respective browsers via their malware protection mechanisms. While this is the right move from a security perspective, it can leave enterprises without the ability to access mission-critical systems that use Java applets running in a browser.
The fix should be to update those affected machines with the latest version of Java. However, this assumes that a) the latest available version of Java is not itself blocked and b) the mission-critical system is able to use the latest version of Java.
From my own perspective, what Apple is doing from a malware protection standpoint is the right thing. I just don’t want my users to lose the ability to access our systems that use a Java applet, especially when the latest available version of Java is blocked and I don’t have a way to otherwise satisfy Apple’s XProtect malware protection without disabling XProtect.
My fix was this: manage XProtect’s ability to disable the Java browser plug-in by modifying the Java browser plug-in settings in the affected Mac’s /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist file. See below the jump for the details.
Filing bugreports with Oracle for Mac OS X’s Java 7
Want to file a bug report about an issue having to do with Java 7 for OS X? It can be tricky to find the right place to submit it, so here’s some guidance for filing it in the right place.
Update: I’ve been informed that it is necessary to install the current JRE of Java 7 from the Oracle JDK7 test site before Oracle will accept bug reports from you.
JDK7 is available from http://jdk7.java.net/, with the download site being http://jdk7.java.net/download.html.
The reason that Oracle does it this way is that they want customers to use Oracle Java SE Support. This is for-pay support and Oracle’s preferred way for non-developer customers to get support.
All that said, if the issue you’re running into also occurs on the JRE from the Oracle JDK site, file a bug using the procedure below.
For example, here’s how to file a bug report for the Java 7 installer for OS X.
1. Go to http://bugreport.sun.com/bugreport/
2. Scroll down to the Submit a Bug section
3. Check the box for Check this box to indicate that you understand this is not a place to receive support….
4. Click the Start a new Report button.
5. On the next page, go to the Start A Report: section
6. For an installer bug, select the following:
Type: Bug
Product/Category: Java Platform Standard Edition (JDK/JRE)
Subcategory: JDK/JRE installation (install)
Release: Java Platform Standard Edition 7
Operating System: Mac OS X 10.7 (Oracle VM)
7. When ready to proceed, click the Continue button.
8. On the next page, provide the information requested to file your bug report and click the Submit button when completed.
Good luck! Filing bug reports doesn’t guarantee that your problem will be fixed, but it raises the odds that it will be. Not filing it may mean that Oracle is completely unaware of the problem and thus will never fix it.
Recent Comments