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

comparing COAS with our Configuration Management, part I

Apparently COAS is not as vapourware as I thought, and the next SuSe
release will use it. After attending a talk about COAS at SANE I
gave it some more thought to figure out if we can use it for our
configuration management problem.

What is COAS?
COAS (Caldera Open Administration System) is a system to help you configure
your computer. It interfaces directly with the various configuration files
and allows you to modify them. It does this in a very flexible way, allowing
for much freedom. It supports multiple frontends, multiple databases,
and can offer you templates to configure something.

What can we use?
Clearly COAS does a lot of things we do not need (or want) to use for
configuration management, since it tries to solve a different problem.
The database from COAS looks promising, and very flexible though. Also
COAS has a system for using multiple frontends (currently only ncurses)
which is also one of our goals. In this mail I'll only look at the
database, I'll cover the frontend later.

The database
COAS uses a design that is very similar to the design that was used
in our last Configuration Management text: they use a database engine
that uses various drivers (or mappers in COAS terminoligy) to get to
the real data. This results in a virtual database consisting if multiple
files. The mappers (I'll use COAS terminoligy when referring to COAS)
map real configuration files (passwd, httpd.conf, sendmail.mc) to
the virtual database. This means that modifying data in the database
also directly edits the real configuration files.

Can we use the database?
This is difficult question, since the COAS database was not designed
for our purpose. I'll go over a couple of things:
* COAS mappers directly use configuration files, which do not even exist
  when we install a package. We will have to write our own mappers/drivers.
* The COAS database does not support metadata. This means that we will
  have to store that somewhere else. However there is a simple solution
  for this: we already have a list with items in the database, which seems
  like a good place to store metadata. Especially since metadata is local
  to a system storing it locally makes sense IMHO.
* COAS currently does not support foreign databases. Again this is not really
  a problem, since it can simply be solved by creating a mapper for this.
* On the down side: COAS does not support data types, everything is encoded
  in strings, which is logical for them since they project the database to

So the only real problems are lack of data types and lack of metadata. Both
could probably be fixed by wrapping the COAS database engine in a new engine
that adds both features without too much problem.

More information for COAS can be found at http://www.coas.org/ .


This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: wakkerma@cs.leidenuniv.nl
WWW: http://www.wi.leidenuniv.nl/~wichert/

Attachment: pgpmRCIsowN4N.pgp
Description: PGP signature

Reply to: