Volume Number: 26
Issue Number: 11
Column Tag: MacEnterprise

MacEnterprise: Managing Software Installs with Munki - Part 2

Setting up a demonstration Munki Server

By Greg Neagle, MacEnterprise.org

Last month, we started looking at munki, a set of open-source tools that can manage software installs and removals on Mac OS X machines. Munki consists largely of client-side tools written in Python, and can use virtually any modern web server as its source of packages and data. Munki's source code, as well as installer packages for the tools, are available at http://code.google.com/p/munki. Munki supports Mac OS X 10.5 (Leopard) and 10.6 (Snow Leopard).

Munki can install software packaged in Apple's Installer package format, software delivered for "drag-and-drop" installs on disk images, and Adobe CS3, CS4 and CS5 products and updates using Adobe's supported enterprise deployment tools.

As part of last month's introduction, we looked at the data munki uses to determine what to install or remove. Aside from the actual software to be installed (which for the rest of this column we'll refer to as "packages," even for items that aren't strictly Apple packages), munki stores its data in the form of Apple plist files. Munki uses manifest files to keep track of which software is to be installed on which machines, and catalog files to keep track of which packages are available.

Manifests are easy to understand. A bare-bones manifest must contain a list of one or more catalogs to be searched for packages, and a list of packages to install. Here's an example:

<?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>

In this example, munki is told to search the production catalog for Firefox and Thunderbird, and ensure the latest versions of these items are installed. The concept of "catalogs" is an important one. It is possible to have different versions of software available in different catalogs. A very common and powerful configuration is to maintain a "testing" catalog and a "production" catalog. New versions of software are first added to the "testing" catalog. Only a subset of managed machines is configured to use the "testing" catalog, and this subset gets the newer versions of software first. Once you are satisfied there are no major issues with a new version of a piece of software, you can add the new version to the "production" catalog, where the rest of your managed machines will find it and install it.

Munki catalogs are lists of items that describe available packages. Munki provides some tools that help you create the catalog information for each package and combine this information into catalogs. In the most common configuration, the information for each package is stored in a corresponding "pkginfo" file. These pkginfo files are combined together to make the catalogs.

We looked at a sample pkginfo file last month, and there's a lot of information crammed into each one. Fortunately, you don't have to create these from scratch - tools provided with munki can create pkginfo files from pkgs. Rather than reviewing the contents and format of pkginfo files, we're going to create some to use with our own munki server.

Since Munki can use virtually any web server as its server, and since Mac OS X ships with Apache2, accessible as "Web Sharing" in the Sharing System Preferences pane, it's very easy to set up a demonstration munki server on any available Mac. You can even set up a munki server on a single machine that is also a munki client, and that is exactly what we are about to do.

To set up a munki server, we're going to create a directory structure in /Users/Shared, and then configure Apache2 to serve it via HTTP. You can do the next few steps via the Finder or via the Terminal, but it's easier to write them out as Terminal commands:

cd /Users/Shared/
mkdir munki_repo
mkdir munki_repo/catalogs
mkdir munki_repo/manifests
mkdir munki_repo/pkgs
mkdir munki_repo/pkgsinfo

You might be wondering what that last directory is. The pkgsinfo directory holds data that is not used directly by munki clients, but is used by other munki tools to create the catalogs. One more thing: let's make sure the Apache2 can read and traverse all of these directories:

chmod -R a+rX munki_repo

Next, we need to tell Apache2 to serve the munki_repo directory via HTTP. You could edit the /etc/apache2/http.conf file, or one of the other .conf files used by Apache2, but there's a much easier method for this demonstration.

sudo ln -s /Users/Shared/munki_repo /Library/WebServer/Documents/

This creates a symlink inside /Library/WebServer/Documents/ that points to our new munki_repo directory. By default on Mac OS X, /Library/WebServer/Documents/ is Apache2 's DocumentRoot, so it will serve anything in that directory via HTTP.

If you haven't already, turn on Web Sharing in the Sharing preferences pane. Now you can test your work so far. Using your favorite web browser, navigate to http://localhost/munki_repo. If you've done things correctly to this point, it should look like Figure 1.

Figure 1 - Our munki repo via HTTP

We now have a working munki repository ("repo") - but it's completely empty and not useful at all. So let's start to populate the repo.

We're going to use some tools distributed with munki to import packages into our new Muni repo. Download the current munki installation package at http://code.google.com/p/munki/downloads/list. For this column, I'll be using a preview of the 0.7.0 release of the munki tools; by the time this reaches print, 0.7.0 (or later) should be in final release. In any case, it's important that you use a 0.7.0 release or later - some of the tools we'll use aren't available in earlier releases, or work differently.

