NB: Slight Digression Follows!! If you are not installing across the network the following few paragraphs will not directly apply to you. However, they may be relevant to your network environment beyond mosix, so you might as well read them anyway.
If you are installing across an internet connection and there is not a proxy cache server on your local subnet, I would suggest that you configure a squid proxy cache server as your first order of business. If you have a number of users on your local network, even 15 or so, it would be a good idea to configure a squid server as be a permanent addition to your network, and for that server to be independent of the cluster. If you look around on the internet you will see a few articles about using mosix clusters as squid servers. If you want to do that, however, you should jump right past our initial configuration and implement our cluster around a 100 Mbps switch instead of a hub, make sure all of the cluster boxes have 100 mbps network cards, and install some fast hard drives on the cluster somewhere to hold the cache. If, however, you also intend to incorporate the uses I am incorporating into this cluster (i.e., fax server, database cluster), you should implement the squid cluster seperately, because those other uses will seriously impede the operation of the squid cache.
The critical factors in the operation of a squid cache are the amount of memory in the machine and the speed of the hard drives that hold the cache, because the memory holds references to cache hits and the cache on the drive, of course, holds the stored cache data. The squid server I have running here, servicing a modest population, is a pentium 100 with 160 Mb. RAM, with the cache housed on a two-drive, soon to be three drive, RAID 0 stripe set on an independent SCSI channel. None of these elements represent impressive hardware requirements. If you were to consistently use that machine for other purposes, you would degrade its effectiveness as a cache by causing the contents of RAM to be flushed to disk and by occupying the disk cache with something other than the characteristics of the cache on the drive.
If you don't currently have a squid cache, I'd suggest that you construct one now. If the population you serve is of modest size, a pentium 100 - pentium 200 with 128 Mb. RAM would be sufficient as a base machine. If you have an available SCSI adapter and some older, smallish SCSI drives, put them in, configure as RAID 0, and use them to house the cache. But even if you have no intention of implementing squid for long-term use, configure the first machine as a squid server. My reasoning will be apparent soon. More information on configuring squid can be found here.
End Digression
At this point, the installation script will ask if wish to continue with package installation. You should, of course, answer yes. You will be asked to choose between easy and hard versions of package selection. Unless you are constrained by disk space, go ahead and choose the easy option and select a reasonable variety of packages. If you are installing the cluster controller I would suggest installing a fairly full set of packages. My personal strategy is to select various network-related packages and the complete X-windows system. My rationale is to get as complete a set of libraries as possible during the initial installation, which can be relevant when building packages at a later point.
The script then allows you to select a location, generally close to you, for package retrieval. I've found that academic sites are best when school is not in session, but that is very much a generalization. i've found that academic sites are best when school is not in session, but that is very much a generalization. My current favorites are debian.uchicago.edu and debian.crosslink.net, but ymmv (your mileage might vary).
The script will then connect to the file source and retrieve the set of scripts you specified, writing them to a cache on your local machine, and the setup of the packages on your local machine will begin. It is quite likely that you will be asked some questions about package configuration to which you don't know the answer. Don't worry about it, just select whatever default is offered. The chance that you could make a choice here that would cause you serious problems is small. These are almost invariably things that you can come back and reconfigure later.
X-windows
I will suggest that unless you are planning on doing a great deal of cluster configuration on the machine you are configuring now there is not much point in configuring an X server on any of the machines in the cluster. The debian version of X server configuration has difficulty dealing with older, legacy hardware, and even distributions like Redhat that have invested more in graphical environment tools have a great deal of difficulty when dealing with an old ISA video card with 1Mb. RAM. Given the nature of the machines on which I generally run Linux, the full X-windows environment is not exactly what you would term responsive. But it is misleading to frame the issue in such terms. Once past this stage of the setup it is rare that I work directly on the machine in question anyway, and it would be very unusual for one to log directly onto the cluster controller beyond what would be required for maintenance actions. That, however, does not mean that X windows apps are not pertinent to you and your Mosix environment. The Mosixview utility itself is an excellent example. For details on configuring and displaying X windows apps see the section Integrating Windows and Xwindows.