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 textfiles. 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/ . Wichert. -- ============================================================================== 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:
pgp9f1JZHrnyo.pgp
Description: PGP signature