Building Installer packages for software distribution
by Greg Neagle,
Packing things up
Previously in MacTech, we looked at modifying Firefox in order to implement custom default preferences. This involved modifying several files inside the application bundle. If you made similar modifications for your environment, you'd then be faced with the next task: distributing the modified application to all your managed machines.
There are many ways to distribute software to Mac OS X machines, but most commercial products - Apple's and third-parties' - rely on Apple Installer packages to install and update software. This can be a convenient approach when the software you want to distribute is already packaged in that format, but you'll find there are several situations in which you need to create your own Installer packages:
1. The software is not distributed in Apple package format by the vendor, and your software distribution mechanism does not support the alternate format.
2. The vendor uses the Apple package format but the package will not install without user input - or, stated a different way, the package cannot be installed "silently".
3. You need to make changes in the files that are distributed, or distribute additional files.
4. You have internally-developed software that must be distributed. If you're lucky, your internal developer will package it for you. If you're not lucky, or you are the developer, then you need to do it.
Therefore, packaging software for distribution is a common task for OS X administrators. Fortunately, there are a lot of available tools to help you with this task.
A partial and by no means complete list of packaging and related tools for OS X in no particular order:
This is Apple's utility for creating packages. It is available as part of the Xcode Tools, and also included with the Server Admin Tools. It can create every package format supported by Apple: old-style bundle packages, new-style flat packages, metapackages, distribution packages, and hybrid packages that work on multiple OS versions. The link above is for the 10.5.5 release of the Server Admin Tools; there may well be a newer release by the time this article reaches print.
Pros: PackageMaker is a supported Apple tool and is free. Many of the other tools rely on PackageMaker for at least some of their functionality.
Cons: It's hard to use, and had a history of buggy releases.
Iceberg is freeware by Stéphan Sudre, licensed with a BSD-style license. Capable and well-documented, Iceberg is very popular among Mac OS X administrators. It can create packages and metapackages, but not the newer distribution packages and flat packages.
Pros: Easy to use and free. It supports creation of packages from filesystem snapshots, as well as manual assembly of package contents.
Cons: Iceberg's installer installs a StartupItem that launches an always-on background task. This makes some admins uncomfortable.
LANrev, the maker of a cross-platform system management tool, recently made their InstallEase package creation utility freely available.
Pros: Ease of use, the ability to export Iceberg project files, and the creation of "uninstall" packages - packages that will uninstall software installed by another package. Creation of packages from filesystem snapshots.
Cons: It does not work standalone. To actually create packages, you must have Apple's PackageMaker and/or Iceberg installed as well.
Casper Composer SE
Composer is a $100 utility from JAMF Software. Part of the Casper Suite of OS X client management tools, Composer is also available separately. Casper Composer creates packages based on filesystem snapshots. When used with the Casper suite, it can create installation packages with extra abilities such as installing default preferences into users' home directories.
Pros: Easy to use. Good documentation.
Cons: It's not free. Casper Composer requires Apple's PackageMaker to build standard Apple packages. Composer's special package features work only with other tools in the Casper Suite.
logGen is freeware from the University of Michigan, by Phil Holland and Dave Pugh. It is a command-line utility for finding filesystem changes. You could use it as part of a package creation workflow together with pkgGen (described below) and PackageMaker.
This is a script by Zack Smith that parses the output of logGen and creates a "fauxroot" directory containing all the files and directories found by logGen. This fauxroot directory can then be used by PackageMaker or Iceberg to create an Installer package. The workflow would look something like:
- Run logGen to create a "before" snapshot.
- Install and configure software.
- Run logGen to create an "after" snapshot and differences list.
- Edit the differences list to remove unwanted items.
- Run pkgGen with the edited difference list to create a fauxroot directory with copies of all needed files and directories.
- Run PackageMaker and use the fauxroot directory to create your package.
Example Packaging Workflow
Let's use one of the tools to build an installation package for our modified Firefox. I'll use LANrev InstallEase for this example.
We'll start by assuming you already have an appropriately modified version of Firefox on your system, and have downloaded and activated a copy of InstallEase from LANrev's website.
Click Start to begin. You may optionally check No longer show this screen to skip the introduction in the future.
Since the Firefox application is self-contained within its own application bundle, we can save a bunch of time and create the package manually. You can do this any time you already know which files and folders you need. Select Manually and click Continue.
Ignore the confusing messages about snapshots; by choosing to create a package manually, you skipped the snapshot process. You are now looking at an empty package. Add the Firefox application to the package by simply dragging it in from the Finder:
After dropping Firefox into InstallEase's window, it should look like this:
You can examine the contents of the Firefox app bundle if you'd like, and make changes to the owner, group, and permissions of all the included files and folders if you wish. When you are satisfied, click Continue.
You have several options, and they are not exclusive - you can select as many as you want.
- Apple Installer (.pkg): This is the default. You'll need Apple's PackageMaker utility installed to use this.
- Uninstaller package for Apple Installer (.pkg): this is an interesting feature of InstallEase. It uses the installation package information to create a special package that contains a post-install script that removes the files and folders defined in the package. You can then use any software distribution system that relies on Apple's Installer (or command-line installer tool) to remove software as well.
- Iceberg project (.packproj): Creates a project file for use with Iceberg. This allows you to use Iceberg to edit package options before creating the actual package.
- Disk image with added files and folders (.dmg): this is mostly useful for use with LANrev's other tools - it creates a disk image that simply contains all the files and folders you've added to the package.
For this sample workflow, all we need and want is a standard Apple Installer package, so click Create.... You'll be asked where to save the package and for a filename. In most cases, you'll be asked to authenticate as an administrator. After a few moments, you should see something like this:
You are done with this simple example and now have a package that will install your custom version of Firefox.
Note that you had no chance to specify any package options, like whether or not the package requires a restart or if the package can be installed only on the startup disk. If you need to specify additional options, you are probably better off saving an Iceberg project and finishing your editing in Iceberg before creating the final package.
Let's do a slightly more complicated example, this time using filesystem snapshots. Again we'll use InstallEase, but the process is similar in Iceberg and Casper Composer.
Launch InstallEase and select Automatically as the package creation method.
Choose the source for the snapshot. In almost every case it will be the startup disk. In this example, the startup disk is named "Leopard". InstallEase by default ignores a lot of items on the disk when making snapshots to reduce the number of false positives. You can view and edit the list of excluded items by clicking the Adjust File Filter... button.
For this example, we'll leave everything at the default settings. Click OK to dismiss the exclusion editor, and click Take Snapshot to start the "before" snapshot.
You'll wait several minutes as InstallEase scans the disk and records information about exisiting filesystem items. Note that it was scanning my FileVault-protected home directory at the moment I took the screenshot. More on that in a bit. When it's done scanning the disk, you'll see this:
Now it's time to install your software. For this example, we'll install TextWrangler 2.3. Normally this is a drag-and-drop install, and so would need to be repackaged to be able to be pushed out with ARD or most other installation methods.
Download the TextWrangler 2.3 disk image from Bare Bones' website and open the disk image. Install the app by dragging it to the Applications folder, authenticating as an admin when requested.
If you were to package TextWrangler now, you'd have a working application, but you'd be missing the command line tools that come with the application. Worse, when your users launched TextWrangler for the first time, they'd be asked for an admin password in order to install the command line tools. To prevent that, we'll do it in advance and add it to the installation package. Launch /Applications/, and you should see this:
Authenticate as an administrator, then quit TextWrangler. Now we can return to InstallEase and click Take Snapshot. After InstallEase scans the disk for changes, you should see something like this:
I've turned down most of the disclosure triangles so you can see what InstallEase has found. Note that it found not only the main TextWrangler application in the Applications folder, but found the command line tool (/usr/bin/edit) and its man page. Without a snapshot utility, it might have been difficult to determine what items were actually installed when the command line tools were added.
We'll want to make a few changes before proceeding. First, InstallEase found changes in my home directory. Unfortunately, since I have a FileVault protected home directory, all it found was a changed "gneagle.sparseimage", so I don't know exactly what changed, but I'm fairly certain I don't care, so I'm going to remove /Users and everything below it.
You may be tempted to edit the exclusion list to always exclude /Users. Resist that temptation. Some software installs items in /Users/Shared which you'll want to capture. Also, it might be useful to see what files are created in a user's home directory on the first launch of an application. (In which case, using an account with a FileVault-protected home directory to install that software is probably a bad idea.) You probably won't want to include user files in an installation package, but you may need to manage them some other way or at least be aware of them.
There's another change to make before we build the package. Note that the TextWrangler application is owned by gneagle. That won't prevent TextWrangler for working on other systems, but it really would be better if we set the ownership to root or a local admin account to match other installed applications.
Here are the changes completed: the /Users folder and its contents have been removed, and the ownership of TextWrangler has been changed to root. Note that TextWrangler is actually an application bundle, so you actually have to expand the contents and change the ownership of every included item individually, which quickly gets tedious. Unfortunately, there seems to be no easy way to propagate changes recursively. We can now click Continue and choose our package formats and create the package just like in the first example.
Packing it in
No matter what tool you use, the basic concepts behind creating installation packages for OS X are the same. Different tools have different options and abilities - you may need to experiment with a few to find the ones that meet your needs.
Greg Neagle is a member of the steering committee of the Mac OS X Enterprise Project (email@example.com.) and is a senior systems engineer at a large animation studio. Greg has been working with the Mac since 1984, and with OS X since its release. He can be reached at