Tag Archives: osx

Sierra’s Built-in Storage Management Utility

New with Sierra there is a built-in utility to help keep disk storage space available.  The function is part of the System Information.app and is accessed a few ways:

  1.  => About This Mac => Storage => Manage…
  2. (Hold the option key down)  => System Information… => Window => Storage Mangement (Cmd-U)
  3. /Applications/Utilities/System Information.app => Window => Storage Mangement (Cmd-U)

Once launched it will proceed to gather data sizes of categories of interest. The available and total disk space will be listed in the window’s name.

main-overview

First you’ll see some recommendations of ways to keep disk space available.  Each has its own set of gotchas so be sure to make note of the implications:

Store in iCloud

store-in-icloud-options

There has been some interesting discoveries in the behavior surrounding iCloud Desktop and Documents.  See iCloud Desktop and Documents in macOS Sierra – The Good, The Bad and the Ugly for a full rundown. Even though these checkboxes are checked by default, that doesn’t represent the actual state of the setting.  On my machine I have Desktop and Documents turned off in the iCloud preference pane yet this box shows as checked.

Optimize Storage —

optimize-storage-options

Empty Trash Automatically —

empty-trash-automatically

If you’re one of those that can’t commit to deleting things once put in the Trash, let the OS handle it for you.

Reduce Clutter —

This option opens the Documents listing.

Along the left are categories and the amount of space each is taking up.  Accessing those brings up a list sorted by largest on top.  If you want to remove an individual listing, right click and select Delete. Even though Applications are listed, non-admins can’t remove applications without admin credentials.

Thanks to @adamcodega for pointing this tool out.

Tagged , , , , , , ,

Cache Active Directory credentials off-site

A scenario I ran into recently involved an existing user who had their computer re-imaged with OS 10.10.5.  Their user data was backed up and restored prior to returning the system to the user.  To restore data I first use createmobileaccount to create a home directory and cache user information based off of AD, then rsync the data into the local home directory.  Since I don’t know the user’s password I don’t use the -p option leaving the cached account information without a password. Instead, the password is cached the first time the user logs in.  However, that only works when the computer can talk to our AD environment.

This user didn’t log in prior to taking the laptop out of the office for the week (who does that after a computer upgrade?!).  Since no password was cached there was nothing to authorize their credentials against. This could make for a long week for this user.

Since I had already created a home folder with all the user data I didn’t want to erase it or even have to bother with moving it around to a temporary user account.  Instead I did the following to preserve the files and allow the user to log in off-site:

  1. Have the user log in as a local admin.
  2. Have the user log into our company VPN as themselves.
  3. I gained access to the computer via Apple Remote Desktop (ssh, ScreenSharing, or any other means would work as well)
  4. I removed the current cached user info, sans password with sudo dscl . -delete /Users/<username>. This removes the locally cached information for the user from /var/db/dslocal/nodes/Default/users/<username>.plist but leaves the /Users/<username> home folder data alone.
  5. I then issued sudo /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -n <username> -p <password> . I had the user type their password to match their AD account.

Step 5 recreates the cached user information in /var/db/dslocal/nodes/Default/users/<userid>.plist (as long as the computer can talk to Active Directory), but this time with a cached password. Log out of the admin account and now the user can log in as themselves off-site using their AD credentials and access the already created home directory in /Users/<username>.

Tagged , , , , , , , ,

Flash Player 20.0.0.235 Adds Phone Home Analytics

Update: This issue seems to be isolated to version 20.0.0.235 as subsequent releases do not contain the LaunchDaemon and executable.  

Starting with the Flash Player 20.0.0.235 there are two new files added to the installer that attempt to send anonymous analytic data back to Adobe.  The files are a new LaunchDaemon at /Library/LaunchDaemons/com.adobe.SC.FPFeedbackService-1.0.plist that fires off  /Library/Application Support/Adobe/FPFeedbackService.  Running strings against the FPFeedbackService binary reveals some interesting tidbits:

# Following anonymous information is being collected from your machine.
# OS, OSType
- Operating System details
# UserAgent
- Browser details
# FlashVersion
- Installed Flash Player version
# RenderMode
- Represents the render mode of the SWF content.
# SWFVersions
- It is the list of SWF Versions played in browser and their count.
e.g. SWF10|23 means that SWF file having version 10 have been played 23 times.
# ASVersions
- It is the list of Action Script Versions associated to SWF files and their count.
e.g. AS2|10 means SWF file having Action Script Version 2 have been played 10 times.
# APIList
- The API List represents the collated API and its count in all played SWF files.
API names have been encoded to reduce the network traffic.
e.g. flash.display3D::Context3D will be encoded as 17.

