Volume Number: 25
Issue Number: 12
Column Tag: System Administration
by Greg Neagle, Macenterprise.org
It's that time of year, when there's snow (at least in parts of the Northern Hemisphere), and people are thinking of packages - packages to ship to friends and family; maybe even packages under a tree. So what better time to talk about Snow Leopard and packages?
As always, with each major OS release from Apple, there are changes that might affect systems administrators. Last time, we went on a scavenger hunt through the OS, looking for some of these changes. This month, we'll focus on changes relating to installer packages, receipts, and Software Update.
Experienced OS X systems administrators should be familiar with package receipts. These are written to disk when software packaged in Apple package format is installed. Receipts serve as evidence that a certain version of a certain software package has been installed, and also are essential for the installer when it is upgrading a software package from an older version to a newer version. Some software installation problems can be resolved by removing the relevant receipt(s). If the receipt is missing, the installer treats the installation as a new install instead of an upgrade install. (This may create its own issues; it is not something you should do as a matter of habit.)
Prior to the release of OS X 10.5 Leopard, when Apple packages were installed, receipts were left in /Library/Receipts. These receipts were copies of the original installation package minus the archive containing the actual files that were installed.
Leopard added a new type of package - the "flat" package - where instead of a bundle-style directory, the package is a single file. This file is actually a XAR archive; similar in concept to a "tarball" or zip archive. When this type of package is installed under Leopard, it does not leave a receipt in /Library/Receipts. Instead, a copy of the "bom" (bill-of-materials) file is placed in /Library/Receipts/boms, and an entry for the package is made in the package database. You can get information from the package database using the /usr/sbin/pkgutil tool.
Even though OS X 10.5 introduced a new package format, there's still plenty of software that uses the older format. Any software that can be installed on OS X 10.4 or earlier must use the older bundle-style package format. Many vendors continue to use the bundle-style package format even for software that runs only on 10.5 and later, because this format is well understood and there are several third-party tools to create this format. Under Mac OS X Leopard, packages in this format leave their receipts in /Library/Receipts - just as they did in previous releases of Mac OS X - so you might have to look in two places and use a variety of tools to find the receipt information you are interested in.
In Snow Leopard, virtually all package receipts now go in the package database, and only extremely old package formats or those missing the CFBundleIdentifier attribute from their Info.plist are not added to the package database. If you haven't had to work with the package database before, under Snow Leopard, you almost certainly will.
If you had previously dug around in package receipts to figure out exactly what was installed, and examined pre- and post-install scripts to puzzle out what additional changes were made when software was installed, you may wonder how to get that information under Snow Leopard. Some of the info is now available via /usr/sbin/pkgutil, but for pre- and post-install scripts, you'll need to find the original installer package - this information is no longer retained.
If you used pkgutil in Leopard, it is mostly unchanged in Snow Leopard. Here are some common uses of pkgutil:
pkgutil —pkgs will list all installed package IDs. By using the —volume option, you can query the package database on a volume other than the boot volume.
pkgutil —pkgs com.adobe.pkg.FlashPlayer com.adobe.shockwave com.apple.pkg.AdditionalEssentials com.apple.pkg.AdditionalSpeechVoices com.apple.pkg.AddressBook ...
pkgutil —files packageid shows all the files installed by packageid.
pkgutil —files com.adobe.pkg.FlashPlayer Flash Player.plugin Flash Player.plugin/Contents Flash Player.plugin/Contents/Info.plist Flash Player.plugin/Contents/MacOS Flash Player.plugin/Contents/MacOS/Flash Player Flash Player.plugin/Contents/Resources Flash Player.plugin/Contents/Resources/English.lproj ...
pkgutil —pkg-info packageid prints extended information about packageid.
pkgutil —pkg-info com.adobe.pkg.FlashPlayer package-id: com.adobe.pkg.FlashPlayer version: 10.0 volume: / location: Library/Internet Plug-Ins install-time: 1255647844
pkgutil —forget packageid removes info about packageid from the package database. This is equivalent to deleting receipts in /Library/Receipts under older versions of Mac OS X, and is a way to get the installer to treat a reinstall like a new install instead of an upgrade install. Note that this does not remove any files installed by the package.
pkgutil —forget com.adobe.pkg.FlashPlayer Forgot package 'com.adobe.pkg.FlashPlayer' on '/'.
pkgutil —file-info path will print information about the filesystem item at path. This can be useful for determining which package is responsible for installing a specific file or directory.
pkgutil —file-info /Applications/Mail.app volume: / path: /Applications/Mail.app pkgid: com.apple.pkg.Mail pkg-version: 10.6.0.1.1.1249291854 install-time: 1251997001 uid: 0 gid: 0 mode: 755 pkgid: com.apple.pkg.update.os.10.6.1 pkg-version: 1.0.1.1249367152 install-time: 1255646935 uid: 0 gid: 0 mode: 755
We can see that the /Applications/Mail.app directory was installed as part of the com.apple.pkg.Mail package as part of the original OS install, then later modified by the 10.6.1 update.
In Leopard, the actual package database was a Sqlite3 database, stored on-disk at /Library/Receipts/db/a.receiptdb. You could use standard sqlite3 libraries to query and even modify this database. In Snow Leopard, it appears the database is created from the contents of /var/db/receipts. In this directory you will find two files for each installed package - a packageid.bom file, and a packageid.plist file. The bom file is a standard bill-of-materials file, containing a listing of all the filesystem items installed by the package. You can use lsbom to list the contents of the bom file. The plist file is, of course, a standard OS X property list file, containing metadata about the package. The plist file is in binary format, so to read it you'll either need to use the defaults command, or use plutil to convert it to XML. Here we'll use the defaults command:
defaults read /var/db/receipts/com.microsoft.rdc.pkg
{
InstallDate = "2009-10-14 15:43:47 -0700";
InstallPrefixPath = "";
InstallProcessName = installer;
PackageFileName = "RDC2.0.0.pkg";
PackageIdentifier = "com.microsoft.rdc.pkg";
PackageVersion = "2.0.0";
PathACLs = {
Applications = "!#acl 1\\ngroup:ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000000C:everyone:12:deny:delete\\n";
};
}
This appears to be a superset of the info you can get from pkgutil:
pkgutil —pkg-info com.microsoft.rdc.pkg package-id: com.microsoft.rdc.pkg version: 2.0.0 volume: / location: install-time: 1255560227
Note that the plist file for com.microsoft.rdc.pkg contains a little more information - the filename of the installer package; which process installed this, and ACLs for any paths in the installed payload. Also, the install date/time is in a more human-readable format in the plist file.
As always, you can type man pkgutil at a command-line prompt to get more information on the syntax and options for /usr/sbin/pkgutil.
Software Update has not changed much from Leopard. One annoyance from Leopard has been fixed, though.
In Leopard, Software Update could be configured to automatically download available updates in the background, and then notify you when they were ready to install. These updates were stored in /Library/Updates. But if you used the command-line version of softwareupdate to download available updates, the updates were downloaded to the Downloads folder of the current user, even when that user was root. This was a minor thing, sure, but was annoying in its inconsistency.
Snow Leopard changes this behavior. /usr/sbin/softwareupdate now downloads updates to /Library/Updates. This makes it easier to script custom behavior for downloading updates, as updates downloaded by a script using /usr/sbin/softwareupdate appear in, and can be installed with the GUI Software Update application.
If you manage an Apple Software Update Server for your organization, in order to serve updates to Snow Leopard clients, Apple's official stance is that you'll need to upgrade to Snow Leopard Server on your Software Update Server machines. This is not a new requirement; the Leopard update required a matching update on the server end, as did Tiger.
What's frustrating about this is there is no real technical reason for it, as Apple's Software Update service is just a specially configured web server and some code that replicates updates from Apple's servers to yours. You may not be ready to upgrade your server infrastructure at the same time you need to roll out client machines running Snow Leopard.
What to do? You could configure your Snow Leopard clients to get their updates directly from Apple. You could set up a new Snow Leopard-only software update server on some spare box you have - Apple's new pricing on Snow Leopard server makes that more appealing than in the past. Or you could go the super-cheap route and hack your Leopard Software Update server.
Software Update Server Hack
The original hack was described by Jan Uschok on an Apple discussion list here:
http://discussions.apple.com/thread.jspa?threadID=2169042&tstart=0
All credit for this hack should go to Jan, and I recommend you read the original hack and discussion if you want to try this. In case the discussion disappears, the basic steps follow:
Stop your Software Update Server process.
On your Software Update Server, create a file at /usr/share/swupd/html/content/meta/mirror-config-1.plist with the following contents (you may need to create the "meta" directory if it is missing):
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PrimaryCatalog</key> <string>http://swscan.apple.com/content/catalogs/index.sucatalog</string> <key>CatalogsList</key> <array> <string>http://swscan.apple.com/content/catalogs/index.sucatalog</string> <string>http://swscan.apple.com/content/catalogs/others/index-leopard.merged-1.sucatalog</string> <string>http://swscan.apple.com/content/catalogs/others/index-leopard-snowleopard.merged-1.sucatalog</string> </array> </dict> </plist>
If you retype this from this magazine, note that there should be no line breaks inside any of the <string> elements - they are all a single line.
Edit /etc/swupd/swupd.plist and change the metaIndexURL entry to look like this:
Again, mind the line breaks; the <string> element is a single line.
Start the Software Update Server process and wait for it to download the catalogs. They'll appear under /usr/share/swupd/html/content/catalogs/ and /usr/share/swupd/html/content/catalogs/other/
Once the new catalogs are in place, stop the Software Update Server process again.
Create some symlinks:
cd /usr/share/swupd/html ln -s /usr/share/swupd/html/content/catalogs/index.sucatalog . ln -s /usr/share/swupd/html/content/catalogs/others/index-leopard.merged-1.sucatalog . ln -s /usr/share/swupd/html/content/catalogs/others/index-leopard-snowleopard.merged-1.sucatalog .
(Again, watch the line breaks; all ln -s commands are a single line)
Start the Software Update Server process (again!) and wait for updates to download.
At this point, your hacked Software Update Server should be acting like a Software Update Server running on Snow Leopard server. You can then configure your clients as described on pages 88-89 of the Server System Imaging and Software Update Administration Guide for Snow Leopard. This guide is available from Apple here:
http://images.apple.com/server/macosx/docs/System_Imaging_and_SW_Update_Admin_v10.6.pdf
Specifically, you need to point Tiger clients to one Software Update URL; Leopard clients to another URL, and Snow Leopard clients to yet another.
Use this hack at your own risk; Apple could make changes that would cause this to stop working, and there's no guarantee that the Leopard Server Admin GUI tools will do the right thing with your hacked Software Update Server.
Figure 1 - Leopard Server hosting Snow Leopard updates.
Figure 1 is a screen shot showing a hacked Leopard server hosting Snow Leopard updates. You can see there vvvare updates available for Tiger, Leopard, and Snow Leopard. For comparison, see Figure 2, which is a Snow Leopard server hosting the same updates.
Figure 2 - Snow Leopard server running Software Update Server.
In my brief testing, this hack seemed to work as desired, but I'm not certain I'd want to rely on it indefinitely. Your mileage may vary; results shown may not be typical; talk to your doctor to see if Software Update Server hacking is right for you.
That completes our look at Snow Leopard, receipts, packages, and Software Update. As with most of the changes between Leopard and Snow Leopard, the changes in handling packages and receipts aren't dramatic; they are more evolutionary than revolutionary. We'll all have to wait for Mac OS X 10.7 to see if revolutionary changes are in store - like for example:
pkgutil -uninstall packageid
A systems administrator can dream!
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.
