An Advanced Guide to Enterprise Application Distributionby Philip Rinehart
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.
Global Preference Placement
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:
- The user scope: /Users/[username]/Library/Preferences
Placement of a preference file here limits it to a specific user.
- The host scope: /Library/Preferences
Placement of a preference file here limits it to all users of a machine.
- The network scope: /Network/Library/Preferences
Placement of a preference file allow all users of a network access.
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.
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.
Directory Location Limitations
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.
Pages: 1, 2