and

User has disabled the service.Exiting.
Analytics Disabled.Exiting.

I found no option for disabling the analytics in the Flash Player PreferencePane.  Flash Player’s configuration can be managed with a /Library/Application Support/Macromedia/mms.cfg configuration file.  That’s how automatic updates have been suppressed previously. However, there is no mention of the new analytics or how to disable it in the ADOBE® FLASH® PLAYER 20.0 Administration Guide.  There is no mention in the blog post announcing the release, either. I’ve submitted a comment to that post for clarification but it has yet to be approved by a moderator.

The macadmins Slack team discussed, dug in, and and discovered that it can most likely be disabled by adding the entry DisableAnalytics=1 to the mms.cfg file.

To suppress automatic updates and disable analytics, the mms.cfg file should look like:

AutoUpdateDisable=1
SilentAutoUpdateEnable=0
DisableAnalytics=1

Tagged , , ,

Help them help you

I support computers AND users. I’m sure you do, too. My users aren’t expected to know their IP address or how to find it. Occasionally I get in a situation where I can’t pre-fetch a computer name for a user I’m about to call. Once I get the user on the horn I’ll need to have them find that IP and give it to me so I can assist remotely. To make the discovery easier I wrote a quick little Applescript app they can run that outputs the computer’s hostname and current active IP address. It offers to put the name or IP address in their clipboard for easier transfer and avoid typos via IM or email.

Below is the code and output:

Computer Name display

Tagged , ,

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 , ,

Custom location detection using CIDR range

Ask the right questions and you’ll get helpful answers.  Ask some code if an IP exists within the CIDR range and the brief answer can be powerful.

Services like munki, reposado, or other internal offering in your company can be replicated out to other locations but if the client settings never change they’ll continue to use the original settings even if the computer is in a different office across the country. That can be expensive in time and bandwidth — if there is inter-office connectivity at all. Every computer on the network gets an IP, and every IP is in a CIDR range. Why not use that information to help.

You can determine where a computer is based on your documented CIDR ranges and checking if the current IP is in one of those ranges. Systematically processing that information can help with the task of re-configuring based on locale. A simple boolean answer can be parsed to mean anything for your environment. It’s what you do with that answer that makes the difference.

First, you need to know what CIDR ranges are active in your company’s network.  Whoever setup the network should be able to provide that information.  Be sure to double check the translation of CIDR to IP ranges. There is a site that can translate CIDR to the IP range. I had a few instances of CIDRs provided were overlapping and caused unexpected results when certain IPs were used.

Next, figure out what information you want returned.  For my implementation I went the simple route and have the script return a single value that signifies which company office the IP is in.  You can have it return as much as you want and make it as complex as you want.

The following perl code returns true if a supplied IP exists in a supplied CIDR range.

#!/usr/bin/perl
use Net::CIDR::Lite;
use Getopt::Std;

#"i"P address and "c"IDR notated range
getopt ('ic');

my $cidr = Net::CIDR::Lite->new;
$cidr->add($opt_c);
print "true\n" if $cidr->find($opt_i);

The following script iterates thru the known company CIDR ranges with the current computer’s IP address and sends those two pieces of information to the perl script until a match is found. When the IP exists inside a site’s CIDR range it will return the value of the site.

#!/bin/bash
# To use this in other scripts reference it by
#   /Library/Management/Scripts/cidr/cidr-check.sh [ -i ip_address ]
#
#   If no IP is provided by the -i argument the current IP on the computer the script is being run on will be used.
# 
#   Site            Return Value
#
#   Des Moines      DSM    
#   New York        NY
#   Chicago         CHI
###############################################################

#Locations of helper scripts
scriptLocation=/Library/Management/Scripts/cidr/
cidrCheckScript=check_IP_and_CIDR.pl

activeiface=`route get google.com | awk '/interface/ {print $2}'`

#Get the current IP address
#Read in the arguments
usage="Usage: cidr-check.sh [-h] [-i ip_address]"
while getopts i:h flag
do case "$flag" in
	i ) ip="$OPTARG";;
	h ) echo $usage
		exit 1;;
    * ) echo $usage
		exit 1;;
esac
done

#Shift out the switches and arguments, leaving the actual
#variables we're operating against
shift $(($OPTIND - 1))

if [ -z $ip ]
then
    ip=`/sbin/ifconfig $activeiface | /usr/bin/awk '/inet / {print $2}'`
fi

#Flag to mark whether the IP has been found
ipFound=n

