...during an initial autoinstall, "after" creates a backup copy of the magic files. For example, /etc/group's backup file is named /etc/group.original. If /etc/group did not exist, then /etc/group.original would not be created. When "run-after" is invoked, it restores each of these files to their right-off-the-CD content (from the .original's), and begins making additions to these "fresh" versions. Obviously, this can be something of an annoyance - it increases the need to coordinate with DCS - because you end up dropping us a note every time you've changed or added a file in a machine's system directories. However, overall, it is believed by some that this can save you (and us) considerable effort, despite the coordination overhead. The benefits are: Every change to these files is logged somewhere. This is something the very best admins have always done meticulously. It means that If the system disk dies, we needn't scratch our heads wondering what used to be there - even if the system disk is not backed up!. It also allows a system disk to be rebuilt quite quickly - against a fairly arbitrary OS release. This makes upgrades a snap - their cost is both lessened, and distributed over time - instead of letting upgrades remain one large, painful upheaval that in practice ends up being put off longer (often much longer) than it should. Restated, these procedures tend to make keeping a machine current on OS releases, a relatively painless operation. If there is a pattern to the changes that need to be made to each machine of a domain, those changes can be easily automated. Algorithmically, at a rather high level of detail, run-after will: Copy each magic file (EG /etc/inetd.conf) to a ".previous" file (EG /etc/inetd.conf.previous). Copy each magic file's .original (EG /etc/inetd.conf.original) file back over the magic file (EG /etc/inetd.conf). Do what run-after does, roaming around making useful modifications to system files, including the magic files. Many of these changes will simply re-add things that were in the magic file (EG /etc/inetd.conf), and that are still in the .previous file (EG /etc/inetd.conf.previous). Near the end of run-after, it will will compare each magic file (EG /etc/inetd.conf) with its corresponding .previous file (EG /etc/inetd.conf.previous). If there are any differences, it will: beep, and output a diff (diff -u, more specifically) to the terminal save a copy of that diff under /var/adm/run-after-log, EG /var/adm/run-after/log/inetd.conf.diff. Each step performed by run-after is saved in a file called /var/adm/run-after-log/output. If you are leary of the effects of "run-after", you can create a file named "/var/adm/no-run-after". If this file exists, run-after will cat it to the terminal, and exit early without changing anything. If a situation arises that makes run-after problematic, I recommend putting a description of the circumstances in /var/adm/no-run-after, using your favorite text editor. The author sometimes chooses to do this, though not for extended periods of time.