Pseudo-“Payload-free” pkgs with pkgbuild

“Payload-free” packages — that is, Apple installer packages that do not have a file payload, but only run scripts, are a nice tool for OS X admins to have. They provide a convenient way to deliver and execute scripts as root. If you have a way to install packages on your managed machines, you can also run scripts as root by wrapping them in a “payload-free” package.

Rich Trouton has written up the basic procedure using the built-in `pkgbuild` tool:

But payload-free packages built this way have a “feature” that can sometimes prove problematic. Flat packages built with pkgbuild using the --nopayload option do not leave receipts in the pkgutil database. This means it can be difficult to determine if a given payload-free package has already been installed on a given machine.

This is especially annoying with Munki: by default, when installing a package, Munki uses the package’s receipt(s) to determine whether or not the package has been installed. Without that receipt, and with no other information, Munki can’t tell if the package has been installed.

Fortunately, it’s trivial to make a pseudo-payload-free package that leaves a receipt. All we need to do is specify an empty payload!

Here’s how we make a “true” payload-free package (that does not leave a receipt):

pkgbuild --nopayload --scripts /path/to/scripts_dir --identifier org.example.payloadfree --version 1.0 MyGreatPayloadFree.pkg

and here’s a “pseudo” payload-free package that does leave a receipt:

mkdir empty
pkgbuild --root empty --scripts /path/to/scripts_dir --identifier org.example.payloadfree --version 1.0 MyGreatPayloadFree.pkg

That’s it! Instead of using the --nopayload option, we create an empty directory and point the --root option at it. The package is built with the empty payload, and when installed, the package leaves a receipt.

Pseudo-“Payload-free” pkgs with pkgbuild

You Oughta Check Out AutoPkg: Links

If you attended my presentation on AutoPkg today, thanks! Here are the links:


AutoPkg recipe repos:


AbsoluteManage Processor:

AutoPkg Change Notifications script:

MacSysAdmin 2013 session:

Steve Yuroff’s AutoPkg and Jenkins notes:

AutoPkg Wiki:

You Oughta Check Out AutoPkg: Links

10.8.3 supported platforms

A follow-up to yesterday’s post on 10.8.3.

I had hoped that the “SupportedModelProperties” list in the InstallESD.dmg’s /System/Library/CoreServices/PlatformSupport.plist would serve as a more-or-less human parseable list of supported models.

But it appears that there are some supported models that do not appear in the “SupportedModelProperties” list, but whose board-ids do appear in the “SupportedBoardIds” list in that same file.

In any case, the _real_ thing that causes the the installer to decide whether or not to proceed is this function in the OSInstall.mpkg’s Distribution file:

