Volume Number: 24 (2008)
Issue Number: 06
Column Tag: Mac in the Shell

Mac in the Shell: Packaging and Installing

Simplify and scale your install methodology

by Edward Marczak

While many systems contain a package manager, OS X's is unique, for better or worse. More and more people are now getting familiar with the graphical PackageMaker.app (and if you're not, see Jose Cruz's article in this issue). However, the GUI utility is only half the issue. Once an application is packaged, it needs to be deployed, sometimes at grand scale. Also, it's important to be able to automate updates to a package over time so new installs user the newer versions. This article talks about the command-line version of PackageMaker.app, packagemaker, and command-line installer – two tools to help get software to the masses easily and automatically.

Packaging refers to placing files into a package format (which acts like a single file) that is used to install said files (the payload) on a target system. The graphical Packager Maker.app that ships with 10.5 developer tools is vastly improved over earlier versions. All of those improvements are brought to the command line build version. This includes the wonderful snapshot package, too.

For the sake of simplicity, let's imagine that the payload that you wish to install is contained entirely in a single directory. This can be a directory full of files, or a single application (which is, in reality, a folder full of files). We'll use the former in this example: a single directory containing some utility programs for our command line pleasure. This will need to be installed on all systems in our organization. packagemaker makes this a snap to package up. The simplest way to package this directory is to do the following:

Create an empty directory for general use in which to create packages.

Create another directory for the specific package to bundle up.

Place all directories and files with the correct hierarchy, permissions and owner inside of the specific directory to be packaged.

Run packagemaker:

/Developer/usr/bin/packagemaker \
-r /Users/germ/pkgbuilds/binutils/ \
-v -i com.radiotope.binutils \
-o ./binutils.pkg

The switches used in the example direct packagemaker in the following manner:

-r The build root, or, the directory of files to be packaged.

-v be verbose about it.

-i specify the package ID

-o Output file.

Technically, to make command this even shorter, the -v and -o switches could be omitted. Output, by default, will be dropped in the current directory, and be named based on the root.

To watch the file system for changes, and create a package based on those changes, use the —watch flag. Start packagemaker with the —watch, -o and -i flags, at minimum:

$ /Developer/usr/bin/packagemaker —watch -v -i com.radiotope.binutils -o binutils.pkg
Watching filesystem as pid: 53917. Send SIGUSR1 to stop: kill -SIGUSR1 53917

Note that you're provided the kill command that will properly stop packagemaker, and allow it perform the actual packaging. Once packagemaker is watching, perform the install that you'd like to package, and then send the signal using kill. packagemaker will carry on and create a package based on any files that have changed on the filesystem between the time it was started, and the time that it received the SIGUSR1 signal. Unlike it's GUI brethren, command line packagemaker does not allow an opportunity to edit the list of files that it has noted as changed. If you choose to use the —watch flag, ensure that you're running it at a time when the filesystem is least active.

While packagemaker is effective at automating package builds, sometimes it's just plain easier to use the GUI-based PackageMaker.app to create the first revision. Package Maker.app grants greater flexibility in many cases. Gratefully, the two utilities can be combined: use PackageMaker.app to initially create a package, with the precise options necessary. This configuration can be saved as a .pmdoc file. The command line packagemaker can take a .pmdoc file and build a package based on the configuration options specified within. This can then be used as upgrades to the original package take place.

To allow packagemaker to take direction from a .pmdoc file, use the -d, or —doc switch to specify the .pmdoc file:

/Developer/usr/bin/packagemaker \
-d /Users/germ/pmdoc/Bin_Utils.pmdoc \
-v -i com.radiotope.binutils \
-o ./binutils.pkg

Any options specified on the command line override the equivalent option from the .pmdoc file.

Once packages are created, the goal is to install them on target systems. They can be brought over to a target system in many ways, but once there, they will be installed using Apple's installer. Like PackageMaker, installer comes in both a GUI and command-line version. The command-line version is the gateway to automating installs.

The basic syntax is short and sweet:

installer -pkg [path to package] -target [path to destination volume/device]

To install the example binutils.pkg on the current system volume, the command would look like this:

installer -pkg /packages/binutils.pkg -target /

