Re: mass-installing Debian

[Bryan Andersen <bryan@visi.com>]

Illo de' Illis wrote:
> 
> On Wed, May 19, 1999 at 09:12:29AM -0700, Dean Carpenter wrote:
> > Now during installation, the exim preinst and postinst scripts would
> > source the install-response file, creating the variables with the
> > responses they need.  At this point, it's just as if they've asked the
> > questions and retrieved the user responses.  If a particular response
> > variable doesn't exist in the install-response file, the script can
> > still prompt just like normal, though this ruins the effect.
> 
> Hmm... and, if we run dselect, dpkg, apt-get or whatever it is without any
> system-wide configuration script, it could generate a skeleton file with the
> user's answers logged. This way we should be able to carefully configure the
> first machine, cut away the variable configuration fields from the generated
> configuration script, and feed the rest of the machines with it.

Or better yet, modify the variable parameters for each system, and get 
complete auto installs.  :)  I'd use this allot to generate "identical"
systems that vary only in name and IP.

I like the idea of a system install prompt answer file.  If parameters 
that are common to many packages get common names that all packages 
could share, this could even work better.  It would also be nice to 
allow some conditional parsing, possibly on the level of a simple C 
preprocessor, but that isn't needed for the initial versions.

One of the main reasons I would like to have this ability is for 
rebuilds of a system.  If you save the configuration file off to 
floppy, then you can rebuild the system quickly to the same state 
of your initial load.

A possible format for variables would be:

  <package>__<variable_name>: "<value>"

For a line that would look like:

  Apache_SSL__webmaster: "bryan@visi.com"

Notes: Convert "-" in package names to "_".  The "__" (double 
underscore) is for separating package name and variable name parts.  
If package name isn't needed as in the definition of a globally 
used value, then the "__" isn't used, and just the variable name 
is used.  Use quoting that is compatible with bash.

If a common set of bash shell functions and C functions are 
created, then programs could easily open and read the 
configuration in.  Then when they want to prompt for a value, 
the call the prompt function which looks up to see if it's 
already set.  It then uses that value, or it prompts.  I see
three main functions, load, prompt, and save.  Load reads in 
set of values.  Prompt searches for a value in the loaded set, 
if not found it prompts for the value.  Save dumps the set of 
vales out to a file if anything changed.

If in the above example there wasn't a definition for 
"Apache_SSL__webmaster", but there is a definition for 
"webmaster", then a call by the Apache-SSL configuration 
script would retrieve the value set for "webmaster".

There is a potential problem with package upgrades invalidating 
values sets.  For this I propose that when the file is generated, 
the package sets a variable with 

  <package>__Version: "<package_version>".  

For a line that would look like:

  Apache_SSL__Version: "1.3.6"

When a package reads in the settings, it can check the version 
tag to check for value set compatibility.

I'd volunteer time to work on this, but I'm embroiled in finding 
a way to compress the Tiger map data onto one CD.

-- 
|  Bryan Andersen   |   bryan@visi.com   |   http://softail.visi.com   |
| Buzzwords are like annoying little flies that deserve to be swatted. |
|   -Bryan Andersen                                                    |