Volume Number: 25
Issue Number: 03
Column Tag: MacEnterprise

MacEnterprise: Packaging for System Administrators

Building Installer packages for software distribution

by Greg Neagle, MacEnterprise.org

In an earlier MacTech article, we discussed reasons Mac OS X systems administrators might need to package or repackage software for deployment in their organization. Some common reasons are:

Repackaging into a format compatible with your distribution mechanism

Repackaging software that won't install "silently" (i.e., prompts the user for info, or launches GUI applications)

Capturing organization-specific changes (licensing, configuration) into a package

Packaging third-party software that is distributed without an Installer package

Packaging internally-developed software or tools

We mentioned several packaging tools, and detailed two repackaging examples using LANrev's InstallEase. The first example was using drag-and-drop to build a installer package for Firefox. The second example used filesystem snapshots to build a package for TextWrangler and its command-line tools.

LANrev's InstallEase is a very easy to use packaging utility, as you might have seen from the earlier article. But it actually relies on other packaging tools to do the "heavy lifting." In order to actually create the final package, you must have either Apple's PackageMaker, or Stéphan Sudre's Iceberg installed. In the case of PackageMaker, InstallEase uses it behind the scenes, and so you never have to directly use PackageMaker if you do not want to. With Iceberg, you save an Iceberg project from InstallEase, and then open that project file with Iceberg to finish building the package.

Why move beyond InstallEase? With InstallEase, you have very little control over things like the package bundle ID (which you might want to use to identify your company), or settings like requiring a restart after install. There's no way to specify a custom read me, license agreement or other user interface settings. For automated installs, none of these features may matter, but for a package you intend to have end-users manually install, you may want more control.

To gain that additional control, we'll look at PacakgeMaker, Apple's packaging utility. PackageMaker is available with Apple's Xcode developer tools, and also as part of the Server Administration Software. New in version 3 is the ability to find files to add to a package via "snapshot", or watching for file system changes. Let's quickly revisit our example of building a package for TextWrangler, this time using PackageMaker, and then look at some of PackageMaker's additional options.

If you haven't already, install PackageMaker by installing either Xcode 3 or the latest release of the Server Administration Tools from Apple. At the time of this writing, the URL for the Server Tools was:

http://www.apple.com/support/downloads/serveradmintools1055.html

Don't run the installer - PackageMaker is available in the Utilities folder on the disk image, ready to be dragged to your hard drive.

In order to play along at home with the example, also download the disk image for TextWrangler from:

http://www.barebones.com/products/textwrangler/download.html

and mount the image.

Open PackageMaker. You'll see an untitled project window, and a sheet asking for some basic info. Enter your organization identifier and choose a minimum OS target, as in Figure 1.

Figure 1. Specifying install properties

We're going to use filesystem snapshots to build this package, so choose Add Snapshot Package... from the Project menu.

Figure 2. Adding a Snapshot Package

You'll have one last chance to get ready - if you haven't downloaded TextWrangler, do it now.

Figure 3. Starting the snapshot

Click Start to begin. Install TextWrangler from the disk image by dragging it to the Applications folder. To install the command-line tools, launch TextWrangler and agree when it asks if you want the current versions of edit and twdiff, authenticating as an administrator when asked. This, of course, is the reason we're building this package: we can then use our software distribution tool to install the TextWrangler application and its command-line tools without having to bother the user with the requests to install the command-line tools.

Once you are done with the install tasks, return to PackageMaker and click Stop.

Figures 4-5. Stopping the snapshot

Click Next to proceed.

Figure 6. Filtering snapshot items

You'll see a tree view of files and directories that were modified between the time you clicked Start and the time you clicked Stop. InstallEase has a configurable filter to ignore certain directories and files; PackageMaker does not, so you'll have a larger number of unwanted files and directories to wade through and uncheck. In the example shown in Figure 6, you'd want to uncheck /Applications/.DS_Store, and the entire tree under /Library, as these are not part of the actual install. The snapshot also captured several log files in /private/var/log, other items in my home directory, and more. You'll need to examine the list of captured items carefully and remove those that are not relevant to the installation. Give the snapshot a title and click Save.

Figure 7. Package configuration

We can now start to customize the package. In the example shown in Figure 7, I've given it a title, and added a description.

Under Install Destination, you'll see three choices. In most cases, Volume selected by user is the best choice, especially if you will be using this package to install software on a non-booted volume, like when using the InstaDMG method of creating installation images. If you want non-admin users to be able to install the software, and it does not require anything to be installed in the System domain, you can check User home directory. This would be an unusual choice in most managed enterprise environments, though.

You can see the contents we captured with the snapshot in the left column under Contents. Turn the disclosure triangle down to see detail on the contents. See Figure 8 for an example.

Figure 8. Configuring the snapshot package

We can further customize the install under the Configuration tab for the snapshot contents. We can give the package an identifier and version, specify a restart action, and indicate if admin authentication is needed. This particular install does not need a restart, but you could choose to require a logout, recommend a restart, require a restart, or require a shutdown. (The only type of installation I can think of that would require a shutdown would be a firmware update that requires the user to hold down the power button on the subsequent startup.) Since this package installs items in /Applications, /usr/bin, and /usr/share/man, it will need admin authentication. Very few installation packages will not need admin authentication unless they install items in the user's home folder or in /Users/Shared, as these areas are modifiable by standard users.

