Advanced Strategy

By: Mike Kimball - Revised: 2006-06-28 devin


This strategy is recommended for advanced users who want more power and flexibility from RevRdist. The advantage of this setup its redundancy, its custom-fitting for each kind of machine in your lab, and its ease of updating software. It emphasizes the distfiles, by calling all software to be distributed (including its System components) with lines of code. The master images contain only the System software that will be on every machine. This method allows one to solve a whole set of new problems, discussed here.

Problems Solved by the Advanced Strategy

What if I have machines in different areas that have the same hardware but not the same software?
Because the image contains only the common System software for machines with the same hardware, the application software gets distributed via the distfiles; so you can have different distfiles for each location, a different software list for each. Or, you can even code a single distfile to distribute different software sets based on something like a Mac's IP address, using the built-in if/then capabilities of RevRdist.

What if the hardware is the same, but I have peripherals (i.e. scanner, external floppy drive, etc) on a few?
Again, the image contains only the common items, while any added software drivers can be distributed via the distfile(s); so you can either use different distfiles for each configuration, or code in the special cases.

What if I have different kinds of hardware in the same room?
You can have separate images for each machine type, so that the System software is appropriate; yet the distfiles can be almost identical if it must copy down the same software listing.

What if I have six different master images, but I don't want to copy all the apps to each one, wasting space on the server to have six copies of MS Office, Photoshop, Lightwave, etc?
You don't have to - you can keep just one copy of each, put it in a "Special Items" folder, and call it with code in your distfile.
All applications, or additional GUI or System enhancements, go in a separate folder called "Special Items" (or whatever you want). Because each particular application and its system components go in a separate folder, one can keep old versions as well as add new versions. Only a change of the code in the distfiles is needed to update software in the machines. With the help of BBEdit's find and replace capabilities (with multiple file searching) you can easily substitute whole code fragments on numerous distfiles. Just as easily, you can reverse the process.

Basically, it is much easier to manage the code redundancy than redundant files on multiple master images. Once you set up the code in one distfile, new distfiles can easily be made by duplicating one, then making minor changes/additions.

One big question we get is why we have so many different images and of course distfiles and prefs; wouldn't it be easier to use a universal system, or maybe just have one big folder and use a lot of "Ad" lines of code. Well, the reason we like having more than one image is so that we don't have a single point of failure. What if your image gets corrupted by problems with the server? What if you make a mistake and it gets distributed to every single machine you support? By having an image for each type of machine (and often each different location), it gives us a comfort zone of redundancy so that if one image gets messed up it is fairly easy to recreate the parts from another. Also, we don't particularly like a lot of "Ad" lines in our code ;) There are ton of other good reasons to do things this way... like, it keeps machine groups separated better which gives you flexibility in testing situations... Mostly, we prefer that our system software be geared for the particular machine so we can get the best performance and stability possible.

