[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dcfgtool and clones

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

   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

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

   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  

So, let's try for some terminology, just so we know what we are talking  

1. This thing essentially holds parameters for scripts. It's the

2. This beast is the SYSADMIN TOOL.


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:


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.


              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
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: