The things you're dependent on others to complete, are listed before the ones you do yourself... If you can, get #1 and #2 out of the way early.
  1. Get an IP address (an A record) allocated for the machine. Request an MX record at the same time. If the machine is a mail hub, ask that it be MX'd back to itself first, and MX'd to mta.service.uci.edu second. If it's a mail client machine, get it MX'd to its hub. Send the request to ucinet-noc@uci.edu.
  2. Get dcslib exported to the machine. Some facilities won't become available (or get upgraded), until after the first time the machine is rebooted with dcslib. The machine will generate many noisy e-mail messages to dcs, via cron, without dcslib. Send the dcslib-export request to ccs@hydra.acs.uci.edu
  3. If this is the first machine in the relevant workgroup, tailor 006-domainname, as appropriate. Here you tell autoinstall what the machine's YP domainname should be (or if it should not have YP at all). This file is really only needed on SGI's and DEC's. Sun's get their domainname passed automatically, as part of the boot sequence. If you're setting up lots of tiny YP domains, you're creating work.
  4. If this is the first machine in the relevant YP domain, tailor 010-is-NIS-server, as appropriate. Here you define the NIS master and NIS slaves, for the YP domain. NIS master's configuration is assisted, but not completed, by autoinstall (you must still populate the map-source-files under /NIS and run ypinit -m). NIS slave configuration is done completely by autoinstall, if the machine can bind to some other NIS server, in order to transfer the NIS maps, at install time.
  5. If this is the first machine in the relevant YP domain, tailor 010-mail-config, as appropriate. Here you define the name of the mail hub, and other mail-related things. The various configuration options this file allows, are described in some detail. There is a lot of choices - but there are also many simple examples. YP.hnet.uci.edu is a good example of a domain with an autoinstalled mail hub, and autoinstalled mail client machines. VL.nacs.uci.edu is a simple example of a domain with autoinstalled mail client machines, but with a non-autoinstalled mail hub ("hidden.hosts" is quite desirable in this case, but it's not absolutely required - which is particularly helpful if the mail hub wasn't configured with hidden.hosts. Note that a mail hub without hidden.hosts, having standard autoinstalled mail clients, will have problems processing .forward's that point at a mail client)
  6. If this is to be a mail client of a mail hub that has hidden.hosts support, add the name of this machine to the hidden.hosts file.
  7. If this is an upgrade of a previously autoinstalled machine, seriously consider running "check-stamp", to see what files have changed since the initial install. Seriously consider incorporating any changes that have been made to the machine, into the "after" script. Note that if "run-after" has been run, the changes run-after made will show up in check-stamp's output.
  8. If the machine has been up and in use, and 6 didn't apply, do a backup. If the machine was previously autoinstalled, you -may- be ok without a full backup, if you save the files listed by check-stamp. A full backup is still the safest bet, but the author usually just saves the things listed by check-stamp, and any filesystems check-stamp doesn't inspect - EG: /export/home.
  9. If the system to be installed has any data disks with data that needs to be kept, TURN THEM OFF, before installing. I know this is a pain, but it's the only way to be Really Sure nothing Bad will happen to the data. If you get in the habit of installing, without turning off data disks first, you'll be fine a very high percentage of the time, but eventually, you'll probably get bit.
  10. Move on to the system-specific autoinstall instructions, for Solaris 2.x, Linux, IRIX and/or Tru64 UNIX.
http://www.nacs.uci.edu/support/dcs/automation/Before-you-autoinstall.html