On Fri, 1 Feb 2002, Chris Howells wrote:
Although the design document is incomplete beyond the specification, the code has passed proof of concept stage and is nearing alpha release. You might find this tool helpful; it's a lot easier to take a 'standard' distro and reconfigure it than it is to repackage everything with your desired configuration. :-) Right, this sounds very good :) Have you thought about perhaps taking a standard distro and adding this stuff to this, burning a CD and distributing it? This is pretty much what I want to do.
Historically we have always used network installs but there is no reason why it couldn't be burnt onto a CD.
You say that you can install a workstation by only presssing a few keys. Does this work on all distros (or even FreeBSD?)? If so, how?
The broad approach is start by doing a bare-minimum install that is fully
automated. Under Mandrake, this is achieved by playing around a little
with the standard boot disk and creating a small auto-install config file
that lists things like the packages to be installed, the default root
password (MD5 hashed, of course!) and specifies that all network settings
should come from DHCP. We can boot from a floppy, press "F", "Enter" and
after 2-5 minutes the system has done the minimal install, rebooted[1] and
is up and running on the network.
At this point, our configuration tool comes in: the workstation (or
server) will locate a source of configuration rules and proceed to install
any necessary additional software and set up any required configuration.
Assuming that all workstations in a school are identical, this means that
you just define the workstation configuration as the default. Servers may
have particular roles, so you would often need to specify their identity.
This is done by typing "fen id=
Kickstart is nowhere near flexible enough to be relied upon as a primary distribution method. Believe me; we have tried this type of method for some time and it is not adequate to the task. Essentially, it comes down to a concept flaw shared by many, many systems (including some that I have written myself): there is a reliance upon a known initial state. Ah right. Well, I don't really understand what you mean by this. Would you mind explaining a little more?
Simplest example is this: suppose you design your workstation configuration and use Kickstart (or similar) to roll it out to half of your 300 workstations. At this point, you realise you made a small mistake in the configuration. There is no easy way to use Kickstart to repair the mistake on the 150 workstations that have already been rolled out, short of rolling them out again (which is time-consuming). Basically, Kickstart is able to perform the transformation "empty machine->installed machine" but is unable to perform the transformation "installed machine->installed machine with slightly different configuration". (Of course, Kickstart and other programs such as Ghost or DrakX were never intended to carry out the latter transformation). The "reliance upon a known initial state" is a more general problem. As an example, consider the following two methods of configuring a new Samba installation: 1. In /etc/smb.conf: Comment out the netlogon share definition In [homes], add the line "user = %S" In [global], add the line "map to guest = Bad User" vs. 2. In /etc/smb.conf: Ensure that the [netlogon] share definition is commented out Ensure that the [homes] share has the setting "user = %S" Ensure that the [global] setting "map to guest" exists and is set to "Bad User" The latter is more flexible; we don't need to worry about what state the smb.conf file is in before we apply the configuration. If we make a mistake in the configuration then we simply change it and reapply it - we probably don't need to do an "undo changes" operation first. We can apply the second method to every machine on a network without worrying that some of them might have already had it applied. If you rely on an initial state then your code will be less robust. Well-written applications will be able to run without requiring any per-user setup first; they will simply create configuration files as necessary. Poorly-written applications (such as most Win32 applications!) will insist on having things like registry entries created by a setup utility before the application is run. Michael