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

Re: Goals for 1.3?




On Mon, 23 Dec 1996, Bruce Perens wrote:

> Sourcing lots of shell files means you need to have a tool to generate
> little shell files 

The file with the default values to source in is supplied by the package.
To generate the file that the sysadmin is "allowed" to modify we
could simply copy the relevant section of the original file (maybe with
stripping off the comment). Not that hard.


> and a whole tree of little shell files wasting space,

Yes, thats a valid point. But it's not completely wasted as there is some
structure in the tree. That makes it easier to survey with standard
software like "ls".
The file "script-env.db" (the main database) only covers 4 (of ~60)
scripts currently and already has 6k of code. I expect that the "full"
version is about 100k and this amount is difficult to survey with a
standard editor.

One of my goals is to keep the system configurable without the need of
the upcoming "admintool".


> and no centralized management of configuration data,

Maybe I was a little bit to radical in posting a cgi for surfing around in
the database (read/write) and then stating I would not continue working 
on it because it's so bad.
I'm sorry if my mail lent to the impression I would discontinue to work on
the idea of using a centralized database. But "cfgdb" was a centralized
database for some environment variables only. Currently I'm working on
something more general that understands

        cfgmgr --print /admin/user("winni")

I already implemented it 2 month ago featuring all tricks I know in
shell-programming (not that much). [It's not robust enough for a
release.] With this tool it is still possible to distribute information
between different machines like

        rsh OTHERHOST cfgmgr --set /admin/user("winni") `cfgmgr --print /admin/user("winni")`

Just like "xauth".


> and no hierarchical organization of configuration data.

We don't have a hirarchical organization of configuration data but an
admintool needs something like that to present the configuration to the
user. So it's out of question that we must create one ourselves.

Hardcoding of this hierarchy into variable names used by some
shell-scripts in /etc/* can be seen as a feature or as a limitation. I see
it as a limitation and suggest to introduce a mapping between names of the
environment variables and the "configuration hierarchy".
As a result, it doesn't matter if we name a variable

        EXPIRE,
        SYSNEWS_EXPIRATION
or      /admin/expiration/sysnews/expire

I depreciate the last one because it would introduce a configuration
hierarchy local to the shell-scripts.


> It would be much better to have all of this information in one database.

This is easy if we limit ourselves to environment variables. It's still
doable for everything but the kitchen sink if we don't insist on a
physical database but see the contents behind the "Configuration
hierarchy" as a virtual database.
Something that is accessible via a configuration path like

        /admin/group("debian")

but without storing the information in any other file than /etc/group.
[Comments and so on have to be stored elsewhere.] The following scheme
describes my intentions:


                  +----------------------------------+
                  |                                  |
                  | A nameserver allows to use IP-   |
                  | addresses and hostnames.         |
                  |                                  |
                  |  1st nameserver ___.___.___.___  |
                  |  1nd nameserver ___.___.___.___  |
                  |  3rd nameserver ___.___.___.___  |
                  +----------------------------------+
                                   |
  +------------------------------------------------------------------+
  | WWW-Browser: lynx (builtin-cgi) or netscape (cgi requires httpd) |
  +------------------------------------------------------------------+
        \/                                                  /\
        \/  cgi-Standard                              html  /\
        \/                                                  /\
  +------------------------------------------------------------------+
  |                                                                  |
  |                     Presentation Manager                         |
  |                                                                  |
  +------------------------------------------------------------------+
        \/                   /\                         \/  /\
        \/     /dev/cfg      /\                         \/  /\
        \/                   /\                         \/  /\
  +-----------------------------------+           +------------------+
  |       Configuration Manager       |           |   Presentation   |
  |                                   |           |     Database     |
  *-----------*-------*---------------*           +------------------+
  | Databases | Files |  Runtime Data |
  +-----------------------------------+          Hierarchical namespace
        cfgdb   fstab    /proc/mounts               for variables
      ctlinnd   groups   ifconfig
         dpkg   fvmwrc   setserial



> You experimented with the SHELL version of cfgdb. No wonder it was much
> too slow! Once you are satisfied with the program it should be rewritten
> in C.

I'm aware of the fact that an interpreted script is much slower than
compiled code. Though, I do all my prototyping with scripts on a
very old 486 because they show up performance/design flaws.

It's simply not adequate to create static data on the fly. Who changes his
configuration more than twice a year?

 
>         . /etc/defaults/boot
>         . /etc/script-env/boot
> 
> PLEASE do not implement it this way.

"cfgmgr" does not mind how it is implemented. If the developers decide to
use "cfgdb" or whatever, it will be happy, too (using the approprecaite
"admin-plugin").


> Do not make it necessary to have hundreds of little files to run a
> Debian system.

If you are really concerned, we could put the default values into the
original shell-script and source the modified file only if it exist.
This should reduce the number of "little files" to somewhat below 20
(organised in a hierarchy).


> Do it in one database, with a program to hide the format of the database
> from the rest of the system.

That's no general solution. We just can't hide the format of /etc/passwd
from the rest of the system (if you know a way, please tell me; it saves
me lots of work).

Hiding usally means "create an interface". Nothing but our (yet to write)
admintool is currently compatible with that interface (based on
configuration paths shown above).


-Winfried


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com


Reply to: