Bryan wrote:
> 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 use a small script called "hack" I wrote many moons ago. I uses RCS to
maintain backup copies of all files you edit/hack in a backup directory.
This way I have an audit trail for all the changes I make to the system.
You could combine this with the auto-install to regenerate a complete
system,
down to the specific config file changes you make or create with hack. The
auto-install process would blast the system down, then the auto-hack process
would blast down the above and beyond changes/additions.
> 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.
I think this would be nice to do, but kind of tough. That means that a
package creator will have to think about each variable she creates and
whether or not it could be considered for use in another package. Sure
enough, package-specific ones will wind up with a use in an as-yet-to-be
package. Then what ?
Obvious ones like "webmaster" and "domain name" are easy and can be used
in several packages. Hmmm, perhaps we could use the deb format style of
"Provides" ?
> 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: "[EMAIL PROTECTED]"
I like the begin and end tags. This would allow the parser to simply grab
all the lines between the tags and dump them to the display, maintaining the
formatting. It also allows for lists of values, one per line, to be easily
parsed out.
For example,
<query__exim__domain-name>
What is the domain name of this system ?
</query__exim__domain-name>
<resp__exim__domain-name> <optional tags> <more options>
debian.org
</resp__exim__domain-name>
A tag beginning with "query__" indicates the question to ask the user. A
tag
with "resp__" is a default answer, or perhaps the script to run to generate
it.
That's another thing I was toying with - a special option that indicates the
value is another script to be run. This would be for values that are not
simply
placed in a file, but need to be generated on the fly. This could even be
a socket connection to another machine to get the values (if networking is
configured :)
<snippage>
> 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.
Good point.
Looks like the following need to get done ...
1. Create a definition for the install-response files. This would have
the definitions for the tags to use, possible options for the tags
and naming conventions. Also specific mandatory tags, like version.
Each package would be updated to include an install-response file
in the deb. These would all get installed to a specific directory,
(say) /etc/debian-install-info.
3. Create the bash/C functions or parser script to query the
install-response
files. This should be able to run the "executable answers" as necessary
if
indicated to by the tags.
4. Update each packages' install scripts to use the install-response files
and
attendant functions. Use Tony Mancill's "NON_INTERACTIVE" type to
indicate
that they should attempt auto-install. Perhaps they should anyway ?
After an interactive install (as normal) one could simply copy and edit the
files
in /etc/debian-install-info as required. Then tar/gzip them up and copy
that
file to the install diskette. Shouldn't be too big.
During an install, if the NON_INTERACTIVE flag was set, or even if the
tar/gzip
file exists on the diskette, the install process would untar this into a
specific
directory in the ramdisk. Then the package install scripts use the parser
script/functions to query their own install-response file in that directory
for
the answers to their config questions.
Like Bryan, my time is pretty severely constrained, but I would like to work
on
this. It definitely needs more thought, and I think it has great promise.
Anyone
else interested ?
--
Dean Carpenter [EMAIL PROTECTED]
94 TT :) [EMAIL PROTECTED]