Before installing, installer can determine which targets on the current system are valid. The -volinfo switch lists all valid volumes for a given package. Some packages have constraints on installation targets, such as "home" or "root volume only." To obtain a list of currently mounted volumes that are appropriate destinations, supply the package and volinfo switches:

installer -pkg /packages/binutils.pkg -volinfo 

This output can be parsed for a valid destination.

Finally, note that the -target switch can also accept other forms of listing the destination. Also acceptable are device node entries (/dev/disk3), a disk identifier (/dev/disk1s6) or a volume's UUID. It will also accept a domain as listed in the -dominfo switch, however, since very few packages contain domain information, this method has lesser value than methods shown earlier.

The importance of the command line versions of these utilities lies in automation.

MacTech has run several articles that talk about AFP548's InstaDMG, a build tool to create a system image. The command line installer is at the heart of this program. An excerpt from the main script shows installer in action:

/bin/ls -A1 $UPDATE_FOLDER | /usr/bin/sed '/.DS_Store/d' | while read UPDATE_PKG
   do
      /usr/sbin/installer -verbose \
    -pkg "${UPDATE_FOLDER}/${UPDATE_PKG}/`/bin/ls ${UPDATE_FOLDER}/${UPDATE_PKG} | \
    /usr/bin/sed '/.DS_Store/d'`" \
    -target $CURRENT_IMAGE_MOUNT >> $LOG_FILE
      /bin/echo "Installed ${UPDATE_FOLDER}/${UPDATE_PKG}/`/bin/ls ${UPDATE_FOLDER}/${UPDATE_PKG} | \
    /usr/bin/sed '/.DS_Store/d'`" >> $PKG_LOG
   done

The idea behind this except is to list all packages in a hierarchy of folders and send that list in order to installer, which installs each package in turn.

Another approach to automating this type of install would be using the find command:

find ${UPDATE_FOLDER} -iname "*pkg" -type d -exec installer -pkg {} -target / \;

This command could also be redirected to a file (remember to specify -verbose in the installer command!) for logging purposes.

The installer command can also be individually distributed to OS X systems using dshell (see the January 2008 issue of MacTech), or via Apple Remote Desktop's "Send Unix" command. While ARD does have a method to directly install packages, it proves unreliable in many instances, including sending packages to machines over a WAN, and sending packages to too many machines. The number that consists of "too many" is inconsistent from run to run and environment to environment.

Rather than send one-liners, a larger, structured script can direct a machine to mount a remote disk image (using hdiutil), install a package on that volume, dismount the volume and reboot the remote machine if necessary and appropriate. It can do all of this while checking for errors and reporting on progress, too.

As OS X systems become more prevalent, better methods of configuration and installation need to appear in order to allow administrators the ability to serve users in a timely manner. The methods in this article can be used with or without a complete OS X infrastructure (e.g. Without OS X Server supporting directory services or more of the back-end). Automation means consistency. Possibly more important, though, is that it means timeliness and less work for administrators once set up.

Also, packaging allows an administrator to pretty much do anything to a target system. Since preferences and user accounts are stored as files, installer can overwrite them. Also, since packages can runs scripts, they can perform even more sophisticated functions. Your imagination is the only limit.

Media of the month: "The Design and Implementation of the FreeBSD Operating System" by Marshall Kirk McKusick and George V. Neville-Neil. While not a perfect fit, this may be the closest thing we have to an OS X internals book. The BSD file structures all match up, along with what happens at the Unix layer. Combine this with the Mac specific (but sadly dated) Mac OS X Internals by Amit Singh, and you have some incredibly deep knowledge of lower level structures and system activity.

Hopefully you're reading this while attending WWDC (yes, it's that time of the year again). Or, this is providing some travel reading for you. In any case, MacTech will be present, so feel free to find us and say hello!

Until next month, enjoy WWDC and all that encompasses it, and keep scripting.

PackageMaker Users Guide, Apple Computer. http://developer.apple.com/documentation/DeveloperTools/Conceptual/PackageMakerUserGuide/PackageMaker_UserGuide.pdf

packagemaker man page

installer man page

Ed Marczak is the Executive Editor for MacTech Magazine, and has been lucky enough to have ridden the computing and technology wave from early on. From teletype computing to MVS to Netware to modern OS X, his interest was piqued. He has also been fortunate enough to come into contact with some of the best minds in the business. Ed spends his non-compute time with his wife and two daughters.