Re: dcfgtool and clones
On Jun 1, Kai Henningsen wrote
> cas@taz.net.au (Craig Sanders) wrote on 01.06.97 in <Pine.LNX.3.96.970601131035.335o-100000@siva.taz.net.au>:
>
> > The config database should be regarded as a convenience for
> > {pre,post}{inst,rm} scripts and /etc/init.d/ boot time scripts only.
>
> Well, that was what started the discussion, anyway. Then the general-admin-
> tool stuff merged with this discussion, and now everybody is talking about
> different things.
>
> I think we should try to separate these things out again.
>
> AFAIKT, we actually have three problems to solve:
>
> 1. We have configuration info in scripts. This makes those scripts hard to
> update.
>
> This is where the text db should come in. Programs and data should be
> separated. The scripts still need to be conffiles, because individual
> admins will sometimes want to do things differently, but a stock Debian
> system should not have any config data in scripts.
i agree.
>
> 2. We need a general system administration tool. Lots of other Unix and
> Unix-like Systems already have those, with varying quality. This thing
> should ideally be able to configure everything that is globally
> configurable on a Debian system, probably via modules provided by the
> packages, and be able to run in text mode, under X, and via the web.
> And it should not change the format of the configuration info, so
> people can avoid it alltogether, and can exchange configuration files
> with other systems.
i agree. but this is a realy huge task, and i know noby that has started
it. all other distributions have their own config files, don't support
all config files (or only restricted) or have some sort of templates
they sed to fill in konfig values to generate the config file.
the only one who might parse the real config files is linuxconf, but
their way is not acceptable (writing c code to parse) - that's too much
work.
> [2a. An individual-user version of this would be good, too. (The dotfile
> generator?)
> ]
again,. i agree.
> 3. We need a general way to separate configuration from installation. It
> should be possible to take all or part of a system's global
> configuration and put it on another system, either before the
> installation of the respective packages, or automatically during that
> installation.
>
> One of the things we should have is a single-floppy net-or-CD automatic
> install - make a customized floppy, put it in the machine, boot, go
> away, come back, and find the machine up and running, fully configured.
> Network administrators really need this feature, and even Windows has
> it. We ought to be able to do what Windows can!
i agree.
> Of course, these these three things ultimately need to be able to work
> together.
yes, but till now nobody showed me a reason why they should not. 2.)
would has to parse so many different and complex config files, it should
be _very_ easy to parse a simple list of name/value stored in the
textdb.
> So, let's try for some terminology, just so we know what we are talking
> about:
>
> 1. This thing essentially holds parameters for scripts. It's the
> PARAMETER DB.
>
> 2. This beast is the SYSADMIN TOOL.
>
> 3. And this is about AUTOMATED CONFIGURATION.
ok. terminology is the right way to go.
> Anyway, if we want to be able to do this, we need a name convention.
> Something like PDB_<package>_<whatever you like> might do. Otherwise, this
> is sure to break a script because a local var clashes with another
> package's config var.
there was a discussion to use path style names like
boot/verbose or network/interface/eth0 or network/route/default or
x11/start/xconsole ...
start to write a long list, where config values should go, so we can
discuss it (and there is a lot to discuss IMO (like : split the ifconfig
commands into several values ? i would like one big value)).
> I'm against the latter. Besides the problems you mentioned, it introduces
> interesting new ways in which this can break.
i agree. everything should work via the text db IMO.
regards, andreas
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: