Volume Number: 25
Issue Number: 10
Column Tag: MacEnterprise
by Greg Neagle, MacEnterprise.org
In past MacTech articles, we discussed reasons Mac OS X systems administrators might need to package or repackage software for deployment in their organization. Some common reasons are:
Packaging internally-developed software or tools
Capturing organization-specific changes or additions (licensing, configuration) into a package
Packaging third-party software that is distributed without an Installer package
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)
In an ideal world, only the first two reasons would require a systems administrator to create an installation package (and if you can train your internal developers on packaging, maybe you can cross the first one off, too!). For the other scenarios, it would be more desirable to just take the installation package provided by your third-party software vendor and use it without having to repackage the software. This month, we'll talk about some of the reasons third-party installers don't work in enterprise environments and provide suggestions on how third-party software vendors could make their installers more enterprise-friendly.
Previous MacEnterprise columns have been targeted towards systems administrators in enterprise-scale organizations. This month's column should also be of interest to systems administrators, but I hope MacTech readers who are software developers find it relevant as well.
If you are a software developer, why should you bother making your installer friendly to enterprise environments? The number one reason is that if you do, you'll sell more of your product into an enterprise environment. Make it too hard to deploy in an enterprise, and systems administrators will look elsewhere and recommend your competitor's solutions.
Reason two: if your installer is not enterprise-friendly, systems administrators will almost certainly have to repackage your software in order to deploy it to their users. This introduces an opportunity for errors to creep into the install process. It's much easier to support your own software when you know it was installed with your own installer - if organizations have to repackage your software for installation, you've just introduced a new variable to support, or many, many new variables, as each organization that repackages your software may do it slightly differently.
What does it mean when we refer to an installer as being enterprise-friendly? It's actually quite simple. An installer is enterprise-friendly when a system administrator can use standard mass-deployment tools to install your software on many machines automatically, and when, once installed this way, the software works as expected for all users of a given machine with no additional post-install configuration that cannot be done as a non-privileged user (i.e., a user without administrator rights).
Now you're wondering: "what does this author mean by 'standard mass-deployment tools'?" Again, a simple answer: on OS X, a standard mass-deployment tool is one that uses the Apple package format. This includes Apple Remote Desktop, LANrev, the Casper Suite, the KBOX, and many other commercial tools. All of these tools can use the Apple package format to install software remotely to a large number of managed machines.
The first, cheapest, simplest, and most important thing you can do as a software developer to ensure your software's installer is enterprise-friendly is to use an ssh session and the command-line installer tool (/usr/sbin/installer) to install your software on a remote machine. Test the install with no-one logged in as a GUI user, and for extra points, test the install with a GUI user logged in.
Some more details:
Copy the installer to the target machine in any way that is convenient - use scp to copy a disk image or tar or zip archive; or log on directly to the target machine and copy the installer from the web or a file server. Put it someplace readily accessible like /Users/Shared.
If a GUI user is logged into the target machine, log that user out.
Use ssh to login to the target machine as root or as an administrative user that has sudo rights.
> ssh gneagle@aquaman Password: Last login: Thu Feb 5 15:16:59 2009 (aquaman) gneagle [201] %
If you've logged in as an administrative user, use sudo to become root, and try to install your software:
(aquaman) gneagle [201] % sudo -s Password: [aquaman:/] root# cd /Users/Shared/ [aquaman:/Users/Shared] root# [aquaman:~] root# installer -target / -pkg MyApp.pkg
If you support Tiger, test with a target machine running Tiger as well as Leopard. Watch what happens on the target machine while the install is happening. No windows or dialogs should appear; no applications should launch. You should see no visible indication that anything is happening.
Assuming the installation was successful and silent, now, using the GUI on the target machine, log in as a non-admin user and verify your software works as expected. Do the same as an administrative user.
Repeat the experiment, this time with a GUI user login on the target machine.
If your software can be installed silently with this method, there is no visual indication that anything is happening when the install is occurring, and your software functions as expected when installed this way: congratulations! There's a very good chance your installer is enterprise-friendly!
As it turns out, it's not hard at all to make an Installer package that is enterprise friendly. The simpler the installer package, the more likely it is enterprise-friendly. But here are some common pitfalls that can make third-party software unnecessarily difficult to deploy in an enterprise environment.
Pitfall #1: using alternate packaging formats
To make your installer enterprise-friendly, use the Apple Installer package format. This does not mean you have to use Apple's PackageMaker tool to create your packages, but whatever tool you use must have as its final output an installation package compatible with Apple's Installer. If you use any other format for your installer, enterprise administrators will almost certainly have to repackage your software to deliver it to their users.
This pitfall extends to the so-called "drag-and-drop" disk images: with this type of install, the user is given a disk or disk image, that when opened, presents the software and typically, instructions to drag it into the Applications folder. While this installation method is acceptable for simple interactive installs, it does not work with mass-deployment tools, once again forcing the administrator to repackage your software.
If you (or your customers) prefer drag-and-drop installs and don't want to give them up, at least consider making an Installer package available as an option for system administrator use. Such an optional package could even be included on the disk image that contains the drag-and-drop application, perhaps in a subfolder and mentioned in a READ ME file.
Pitfall #2: asking for administrator credentials on first launch
Some software asks for administrator credentials on first launch so that it can install additional items. Some examples are TextWrangler, and TextMate, each of which ask the user if they can install command-line tools, which requires administrator rights. If the user declines, the software won't ask again. Worse examples include some of the Adobe Acrobat family of products, which ask every time the product is launched until its demands are met.
This is problematic in an enterprise environment because best practices dictate that most users do not have administrative rights, and so cannot provide the requested credentials. The assumption that a user of your software has or can obtain administrator rights after your software has been installed is simply a bad assumption in an enterprise environment, or any other large-scale environment (like education).
To avoid the issue, administrators have to repackage the software; either including the optional installations or packaging a modified version of the software that doesn't ask the user to install the additional items.
From an administrator's viewpoint, it would be better if the installer simply installed everything it wanted installed up front. In the case of TextWrangler and TextMate, there are no installers - these are distributed as drag-and-drop disk images - so again, the option of an Installer package would make administrators lives easier. In the case of software like Acrobat or Reader, vendors should provide a way for administrators to turn this behavior off without having to modify or repackage the software.
Pitfall #3: pre- and post-install scripts
If your installer makes use of pre- and/or post-install scripts, test them during your remote install tests to make sure they don't do anything visible. The Microsoft Office 2008 installer has a post-install script that attempts to add things to the dock. When run remotely when no one was logged in on a Tiger machine, this script caused the Finder and Dock to open behind the login window. Not only was that annoying, it was a security risk since the Finder was running as root! The Office 2008 installer is not the first installer to do something like this, and unfortunately, probably won't be the last.
Even if a user is logged in, if the administrator was installing Office 2008 remotely, is it really good form to kill and relaunch a user's Dock out from under them?
Other things to watch out for are scripts that attempt to quit open applications, and anything that makes use of AppleScript, which may not behave as expected when no-one is logged in.
Fortunately, a pre- or post- script can easily tell if it's being run in the context of a non-GUI install: the installer command sets the COMMAND_LINE_INSTALL environment variable. Just test for it and exit or skip over a task if it's set - here's a Perl example from a postflight script in the iTunes install package that updates the Dock:
# exit if command-line install
exit(0) if ($ENV{'COMMAND_LINE_INSTALL'});
Pitfall #4: Licensing and registration
It's a fact of life that many commercial applications need some sort of license code or registration code to run as an effort to combat piracy. If your installer requires entering a license code as part of the install process, it will not be able to be installed via mass-deployment tools. Site licensing can help the problem somewhat, but still doesn't solve it completely if the installer asks for the site license code. Consider these alternatives:
If the software is being installed via command line (i.e. the COMMAND_LINE_INSTALL environment variable is set), allow the installation to occur without entering a registration code. Your app could then ask for the registration code at first launch. (But that can cause its own problems...)
An ever better option, but one that I've seen very few vendors embrace, is to provide administrators with a method to include the registration code or codes with the installer. This could take the form of a separate package install that simply installs the registration code(s), or a properly named and formatted text file that a script included with the installer looks for and uses, or some other method for an admin to provide registration codes without having to visit each machine or do a full repackaging of your software.
There are certainly other failure modes and issues that can make an installer less than enterprise-friendly, but these are among the most common pitfalls.
Apple has some documentation on software delivery, managed installs and remote installs. A PDF is available here:
and an HTML version is here:
http://developer.apple.com/documentation/developertools/conceptual/SoftwareDistribution
Software vendors: if you follow the suggestions in this article, your installer will be enterprise-friendly and you may even see increased sales and fewer enterprise support issues.
System administrators: if your software vendors aren't providing enterprise-friendly installers, let them know! File bug reports, pester your account representatives, or, worse case, investigate alternatives from vendors who "get it." Good luck!
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.
