Category Archives: Yosemite

Installing VMWare Tools on a Netboot NBI

Netboot is great.  VMWare Fusion is great. Yosemite is….Netboot and VMWare are great. I use VMs to test things on our builds at work.  To get those VMs setup I use our imaging process that utilizes Netboot.  However, I discovered that, new with Yosemite, when the VM Netbooted to our Yosemite NBI I wasn’t able to login to OS X. After typing in the username and password the login attempt would just hang with the spinning gear turned beachball.  No bueno. Turns out all it requires is getting the VMWare Tools installed on the NBI.  No problem right? But VMWare’s installer (read: .app) doesn’t allow installing on a non-boot volume.  Crap.  This wouldn’t be a very interesting post if we stopped here so…

TL;DR: you need to mount the NBI and install the tools via the CLI ‘installer’ command.

First, make sure that your existing NBI is read/write when mounted.  In my case the NBI is actually a .sparseimage but renamed to .dmg for Netboot use.  When mounting the image named .dmg it mounts as read-only.  Renaming the .dmg to .sparseimage mounts the volume as read-write. YMMV. There are ways to convert disk images to read-write. I’ll leave that discovery up to you if your environment requires it.

VMWare Tools acquisition/installation:

There are a couple ways to get the tools.  I prefer to pull the tools from the VMWare Fusion.app bundle itself to guarantee that the version of VMWare Fusion you’re running is compatible with the tools. If you want an automated way using AutoPkg to get the latest tools check out Rich Trouton’s post at Der Flounder.  You can also download the tools if you know what version you need at VMWare’s repository.

Locally, the tools are located in the application bundle found at /Applications/VMware\ Fusion.app/Contents/Library/isoimages/darwin.iso

iso-location

Mounting that image results in the installer and uninstaller.

mounted-iso

However attempting to use the .app installer will fail as it won’t let you target the install on a non-boot drive.  Since it’s a .app “installer” there must be a .pkg buried in the bundle. To get the actual installer .pkg right click on “Install VMWare Tools.app” and choose “Show Package Contents”.  Navigate to the /Volumes/VMware\ Tools/Install\ VMware\ Tools.app/Contents/Resources/ directory.  There you’ll find “VMWare Tools.pkg”. Jackpot.

installer-location

Copy the “VMWare Tools.pkg” to the computer where the NBI is mounted and run ‘installer’ pointing the target at the mounted Netboot NBI.

 sudo installer -pkg /Volumes/VMware\ Tools/Install\ VMware\ Tools.app/Contents/Resources/VMware\ Tools.pkg -target /Volumes/Yosemite\ NetBoot -verbose

That will install on the mounted volume.  Once complete, unmount the NBI, rename it if necessary, and you should now be able to log into a Yosemite NBI when Netbooted in VMWare Fusion.

Tagged ,

createmobileaccount workaround for 10.10.3

UPDATE: As of Mac OS X 10.10.4 this issue has been addressed by Apple. The following still applies to 10.10.3 installs. 

Since 10.10.3 was released on April 8, 2015, the Mac admin community has had the privilege of discovering what’s broken with this new OS. We knew about the rootPipe fix but not it’s unintended collateral damage. One piece that was discovered comprimised is the tool “createmobileaccount” found in /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount. This tool can be used to pre-create a home folder and add the user to the local directory service node without having a user log in. It can also dynamically verify that the account attempting to be made actually exists in the directory service prior to creating the account. That can be handy for restoring user data, creating a directory based account prior to sending off-site, or giving a user admin rights prior to deployment. As of 10.10.3 and it’s rootPipe fix, that tool is broken. BUT, there is a workaround.

The workaround to still use createmobileaccount is to do the following*:

  1. Copy the user template to create the home folder: cp -R /System/Library/User\ Template/English.lproj /Users/${newUser}
  2. Change rights on the folder for the new user: chown -R ${newUser}:staff /Users/${newUser}
  3. Run createmobileaccount: /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -n ${newUser}

Take note if you implement this workaround in your workflow that the home folder is being created before createmobileaccount is run.  If createmobileaccount fails, the home folder you created will still exists and you may want to clean that up depending on the environment.

