Mailinglist Archive: opensuse-edu (332 mails)

[Michael Brown <mbrown@xxxxxxxxxxxxxxxx>]

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=<server_name>" instead of just "f" at the
boot floppy screen.

[1] One neat trick we came up with is that you don't need to remove the
    floppy before rebooting - magic!  (Yes, I *am* lazy enough to find
    the need to remove floppy disks at specified times irritating!)

> > 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