An Advanced Guide to Enterprise Application Distribution
Pages: 1, 2
Complex Tracking of Installations
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:
- Your technical ability.
- Do you want to use a GUI application or the command line?
- The accuracy of the tracking tool.
- The security verification method of the tracking tool.
- Ease of integration into your software distribution model.
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:
- Viewing file and folder info.
- Editing file and folder info.
- Finding files.
- Finding and fixing orphaned aliases.
- Removing unused files.
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.dat
After 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.txt
All changes are saved with this command to the file
changes.txt. You can then review this file for any potential
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/Preferences
lsof -c Mail
The 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_HIT
Let'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:
will 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.
Avoid tripwires with non-Apple Installers?
2004-08-27 08:31:36 richardglaser [View]