Over the weekend, Rasmus Sten posted to Twitter about an interesting uninstall command line utility that he had found while testing 10.10.
On investigation, it became apparent that this uninstall utility was not new and was available starting in 10.7.x and later. It also appears to be undocumented and has neither a man page or help pages available.
To use the uninstall tool:
1. Log into the Mac in question
2. Verify that your application was installed by the App Store
3. Open Terminal
4. Run the following command with root privileges:
5. You will be prompted to authenticate with an administrator’s username and password
6. The application should then be uninstalled.
After working with this tool, it does have some limitations. For more details, see below the jump.
To go along with my earlier post about automating Oracle Java 7 updates, I’ve also posted a script to download and install the latest Java 8 update from Oracle. The method is identical, with the exception of referring to Java 8’s SUFeedURL value in Java 8’s /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist file.
For more information, see below the jump.
Something I’ve wanted to do for a while was to write a script to download and install the latest Java 7 update from Oracle. I’ve been using AutoPkg to download the latest Java 7 updates using AutoPkg’s OracleJava7 recipes, but I wanted to develop a script that would do the following:
- Download the latest Java 7 installer from Oracle’s website
- Install the latest Java 7 update
- Clean up after itself
Oracle didn’t make this an easy task, as the download URL seems to change on a per-update version. AutoPkg handles its update task by scraping Oracle’s manual download page for the current correct URL to use.
Oracle does provide a Sparkle-based update mechanism for Java 7 on OS X, so I wanted to see if there was a way to leverage that to pull down updates. The only address I could find in that regard was the SUFeedURL value included in Java 7’s /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist file. I checked that value using the following command:
defaults read "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info" SUFeedURL
The output I received for Java 7 Update 67 was the following:
I decided to see what output would come back from Oracle’s site when accessed, so I used the following curl command to see what was returned:
/usr/bin/curl --silent https://javadl-esd-secure.oracle.com/update/mac/au-1.7.0_67.xml
The following XML was returned and I was gratified to see that it contained a download link to a Java 7 Update 67 disk image.
One of the important things I was able to establish is that the XML address embedded with Java 7 Update 67 is not special in this regard. As part of my testing, I verified that using the SUFeedURL value for Java 7 Update 15 and 65 will also work to pull the address of the latest Oracle Java 7 installer disk image.
Using this information, I was able to build a script that can download and install the latest Java 7 update. See below the jump for details.
As part of Apple’s FileVault 2 encryption, Apple has provided for the use of recovery keys. These keys are a backup method to unlock FileVault 2’s encryption in the event that the usual method of logging using a user’s account password is not available.
There are two main types of recovery keys available:
1. Personal recovery keys – These are recovery keys that are automatically generated at the time of encryption. These keys are generated as an alphanumeric string and are unique to the machine being encrypted. In the event that an encrypted Mac is decrypted and then re-encrypted, the existing personal recovery key would be invalidated and a new personal recovery key would be created as part of the encryption process.
2. Institutional recovery keys – These are pre-made recovery keys that can be installed on a system prior to encryption and most often used by a company, school or institution to have one common recovery key that can unlock their managed encrypted systems.
Institutional keys are not automatically created and will need to be properly generated before they can be used. For more information on institutional recovery keys, see below the jump.
While working with a colleague to prepare a FileVault 2 rollout at his institution, he reported that in his testing, the decryption process did not appear to be working correctly when he was booted from the Recovery HD partition and using the command line diskutil-based decryption procedure that I had posted. In his testing, he was finding that the CoreStorage volume that the FileVault 2 encryption process created was not being removed when the diskutil corestorage revert command was run. The drive was being decrypted, but the CoreStorage volume was being left behind. This caused problems in his testing, because he found that rebooting afterwards led to the Mac booting to a prohibited sign.
This symbol at boot means the system has found a bootable installation of Mac OS X on the system, but there is something wrong with it.
After some additional testing, he discovered that he actually needed to run diskutil corestorage revert twice in succession. Running diskutil corestorage revert the first time would decrypt the drive. Running diskutil corestorage revert a second time following the first command would then remove the unencrypted CoreStorage volume. Once the CoreStorage volume was removed, the Mac would then be able to reboot normally to the regular boot drive.
The behavior seems to be tied to the following:
1. Booting from a Mavericks Recovery HD partition (all testing was done with a 10.9.4 Recovery HD partition.)
2. Decrypting either of the following methods:
A. Using Recovery HD‘s Disk Utility to decrypt the FileVault 2-encrypted boot drive. This decryption method is described here.
B. Running diskutil corestorage -revert from the Terminal. This decryption method is described here.
3. Letting the drive get to Conversion Progress: 100% while booted from the Recovery HD partition. Conversion Progress status can be displayed by running the diskutil corestorage list command in Terminal.
4. Rebooting back to the main boot drive once Conversion Progress: has reached 100%.
The end result is a locked CoreStorage volume that will not unlock or mount on boot, or when accessed from a Recovery HD partition or Apple’s Internet Recovery. This was the root cause for the prohibited symbol at boot that my colleague was receiving.
In my testing, I did find it was possible to decrypt the drive via Disk Utility or the command line when it was attached as an external drive (via Target Disk Mode or other means) to a Mac that was booted to a full version of OS X 10.9.x. Once decrypted, I verified that the CoreStorage volume was removed. Once I had verified that, I further verified that I could now boot normally from the previously non-bootable hard drive.
One drawback to decrypting while attached to a regular 10.9.x boot drive is that you are not able to use an Institutional Recovery Key (IRK). Using that kind of recovery key for unlocking or decryption only works when booted from a Recovery HD partition or Internet Recovery. Since that’s precisely where our problem exists, I investigated further to see if there were alternate workarounds for this problem. For more details and the workarounds I found, see below the jump.
I had an interesting issue crop up yesterday. One of our users sent in a ticket to report that Word 2011 on her laptop kept crashing with an EXC_BAD_ACCESS error. None of her other Office 2011 applications were exhibiting the behavior; it was specific to Word 2011.
When this error has cropped up in the past, I’ve fixed it in the past by removing Word’s Normal.dotm template from /Users/username/Library/Application Support/Microsoft/Office/User Templates or removing the com.microsoft preference files for the affected application from /Users/username/Library/Preferences.
So this time, I moved the following files to a new folder that I created on the user’s desktop:
/Users/username/Library/Application Support/Microsoft/Office/User Templates/Normal.dotm /Users/username/Library/Preferences/com.microsoft.Word.plist
Then I logged the user out, asked them to log back in and had them relaunch Word. Crash. EXC_BAD_ACCESS error again. This was going to be an unusual one…
As part of Firefox 31’s release, Mozilla made a change to enable support for NT LAN Manager version 1 (NTLMv1) network authentication when connecting to sites that are using HTTPS to allow encrypted communication via SSL between Firefox 31 and the website in question. This is to address the change made in Firefox 30, which disabled support for NT LAN Manager version 1 (NTLMv1) network authentication for sites using either HTTP and HTTPS.
NTLMv1 authentication to sites using HTTP is still disabled by default. For more information on why HTTPS is now enabled while HTTP remains disabled, this Mozilla bug report discusses the issue.
A way to tell if the NTLMv1-using site you’re trying to access is using HTTP or HTTPS is to check the connection address. If it begins with https://, you should be OK. If it begins with http:// , Firefox 31 will still block NTLMv1 authentication.
If you need to enable NTLMv1 authentication for an HTTP site that uses NTLMv1 authentication, Mozilla has provided a workaround to non-Windows users of Firefox, in the form of a setting that can be toggled to allow NTLMv1 authentication. This workaround should allow Mac and Linux users to continue using NTLMv1 authentication on HTTP sites, which will allow access again to SharePoint-based or IIS-backed web applications. For those folks who need it, I have the workaround documented here.
The Linde Group has released a new tool on Github: AutoPkgr, a GUI interface for AutoPkg. In my working with the initial release today, I’ve been impressed with the problems it solves for Mac admins who want to get started using AutoPkg but aren’t sure where to begin.
To use AutoPkgr, you will need to have the following pre-requisites:
1. OS X 10.9.x
3. Acceptance of the Xcode license agreement.
4. A logged-in user to run the AutoPkgr application in. This user can be a standard user or have admin rights.
Once the prerequisites have been met, see below the jump for details on installation and configuration.
As part of the man page for fdesetup, Apple provides a sample plist file as a guide for those who want to import authentication credentials as part of running commands with fdesetup.
As part of the plist, there are two plist keys that reference using a keychain which contains the private key for an institutional recovery key:
For KeychainPath, you will need to provide the file path to the keychain as the plist value. For KeychainPassword, you will need to provide the password that unlocks that keychain.
For example, if you put the keychain file into the /tmp directory, you would reference /tmp/filename.keychain as the KeychainPath plist value. If the password to unlock that keychain is seKritPassword, you would reference seKritPassword as the KeychainPassword plist value.
One particular thing to note is that the KeychainPath entry on the fdesetup man page references that this works with certain fdesetup commands, but does not specify which commands are applicable.
As of OS X 10.9.4, it appears that you can leverage the KeychainPath and KeychainPassword plist keys with the following two fdesetup commands.
If using the current institutional key to authenticate, the plist should look 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>KeychainPath</key> <string>/path/to/filename.keychain</string> <key>KeychainPassword</key> <string>password</string> </dict> </plist>
If you are using the current institutional key to authenticate a change to a new institutional recovery key, you can also embed the public key of the new institutional recovery key in the plist. In that case, the plist will look 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>KeychainPath</key> <string>/path/to/filename.keychain</string> <key>KeychainPassword</key> <string>password</string> <key>Certificate</key> <data> (Certificate data goes here.) </data> </dict> </plist>
VMware has released the VMware Fusion Technology Preview July 2014 as of Jul 3, 2014. One of the new items included in the Features list was this one:
Support for viewing VMware Fusion Professional to VMware Workstation, VMware ESXi, VMware vSphere servers in the library (File > Connect to Server)
When I investigated, it looks like this feature brings to VMware Fusion something that’s been in VMware Workstation for a while: a way to manage free ESXi and paid vSphere servers.
For more details, see below the jump.