COAS: A Flexible Approach to System Administration Tools

Caldera is working on a new easy-to-use configuration tool for Linux. Mr. Kirch gives us the details.

COAS stands for Caldera Open
Administration System. It will be incorporated as the main
configuration tool in future versions of the OpenLinux
distribution.

For those who have never used OpenLinux, the tool we have
been using for quite a while is called LISA (Linux Installation and
System Administration), which is basically one huge shell script
using a modified version of the
dialog tool to interact with the
user. When we felt it was time to move on to something new, we of
course looked at what was already available. The only viable option
at that time seemed to be LinuxConf, which had quite a ways to go
before it would become useful. Since that time it has become much
better, but because we had already started work on COAS, we decided
to stick with it. Of course, we believe our concept is
better.

The source code to COAS is released under the GNU General
Public License. We feel our work might be useful to the Linux
community as a whole and we want to invite interested programmers,
administrators and users to participate in its development by
offering comments contributing patches or even modules.

Vertical Modularity

The main idea behind COAS is not to provide just another
administration tool, but an entire framework for writing one. From
the start, we wanted it to be a modular application where
assumptions about such things as system data representation, file
locations and dependencies are separated as much as possible from
user dialogs and vice versa. Ambitious as this goal may appear, our
main interest was the ability to easily adapt the tool to changes
in the underlying platform and in porting it to other Linux
platforms.

I like to call this vertical modularity, because it breaks up
the task of system administration into three layers. At the lowest
level are native system data files, such as /etc/passwd, /etc/hosts
or files that define the IP address for a particular network
interface.

On top of that, COAS implements an internal representation as
a kind of database. If this term made you jump in your seat and
shout, “Oh no, Mr. Bill, not a Linux Registry!”, please be
assured that this is definitely not what we want it to be. COAS is
supposed to be vi-administrator friendly. We want users to be able
to switch between COAS and vi (or Emacs) administration, because
even though we hope COAS will be useful for everyday tasks, it
cannot cover each and every feature of a system component.
(Consider the configuration monster incarnate,
sendmail--you can spend as much
time writing configuration software for it as Eric Allman keeps
churning out new features.)

The native system files will remain the primary source of
information. The COAS data model is strictly a run-time
representation of system data that attempts to hide the on-disk
representation from the upper layers. For instance, an
administration module for the BIND server should not have to bother
about where DNS zone files are located and how they are to be
parsed; all it needs is the list of DNS zones this server is a
primary or secondary name server for and the records they
contain.

Having an abstract data representation also allows for
alternate data access mechanisms. For example, our database engine
can store a change log of an administration session to a file,
which could then be distributed to other machines, thus allowing
for bulk updates. Also, there's the vague idea that COAS might one
day support remote access via LDAP or SNMP.

The top-most layer is the user interaction code. This code
drives the dialog with the user and controls what information is
displayed to the user at what time. It uses a standard set of
dialogs, provides on-line help, etc. We decided to use a scripting
language, Python, at this layer in order to allow for rapid
prototyping. In addition to this, wrapping all lower-level
functionality in Python classes and functions provides an
additional level of insulation that restricts the number of tricks
a programmer can pull. This may seem like a disadvantage to the
hackers among you, but it is truly a big plus when it comes to code
maintenance.

Horizontal Modularity

You may have guessed from my choice of the term “vertical
modularity” that there is also a horizontal one, and so there is.
Consider the following scenario: a security problem or other
misfeature requires you to update a component of your system, such
as the BIND name server. Alas, the update is from version 4.9 to
version 8.2, which uses an entirely different configuration file
format. We could now ask you to install an all-new version of our
administration tool in order to accommodate the new configuration
file format. On one hand, that is costly in terms of bandwidth. On
the other hand, making sure the tool operates properly with all
possible combinations of updates applied or not applied would be
rather time-consuming for us. The ideal solution would be to
package the DNS server administration module alongside our BIND
update.

We are attempting to accomplish the following: COAS lets you
rip out an entire module, including the data model definition,
Python code, message catalogs and so on, and replace it with a
different version. We have nicknamed these CLAMs, which is short
for Caldera Linux Administration Module (we invented the acronym
first and then decided on its meaning, in case you were
wondering).

Trending Topics

Webinar: 8 Signs You’re Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th

Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.