###############################################################
#           Lists of CIDR range names                         #
###############################################################
dsmCidrRangeNames=(currentCIDR_DSM1 currentCIDR_DSM2)
dsmCidrRangeNames_Site="DSM"
chiCidrRangeNames=(currentCIDR_CHI)
chiCidrRangeNames_Site="CHI"
nycCidrRangeNames=(currentCIDR_NYC)
nycCidrRangeNames_Site="NY"

##Eastern Time CIDR ranges
    #New York
        currentCIDR_NYC=1.2.0.0/18
##Central Time CIDR ranges
    #Chicago
        currentCIDR_CHI=1.3.224.0/20
    #Des Moines
        currentCIDR_DSM1=1.4.0.0/16
        currentCIDR_DSM2=1.5.0.0/16
###############################################################

if [ "$ipFound" = "n" ]
then
	for cidrRange in ${dsmCidrRangeNames[@]}
	do
		if [ "`${scriptLocation}${cidrCheckScript} -i "$ip" -c ${!cidrRange}`" = "true" ]
		then
			returnValue="${dsmCidrRangeNames_Site}"

			#Mark that we fnd the IP address
			ipFound=y

			#Break out of the for loop
			break
		fi
	done
fi

#CHI
if [ "$ipFound" = "n" ]
then
	for cidrRange in ${chiCidrRangeNames[@]}
	do
		if [ "`${scriptLocation}${cidrCheckScript} -i "$ip" -c ${!cidrRange}`" = "true" ]
		then
			returnValue="${chiCidrRangeNames_Site}"

			#Mark that we fnd the IP address
			ipFound=y

			#Break out of the for loop
			break
		fi
	done
fi

#NYC
if [ "$ipFound" = "n" ]
then
	for cidrRange in ${nycCidrRangeNames[@]}
	do
		if [ "`${scriptLocation}${cidrCheckScript} -i "$ip" -c ${!cidrRange}`" = "true" ]
		then
			returnValue="${nycCidrRangeNames_Site}"

			#Mark that we fnd the IP address
			ipFound=y

			#Break out of the for loop
			break
		fi
	done
fi

if [ "$ipFound" = "n" ]
then
	#We didn't find the IP in a CIDR range
	/bin/echo "IP: $ip not within the specified CIDR ranges." 2>&1
	exit -1
fi

/bin/echo "${returnValue}"

exit 0

With that information I now know what location that computer has an IP from. Those two pieces of code can be re-used as a function in any number of ways. One way we use it is to configure munki to point at the local repo for pkgs, icons, and client_resources during its preflight execution on every run. That way regardless of what office the computer is in it won’t cross the WAN to pull a pkg.

#!/bin/bash
# Script to determine local site and change munki urls to local resources
# Uses 'cidr-check.sh' to determine the site based on IP

#Static variables
munkiConfig=/Library/Preferences/ManagedInstalls
cidrCheckScript=/Library/Management/Scripts/cidr/cidr-check.sh
centralMunkiServer=munki.YOUR.DOMAIN.COM
#################

#Check to see if we're running as root
if [ `id -u` != 0 ]; then
	echo $0: "You must have root privileges to run this command!  Exiting."
	exit 1
fi

#Set the variable "localSite" to the returned value from 'cidr-check.sh'
localSite=`"${cidrCheckScript}"`
echo Local site determined to be "${localSite}"

#Determining the local PackageURL to use
case $localSite in

	DSM )	
			localServer=('munki-dsm.YOUR.DOMAIN.COM')
			;;

	NY )	
			localServer=('munki-nyc.YOUR.DOMAIN.COM')
			;;

	CHI )	
			localServer=('munki-chi.YOUR.DOMAIN.COM')
			;;
	#All other locations should default to the central server
	* )		
			localServer=('munki-dsm.YOUR.DOMAIN.COM')
			;;
esac

echo Local server determined to be "${localServer}"

#If we can't talk to the local munki server, use the central server
if ! ping -o -c 5 "${localServer}" > /dev/null 2>&1
then
	localServer="${centralMunkiServer}"
fi

#Write the local munki URLs
defaults write "${munkiConfig}" PackageURL http://"${localServer}"/repo/pkgs
defaults write "${munkiConfig}" IconURL http://"${localServer}"/repo/icons
defaults write "${munkiConfig}" ClientResourceURL http://"${localServer}"/repo/client_resources

#Write the central munki URL for everything else
defaults write "${munkiConfig}" SoftwareRepoURL http://"${centralMunkiServer}"/repo

#echo Converting ManagedInstalls.plist to XML, the original format of the file
plutil -convert xml1 ${munkiConfig}.plist

I’m sure there are multiple ways to handle this type of problem. I’d love to hear how you handle the complexity of roaming computers and keeping configurations local.

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 , ,