Let's proceed to the Contents tab.

Figure 9. Editing the contents

In Figure 9, we can see all the items that will be installed. I've turned down several of the disclosure triangles so we can see more of the items. There are some changes that should be made. You'll see that the TextWrangler application is owned by gneagle. If we're going to install this on multiple machines, we'll want to change the ownership to root. We had to do the same thing when packaging with InstallEase, going through each file one-by-one and changing the ownership and permissions. PackageMaker has what might look like a handy shortcut: the Apply Recommendations button. If you were to click it, PackageMaker will go through all the items in your project, applying its recommended permissions and ownership. In my experience, the ownership and permissions it applies end up causing warnings later in the build process. It seems to just blindly set owner to root, group to admin, and permissions to 775 or 664. These are generally fine for things in /Applications, but cause warnings elsewhere in the filesystem - like in /usr/bin. So, sadly, you are probably better off fixing ownership and permissions manually.

If you discover you've accidentally included a file or directory you don't want installed, you can remove it from the contents by unchecking it in the contents list.

Next, we move to the Components tab.

Figure 10. Editing Component options

As shown in Figure 10, PackageMaker has identified the TextWrangler.app application bundle as a "component", and marked it as relocatable. This means that if after installation, a user with admin privileges moves the component somewhere else, that for future reinstalls or upgrades, Installer will search the disk for the component.

In most cases, for managed installs in an enterprise environment, I'd recommend that you disable this option. You as the OS X administrator know where you are going to install it and probably don't intend to move it around. Additionally, it slows down the install process as it scans the drive for the application, and there are some definite non-intuitive behaviors with this option in some configurations. It seems safest to turn this off unless you understand the implications and need the behavior.

The second checkbox, labeled Allow Downgrade, controls whether or not the Installer allows the user to install an older version of this component over a newer version. Most of the time, you would not want this, but if you are creating a package to downgrade an application because the newer version has problems in your environment, this might be a useful option.

We could also specify pre-installation and post-installation scripts to run at this point, but we don't need them for this project, so we'll leave the Scripts tab alone.

Let's look at an (optional) final task before building our package.

PackageMaker contains an interface editor to customize what the user sees when installing your package. If you are building packages that are to be installed silently in the background, you can safely ignore the user interface altogether. But if you are building packages you intend to be installed manually, you might want to customize the user interface.

Start by clicking the Edit Interface icon on the right side of the PackageMaker project window toolbar.

Figure 11. PackageMaker's Interface Editor

The Interface Editor will open, and will look like Figure 11. Here you can customize the background image and the Introduction, Read Me, License, and Finish Up messages, including adding localizations for languages other than English. Feel free to play with the various options. Once you are happy with your edits, close the editor and save the project.

Now for the moment you've all been waiting for: building the actual package. If you haven't done so already, save the project. Click the Build icon in the project window toolbar. Give the package a name, choose a location, and click Save. You should see a progress indicator for a minute or less, and then something like Figure 12.

Figure 12. Build results

Though my build succeeded, there's one warning. I've turned down the disclosure triangle to read the warning, and I can click on the magnifying glass to be taken to where I can fix it.

Figure 13. "Spotlight"-style focus on the problem

In Figure 13, you can see that PackageMaker highlights the relevant control ala Spotlight in System Preferences. In this case, I needed to enter the destination - "/". Build again, and the warning should be gone.

If you wish, you can now open the built package in Installer and test it.

This was a fairly typical example of building a simple Installer package. We took some third-party software that is distributed in a non-Apple Installer package format and did some post-install configuration tasks. We then used Apple's PackageMaker to capture the installed and modified files and build an Installer package. This example only scratches the surface of the many capabilities of PackageMaker. PackageMaker can build metapackages, new Leopard-style flat packages, and more. You can specify install requirements (like minimum available disk space, CPU type and speed), and optional installs, like user guides.

Though PackageMaker is a full-featured, powerful packaging tool, it also has some non-trivial issues. A key issue, in my experience and in the experience of other OS X systems administrators, is that PackageMaker has a hard time creating packages that have a large number of items. Many admins have seen PackageMaker crash or become unresponsive when trying to repackage Microsoft Office or the Adobe Creative Suite applications. This problem also occurs with the command-line version of PackageMaker, so other tools that build on or rely on PackageMaker will almost certainly have the same issue.

Workarounds for this issue include breaking the install into smaller packages that are then part of a metapackage, or using another tool like Iceberg. An attempted repackaging of Microsoft Office 2008 that failed for me using PackageMaker, both via the GUI and the command line, was successful using Iceberg.

A OS X administrator may need a variety of packaging tools at his or her disposal, since they all have their strengths and weaknesses. The good news is that you can get your feet wet with simpler tools, and as you need more capabilities, use heavier-duty (and more complicated) tools.

Greg Neagle is a member of the steering committee of the Mac OS X Enterprise Project (macenterprise.org) 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 gregneagle@mac.com.