Using autopkg for “general purpose” packaging

A few days ago I made a simple tool for building packages available: munkipkg.

https://github.com/munki/munki-pkg

I got many comments and suggestions for additional features and all sorts of cool additions. Some have even been added to the tool already. But I would like to keep munkipkg a pretty simple, basic tool.

The Luggage (https://github.com/unixorn/luggage) has been around for a while; if munkipkg is too simple for your needs, please have look at that.

I also suggested to several people that if they had more complex needs than munkipkg could handle, it might make more sense to use autopkg, which supports very complex, customizable workflows.

I could tell by the awkward silence that my suggestion was confusing to some — that they had trouble grokking how to use autopkg to build packages “from scratch”, using files and scripts on the local disk.

So I created a GitHub repo demonstrating how to use autopkg in this manner. It’s here: https://github.com/gregneagle/autopkg-packaging-demo

munkipkg comes with three demo package projects. Two of the packages install files, the third is a “payload-free” package that simply runs a script when installed. The autopkg-packaging-demo duplicates these packages, but uses autopkg to build them instead of munkipkg.

(One could also imagine building these packages using either tool: the payload and scripts directories would be the same — in other words, you could have both a build-info.plist for munkipkg and a recipe for autopkg in the same package project directory.)

Assuming you have autopkg installed, you can `git clone` the repo, or download and expand the zip file, and run the autopkg recipes within.

I hope this clears up some confusion, and sparks some new ideas!

Using autopkg for “general purpose” packaging

Introducing munkipkg

https://github.com/munki/munki-pkg

munkipkg is a simple tool for building packages in a consistent, repeatable manner from source files and scripts in a project directory.

Files, scripts, and metadata are stored in a way that is easy to track and manage using a version control system like git.

Another tool that solves a similar problem is Joe Block’s The Luggage (https://github.com/unixorn/luggage). If you are happily using The Luggage, you can probably safely ignore this tool.

Though this tool may eventually be added to the set of tools installed with the Munki command-line tools, it’s not currently tied to Munki and can be run completely standalone.

Learn more here.

Introducing munkipkg

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: https://derflounder.wordpress.com/2012/08/15/creating-payload-free-packages-with-pkgbuild/

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:
http://autopkg.github.io/autopkg
https://github.com/autopkg/autopkg
https://github.com/autopkg/autopkg/releases

AutoPkg recipe repos:
http://github.com/autopkg

JSSImporter:
https://github.com/arubdesu/jss-autopkg-addon

AbsoluteManage Processor:
https://github.com/tburgin/autopkg/blob/master/Code/autopkglib/AbsoluteManageExport.py

AutoPkg Change Notifications script:
http://seankaiser.com/blog/2013/12/16/autopkg-change-notifications/

MacSysAdmin 2013 session:
http://docs.macsysadmin.se/2013/video/Day2Session4.mp4

Steve Yuroff’s AutoPkg and Jenkins notes:
http://swytechnotes.wordpress.com/2013/10/21/autopkg-and-jenkins-under-one-admin-account/

AutoPkg Wiki:
https://github.com/autopkg/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 1.7.11.22.

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:

https://dl.dropbox.com/u/8119814/DisableXProtectUpdater.pkg.zip

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

#!/bin/sh

# don't check JavaWebComponentVersionMinimum
XPROTECT_META_PLIST="$3/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist"
/usr/libexec/PlistBuddy -c "Delete :JavaWebComponentVersionMinimum" "$XPROTECT_META_PLIST"

# disable the xprotectupdater job
LAUNCHD_JOB_PLIST="$3/System/Library/LaunchDaemons/com.apple.xprotectupdater.plist"
/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/com.apple.xprotectupdater.plist

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 :PlugInBlacklist:10:com.oracle.java.JavaAppletPlugin:MinimumPlugInBundleVersion 1.7.10.19" "$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¬†1.7.13.20.

(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