In A Basic Guide to Enterprise Application Distribution, I talked about some of the issues you might encounter when deploying applications in an enterprise environment. Tracking package installers can be a fairly simple task. However, how do you track and deploy applications that use third-party installation mechanisms? In this article I'll provide an overview to some of the commonly overlooked issues that enterprise administrators must deal with when deploying non-package installers.
Mac OS X creates a hierarchy of folders designed to contain and maintain various preference settings for applications. Ideally, an application should use this flexible Mac OS X hierarchy, instead of restricting or specifying a preference location. By using this Mac OS X preference hierarchy, the deployment of any application becomes more flexible and can be more easily managed in diverse environments.
Preferences commonly reside in one of three scopes:
Flexible applications that use the operating system's preferences hierarchy can have preferences stored at the User preference level. However, a flexible application allows preferences to be relocated in a higher level of the preference hierarchy. This relocation allows the application to be used by all users of the machine, which might be required by some deployments of Mac OS X, such as network home directories that typically have limited disk space.
What does ByHost Preferences mean? The ByHost Preferences folder is used by some applications for initial setup or customization of an application. The "e;.plist"e; files inside the ByHost folder use hardware or host information from the specific machine that the application was launched on. They are usually created in ~/Library/Preferences/ByHost with the format com.company.name.product.123456789012.plist. "e;123456789012"e; is the hardware or "e;Mac"e; address of the machine.
ByHost preferences also may use the hostname of the machine, i.e. com.company.name.product.hostname.plist, where "e;hostname"e; is the fully qualified DNS host name of the machine. When the application is deployed to a new machine this file must be created anew, with the new hardware or host information for the customized preference file to function as expected.
Placement of preferences in this location makes the application available only to that user on the original model machine where the application preference was customized. In a multi-user enterprise environment, where users must be allowed access to machines in public computing facilities, libraries, or kiosks in public spaces, the use of global preferences as discussed above is preferred.
There are many ways to overcome this problem; many examples of scripts can be found at the macenterprise.org script archive.
|
Related Reading 
Mac OS X Panther in a Nutshell |
Software applications in Mac OS X can incorporate Finder aliases or symbolic links. Symbolic links use Unix file paths, while aliases use id numbers. Either moving or renaming an application or its parent folder can invalidate an incorrectly formed symbolic link. In turn, an application may not function properly if it depends on the symbolic link. Software should not use symbolic links with absolute paths since the application may be moved or renamed.
In versions of Mac OS X before 10.2, aliases located a file or folder using its unique identity first and its pathname second.
Beginning with Mac OS X 10.2, aliases reversed the search order, using the pathname first and unique identity second. If a file is moved and replaced with an identically named file, aliases to the original file now point to the new file. Similarly, if you move a file on the same volume, without replacing it, aliases use the unique identify information to locate the file. This behavior mimics Unix symbolic links.
As an example, with an application MyApp, if the following symbolic link is created: MyApp -> /Applications/MyAppFolder/MyApp, the software application can never be moved from its original location. In this situation a relative symbolic link would not work either, i.e. MyApp -> ../MyApp, because if the application is renamed the link is no longer valid.
"Symbolic links rely exclusively on path information to locate a file. If you move a file somewhere on the same volume without replacing it, symbolic links to the file break while aliases do not. The only way to fix a symbolic link is to delete it and create a new one." -- Apple Documentation, Aliases and Symbolic Links.
Aliases can also be broken. As an example, if the following alias is created: MyApp > /Applications/MyFolder/MyApp, and the software is moved or renamed, the alias can break during a cloned hard-drive operation such as using Apple Software Restore. This behavior is caused by the alias using the file inode, which is different on a cloned system. Most readers are familiar with Apple Software Restore due to Mike Bombich's NetRestore application, which depends on ASR.
Paths in any installer have the potential to create havoc on a Mac OS X system. This problem can become especially significant in an enterprise infrastructure that uses network-based user directories.
Closely related to broken links, some applications may not allow for relocation of either the application or preferences. If relocated or renamed, the application may not launch or act as expected. As an example, DVD Studio Pro 3 does not allow relocation of the application. If an enterprise administrator moves or renames the application, unexpected behaviors may occur. Often an application cannot be updated, or in DVD Studio Pro's case, assets may not be found, preventing use of the application.
Applications should also not require installation at the root level of the hard drive. By limiting the placement of applications to certain directories, the application may not be able to be updated or function as expected. Installers should allow directory names that contain application files to be renamed, as well as support of special characters including spaces.
For example, Painter 7 installs the application at the root level of the hard drive. When attempting to upgrade the application, Painter 7 must still be installed at the top level of the hard drive. It cannot be upgraded if it is not. In an enterprise environment, installation directories cannot be limited in this way.
File attributes can be associated with files and folders in the Mac OS X file system. Most commonly, these attributes are found on files that use Carbon-based preference files. The developer tool, GetFileInfo can be used to find the type code, creator code, Finder attributes, creation date, and modification date. Some applications depend on these attributes to define configurations and application settings. The following tools do not preserve these File Attributes: Carbon Copy Cloner, cp, CpMac, ditto -rsrcFork, zip, radmind, and tar. The attributes are preserved with the Finder, Apple Remote Desktop, RsyncX, Path Finder, and Stuffit (.sit format only). This may become especially important if using a directory service for authentication and authorization on a Mac.
|
Now that I've talked about some of the problems that can arise when trying to distribute an application, how do you track an application that has one of these problems?
So, what method should an you use? Some of the factors to consider when deciding include:
File Buddy is a popular and very powerful file utility for the administrator who has moved from Mac OS 9 and Mac OS X. There are many features, including:
It also allows you to capture a snapshot of a hard drive before and after application installation and setup to detect differences. It uses file and folder attributes such as modification date and size; however, it does not use checksums when gathering differences.
A checksum is a value based on the contents of a set of constant data, such as files created or modified by an installer. Checksums are used to detect data integrity, which may not be caught using modification date and file size attributes. Additionally, it does not support owner and group file permissions. Ideally, due to security and accuracy concerns, the enterprise Information Technology administrator uses checksums when tracking installation and distributing software.
logGen is a freeware command-line utility. It can be used to detect file-system changes after a preference change or installation. It accomplishes this by utilizing a number of methods, but primarily uses the modification date and a checksum of each file. This tool is only compatible with Mac OS X 10.3 and above, due to some Perl modules that are missing in earlier versions.
To use the tool, take a baseline snapshot of the file system using the following command:
sudo /usr/local/sbin/logGen before snapshot.datAfter issuing this command, install the software or make modifications to the preference files. Then run the following command:
sudo /usr/local/sbin/logGen after snapshot.dat / before snapshot.dat > changes.txtAll changes are saved with this command to the file changes.txt. You can then review this file for any potential
problems.
radmind is a suite of command-line tools with
corresponding GUI tools that can be used to determine what was installed
by a particular installer. After initial setup of a managed client with
the basic system, i.e. baseline, the administrator can track any additional
installations and setups , i.e. overloads, with radmind. As a short example,
the radmind command-line tool fsdiff can be used:
fsdiff -C -c sha 1 -o /var/radmind/client/loadset.T /After checking file-system differences, the administrator can use the GUI Radmind Transcript Editor or favorite text editor to review a transcript of the complete install. The setup, including permissions, privileges, and files modified by the installer, can be examined.
Complex installations may require the use of advanced Unix tracking tools to determine the problems for an application if using the above tools does not provide the answer. Often, a file may not have the correct permissions, or may be located on the file system where a normal user cannot write.
The first tool in an enterprise administrator's toolkit is lsof. This tool lists information about files opened by processes. Two commands are of particular use:
lsof +D /Library/Preferenceslsof -c MailThe first command uses the +D option. Only files at the top of the directory and below are listed when opened by the process. Symbolic links are not followed with this command. When tracking a preference file, this command may be particularly useful.
The second command uses the first few characters provided by the -c option. If the command is not found, it will fall back to a regular expression. If you do not want to use the command line, a GUI utility, Sloth, can be used as a replacement.
The next tool after using lsof, is the command-line tool fs_usage. This presents an ongoing display of system-call-usage information pertaining to file-system activity. It is more advanced than lsof as it uses kernel-level tracing. Here's how:
fs_usage -w -f filesys [cmd] | grep -v CACHE_HITLet's deconstruct this command a little bit. The first switch, -w, forces a wider, more-detailed output. It is not restricted by the size of the terminal window. The next switch -f filesys instructs fs_usage to only track file-system output, not any network-related output. The [cmd] is the name of the command invoked within the application bundle. It may be easier to use the Process ID (PID) instead. The entire command is then filtered through a Unix pipe, | grep -v CACHE_HIT. This eliminates any potential cached hits, and makes the output more readable.
The last, and most complete tool is ktrace. This command tracks every kernel call at the lowest level. Once tracing is enabled on a process, trace data will be logged until either the process exits or the trace point is cleared. If left running, large amounts of data can be generated and quickly disable a system if left unchecked. As an example:
ktrace -ti [pid]This command will trace all kernel input/output operations and put it in a file ktrace.out. This file can only be read with the command-line utility
kdump. Issuing the following command will create a file that can be read with your favorite text editor: kdump > tracefile.txt. This file can be analyzed; however, it is not as easily dissected as the above file.
One important note, is that ktrace must be manually stopped after it is started. The command:
ktrace -Cwill stop all kernel tracing. If you do not issue this command, the ktrace.out file may grow unchecked until the hard drive space is filled entirely.
Many of the problems listed above can be analyzed and tracked with the methods I've presented. They are intended to be general guidelines to help the enterprise administrator overcome problematic applications.
Philip Rinehart is a member of the steering committee leading the Mac OS X Lab Deployment Project (www.macosxlabs.org) and manages Macs as a support specialist at Yale University.
Return to MacDevCenter.com.
Copyright © 2009 O'Reilly Media, Inc.