*thanks to mm2270’s post on JAMFNation.

Tagged , ,

10.10 – Boot Hangs after Deleting /var/folders Directory

UPDATE 4-13-2015: Apple replied back to my bug report stating it behaves as expected and deleting the /var/folders directory is not supported. So….don’t delete /var/folders.

Previously, in OS 10.9 it has been documented that removing the data in /private/var/folders is a good troubleshooting step for various reasons. There is a good writeup at blog.magnusviri.com describing what /var/folders contains and what issues arise from its bloat. Up thru OS 10.9.5 it hasn’t been an issue deleting contents or the parent directory.

The article above mentions deleting just the contents of /var/folders, which is still good advice. However a haphazard deletion of the /var/folders directory itself will cause issues in 10.10. If you delete the parent folder /var/folders and reboot, the computer will boot to about 50% and hang indefinitely. It will look a lot like the “loginLockout” behavior except the progress bar is at around 50% instead of 33% and the cursor is on screen. Don’t be fooled as I was. This is not loginLockout.

Examining the boot drive while booted from another source showed many errors in system.log when booting about /var/folders/zz not being present. Surprisingly it appears that mkdir is being called but unable to create the directory structure.

.
.
.
Mar 19 09:40:26 macadmins-Mac.local dirhelper[1008]: mkdir(/var/folders/tx): No such file or directory
Mar 19 09:40:26 macadmins-Mac xpcproxy[1007]: libcoreservices: _dirhelper_userdir: 351: stat: /var/folders/tx/56ff45qs2rlc89vggkr8x3yr0000gn/: No such file or directory
Mar 19 09:40:26 macadmins-Mac.local dirhelper[1008]: mkdir(/var/folders/tx): No such file or directory
Mar 19 09:40:26 macadmins-Mac fontworker[1007]: libcoreservices: _dirhelper_userdir: 351: stat: /var/folders/tx/56ff45qs2rlc89vggkr8x3yr0000gn/: No such file or directory
Mar 19 09:40:26 macadmins-Mac fontworker[1007]: libcoreservices: _dirhelper: 454: mkdir: path=/var/folders/tx/56ff45qs2rlc89vggkr8x3yr0000gn/T/ modes[1]=0700: No such file or directory
Mar 19 09:40:26 macadmins-Mac fontworker[1007]: libcoreservices: _dirhelper: 454: mkdir: path=/var/folders/tx/56ff45qs2rlc89vggkr8x3yr0000gn/C/ modes[2]=0700: No such file or directory
Mar 19 09:40:27 macadmins-Mac storeassetd[304]: libcoreservices: _dirhelper: 454: mkdir: path=/var/folders/tx/56ff45qs2rlc89vggkr8x3yr0000gn/T/ modes[1]=0700: No such file or directory
Mar 19 09:40:27 macadmins-Mac fontd[227]: libcoreservices: _dirhelper: 454: mkdir: path=/var/folders/tx/56ff45qs2rlc89vggkr8x3yr0000gn/T/ modes[1]=0700: No such file or directory
Mar 19 09:40:31 macadmins-Mac.local dirhelper[1008]: mkdir(/var/folders/tx): No such file or directory
Mar 19 09:40:31 macadmins-Mac xpcproxy[1011]: libcoreservices: _dirhelper_userdir: 351: stat: /var/folders/tx/56ff45qs2rlc89vggkr8x3yr0000gn/: No such file or directory
Mar 19 09:40:31 macadmins-Mac.local dirhelper[1008]: mkdir(/var/folders/tx): No such file or directory
Mar 19 09:40:31 macadmins-Mac xpcproxy[1012]: libcoreservices: _dirhelper_userdir: 351: stat: /var/folders/tx/56ff45qs2rlc89vggkr8x3yr0000gn/: No such file or directory
Mar 19 09:40:31 macadmins-Mac fontd[227]: libcoreservices: _dirhelper: 454: mkdir: path=/var/folders/tx/56ff45qs2rlc89vggkr8x3yr0000gn/T/ modes[1]=0700: No such file or directory
Mar 19 09:40:31 macadmins-Mac fontd[227]: libcoreservices: _dirhelper: 454: mkdir: path=/var/folders/tx/56ff45qs2rlc89vggkr8x3yr0000gn/T/ modes[1]=0700: No such file or directory
Mar 19 09:40:31 macadmins-Mac loginwindow[64]: libcoreservices: _dirhelper: 454: mkdir: path=/var/folders/tx/56ff45qs2rlc89vggkr8x3yr0000gn/T/ modes[1]=0700: No such file or directory
Mar 19 09:40:31 macadmins-Mac fontd[227]: libcoreservices: _dirhelper: 454: mkdir: path=/var/folders/tx/56ff45qs2rlc89vggkr8x3yr0000gn/T/ modes[1]=0700: No such file or directory
Mar 19 09:40:31 macadmins-Mac.local locationd[241]: Could not write data to disk /var/folders/zz/zyxvpxvq6csfxvn_n00000sm00006d/C/cache.plist
Mar 19 09:40:45 localhost dirhelper[61]: /var/folders/: invalid ownership
.
.
.

