[EMAIL PROTECTED] (Craig Sanders) wrote on 01.06.97 in <[EMAIL PROTECTED]>:
> 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.
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.
[2a. An individual-user version of this would be good, too. (The dotfile
generator?)
]
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!
Of course, these these three things ultimately need to be able to work
together.
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.
I sure hope this helps to get the discussion productive again!
Back to Craig (who is talking about the parameter db).
> All that is needed is a set of "key=value" pairs in a plain text file. Take
> a look at FreeBSD's /etc/sysconfig or NextStep's /etc/hostconfig for an
> example.
Well, mostly. A simple way to do arrays would be good, too (think network
interface setup, for example).
This can, of course, be done on top of simple variables, and I have done
so in another context, but as soon as you try to write, say, a tool to
admin this stuff, you need at least to have some conventions.
One way to do this:
XXXX_N=4
XXXX_1=value1
XXXX_2=value2
XXXX_3=value3
XXXX_4=value4
On the other hand ...
> This is not only simple to implement, but it is also simple to
> parse...and it allows the sysadmin to change the setup with
> vi/pico/ae/joe/emacs or whatever. Later, a GUI or web front end can be
> layered ON TOP of this.
... having a real array syntax makes this less error prone - imagine
someone adding XXXX_5=value5 and not changing XXXX_N to have 5 as value.
> parsing the files in shell is simple:
>
> source /etc/sysconfig
And on the third hand (hmmmm?), this argues against automatic arrays. I
don't know.
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.
> parsing it in perl is almost as easy. The following code fragment reads
> /etc/sysconfig into an associative array called $config.
>
> $sysconfig="/etc/sysconfig" ;
> open(SYSCONFIG,"$sysconfig") || die "can't open $sysconfig: $!\n" ;
>
> while (<SYSCONFIG>) {
> s/#.*$//; # strip out comments
> next if /^$/ ; # ignore blank lines
> ($variable, $value) = /^(.*)=(.*)/ ;
You might want to do something about spaces, too. And you may want to
allow # in values.
Maybe
/^\s*(\S+)\s*=\s*(\S.*?)\s*$/;
next unless defined $2;
($variable, $value) = ($1, $2);
This silently ignores syntax problems. Nothing this short can be perfect.
> $config{$variable} = $value ;
> } ;
>
> close(SYSCONFIG) ;
> print $config{hostname} ;
> print $config{ip_address} ;
If you're learning Perl, you might want to listen to the words of the
great guru (one L. Wall). You can debug your scripts faster if they all
start with these lines:
#! /usr/bin/perl -w
use strict;
However, this makes Perl complain about use of barewords such as the
above, I believe. (No, I haven't actually tested this.)
> So, a decision needs to be made: whether to allow only simple
> assignments or to also allow complicated assignments like
> "foo=`cat /etc/bar`". Parsing the former is easy in any scripting
> language. Parsing the latter could get quite difficult in languages
> other than sh.
I'm against the latter. Besides the problems you mentioned, it introduces
interesting new ways in which this can break.
MfG Kai
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
