Ghost In The Machine
Volume Number: 21 (2005)
Issue Number: 5
Column Tag: Programming
The Source Hound
Ghost In The Machine
by Dean Shavit
"The mind is not a non-physical substance residing in the body, 'a ghost in a machine,' but a set of
capacities and abilities belonging to the body."
Gilbert Ryle, Concept of Mind (1949)
Mea Culpa
First, before I go any further, I have to say the following: I am a liar. In last month's Source Hound, I
promised to bring MacTech readers an investigation into Tiger Server's new extended permissions a.k.a. Access
Control Lists. While I am sure that I could have "bitten into the topic" with the Source Hound's special
flair, it appears that Ed Marzcak, my fellow columnist, had an ace up his sleeve, so he'll be covering Tiger
Server's ACLs.
One of Us, One of Us
If you've ever worked in corporate IT, the verb "Ghost" (as in 'to Ghost') is sure to conjure up an image
familiar to many, that of a Help Desk Analyst, floppy disk in hand, with a big smile on their face: "So, your
PC giving you a bit of the 'ol trouble no, well , go have yourself a cup of coffee and when you come back,
it'll all be right as rain." One reboot later, a few keystrokes, and the Windows PC is back to pristine
condition, barring no hardware trouble. It's magic.
Cloning hard drives has been the standard in corporate PC support and rollouts since the mid 1990s. It's a
great way to cut the installation times for the Windows Operating System and applications down to minutes in
some cases, rather than hours. Network home directories or "roaming" profiles, where the users' data resides
on a server, rather than the local workstation, makes cloning almost standard operating procedure for fixing
even the smallest of software glitches. While the "Imagists" are often thought of as a school of modern poets,
whose ranks included William Carlos Williams and T.S. Eliot, today "imagists" are a highly-skilled
loosely-knit group of tradesmen (and women) who spend their days managing a single image--operating system and
software (sometimes referred to as a "standard image") that gets deployed onto dozens, hundreds, or even
thousands of similar PCs.
The verb "Ghost" comes from the same type of lexical twist as calling every variety of Cola a "Coke."
Symantec, the maker of antivirus and disk utilities for the Macintosh purchased the Ghost hard disk imaging
solution from Binary Research Limited in June of 1998. As a defacto standard in the IT world, Ghost was and
still is the preferred cloning solution for Windows PCs. At the time, I remember more than one person
inquiring as to why Symantec didn't ship a Mac version of Ghost, since Symantec was a company that heavily
supported the Mac with Symantec Anti-Virus (now Norton Anti-Virus) and the indispensable Norton Utilities
suite of disk tools. The standard answer to that question was "with the Mac OS, you don't need to clone
systems, as you can simply drag and drop a System Folder from the network or even pre-installed applications."
That indeed was true. At the time, all you really needed to clone a Mac OS system and all applications was a
SCSI hard drive big enough to hold everything.
In My Image
Working with images of floppy disks was nothing new to the Mac OS, even in the late 1990s. Until System
8.1, for example, Apple's installer technology used self-mounting disk images on the offhand chance someone
would actually need to produce the nineteen floppy disks to install System 7.5.3 on, let's say, a PowerBook
5300 without a CD-ROM drive. Utilities such as DART (Disk Archiving Tool) and Disk Copy became more
commonplace as installers grew larger and larger as Apple maintained compatibility between Macs with floppy
drives and those with CD-ROMs.
Eventually, Apple did away with the floppy drive altogether, and now, with the retail release of OS X 10.4
Tiger shipping only on DVD-ROM, Apple is trying to do away with the CD-ROM as installer media as well. This is
a pattern that repeats itself every time a type of media becomes unwieldy. It was not uncommon, for example,
that an iMac or PowerMac G4 shipping in 2001 with OS 9.2.2 and OS X 10.1 would have a set of six or more
restore CDs included. Running the software restore sequence would put the computer back into factory condition
with all bundled software included. For those of us who were curious about the restore process, a little
investigating led us to discover a nifty program called ASR (Apple Software Restore) hidden away on the first
restore CD.
Figure 1. Classic Mac OS Disk Copy and ASR, Circa 2001
Those of us who played with the Classic Mac OS version of ASR found it could do some interesting things for
deploying many Macs at the same time. In late 2001, I used ASR to roll out 35 iMacs at a customer's site in a
single day. I prepped a single iMac and tested it for a while, made tweaks and updates until everyone agreed
that it was ready, then used ASR to clone it to the rest of the iMacs using Firewire Target Disk mode.
The Ghost Reappeareth
Prior to the release of OS X 10.2, ASR (v1.1) was available only upon "special request" from an Apple
System Engineer or an AppleCare representative. This first and unsupported version of ASR had a pretty short
life span, because by the time August of 2002 had rolled around, Apple released OS X 10.2, along with a spiffy
new version of Disk Copy and ASR as a supported command-line tool (Disk Copy was later rolled into Disk
Utility with OS X 10.3).
It was about this time that I re-discovered ASR as a useful tool for cloning Macs, mostly out of need for
refreshing our ten training Macs at our office. At first, I'd set up NetInstall (which, by the way, deserves
another look in Tiger Server) but had found it slow and awkward, even though I was able to automate the
installation of OS X and several applications. ASR, it turned out, was exactly what I needed.
Like Peanut Butter and Chocolate
By itself, ASR is the "Peanut Butter" of the cloning process, and without disk images, the "chocolate," is
only really useful for making a quick down-and-dirty copy of a hard disk, as I'd done back in 2001 with the 35
iMacs. But this is still a great thing. Let's take the retail Tiger Install DVD, for example. If you have a
number of Macs without the ability to read a DVD drive, your only alternative is to order the $19.95 CD media
exchange kit directly from Apple. This is hardly convenient. Not only that, you'll still have to swap out
three or four CDs during the installation.
The solution to this dilemma's rather simple. You'll need to insert the Mac OS X Tiger install DVD into a
computer, and attach a Firewire hard drive, making sure to uncheck the "Ignore Ownership on This Volume"
checkbox in the "Get Info" window of the disk. If you don't want to use up all of the space on the Firewire
drive, you might want to partition it beforehand, setting aside 4.2 gigs for the installation files. Insert
the Installation DVD, attach the Firewire Drive, and issue the following command in the Terminal:
classadmin:~ classadmin$ sudo asr -source /Volumes/Mac\ OS\ X\ Install\ DVD/ -target
/Volumes/Firewire/ -erase
Password:
Validating target...done
Validating source...done
Erase contents of /dev/disk2s10 (/Volumes/Firewire)? [ny]: y
Erasing target device /dev/disk2s10...done
Validating sizes...done
Restoring ....10....20....30....40....50....60....70....80....90....100
Remounting target volume...done
classadmin:~ classadmin$
Note the presence of the -erase flag in the ASR command. This is very important. Without the -erase flag,
ASR will perform a file copy rather than a block copy, which will copy items "in place," overwriting folders
that exist with folders of the same name from the install source, yet leaving in place any other extant
folders. Not only can this potentially be messy, it can also be disastrous if you accidentally miscalculate
what's going to be installed or think that somehow the source and destination will "merge." Possible data loss
aside, the file copy or "restore in place" is going to be much slower than the fast block-level copy that the
-erase flag enables. Using the block-copy, the whole process takes exactly nine minutes. Now, you can boot off
of the Firewire disk by holding down the option key at boot time or selecting it in the Startup Disk System
Preference (double-clicking the black "Install OS X" icon in the Finder won't work) and run that upgrade
installation or archive-and-install or nuke-and-pave (erase and install) right from that same Firewire drive
at an installation speed that'll average less than ten minutes. If you've got a lot of installations to do,
and don't want to use a standard image, using a Firewire drive instead of the DVD drive is a real timesaver
Hey Tiger, Your Ectoplasm is Showing!
One of the new "features" of Tiger is a change in the way the Finder handles invisible files. Many of us
veteran cloners have noticed that the ".hidden" file that lived at the root of the startup disk in previous
version of OSX, has been sloughed off in favor of "genuine Mac OS 9 style" invisibility flags. While the
".hidden" file was a pretty elegant solution, allowing Mac admins to specify additional invisible folders such
as /sw for Fink (http://fink.sourceforge.net) installations. What is rather inelegant, and at first glance
pretty spooky, is what happens after OS X 10.4 is cloned--the formerly invisible links to /etc, /var, /tmp, and
the /Volumes directory (and perhaps all of the rest, as in the figure below) become visible. To fix this, a
cloner either needs to recreate the .hidden file (which is still respected by OS X 10.4) with the tmp, var,
etc and Volumes entries, of course making sure to set the proper permissions when finished, or follow Apple's
instructions, which requires having the Mac OS X Installation DVD inserted:
Figure 2. Ectoplasm On
Figure 3. Ectoplasm Off
Using a .hidden file:
\imacg4:/ mostadmin$ sudo vi .hidden
Password:
etc
var
tmp
Volumes
imacg4:/ sudo chmod 444 .hidden
Using Apple's Directions from Knowledge base article number 30167:
classadmins:~ classadmin$ cd /Volumes/Mac\ OS\ X\ Install\ DVD/System/Installation/
Packages/OSInstall.mpkg/Contents/Resources/
classadmins: /Volumes/Mac OS X Install DVD/System/Installation/Packages/OSInstall.mpkg/
Contents/Resources classadmin$ sudo ./SetHidden /Volumes/Mac\ OS\ X\ Install\ DVD\ 1/
hidden_MacOS9
Password:
set invisible: "/Volumes/Mac OS X Install DVD 1/bin"
set invisible: "/Volumes/Mac OS X Install DVD 1/dev"
set invisible: "/Volumes/Mac OS X Install DVD 1/etc"
set invisible: "/Volumes/Mac OS X Install DVD 1/mach"
set invisible: "/Volumes/Mac OS X Install DVD 1/mach_kernel"
set invisible: "/Volumes/Mac OS X Install DVD 1/private"
set invisible: "/Volumes/Mac OS X Install DVD 1/sbin"
set invisible: "/Volumes/Mac OS X Install DVD 1/tmp"
set invisible: "/Volumes/Mac OS X Install DVD 1/usr"
set invisible: "/Volumes/Mac OS X Install DVD 1/var"
set invisible: "/Volumes/Mac OS X Install DVD 1/Volumes"
set invisible: "/Volumes/Mac OS X Install DVD 1/Desktop DB"
set invisible: "/Volumes/Mac OS X Install DVD 1/Desktop DF"
set invisible: "/Volumes/Mac OS X Install DVD 1/.Trashes"
Whew! That's a lot of typing to stuff that Ectoplasm back into the ghostly area of the OS, as it should be.
However, don't try running this command on the current startup disk before making your image! Can you say
instant kernel panic? I can! Evidently Apple engineers haven't yet found a way to incorporate the
"hidden_MacOS9" attributes into the imaging process, which brings us to the our next point: exactly what is
the proper process to prepare a clone-able disk image for use for Tiger?
Ghosts of Images Past, Present, and Future
Up until the release of Tiger, the answer to that question was very straightforward: use Mike Bombich's
amazing Carbon Copy Cloner (http://www.bombich.com), which could automate several steps of the imaging
process, and which is also, by the way, considered by many (myself included) to be one of the greatest
AppleScript Studio Applications in existence. Carbon Copy Cloner also alleviated the need to boot off of
another drive to make the disk image, saving some time in that regard. However, due to some drastic changes to
the way AppleScript Studio handles authentication in Tiger, as well as some Tiger-specific imaging issues,
such as the yucky ectoplasm above, Carbon Copy Cloner no longer works, although you can run it from a Mac
booted from OS X 10.3 to clone a drive with 10.4 on it. Though Bombich is working on an update to CCC for
Tiger, which we'll hopefully see soon, it's also useful to step through the process of creating an image using
Apple's Disk Utility.
Step 1: Preparing to Make an Image
In last Month's MacTech, Clay Williams' excellent article "An Introduction to Builds, Creating Them and
Using Them in Mac OS X" gave an overview of the process of creating an image for a deployment. While we're not
going to concentrate on the nuances of building the "perfect" image here (which is an art form unto itself),
let's just say that there's certain "gotchas" to look out for prior to cloning multiple Macs.
1. Make sure none of the applications on your image require individual serial numbers. Often these will
check the network and will simply complain and quit if they detect other copies of themselves running.
2. Make sure you build your image on the newest, fastest Mac you can get your hands on. It'll make the
imaging process snappier, as well as ensure that all of the proper driver-level support is in place for newer
hardware, as well as the old.
3. Create your users accounts after the cloning process, unless you absolutely have no other way to deploy
the Macs. I'm not necessarily talking about the "admin" user that's on every Mac, but more so about the
end-user. The main reason for this is to avoid the "ByHost" preferences issue where the wrong Ethernet
hardware address is embedded in the .plist files. If you need to fix this issue post-imaging, you can download
a nifty perl script from: http://www.occam.com/tools (updatebyhostprefs) which can fix this issue post-cloning
if you don't have network user accounts or can't/don't want to create local accounts after the fact.
4. Make sure you clean up your Mac properly before imaging it and try not to "use" it too much between
making images so that the log files, for example, don't reflect spurious information from the "master" imaging
Mac. If necessary, force a log rotation by running the weekly maintenance process:
Dual2ghz:/etc/periodic/weekly dean$ sudo ./500.weekly
Then removing any archived log files:
Dual2ghz:/ dean$ sudo rm /var/log/*gz
5. Another good practice is to "tag" your image with a small text file to identify it, who built it, what
the imaging date was, and any other notes that might help you or others you work with remember when/who/did
what. I favor naming the text file with a ".log" extension and saving it in the /Library/Logs folder in order
to check it with the Console Utility.
Step 2: Creating the Image
In order to effectively make an image from the disk you want to clone, you'll have to boot your Master Mac
from another drive, either an external Firewire disk (another Mac in target disk mode will also work quite
well) or another partition (I've seen G5s with two 160 gig drives all partitioned up just for this purpose),
or, if you just want to go really slow, from the OS X Tiger Install DVD (but you'll still need another drive
or partition to save your image on).
1. Open Disk Utility located in /Applications/Utilities, first, select your master disk on the left-hand
side and make sure that "Repair Disk Permissions is not grayed out. If it is, you'll need to uncheck the
"Ignore Ownership on this Volume" checkbox choose File > New > Disk Image from Folder. . .
Figure 4. Ignore Ownership toggle in "Get Info" Window
2. Choose the Folder you want to image, in this case, it'll be /Volumes/YourMasterDrive. Do not choose
"Disk Image from Device," as that could wreak havoc with the ASR restore process later on. The "From Folder"
option results in a disk image with a flexible partition size that can easily fit the drive you're imaging to.
The "From Device" option will cause the restore process to revert to a file copy process rather than a block
copy that will slow things down, and might result in unexpected volumes sizes on older version of OS X. For
the type of image, choose "Read/Write." Normally, we'd go straight to "Compressed" which is both compress and
read-only. But we've got to nuke the ectoplasm first. . . so it's another step for us. . . wait until the
image finishes, then go ahead and scrub the ectoplasm by creating a .hidden file, or issuing the command from
Apple knowledge base article number 30167 (after inserting the Tiger Install DVD). If you then unmount/remount
the disk image, you'll see that all's well again, no ghostly remnants.
Figure 5. New Image from Folder
3. In Disk Utility, click the "Convert" button and choose the image you just created. For the format,
choose "compressed," and give it a slightly different name if saving into the same location, like
"image_compressed.dmg." Go grab a beverage or several, depending on the size of your image. When done
compressing, you'll notice that the image, if a base install of OS X 10.4.1, has shrunk to 1.5 gigabytes all
the way down from 3.5 gigabytes.
4. Once done converting, we've got to prep or "scan" the image for ASR. This process double-checksums the
image and aligns all of the blocks for the fastest possible restore times, and, new to Tiger, is the multicast
option. So, regardless if you don't know what multicast streaming is, or if you think you're going to be
imaging Tiger, read on, and make sure you use Disk Utility from OS X 10.4 for the next step (though you should
be using it for all of the steps). Go to the Images > Scan Image for Restore. . . menu item and select your
compressed image. Time for a beverage run. Once you're done, you've got an ASR-ready disk image.
Figure 6. Scanning Image for ASR Successful
But first, before we go off willy-nilly imaging and restoring every single Mac in sight, let's savor the
taste of these two great tastes that taste great together, and look into a few other uses for the "chocolate"
goodies that we can make with our Disk Utility.
Other Uses for Disk Images
Disk images aren't just useful for cloning or duplicating. You'll find that applications that don't require
authentication for installation are often distributed on disk images (.dmgs) for drag-and-drop easiness. Even
compressed .dmgs don't require an external helper application to open and mount the downloaded file. But
beyond the standard distribute-it-on-a-.dmg practice, there are other great uses for disk images that would
otherwise require third-party software or even extra disk drives.
Backup: using a combination of hdiutil, cron, and psync or rsync, you can keep a bootable clone of your
hard drive-up-to date as often as you'd like. It's also a great way to "preserve" a configuration of a hard
disk before an upgrade (as I did before upgrading to Tiger on my PowerBook) or before sending in a Mac for a
hard drive replacement, allowing for a restore to that exact configuration, if the upgrade doesn't go exactly
as planned. A compressed disk image is also a nice alternative to .zip archive for long-term file archiving or
electronic transfer if you know for sure that it'll be opened on another Mac. A backup script such as the one
below will keep a bootable image in sync on a schedule with cron or when double clicked, if wrapped in an
AppleScript as below:
do shell script "hdiutil attach '/Volumes/MAC_BACKUP/Macintosh_HD.sparseimage'"
do shell script "/usr/bin/runpsync -d '/Users/$USER'
'/Volumes/Mac_HD/Users/$USER'" with administrator privileges
set disk to do shell script "diskutil list|grep Mac_HD|awk
'{print $5}'"
do shell script "hdiutil detach /dev/" & disk
A couple of things to watch out for are to make sure that the .sparseimage is initially created to be big
enough to encompass all of the data it might eventually hold, and also that the like which contains the "awk"
statement is properly adjusted based on the capacity of the disk, and the version of diskutil you're using,
whether it be Panther or Tiger.
Security: using the 128-bit AES encryption capability of hdiutil or Disk Utility, you'll be able to store
the most sensitive files in a virtually unbreakable cipher. Apple's own FileVault, by the way, uses a
combination of the growable .sparseimage format with the AES-128 cipher, but is actually less secure because
the password's the same as the login password by default, can be unlocked with the system's "Master" password,
and is also stored in the login keychain. For the most secure settings, create a standalone AES-128 encrypted
disk image, and never save the password in your keychain.
A safe, FAT haven for your HFS files: Recently, with the price of large (one gigabyte and bigger) keychain
(USB) flash drives coming down to below $100 or even $49, they've become viable as a data transfer tool,
quickie backup device, or even a data recovery or troubleshooting tool. However, in these days of OS X
applications that don't have resource forks or create documents with resource forks, it easy to sometimes
forget that nearly all of these USB drives come formatted with the FAT16 file system, which is still
unfriendly to Classic Mac Applications, as well as Postscript Fonts, and QuarkXpress Documents, just to name a
few. If you copy a file from your Mac to a FAT16 keychain drive, you'll separate the resource forks of the
files and find that your Applications, Fonts, and other document may be trashed beyond the point of
recoverability. One way around this problem is to format your USB drive with the HFS+ file system using Disk
Utility, however, this prohibits the flash drive from ever being used with a Windows or Linux computer. I
simply created a "sparseimage" on my USB keychain drive. A sparseimage is the a disk image with a "growable"
filesystem. When you create a sparseimage, you have to specify the maximum size it can grow to, but it won't
reach that size unless you fill it up. Now, when you attach your USB drive to a Mac, simply double-click the
sparseimage to mount it. Put your Mac files in there, and you'll enjoy the best of both worlds, without having
to reformat your USB drive.
Prepping for Emulators: often installing an emulator such as PearPC (http://www.pearpc.net) or Qemu
(http://fabrice.bellard.free.fr/qemu), or even Mini vMmac (http://minivmac.sourceforge.net) for those who want
a Mac Plus emulated under OS X requires a blank hard disk image to begin installation of an operating system
or host the applications.
Figure 7. Mini vMac Emulator
Disk Utility is Apple's way of churning out blank filesystems that can be in various formats, including
UFS, HFS+ with case sensitivity, FAT32, UFS (UNIX File System) or even free space, so that your chosen
emulator can recognize and re-format if its chosen filesystem (like NTFS, for example) isn't directly
supported by Disk Utility. Simply create a new read-write disk image, mount it, and treat it just like any
other disk! Here's a quick tip for emulation fans: don't try the sparseimage format with an emulator, it won't
work.
Figure 8. File System Options in Disk Utility
Burning: just about any CD-ROM or DVD-ROM (single layer) that mounts under Mac OS X is a candidate for
burning. Even though the Tiger's Burn Folders have made it quicker to make multiple copies of CDs or DVDs,
nothing's quicker than using Disk Utility to burn disk images, since OS X preps the burn session as a disk
image anyway, increasing processing time. If there are discs that need to be distributed, it's easier to burn
them as needed from disk images rather than from another optical disc or from a folder. A multiple-session CD
or DVD is also possible with the "Leave disc appendable" option--simply burn additional disk images to the
media until you run out of space. Note that ISO-9660 format (used for cross-platform discs) doesn't support
multiple sessions.
Figure 9. Burn Options in Disk Utility
Ready, Set, Ghost!
OK, I know you're all excited about what we can do with disk images. Now it's time to start slinging them
via ASR. I'll start with the simplest, most straightforward way. Of course, if you're going to be wiping out
an entire disk with the contents of another, it should be pretty clear that the drive that's going to be
imaged can't be "in use," so I'll have to boot from another disk. In this first example, I'll work from a Mac
that's got the hard disk of an iBook mounted in target disk mode. The image is coming from a server volume.
It's a simple process to drag the source image into the "Source" section of the "Restore" tab in Disk Utility,
tell it to erase the destination, and viola, in just a few minutes I have a perfect clone from my image.
Figure 10. Using ASR from Disk Utility
Alternately, you can boot from the OS X Installer DVD and grab the .dmg from a Firewire drive, then use the
"Restore" tab in Disk Utility to image the target drive, but booting from the Installation DVD is quite slow,
so you'd even be better off booting from a Firewire disk that had the Installation DVD copied to it as in our
very first ASR example. If you're a little more hard core than that, you can always do it the via the CLI:
powermacg4:~ classadmin$ sudo asr -source ~/Desktop/System_asr.dmg -target /Volumes/Firewire/
-noverify -erase
Password:
Validating target...done
Validating source...done
Erase contents of /dev/disk1s10 (/Volumes/Firewire)? [ny]: y
Erasing target device /dev/disk1s10...done
Retrieving scan information...done
Validating sizes...done
Restoring ....10....20....30....40....50....60....70....80....90....100
Remounting target volume...done
There's absolutely nothing wrong with using "a different" hard disk to boot from and then clone your target
disk. If you're deploying new machines, right out of the box, it can be a pretty efficient way to go, though
you'll have to do one or two or three at a time. However, in some Mass Deployment situations, it's helpful to
be able to "re-image" Macs say, at a semester break during a school year without having to go from machine to
machine. If that's the case, then you're going to need to use NetBoot, of which the setup details, I'm sorry
to say, are far beyond the scope of this article. However, if you've used NetBoot to re-image or deploy a lot
of Macs, you'll know that running ASR over afp (Apple Filing Protocol) can put quite a drag on your network,
with each additional ASR session taking up more and more bandwidth until all slow to a crawl.
The New Black
Luckily for us, Apple's been thinking a little ahead, and has, with Tiger, given us a new form of ASR: the
multicast server. Mutlicasting is based on the concept of a group. The multicast "data stream" (often video or
audio) is broadcast one way to a group of addresses that fall in between 224.0.0.0 to 239.255.255.255, or
what's also referred to as the class "D" IP address space. If you've ever heard of a "broadcast storm" you're
not far from the concept of a multicast. Therefore, except for special networks such as the Multicast backbone
or "mbone," multicasting is not allowed on the Internet. Basically, a multicast is a continuous, one-way
stream of data that a group of clients tap into to receive that data stream, and because the mutlicast is
delivered to all clients willing to accept it, it can move data much more efficiently than session-oriented
afp connections.
While multicast ASR isn't going to help with the requirement to "boot from another disk" or to NetBoot, it
could make the process of deploying multiple Macs much faster than ever before. I decided to put multicast ASR
through its paces to see how well it worked in the early releases of Tiger. First, I was delighted to find
that the ASR multicast server does not require OS X Server, but does require that the ASR multicast client be
booted from a Tiger disk. That doesn't mean, for example, that the image being multicast couldn't be OS X
10.3, or even OS 9 for that matter.
The steps for setting up an ASR multicast server are rather simple. First, prepare the image as in the
instructions above, but if using an image prepared under Disk Utility for OS X 10.3, be sure to scan the image
for ASR again, which will make it multicast compatible. Then, setup the server from the CLI:
imacg4:~ mostadmin$ defaults write ~/Desktop/asrcast "Data Rate" -int 3000000
imacg4:~ mostadmin$ defaults write ~/Desktop/asrcast "Multicast Address" 224.0.0.123
imacg4:~ mostadmin$ defaults write ~/Desktop/asrcast "DNS Service Discovery" -bool true
Note that although the man page for ASR suggests that you create the ".plist" file (asrcast in the example
above) in the /tmp directory, I've had problems with that, so I just throw it on my desktop or in another
folder. The two required settings govern the rate of the multicast, which is very important for both
performance and "network safety," which I'll get to in a minute. The second is the multicast address that the
server uses. That's not the address for the client to connect to, however, but note that third, optional
setting "DNS Service Discovery" -bool true, which activates Bonjour (a.k.a Rendezvous or Zeroconf) for the
multicast server. Once all those are entered, the multicast server can be started with:
imacg4:~ mostadmin$ sudo asr -source ~/system_asr.dmg -server ~/Desktop/asrcast.plist/
Password:
Multicast server configuration:
DNS Service Discovery: true
Data Rate: 3000000
Multicast Address: 224.0.0.123
Ready to start accepting clients
Starting stream Tues May 31 05:09:31 2005
And the multicast client, when ready to connect can do it this way:
classadmins-power-mac-g4:~ classadmin$ sudo asr -source asr://imacg4.local -target
/Volumes/System -noverify -erase
Password:
Validating target...done
Validating source...done
Erase contents of /dev/disk0s3 (/Volumes/System)? [ny]: y
Erasing target device /dev/disk0s3...done
Retrieving scan information...done
Validating sizes...done
Restoring ....10....20....30....40....50....60....70....80....90....100
Remounting target volume...done
It's interesting how well that works: even if the ASR multicast server has a dynamic IP address, you can
connect to it by its "computername.local" if you've enabled the "DNS Service Discovery" setting, but then that
only works on your local subnet, which incidentally, is where the ASR multicast would most likely be
contained, unless multicast forwarding has been properly configured on your LAN.
Multicast Ups/Downs
After giving ASR mutlicast a workout, I've come to several conclusions, none of which are very surprising.
At its peak performance, a multicast ASR restore is a little bit faster than a single restore over an afp
connection or even a locally attached Firewire disk. The difference is really apparent, however, when you run
several concurrent multicast restores, which all take virtually the same amount of time as a single restore,
whereas the afp restores start to bog. I could see, that under ideal conditions, multicast ASR could cut the
restore times by nearly 75% for a group of 100 network-booted Macs, depending on the size of the image.
Yet running an ASR multicast server isn't without its pitfalls. You have to carefully evaluate how much
multicast traffic your LAN can handle. . . as I found out when I first fired up my multicast server. A tcpdump
of the network interface of all of the computers in my lab revealed the following multicast traffic:
04:05:58.625372 IP 192.168.0.90.55035 > 224.0.0.123.7800: UDP, length: 1466
04:05:58.626846 IP 192.168.0.90.55035 > 224.0.0.123.7800: UDP, length: 1466
04:05:58.628306 IP 192.168.0.90.55035 > 224.0.0.123.7800: UDP, length: 1466
04:05:58.629778 IP 192.168.0.90.55035 > 224.0.0.123.7800: UDP, length: 1466
04:05:58.631251 IP 192.168.0.90.55035 > 224.0.0.123.7800: UDP, length: 1466
04:05:58.632740 IP 192.168.0.90.55035 > 224.0.0.123.7800: UDP, length: 1466
04:05:58.634217 IP 192.168.0.90.55035 > 224.0.0.123.7800: UDP, length: 1466
04:05:58.635730 IP 192.168.0.90.55035 > 224.0.0.123.7800: UDP, length: 1466
04:05:58.637169 IP 192.168.0.90.55035 > 224.0.0.123.7800: UDP, length: 1466
04:05:58.638630 IP 192.168.0.90.55035 > 224.0.0.123.7800: UDP, length: 1466
04:05:58.640113 IP 192.168.0.90.55035 > 224.0.0.123.7800: UDP, length: 1466
04:05:58.641579 IP 192.168.0.90.55035 > 224.0.0.123.7800: UDP, length: 1466
04:05:58.647351 IP 192.168.0.90.55035 > 224.0.0.123.7800: UDP, length: 1466
04:05:58.648753 IP 192.168.0.90.55035 > 224.0.0.123.7800: UDP, length: 1466
which seemed to be a little bit too much for some of our other network services such our 3Com NBX VOIP
phone system, which went offline, or my internal Nagios test server, which promptly emailed me the following
warning:
***** Nagios *****
Notification Type: PROBLEM
Service: current users
Host: nagitest
Address: 64.32.214.184
State: CRITICAL
Date/Time: Monday May 30 05:38:43 CDT 2005
Additional Info:
CHECK_NRPE: Socket timeout after 10 seconds
And then a minute or so after shutting off the multicast:
***** Nagios *****
Notification Type: RECOVERY
Service: current users
Host: nagitest
Address: 64.32.214.184
State: OK
Date/Time: Monday May 30 05:43:22 CDT 2005
Additional Info:
USERS OK - 1 users currently logged in
Other anomalies included DNS lookup timeouts, web pages that failed to load, as well as afp authentication
hangups. It seems that the multicast rate suggested by Apple in the ASR man page is a little too high for
practical use for the network at our office, so cutting it in half seemed to help somewhat, but realistically
it seemed safer to cut it to a third of the suggested rate, 2000000. Also, any other multicasting devices
(phone systems, video streaming, etc.,) or running two multicast servers simultaneously will absolutely kill
your network. Also to take under consideration is lowering the data rate at the client side to account for
Macs with slower hard drives, less RAM, or slower network connections. It's pretty obvious to me that ASR
multicast would be best run on an isolated switch or on a network where everyone had gone home for the day or
the weekend. It's a pretty harsh mistress.
In the Black
If you've followed along with me up to this point, you might have already formulated the question that'll I'll answer for you right now. Is ASR Open-Source software? The answer's a big en-oh. So what's the Source Hound doing writing about something not-open-source? Well, it's free, which is close enough for me. Oh, and did I fail to mention that Symantec Ghost starts at $69 a seat? Of course, the cost goes down with volume buys, but the last group of thirty licenses I purchased for a Windows customer came in at about $400, and who knows what the upgrade will cost when Longhorn arrives. Who was it that said Macs were more expensive than PCs?
In Next Month's Source Hound
If you think I like Open-Source software, tune in next month as I sit down for a virtual interview with the grand pubah of Mac Geekery, Drunkenbatman of Drunkenblog (http://www.drunkenblog.com). We'll be discussing a wide range of topics from Open-Source to software development at Apple, QuickTime 7, Intellectual Property and the GPL, and oh my! Everything, including the cow!
Dean Shavit is an ACSA (Apple Certified System Administrator) who loves to use a Mac, but hates
paying for software. Since he's not into breaking the law, his most common response to any cool solution is:
"Does that cost money?" If it does, you can bet he's on the hunt for an Open-Source or freeware alternative.
Besides surfing for hours, following the scent of great source code, he's a partner at MOST Training &
Consulting in Chicago, where he trains system administrators in OS X and OS X Server, conducts large-scale Mac
Deployment and Upgrade projects, and writes for his own website, http://www.themachelpdesk.com. If you have
questions or comments you can contact him: dean@macworkshops.com.