To fix the issue I had to maually recreate the directories folders/zz in /var to allow the system to boot once again.

I’ve file a bug report and posted on OpenRadar.

Tagged , ,

Jettisoning the Boot Cache – is it safe?

UPDATE – Apple released OS 10.10.3 on April 8, 2015 that addresses the boot lockout issue described below. Information on the release can be found at Apple’s support site.

You may have heard of this little problem with Yosemite some are giving the moniker “Login Lockout”. The problem, as described at AFP548.com, is that the computer will boot about 1/3 of the way and halt. It happens randomly, but more often after a hard reboot.

A community fix has been gaining traction at JAMFNation that suggests editing /etc/rc.server to run /usr/sbin/BootCacheControl jettison that seems to work. But is it safe to jettison the boot cache every boot?

In short, probably.

My friend @mikeymikey on Twitter spelunked into the issue at depths I’m not comfortable with and discovered, among other things, that the BootCache.kext has code that calls for a jettison on multiple occasions. The code is open sourced and available to browse at Apple’s open source site. Searching for “jettison” in the code will reveal some nice comments about different scenarios that would invalidate the cache. You can also see the command’s semi-hidden documentation by running /usr/sbin/BootCacheControl without an option. It will display the following, jettison being one option.


Usage: /usr/sbin/BootCacheControl [-vvv] [-f ] start
           Start recording history and play back .
       /usr/sbin/BootCacheControl [-vvv] [-f ] stop
           Stop recording history and write the playlist to .
       /usr/sbin/BootCacheControl mount
           Notify the boot cache of a new mount.
       /usr/sbin/BootCacheControl [-vvv] jettison
           Jettison the cache.
       /usr/sbin/BootCacheControl statistics
           Print statistics for the currently-active cache.
       /usr/sbin/BootCacheControl tag
           Insert the end-prefetch tag.
       /usr/sbin/BootCacheControl [-vvv] [-t batchnum] -f  merge  [...]
           Merge ... into .
           Playlist files after the first will be offset  batches, if provided
       /usr/sbin/BootCacheControl [-c] -f  print
           Print the contents of .
       /usr/sbin/BootCacheControl -f  unprint
           Read a playlist from standard input and write to .
       /usr/sbin/BootCacheControl -f  generate []
           Generate a playlist from standard input data for  and write to .
       /usr/sbin/BootCacheControl -f  truncate 
           Truncate  to  entries.
       /usr/sbin/BootCacheControl -f  generalize
           Modify  to apply to any root volume.

The result of running this on every boot just means that the computer may boot a smidge slower as the cache is not there to reference.

There are rumors of a fix coming from Apple but it’s unclear if that will be included in 10.10.3 or not. Adding the jettison to rc.server appears to be a valid workaround until the official fix is out. This temporary workaround is easily revertible by just removing the rc.server file and rebooting.

Tagged , ,

Profile Behavior Changes in Yosemite