Install the munki tools by mounting the disk image and double-clicking the Installer package and installing like any other package. A restart is required after installation.

The tools you'll use as an administrator are available from the command-line, and are installed in /usr/local/munki. This location is not in the standard search path, so you'll need to either add this directory to your search paths, or be sure to type the full path when invoking these tools.

The tool we will use to import packages into the munki repo is called munkiimport. We need to configure it before we can use it - telling it where to find our repo, among other things.

bash-3.2$ /usr/local/munki/munkiimport —configure
Path to munki repo [None]: /Users/Shared/munki_repo   
Repo fileshare URL [None]: 
pkginfo extension [None]: 
pkginfo editor [None]: TextMate.app

We are first asked for the path to the munki repo, and since we set one up at /Users/Shared/munki_repo, that's what we enter. Next, we are asked for a repo fileshare URL. This is used when the repo is hosted on a remote file server, and this would typically be an afp:// or smb:// URL specifying the share. Since we're hosting the repo on the local machine, we'll leave this blank. We are then asked to specify an extension to append to the name of pkginfo files. Some admins prefer ".plist", some prefer ".pkginfo". Personally, I just leave it blank - munki doesn't care. Finally, you are asked for an editor to use for the pkginfo files. If you like command-line editors, you can specify /usr/bin/vi or /usr/bin/emacs for example. If you, like me, prefer GUI text editors, you can specify GUI apps by name (but be sure to include the ".app" extension). I picked TextMate.app, but you could choose TextWrangler.app, BBEdit.app, or even TextEdit.app.

Next, let's get a package to import. Firefox is a good example package, and you can download it from http://www.mozilla.com/. As of this writing, the current version is 3.6.12, and when I download it using Safari, a disk image named "Firefox 3.6.12.dmg" is downloaded to my Downloads folder and opened in the Finder. We want to work with the disk image file itself, so eject the mounted "Firefox" volume in the Finder.

We'll return to the command line to import the Firefox package.

/usr/local/munki/munkiimport ~/Downloads/Firefox\ 3.6.12.dmg Item name [Firefox]: Display name []: Mozilla Firefox Description []: Web browser from Mozilla Version [3.6.12.0.0]: Catalogs [testing]: Item name: Firefox Display name: Mozilla Firefox Description: Web browser from Mozilla Version: 3.6.12.0.0 Catalogs: testing Import this item? [y/n] y Upload item to subdirectory path []: apps/mozilla Path /Users/Shared/munki_repo/pkgs/apps/mozilla doesn't exist. Create it? [y/n] y Copying Firefox 3.6.12.dmg to /Users/Shared/munki_repo/pkgs/apps/mozilla/Firefox 3.6.12.dmg... Saving pkginfo to /Users/Shared/munki_repo/pkgsinfo/apps/mozilla/Firefox-3.6.12.0.0...

Let's walk through this. We run the munkiimport tool and provide it a path to our downloaded disk image. munkiimport then asks us to confirm or override some basic information about the package. We accept the item name by simply hitting return, but provide a new "Display name" and "Description". We accept the version and the catalogs.

munkiimport then prints back our choices and asks if we want to import the item. (If we made any mistakes, this would be a good time to say "no"!) We agree, and munkiimport asks us if we'd like to upload the package to a subdirectory path. We could just skip this, and upload everything to the top level of the pkgs directory in the munki repo, but as our number of packages grows, that might get hard to navigate. So we're going to upload this into a directory named "Mozilla" inside a directory named "apps". As a sanity check, munkiimport warns us that the subdirectory path we've chosen doesn't yet exist. Since this is a brand new repo, we knew in advance that the directory didn't exist, so we want munkiimport to create it for us. Finally, munkiimport copies the Firefox package to /Users/Shared/munki_repo/pkgs/apps/mozilla/ and saves the pkginfo to /Users/Shared/munki_repo/pkgsinfo/apps/mozilla/Firefox-3.6.12.0.0.

Since I chose TextMate.app as my editor when I configured munkiimport earlier, munkiimport next opens the newly created pkginfo file in TextMate. See Figure 2.

Figure 2 - Munki pkginfo for Firefox 3.6.12

This gives you another opportunity to edit the pkginfo using your favorite text editor. We don't need to make any changes, though, so we can just close it. If we return our attention to the terminal window we used to run munkiimport, we'll see it's prompting us for one more bit of information:

Rebuild catalogs? [y/n] 

Remember that munki clients don't use the individual pkginfo files; instead they download and consult munki catalogs to find available software. So to actually make use of the pkginfo we just generated, we need to build new versions of all the defined catalogs. Answering "y" to this prompt causes munkiimport to rebuild the munki catalogs.

