Volume Number: 26
Issue Number: 10
Column Tag: MacEnterprise
By Greg Neagle, MacEnterprise.org
Managing Mac OS X machines has many facets. Common tasks include the initial building or imaging of machines, configuration of the OS and applications for use, managing user accounts, setting and enforcing organizational policies, and inventorying hardware and software. Remotely assisting users might also come under the category of Mac management.
Another very common task is installing, updating, and removing software on deployed machines. There are some organizations that build their machines with a "golden master" image, and then never touch them again until they are reimaged, but that's a rare arrangement. For most organizations, there is a continuing need to add, update, and remove software from machines that have been deployed.
There are several commercial tools available to assist you with this task. Among these are the Casper Suite, Absolute Manage (formerly LANrev), KBox, and FileWave. There are also some free tools. Radmind, developed at the University of Michigan, is a tool to manage the contents of a filesystem. Its design allowed it also be used as a software management system, and it has enjoyed some popularity among Mac OS X administrators. I, personally, have used it for the better part of a decade to manage hundreds of Mac OS X machines.
For various reasons, a couple of years ago, I began to look at alternatives to radmind. I needed a system that did not manage the entire filesystem and allowed greater flexibility for users to decide what was installed on their machines, and I wanted a system that removed much of the tedium of adding new software to the management system. The commercial solutions mentioned earlier probably would have met my needs, but timing and finances meant that I'd have to wait a year before we could consider purchasing one of these solutions. So with a year to wait before I could possibly buy a commercial solution, I decided to try writing my own software management utility. The result is munki.
Although munki is relatively new compared to radmind and many of the commercial solutions, it has been in use at my organization for over a year, and is in use by many other organizations world-wide.
Munki consists of client-side tools written largely in Python, and is available as open-source under the Apache 2 license at http://code.google.com/p/munki. The client tools run on Leopard and Snow Leopard. They require Python 2.5, and so will not run on Tiger or earlier versions of Mac OS X.
On the server side, munki can use any web server. I run my munki repository on an Xserve running Snow Leopard Server, but you can use any available modern web server on any platform. (I say "modern" because some software packages can be over 2GB in size and older web servers have problems serving files of that size.) You do not need to install any munki-specific software on the web server, but you must be able to create directories and files on the web server.
Munki can install software delivered as standard Apple packages - the same kind of packages, that when double-clicked, open in Apple's Installer.app. Munki can also install software from disk images - for example, an application delivered on a disk image that is supposed to be dragged to the Applications folder. These "drag-n-drop disk images" are easily installed by munki. Munki also knows how to install many Adobe products - specifically, it can install the Adobe CS3, CS4, and CS5 products and their updates. In many cases, munki can also remove the software it has installed.
Munki also supports "Optional Software". These are items that are made available to the users of machines your manage, who can decide for themselves whether or not they'd like any of these items installed. If they choose to install an optional software item, they can also later remove it. This feature does not require admin rights for the user, and is similar in concept to "Self Service" installs offered by the Casper Suite from JAMF Software.
Additionally, munki can update software it did not install itself. You can specify that certain software should be updated only if some version is found already installed on a user's machine.
Earlier, we mentioned that managing Mac OS X machines has many facets. Many of the commercial solutions for software deployment also provide solutions for other facets of Mac management. Munki does not. Munki focuses only on software deployment. You'll need to turn to other tools for imaging, inventory, remote assistance, and preference management. At my organization, we're using DeployStudio for imaging and Apple's Screen Sharing for remote assistance. If you've been reading this column for very long, it shouldn't come as a surprise that we're using Local MCX for preference management.
Most of the data munki needs to function is stored on a web server. Munki uses three types of data:
Installer items: these are packages or disk images containing the software to be installed. In many cases, you can use a package or disk image provided by the software vendor without having to repackage or convert the installer package in any way. For example, munki can install Firefox from the disk image that you download from http://www.mozilla.com.
Catalogs: these are lists of available software, containing metadata about the installer items. You, as the munki administrator, build these catalogs using tools provided with munki.
Manifests: A manifest is essentially a list of what software should be installed on or removed from a given machine. You could have a different manifest for every machine, or one manifest for all of your machines. Manifests can include the contents of other manifests, allowing you to group software for easy addition to client manifests. For example, you could create a manifest listing all of the software every machine in your organization must have. The manifest for a client could then include the common-software manifest, and additionally have software unique to that client.
Manifests and catalogs are stored on the web server as standard Apple plist files in text format. If you've administered Mac OS X machines, you've almost certainly encountered plist files. They are a well-understood way to store structured data in a text format. Here's an example of a simple manifest:
<?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>catalogs</key>
<array>
<string>production</string>
</array>
<key>managed_installs</key>
<array>
<string>Firefox</string>
<string>Thunderbird</string>
</array>
</dict>
</plist>
This manifest simply tells munki to look for information about software to install in the "production" catalog, and to ensure Firefox and Thunderbird are installed. Munki then searches the production catalog for items named "Firefox" and "Thunderbird", and since we did not specify a version, it selects the items with the latest versions. Here's what it finds for Firefox:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>autoremove</key>
<false/>
<key>catalogs</key>
<array>
<string>production</string>
</array>
<key>installer_item_hash</key>
<string>10ede8228c869ba4b03611b6ec750acbccf879f20ce52cb86e1baf6972f60fb0</string>
<key>installer_item_location</key>
<string>Firefox 3.6.10.dmg</string>
<key>installer_item_size</key>
<integer>18996</integer>
<key>installer_type</key>
<string>copy_from_dmg</string>
<key>installs</key>
<array>
<dict>
<key>CFBundleIdentifier</key>
<string>org.mozilla.firefox</string>
<key>CFBundleName</key>
<string>Firefox</string>
<key>CFBundleShortVersionString</key>
<string>3.6.10</string>
<key>path</key>
<string>/Applications/Firefox.app</string>
<key>type</key>
<string>application</string>
</dict>
</array>
<key>items_to_copy</key>
<array>
<dict>
<key>destination_path</key>
<string>/Applications</string>
<key>source_item</key>
<string>Firefox.app</string>
</dict>
</array>
<key>minimum_os_version</key>
<string>10.4.0</string>
<key>name</key>
<string>Firefox</string>
<key>uninstall_method</key>
<string>remove_copied_items</string>
<key>uninstallable</key>
<true/>
<key>version</key>
<string>3.6.10.0.0</string>
</dict>
</plist>
At this point, you might be intimidated by the complexity of this information. But don't worry, it's very easy to generate this info with tools that are part of munki, and we'll cover that in the future. The information might look less intimidating if I were to remove the plist overhead and present a subset of the information as a simple table. Look at Table 1 for the result.
Table 1 - munki's information about an installer item
Let's look at parts of the information that munki found about Firefox.
The most important field is name. Here it is "Firefox", which matches the name in the managed_installs list in the manifest. When looking for information about a managed install, munki searches the catalogs for items matching the name given. If no version is given, it selects the item with the highest version it finds. Here the version is "3.6.10.0.0".
Once it has found information on the item to be installed, munki checks to see if the item has already been installed. Munki can do this one of two ways. If the item to be installed is installed via an Apple package, munki can check for the receipts left when a package is installed. But software that is not installed via an Apple package does not leave a receipt. And even for items that come in package format, it is possible for software to be removed (for example, by dragging an application to the trash) while leaving the receipt in place. So munki has a second method is can use to determine if an item has been installed, the installs list. For our Firefox example, here is that list:
<key>installs</key>
<array>
<dict>
<key>CFBundleIdentifier</key>
<string>org.mozilla.firefox</string>
<key>CFBundleName</key>
<string>Firefox</string>
<key>CFBundleShortVersionString</key>
<string>3.6.10</string>
<key>path</key>
<string>/Applications/Firefox.app</string>
<key>type</key>
<string>application</string>
</dict>
</array>
A simplified version of the installs data is shown in Table 2: Installs data for Firefox 3.6.10
Installs: Type: application Identifier: org.mozilla.firefox Name: Firefox Version: 3.6.10 Path: /Applications/Firefox.app
Table 2 - Installs data for Firefox 3.6.10
In this example, the installs list contains a single item. This item contains information about the Firefox application itself. Most importantly, it has the name, version and pathname for the application. Munki can then use this information to determine if Firefox is installed, and if so, compare the version of the installed application to the one defined in the catalog information about Firefox. (Munki can often find the application even if it has been moved from its normal location by using System Profiler data and the name and identifier.)
If Firefox isn't found, or the version of the installed Firefox is lower than the version described by the catalog information, munki decides that Firefox needs to be installed and downloads the disk image file containing Firefox, using information from the installer_item_location field. If we were using the sample manifest shown earlier, the check would be repeated for Thunderbird.
Let us assume that munki found that Firefox was out-of-date, but the current version of Thunderbird was installed. After downloading the disk image for Firefox 3.6.10, munki would alert the user of available updates using the Managed Software Update application, shown in Figure 1.
Figure 1 - Managed Software Update.app
As you can see, Managed Software Update.app is designed to closely resemble Apple's Software Update application so that users might quickly grasp its purpose and how to use it. Unlike Apple's Software Update application, users do not need administrative rights to install software using this application. If the user clicks Update now, munki will install Firefox 3.6.10 without an administrative prompt. The next time munki checks, it will find that Firefox is installed and not attempt to install it again.
The installs list also bestows munki with another feature: automatic repair. If a user (with administrative rights) were to remove Firefox (by accident or on purpose), munki will notice and reinstall the application. For more complex software installs, munki can check for the existence of multiple items - not only applications, but other filesystem items as well. If any of the items in the installs list are missing or out of date, a reinstall is triggered.
To remove a software item from a machine, you'd edit the manifest for the machine, moving the item from the managed_installs list to the managed_uninstalls list. If we wanted to remove Firefox, the edited manifest might look like this:
<?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>catalogs</key>
<array>
<string>testing</string>
</array>
<key>managed_installs</key>
<array>
<string>Thunderbird</string>
</array>
<key>managed_uninstalls</key>
<array>
<string>Firefox</string>
</array>
</dict>
</plist>
This time we'll run munki from the command line:
>/usr/local/munki/managedsoftwareupdate
Managed Software Update Tool
Copyright 2010 The Munki Project
http://code.google.com/p/munki
The following items will be removed:
- Firefox
Run managedsoftwareupdate —installonly to install the downloaded updates.
Munki sees Firefox in the list of managed_uninstalls, and uses the information in the installs array we discussed earlier to determine that Firefox is installed. Munki then schedules Firefox for removal. From the GUI, the scheduled task looks like Figure 2.
Figure 2 - Software removal
In the interface presented to the user, details about software removals are hidden by default (though the administrator can override this if he or she would like). This is to discourage users from deferring updates indefinitely because they don't want a certain application removed.
This is a good time to discuss a major part of munki's design. Munki is designed to be polite. It never installs anything under a currently active user session without the user's approval. If no one is logged in, munki will by default install or remove software automatically, hiding the loginwindow and presenting a status window. If a user is logged in, munki notifies the user of updates and allows the user to either update right away or defer the update until later. Munki also handles multiple user logins (via Fast User Switching) gracefully and will not install items if more than one user is logged in (as doing so could cause switched-out users to lose work).
Administrators can customize these behaviors, configuring munki to never bother the user with available updates (therefore waiting to install all updates when no user is logged in), or the inverse - telling munki to never automatically install software when at the loginwindow, and instead always requiring user consent for all updates. Administrators cannot, however, easily configure munki to force an install or removal while users are logged in.
This month, we've presented a basic introduction to munki, an open-source utility for managing software installs, updates and removals on Mac OS X machines. Next time, we'll dive a little deeper and set up a proof-of-concept installation of munki on a standalone machine. This will include both the munki client tools and a working munki server. We'll then explore more of the munki toolset and look at creating munki catalogs - the listings of available software munki uses to determine if a piece of software needs to be installed or removed, and if so, how to complete the installation or removal.
In the meantime, if this month's column has piqued your interest, be sure to check out the resources available on the munki Google Code website at http://code.google.com/p/munki, and browse the archives of the munki-dev Google Group at http://groups.google.com/group/munki-dev. Until next month, have fun munki-ing around!
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.
