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.

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:

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. . .

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.

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.

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.

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.

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.

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.

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.