function isSupportedPlatform(){

	if( isVirtualMachine() ){
		return true;
	var platformSupportValues=["Mac-F42D88C8","Mac-F2218EA9","Mac-F42D86A9","Mac-F22C8AC8","Mac-F22586C8","Mac-AFD8A9D944EA4843","Mac-F227BEC8","Mac-F226BEC8","Mac-7DF2A3B5E5D671ED","Mac-942B59F58194171B","Mac-2E6FAB96566FE58C","Mac-F42D89C8","Mac-00BE6ED71E35EB86","Mac-4B7AC7E43945597E","Mac-F22C89C8","Mac-942459F5819B171B","Mac-F42388C8","Mac-F223BEC8","Mac-F4238CC8","Mac-F222BEC8","Mac-4BC72D62AD45599E","Mac-F2268DC8","Mac-F2208EC8","Mac-66F35F19FE2A0D05","Mac-F4238BC8","Mac-F221BEC8","Mac-C08A6BB70A942AC2","Mac-8ED6AF5B48C039E1","Mac-F2238AC8","Mac-FC02E91DDD3FA6A4","Mac-6F01561E16C75D06","Mac-742912EFDBEE19B3","Mac-F22589C8","Mac-F22587A1","Mac-F22788AA","Mac-F42C86C8","Mac-942C5DF58193131B","Mac-F2238BAE","Mac-F22C86C8","Mac-F2268CC8","Mac-F2218FC8","Mac-7BA5B2794B2CDB12","Mac-F65AE981FFA204ED","Mac-031AEE4D24BFF0B1","Mac-F22587C8","Mac-F42D89A9","Mac-F2268AC8","Mac-F42C89C8","Mac-942452F5819B1C1B","Mac-F2218FA9","Mac-F221DCC8","Mac-94245B3640C91C81","Mac-F42D86C8","Mac-F2268EC8","Mac-F2268DAE","Mac-F42C88C8","Mac-94245A3940C91C80","Mac-F42386C8","Mac-C3EC7CD22292981F","Mac-942B5BF58194151B","Mac-F2218EC8"];
	var boardID = system.ioregistry.fromPath('IOService:/')['board-id'];
	if( !boardID || platformSupportValues.length == 0 ) {
		return false
	for( var i = 0; i < platformSupportValues.length; i++ ){
	 	if( boardID == platformSupportValues[i] ){
				return true;

	return false;

Unfortunately, I have not found a reliable resource for mapping board-ids to models.

10.8.3 supported platforms

Disabled Java Plugins, XProtect Updater

JavaToday Apple updated the XProtect.meta.plist file, which, among other things, causes XProtect to disable Java Plugins that don’t meet a minimum version.

The net effect was to disable the Java 6 plugin on all browsers, as well as Java 7 plugins older than

If you need to continue to use the Java 6 plugin in your organization, you can revert the changes and disable the mechanism that updates the XProtect.meta.plist by installing this package:

This is a payload-free package that runs this script as a postflight:


# don't check JavaWebComponentVersionMinimum
/usr/libexec/PlistBuddy -c "Delete :JavaWebComponentVersionMinimum" "$XPROTECT_META_PLIST"

# disable the xprotectupdater job
/bin/launchctl unload -w "$LAUNCHD_JOB_PLIST"

I won’t tell you this is a smart thing to install; there are many reasons to leave things as they are. Apple disabled these plugins to protect from known exploits. By re-enabling them, you are opening up your managed machines to these exploits.

But if your org needs the Java 6 Web Plugin, this should get you running again. You should re-enable the XProtect updater as soon as you are able, though:

sudo /bin/launchctl load -w /System/Library/LaunchDaemons/

NOTE: if you need to re-enable an older version of the Oracle Java 1.7 Plugin, you’ll need to edit the postflight script and add something like:

/usr/libexec/PlistBuddy -c "Set" "$XPROTECT_META_PLIST"

(Sadly, WordPress changes a colon followed by a P into a emoticon, even in pre-formatted text. Not helping…)

This sets the MinimumPlugInBundleVersion for the Oracle Java Web Plugin back to the value it was with the 10 Jan 2013 version of the XProtect.meta.plist. Again, if you do this, you are choosing to expose your machines to a known Java Web Plugin exploit. Do so at your own risk.

(Update 01 Feb 21013)
If you need to run the Oracle Java 1.7 Plugin (or are already running it and it’s been disabled) the best fix is to update the Java install. As of this writing, Java 7 Release 13 for OS X is available here. This installs a web plugin with BundleVersion¬†

(Update 02 Feb 2103)
Apple has released a Java 6 update for Snow Leopard. Installing this update will restore Java 6 web plugin functionality under Mac OS 10.6. This won’t help if you need to use the Java 6 web plugin under OS X 10.7 or later.

Disabled Java Plugins, XProtect Updater

Fix for Adobe CS6 activation issue

Adobe has posted some information and a fix for the recent issue with Adobe Photoshop CS6 registration/activations:

This issue appears to have been triggered by the Photoshop CS6 13.0.2 and/or 13.0.3 updates. The official recommendation on a fix is to update Photoshop CS6 to 13.0.4, then use the APTEE tool to remove and reapply serialization. See the above post for more details.

The APTEE tool is not exactly easy to use to deploy this fix in an enterprise environment; you need to install it on all your machines and also run a script (which you must write, test, and debug) on all your machines to perform the unserialization/reserialization.

Later today I will post a tool to help you create a standard Apple package to perform these steps. If you have some way to distribute and install Apple packages on your machines, you’ll be able to do the unserialization/reserialization by installing a package.

Check back later!

Fix for Adobe CS6 activation issue