Forced. Often. Once. If you’ve used MCX and/or Profiles before you’re familiar with those terms and what they mean when a Profile is installed on a system.

I thought I did, too, until I stumbled upon a fundamental change of the rules in how Yosemite now behaves in the case of Often. Granted, anything besides “Forced” isn’t necessarily supported by Apple as their own Profile Manager tool only spits out Force management frequency profiles. Previously, adjustments could be made to Profiles to allow for a less heavy handed frequency of management. It appears our grace period for one type of manual change is over.  A tool to help create custom Profiles is called mcxToProfile.  Check out Tim Sutton’s documentation and tool — mcxToProfile as we’ll be using it later in this example.

See for yourself
As an easily observable example lets use a simple preference structure.
First, create a plist file with the keys you want to manage.

 defaults write my.great.app setting1 -string foobar
 defaults write my.great.app setting2 -bool false
 defaults read my.great.app
 {
 setting1 = foobar;
 setting2 = 0;
 }
 

Use Tim’s mcxToProfile tool to create a Profile to manage the domain “often”.

mcxToProfile.py --plist ~/Library/Preferences/my.great.app.plist --identifier MyGreatApp --manage Often

Copy the profile to a test machine or VM running Yosemite and install it.

sudo profiles -IF MyGreatApp.mobileconfig

You can see the preferences have been applied by running

defaults read my.great.app

Make some preference changes after the Profile was installed:

 defaults write my.great.app setting3 -string Chickens
 defaults write my.great.app setting4 -int 42
 defaults read my.great.app
  {
  setting1 = foobar;
  setting2 = 0;
  setting3 = Chickens;
  setting4 = 42;
  }

Log out and back into OS X and read the plist again.

 defaults read my.great.app
  {
  setting1 = foobar;
  setting2 = 0;
  }

The user’s settings have been eradicated even though they aren’t the keys being managed.

For a real world example lets look at how it works when we manage the Dock with a profile.

First, create a plist file with the keys you want to manage. This example sets the Dock to anchor to the right side of the screen.

defaults write ~/Desktop/com.apple.dock orientation -string right

That will result in a plist that only has the key specified in the defaults command:

<?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>orientation</key>
    <string>right</string>
</dict>
</plist>

Create a Profile to manage the domain “often”.

mcxToProfile.py --plist ~/Desktop/com.apple.dock.plist --identifier MyDockSettings --manage Often

The payload content in the resulting .mobileconfig is

 <key>PayloadContent</key>
 <dict>
   <key>com.apple.dock</key>
   <dict>
     <key>Set-Once</key>
     <array>
       <dict>
         <key>mcx_preference_settings</key>
         <dict>
           <key>orientation</key>
           <string>right</string>
         </dict>
       </dict>
     </array>
   </dict>
 </dict>

Copy the profile to a test machine or VM running Yosemite and install it.

sudo profiles -IF MyDockSettings.mobileconfig

When the Profile payload applies you will see the Dock quit and reappear pinned to the right of the screen. Now make a manual change to the Dock, for instance, drag and drop a couple apps to the Dock. Log out and back into OS X. The apps you added are gone. The Dock has reverted to the way it was when the Profile was installed. This will happen every time you log out and back into OS X.

So now what?
An informal survey in the IRC channel ##osx-server on Freenode showed that the Often management frequency isn’t used that..well..often. The only admins in the know of that frequency would be those that use Tim’s mcxToProfile tool or hand craft their own. But if you happen to have that frequency there are a couple options.

  • Change the frequency. Set-Once with a timestamp still appears to function correctly (for now). And Forced should work as long as the application you’re trying to manage uses the OS’s APIs for reading preferences.
  • Use a different tool. Use outset to run scripts to make the change on the frequency you need. LaunchAgents or LaunchDaemons are viable as well.

tl;dr – Don’t use Often in Yosemite. Profiles set to apply “Often” reset setting changes made after the profile was installed every “often” time it is applied. If a plist didn’t exist before the Profile was installed the resulting plist contains only the keys that are in the profile — collateral damaged keys be damned.

Tagged , ,