Rebuild catalogs? [y/n] y
Adding apps/mozilla/Firefox-3.6.12.0.0 to testing...

Since we only have one package (and its corresponding pkginfo) in our munki repo, we see a single item has been added to the testing catalog.

Again we can check our work so far. In your web browser, navigate to http://localhost/munki_repo/catalogs/testing. You should see something similar to Figure 3.

Figure 3 - Munki "testing" catalog

We now have one package in our munki repo. Our next step is to create a manifest so that munki knows what to install on a machine. Create a new text file in your favorite text editor with these contents:

<?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>Firefox</string>
        </array>
</dict>
</plist>

Save the file as /Users/Shared/munki_repo/

manifests/test_munki_client. Be sure your editor doesn't add a file extension to the file name (many will try to add ".txt" for you). Again, check your work in your web browser by navigating to http://localhost/munki_repo/

manifests/test_munki_client. You should see the file you just created displayed in your web browser.

We're done (for now) with the server. Next, we need to configure the munki client so it knows about our server. The munki client stores its configuration in /Library/Preferences/ManagedInstalls.plist. Unless you've run the munki client before, this file won't yet exist. We'll use the defaults command to create it with the data we need. (Watch the line breaks - these are two commands, each on a single line.)

sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL "http://localhost/munki_repo"
sudo defaults write /Library/Preferences/ManagedInstalls ClientIdentifier "test_munki_client"

We've told the client tools the top-level URL for the munki repo, and the name of the client manifest we'd like to use. That's it for the client configuration. Now the moment of truth: let's run the munki client from the command line.

sudo /usr/local/munki/managedsoftwareupdate 
Managed Software Update Tool
Copyright 2010 The Munki Project
http://code.google.com/p/munki
Downloading Firefox 3.6.12.dmg...
   0..20..40..60..80..100
Verifying package integrity...
The following items will be installed or upgraded:
    + Firefox-3.6.12.0.0
        Web browser from Mozilla
Run managedsoftwareupdate —installonly to install the downloaded updates.

Success! munki saw that we needed Firefox 3.6.12 and downloaded it. (It did not yet install it - we'll get to that in a bit.) But what if instead when you run managedsoftwareupdate you see this:

sudo /usr/local/munki/managedsoftwareupdate 
Managed Software Update Tool
Copyright 2010 The Munki Project
http://code.google.com/p/munki
No changes to managed software are available.

The most likely reason you see this is because you already have Firefox 3.6.12 (or later) installed. If you really want to test munki, delete your copy of Firefox:

sudo rm -r /Applications/Firefox.app

Then try running managedsoftwareupdate again - you should see it being downloaded as in the example above.

We ran managedsoftwareupdate from the command line and verified that the munki tools could talk to our munki server and download the Firefox package. But, as we've noted, managedsoftwareupdate did not actually install Firefox. We could call managedsoftwareupdate again, this time passing it the -installonly flag to make it install what it just downloaded. But instead, we're going to introduce another tool - the one "regular" users would interact with - Managed Software Update.app. You'll find it in the /Applications/Utilities folder. Double-click it to launch it. You should see a window similar to Figure 4.

Figure 4 - Managed Software Update.app

If you click on Update now, you'll be asked if you want to install without logging out, or to log out and install. Choose one and Firefox will be installed, and it will look something like Figure 5.

Figure 5 - Installing Firefox

Huzzah! We've accomplished a lot. We've set up a munki server, imported a third-party software package, built a catalog, and created a client manifest. We've also configured a munki client and successfully installed software using the munki tools.

There's a lot more we can do with our demo munki server, but we've run out of space for this month, so we'll need to continue next month. Next time, we'll look at updating software and removing software. We'll also examine pkginfo files in more depth to get a sense of the additional capabilities munki can offer a Mac OS X administrator.

Perhaps you have decided you don't want to do anything more with munki. Maybe you intend to explore more, but don't want to leave the munki tools and munki server in place until next month's installment. In any case, if you want to remove the munki tools and server, here's what you need to remove. Watch the line breaks.

Removing the client tools:

sudo launchctl unload /Library/LaunchDaemons/com.googlecode.munki.*
sudo rm -rf "/Applications/Utilities/Managed Software Update.app"
sudo rm -f /Library/LaunchDaemons/com.googlecode.munki.*
sudo rm -f /Library/LaunchAgents/com.googlecode.munki.*
sudo rm -rf "/Library/Managed Installs"
sudo rm -rf /usr/local/munki
sudo pkgutil —forget com.googlecode.munki

Removing the server:

sudo rm /Library/WebServer/Documents/munki_repo
rm -r /Users/Shared/munki_repo

If you aren't using Web Sharing for anything else, remember to turn it off using the Sharing preferences pane.

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.