Recently, with the addition of the PSU Theory page, we have learned and added the if/then capability to our distfiles, so that we can reduce the number we have to maintain. We like the balance - we still use separate distfiles, but we can use code to handle the minor differences that occur within a machine group (for instance, our group of Blue and White G3's has special code for scanner software on one machine, or Quark 4.11 and its dongles on two machines).

How To

Let's say you have a room with fifty Macs of varying vintages in it. You want all fifty to have the same configuration of software, same appearance. You want to Clean the machines every day and get rid of all the Garbage that people put on them. And you don't want to do it by hand.

The problem is you have beige G3's mixed with iMacs, mixed with G3 blue & whites, mixed with G4's... You cannot use the same System Folder for all of them because they have different System components, treat various System preferences differently, etc. Further, you don't want to copy Microsoft Office 2001 into four or five separate image folders. Or maybe you're evaluating Office 2001 and want to go back to Office 98 easily if you find it necessary.

Create a master image
A master image is simply a folder on a server, which contains the exact contents that you want all your Hard Drives to have (i.e. System Folder, Applications, Documents, etc). In this case your images will only contain the System Folder, and empty folders for the root-level folders "Applications", "Documents", etc. Remember that RevRdist can't "create" a folder simply through lines of code in the distfile, it has to be copied from somewhere. So, you have to put the folder in your image, even if it is empty. Again, make sure that your master image contains all System software you want, and looks exactly as you want it to look - RevRdist will duplicate it exactly. See below:

Contents of RevRdist Monkey : PowerMac G4/500 Mac OS 9.1
G4 master image

As for all your application software and its System Folder components (i.e. any Control Panels, Extensions, or Preferences it installs), put these in a separate folder on your server, named something like "Special Items". Then you can have separate folders for "Microsoft Office 98" and "Microsoft Office 2001". See below:

RevRdist Monkey : Special Items : Applications
Special Items : Applications folder
We arrange everything inside these folders hierarchically even further, so that the folder for the Office apps is in its own "Applications" folder, while all its System components are in a "System Folder" (this is very useful for keeping track of what System components get installed with what applications). See below:

RevRdist Monkey : Special Items : Applications : Microsoft Office 2001
Special Items : Applications : Microsoft Office 2001 folder

From here it's a simple matter of adding code to the distfiles to copy these items onto the machine as it runs RevRdist.

Settings you shouldn't set
Do not use the Setup Assistant to give the machine a name. You actually want the Owner Name and Computer Name in the System file to be blank when you copy it to the master folder. Otherwise, when you distribute it to all your machines, they'll all think their names are "Macintosh HD" or something, and will produce an error on startup. See the ResEdit Hacks section on how to fix this after the fact.

If you are assigning IP addresses manually, you probably shouldn't include this preferences file in your master image, and should make sure there's a line of code in your distfile that ignores it.

Create a read-only user account
RevRdist needs an account with read rights to the server folder where your master image resides. DO NOT USE AN ADMIN OR EQUIVALENT ACCOUNT. (Believe me, I've seen people do this.) RevRdist does not modify anything on the server, it only executes the instructions in the distribution control file (distfile).

RevRdist application and preferences
The two items that sit on the individual client machines and do the synchronizing are the application, and the preferences file.

See our downloads page to download RevRdist and RevrDist documentation.

RevRdist Prefs
You have to tell the prefs file how to log in, where the distfile is, where the master image is, etc. The RevRdist app itself can create this pref file, but we usually just duplicate an existing one and then use ResEdit to change the one or two settings that are different. (Go to ResEdit Hacks page for download info.)

Open RevRdist Prefs with ResEditOpen the RevRdist Prefs file in ResEdit, and find the STR resource (selected in picture to left). Double-click on this resource icon.

Open RevRdist Prefs STR Resource with ResEditTo configure the settings, double-click on the item you wish to set (as with the Password resource, selected here).

All of the resource windows look like this one (this is the "Directives file" resource; simply enter the path to your RevRdist distfile):

Open RevRdist Prefs Settings with ResEdit

Distribution control file (distfile)
This is the set of directives that RevRdist uses to determine what gets copied, deleted, ignored, or modified on the client machine. It can be created with a text editor such as SimpleText, though we definitely prefer BBEdit (Lite version is free) due to its extra functions (such as multiple-file find and replace, which we use constantly to manage our distfiles). This document will reside on the server. Writing the distfile is explained in greater detail on the distfiles page.

Once you are sure you have all the settings in your image, distfile, and prefs file configured correctly, just put the RevRdist app and Prefs file on your test machine (both should be in the same folder, but will run from anywhere on your hard drive). Double-click the RevRdist app (but only if the prefs file is named "RevRdist Prefs", otherwise just drag and drop the pref file on the app). Wait for it to run and then restart, and check to see if the machine looks as it should and contains all the proper software. Run a web browser to test networking, run the major apps to test that they work right (i.e. prefs, licensing, etc).


See our downloads page to download our advanced RevRdist template. Contains RevRdist applications, example distfiles and prefs files, sample RevRdist Server folder hierarchy, custom Hard Disk icons, a ReadMe explaining the examples, and bookmarks to this site and Purdue's site.