FileWave has introduced a free new tool for creating compiled OS X images: Lightning.
Though they position it as a tool to help with Thunderbolt/Firewire imaging, it actually is a more general purpose tool. My initial impression is that if you are building compiled Lion or Mountain Lion images, this tool could replace the use of InstaDMG or System Image Utility for many people.
Allen Golbig has an article on AFP548 on creating a package that will create or update a Recovery partition on a Lion or Mountain Lion volume.
The solution requires you get a few pieces from Apple:
Additionally, Allen’s solution requires the use of Joe Block’s The Luggage, which in turn requires Xcode (or at least the Xcode command line tools) and PackageMaker.
Since getting all of that running might be a nasty hurdle to jump for some, I’ve put together a package template you can use. It’s available here.
To use it, you’ll still need to obtain the dmtest tool from the Lion Recovery Update package and the BaseSystem.dmg and BaseSystem.chunklist from an InstallESD.dmg.
pkgutil --expand RecoveryHDUpdate.pkg ./RecoveryUpdate
cd ./RecoveryUpdate/RecoveryHDUpdate.pkg/Scripts/Tools/
cp dmtest /path/to/CreateRecoveryPartition.pkg/Contents/Resources/
hdiutil attach /path/to/InstallESD.dmg -noverify
cp /Volumes/Mac\ OS\ X\ Install\ ESD/BaseSystem.* /path/to/CreateRecoveryPartition.pkg/Contents/Resources/
hdiutil eject /Volumes/Mac\ OS\ X\ Install\ESD/
When you are done, CreateRecoveryPartition.pkg/Contents/Resources/ should contain:
BaseSystem.chunklist
BaseSystem.dmg
dmtest
en.lproj/
package_version
postflight
You’re done unless you’d like to edit the package identifier and/or version in CreateRecoveryPartition.pkg/Contents/Info.plist.
You can now use this package to install a Recovery partition (or update an existing partition).
Now that you can create an Installer package to install Lion or Mountain Lion, you have the possibility of using this package instead of an “image” to initially setup/configure a machine.
This may not be initially obvious.
If you’ve used InstaDMG or Apple’s System Image Utility to build a deployment image, you might notice that the components you use are very similar to the components you use to create a Lion or Mountain Lion installer package. Those components are:
The difference is that InstaDMG “compiles” those components into a disk image that you “restore” to a target volume. System Image Utility can do that as well, or it can create a NetInstall workflow that just installs the components in order.
An advantage of the “compiled” disk image approach is speed. It’s much faster to restore a disk image to a target volume than it is to install the components seperately.
But there are advantages to the “install the components” approach as well:
It’s possible to use DeployStudio to install Lion or Mountain Lion on a target volume using a package created by createOSXinstallPkg. You can upgrade an existing volume, or erase and install to an empty disk. Rich Trouton has documented these options:
http://derflounder.wordpress.com/2011/09/08/upgrading-to-lion-with-deploystudio/
Last fall, I released a set of tools I called “InstallLion.pkg”. The introductory post is here.
Now that Mountain Lion has been released, you may be wondering: “Can I use these tools to create a deployment package for Mountain Lion?” The answer is yes. InstallLion.pkg can be used to make an installer package for Mountain Lion.
But I have a better set of tools for you. Today I’m introducing createOSXinstallPkg. This tool can be used to create installer packages for Lion and Mountain Lion and features many improvements over the “InstallLion.pkg” tools.
The first improvement: it’s much easier to use createOSXinstallPkg to create installer packages. With the old tools, you had to run one or two scripts — one to download an “IncompatibleAppList” package, and one to customize the InstallESD.dmg if you wanted to install additional packages along with the OS X install. And then you had to manually assemble the package, copying several components into the right places within a template package.
With createOSXinstallPkg, it’s as easy as:
sudo ./createOSXinstallPkg --source /Applications/Install\ OS\ X\ Mountain\ Lion.app
to create a basic uncustomized package that installs Mountain Lion.
But wait! There’s more!
UPDATE 18 July 2012:
Apple has re-added the iPhoto 9.1 and 9.2.3 updates to Software Update. This should fix the issue described below.
Recently on several mailing lists and on the #osx-server IRC channel on Freenode, people have been reporting issues with iPhoto 9.0, installed from the Apple iLife ’11 DVD or an disk image of the DVD, not showing any available updates from Apple Software Update.
Several of us looked at this issue yesterday on the Freenode #osx-server IRC channel and have concluded it is an Apple bug.
It appears that the only update for iPhoto 9 currently offered in Apple Software Update is the iPhoto 9.3 update.
There are two problems with this.
Workarounds:
For 10.7.4 machines, install the standalone iPhoto 9.1 update available from http://support.apple.com/downloads. The 9.3 update will become available. (Of course you could just use the standalone updates to update all the way to iPhoto 9.3.)
For machines running OS X versions earlier than 10.7.4, you’ll need to use the standalone updates available from http://support.apple.com/downloads to first update to iPhoto 9.1, then to iPhoto 9.2.3.
Links:
http://support.apple.com/downloads/#iphoto
http://support.apple.com/downloads/DL1322/en_US/iPhoto9.1Update.dmg
http://support.apple.com/downloads/DL1514/en_US/iPhoto9.2.3Update.dmg
http://support.apple.com/downloads/DL1545/en_US/iPhoto9.3Update.dmg
Starting with Xcode 3.2 on Snow Leopard, and installed by default on Mac OS X Lion are two new-ish packaging tools:
/usr/bin/pkgbuild
/usr/bin/productbuild
These tools are ideal for use in scripted package building, and can replace much of the use of the packagemaker binary inside Apple’s PackageMaker application.
pkgbuild can be used to create simple flat packages. productbuild can create more complex distribution packages, which may contain one or more flat packaged generated using pkgbuild.
Check out the man pages for pkgbuild and productbuild for more info.
pkgbuild is very easy to use, compared to packagemaker. There are two chief limitations that I found in attempting to use it as a replacement for packagemaker:
pkgbuild creates only flat packages. These are supported only on 10.5 Leopard and newer.The first is not really a problem if you don’t have to manage any pre-Leopard machines.
The second can be worked around by using productbuild — the Distribution file can specify the need to restart. That’s the officially supported solution, but is a bit of a pain.
It turns out that pkgbuild has an undocumented --info option. This allows you to specify a PackageInfo template that can be used to specify some additional info that can’t be specified through other pkgbuild flags.
If I create /tmp/PackageInfo with these contents:
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<pkg-info postinstall-action="restart"/>
Then do this:
pkgbuild --info /tmp/PackageInfo --component /Applications/Firefox.app /tmp/Firefox.pkg
I get a package for Firefox that requires a restart.
See http://s.sudre.free.fr/Stuff/Ivanhoe/FLAT.html for more info on flat package PackageInfo files, which are not the same as bundle package Info.plist files.
There is some concern that this relies on an undocumented option, which Apple could change or take away at any time — but they could do that with documented options as well…
The May 2012 issue of MacTech is available via the iPad app; dead-tree mailings can’t be far behind.
In this month’s issue I detail a method for creating packages to create a local admin account on your managed machines. This same package will create a working local admin account on Leopard through Lion (and possibly beyond), and will work in the stripped-down Lion install environment. If you need to update the local admin password, you can just install a newer version of the exact same package.
This fits in with my general theme for 2012: which is “Don’t Repeat Yourself!”
AFP548.com introduced a new look today. Lots of new, great articles on the site, including one by yours truly:
http://afp548.com/2012/06/05/skinning-a-cat-lots-of-ways-to-deploy-lion/
A new release candidate of the Munki tools is available here:
http://munki.googlecode.com/files/munkitools-0.8.2.1475.0.mpkg.dmg
In my previous post, I provided a tool to enable you to check your collection(s) of packages to determine if any are affected by the Package Apocalypse.
But what to do once you’ve found packages with expired signatures? If Apple has provided an updated replacement package at http://support.apple.com/downloads/, it’s probably best to replace the package with the expired signature with the updated one.
But that might not always be possible — Apple has not provided replacements for every package that has been affected, or the replacement might not be practical to use.
Continue reading “Fixing packages with expired signatures”
Managing OS X 