[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SEUL: seul-db and high-level vs. low-level (fwd)
Regarding your mail on the seul-db, I agree with you to a point. The config
files that are there should really be used as is. In most cases, this is
possible. In reality, much of what we will be doing with the system-level
administration will be canned initially. When we have time, we may set it up
to deal with multiple levels of control over things, i.e. from clueless
newbie through unix-god.
I haven't really though too much about this yet. That's tomorrow, as I get
more in-depth with my walkthrough of the admin system of a typical
installation or two. In the meantime, here's a copy of a message from the
Linnet mailing list, complete with foreward. I haven't studied it too
carefully, but it has it's share of good and bad points, at least from the
POV of SEUL.
------- Forwarded Message
From: Brian Candler <B.Candler@pobox.com>
BTW, the reason I have not been saying anything here is that I have been
involved in a 50-mail-a-day discussion on debian-admintool, where I have
been trying to persuade them to adopt a good (i.e. linnet-like :-)
architecture.
My most recent attempt is below, and at the current moment in time it seems
that I _may_ have succeeded... but swings in position have been known before
:-)
- --
From: Brian Candler <B.Candler@pobox.com>
Subject: High-level and low-level datasets
To: debian-admintool@lists.debian.org
Date: Tue, 22 Jul 1997 15:03:45 +0100 (BST)
Resent-Message-ID: <"ZtkG_2.0.Vo5.flCrp"@debian>
Resent-From: debian-admintool@lists.debian.org
I would like to try and contribute something to the debate which may give a
framework for discussing and comparing the various options on the table.
To do this, I want to make a distinction between "high-level" configuration
and "low-level" configuration data. The "high-level" configuration is the
service that the sysadmin wants to set up, whilst the "low-level"
configuration is the implementation details required by the packages(s)
involved to perform that service. To give an example, using majordomo:
High-level configuration: (HL)
"A mailing list"
(specify name, owner, subscription and posting policies, members)
Low-level configuration: (LL)
A list of aliases for the list, owner-, -request etc
List parameters for majordomo
A list of members
In some cases, perhaps many, the two will be the same (e.g. for "What type
of mouse I have", "What port it is connected to", there is no HL/LL
distinction to be made). Note that at the moment I am not talking about the
format of the data nor where it is saved, just the data itself.
An admintool will presumably be concerned with presenting the system
configuration in the high-level form; otherwise it is just a "configuration
editor", and I think we can assume that this is not what we want.
So if this is clear, and given that the configuration must be persistent,
then the important question to me is: do we want to store the HL data or the
LL data?
1. STORING HIGH-LEVEL DATA
==========================
If the user enters configuration information in HL form, it can obviously be
stored in this form. Since standard Unix systems don't have a HL
configuration store, this necessitates the introduction of one (a database).
Conversion from HL->LL data, and from LL data->config files, are
straightforward processes. They can be implemented easily using generator
programs and/or templates (to simplify the writing of the generators), and
done together as a one-step process.
Since the HL data is stored, it is very easy to present it to the user
subsequently and allow it to be edited. Then, the simplest way to make
corresponding changes in the config files is to regenerate them.
+---------+
User <----> | HL data | ------> LL data -----> config files
+---------+
As long as the HL representation is sensible, a valid LL representation can
always be derived from it.
2. STORING LOW-LEVEL DATA
=========================
A standard Unix system falls into this class - it stores LL configuration
data inside config files.
It is very simple to convert LL data into config files (just write it out),
and it is pretty straightforward to extract LL data from config files (parse
it in). After all, the config file is just a physical representation of the
LL data: a text file in a format which the package author decided on.
LL config data _could_ be stored in a database; since the config files are
also needed anyway, this would amount to a duplication of the data. However
it _is_ possible to synchronise LL configuration between config files and
database entries, and this may give some benefit (e.g. the database is
easier to edit than a tarball of /etc).
+---------+ <-------> config files
...| LL data |
+---------+ <- - - -> LL database
HL configuration data is very easily converted into LL configuration. e.g. if
the user says "add a mailing list", this can be transformed into the LL
configuration items mechanically, and added into the LL configuration (e.g.
appended to config files)
However the same is not true in the reverse direction. Given the LL
information (e.g. list of aliases), it is very non-trivial to convert this
to a HL description.
Special code will have to be written to scan the LL data and work out what
HL data it represents, and it will be different for each type of HL data.
Its job is made complicated by the one-to-many relationship between HL and
LL data (e.g. one mailing list is represented by a bunch of aliases plus
majordomo configuration information). This job may be made completely
impossible if the LL data has been altered in such a way as to be
inconsistent with _any_ HL representation - for example, if an inexpert user
tries to rename a mailing list by changing the aliases but not the majordomo
config, or vice versa.
We can attempt to predict these inconsistencies and give the user the option
of "fixing" any which are found, but this starts to move into the realm of
expert systems. Alternatively, we can just complain that the system is
broken.
<---- HL data <----- +---------+ <-------> config files
User / \ | LL data |
------> ------> +---------+ <- - - -> LL database
3. STORAGE OF BOTH?
===================
There seems to be little point in storing both HL and LL representations of
the dataset, because they would have to be kept in sync. A prerequisite of
keeping the two in sync is that you are able to transform (altered) LL data
into HL data. However if you _are_ able to reliably transform LL data into
HL data, then there is no need to actually store the HL data because it can
always be regenerated on demand (case 2 above).
Actually, if you have a HL data store, and extract config files from it,
then you implicitly have a LL data store too (the config files themselves).
Whether this is really a "store" depends on whether you actually read data
back out of them or not. If you don't, then you are only using the HL data
store, which was case 1 above.
SOME PROPOSALS SO FAR
=====================
Craig's (and my) template proposal is an example of HL data storage, case 1.
LL data, in the form of config files, is extracted from the HL database,
using templates and/or generator programs. (The facility is there to
override this conversion and modify the LL configuration by editing the
templates).
Fernando was proposing config files marked up to make them easy to parse
into HL data, and so he was proposing either a LL data store (case 2), or a
HL database in addition to the marked up config files (case 3).
Bruce wants to see a system driven by the low-level data (case 2). His
solution to the "aliases problem" was to just store the raw aliases in the
database - in which case, this is again saying he wants to store LL data.
(Whether they are in a config file or a database is irrelevant: they are
still a LL representation of the configuration)
Linuxconf is an example of LL data storage in config files, deriving HL data
where required (case 2 again).
MY OWN THOUGHTS
===============
Having introduced what I hope is an objective way of looking at the
proposals, I'd just briefly like to add my own opinion to the end.
I am very strongly in favour of case (1) - the high level data store. This
is not because the LL approach cannot work, because clearly it can (witness
Linuxconf)
However, the job of converting HL into config files is very easy (simple
generators), and for a system which stores the HL config data (case 1), that
is all that is required.
In case (2), you need to have parsers to convert config files into LL data
(tedious), and then convertors for LL data into HL representation (very
complex). Not every package will require the same sort of work as majordomo,
of course, but equally I believe this is not an isolated case. Furthermore,
the interactions between packages will make modularisation very difficult
(i.e. the configuration of majordomo and sendmail are likely to be tightly
bound)
The net effect is that I believe the LL data store approach will take a LOT
more effort to implement. With a HL data store, each package maintainer
could maintain their own template/generator, or one person could maintain a
whole bunch of templates. With the LL data store, the admin module for a
single package itself becomes a major software undertaking, needing an
amount of work which starts to become comparable to the work invested in the
package which you are trying to provide an admintool for!
As a result of this, and finite programming resources for the admintool
itself, it may end up being
- not as powerful as we would like
- not as up-to-date as we would like (i.e. not able to take advantage of
new features when they are implemented in the actual packages)
- not as reliable as we would like
- not as slick or smart as we would like
- not have as many choices of user interface
I like the HL approach because the admintool then consists of a bunch of
small, standalone modules which each perform a simple task: the same
approach as Unix itself takes and which makes it so powerful. It is
conceivable that every Debian package could get an interface into the
admintool tool, _and_ the majority of user-contributed software too. With an
admintool which has at its core the storage and interpretation of the LL
data representation, I believe that this may not be true.
That's my primary argument. The primary argument AGAINST this position says:
"the admintool MUST work with configuration stored and altered in config
files, and therefore it must work with a LL representation of system
configuration."
It seems to me that this may become the overriding factor. If it is, I think
we will have a worse admintool as a result: one which self-fulfills the
prophecy that it is better to administer a system using vi. That will be
very sad if it happens.
Brian.
------- End of Forwarded Message
Erik Walthinsen - Programmer, webmaster, 3D artist, etc. __
__ / /\
/ \ omega@sequent.com Work: (503)578-5314 / / \
| | M E G A omega@aracnet.com Home: (503)281-4281 / / /\ \
_\ /_ psu12113@odin.cc.pdx.edu Majoring in CS / / /\ \ \
/ /_/__\ \ \
Omega Station: http://www.aracnet.com/~omega/ /________\ \ \
Info on Linux, Graphics, Descent, Laptops, etc. \___________\/
----------------------------------------------------------------------------
Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.
----------------------------------------------------------------------------