COAS white paper draft
COAS Technical Notes
Introduction
============
This white paper discusses design and architecture principles of the
Caldera Open Administration System. It is intended to give a high
level view of features of the system which would be useful for
potential developers or plug-in module authors. An exhaustive SDK
for the system will be available shortly from Caldera's web site.
It should be noted that not all of the features in the document are
implemented or currently available in the COAS framework.
Why is Caldera working on a new administration system for Linux:
================================================================
Linux is increasingly renowned as a stable and robust operating system
solution. However, managing and administering a Linux system is a complex
task. For many sub-systems of Linux, there is no administration tool
at all (except for vi).
In many other cases, where tools do exist for certain administration
tasks, they exhibit a number of possible weaknesses: Since different tools
come from different sources, they present inconsistent user interfaces,
and have differing approaches to common configuration tasks. The level
of features, quality and robustness of various administration tools also
differs. Finally, many tools have technical limitations, and reflect
only the author's method of configuring a particular item on the system.
Unified administration systems are available for many other Unix and
non-Unix OS platforms. This fact raises the bar of acceptability for
Linux. A good administration system is something that Caldera customers
require in order for Linux to be accepted as a mainstream, commercially
viable OS.
Caldera is committed to providing a solution to this problem, both for
its current and potential customers, and also for the Linux community
as a whole. Caldera has thus designed the Caldera Open Administration
System.
Main goals of the system:
=========================
Unified administration tool
---------------------------
COAS is intended to serve as a single unified administration system
for a Linux-based machine. The benefit of having a single tool
is that a consistent user interface and method of operation can be
presented to end-users and system administrators. This will reduce
the amount of learning required to perform new administration tasks
once the user is familiar with the system.
COAS uses a modular approach, where additional administration tools can
be added to the system in an ad hoc fashion. Administration modules,
called CLAMs, can be installed into (or updated, or removed from) the
system without recompiling. Administration modules can be written in
either a compiled or interpreted language, and will be described in
greater detail later.
COAS supports multiple user interfaces for the same administration
tasks, so that administrators can choose the most comfortable
environment for their work. Some users prefer command line operation,
while others may prefer a graphical user interface environment. Still
others may require that administration be performed remotely. COAS will
support all these different environments, and will thus suite the needs
of a wide range of administrators' perferences and work habits.
Ease of Use
-----------
COAS has several mechanisms which will make it easy to use. Several
levels of online help are provided, including general task-level help,
as well as item-specific context sensitive help. The system includes
facilities for validating the consistency and syntactical correctness
of configuration data. Also, the user interfaces are internationalized
so that translations for different languages will be available for
menus, dialogs, and on-line help.
Finally, COAS will provide information about what it is doing, and how
it is doing it when it performs administration tasks. For example, it
will be possible to see what native configuration files will be affected
by a proposed edit. It is hoped that the availability of this type of
information will help users (who wish to) understand more about the
internal workings of their Linux system.
Scalable
--------
It is intended that COAS will be able to handle large system administration
tasks. Features of the architecture, such as the ability to provide
a module in natively compiled format, and demand-loading of required
code and data, make it possible for the system to remain responsive
and performant even when performing large administration tasks.
Backwards Comptible
-------------------
It is simply not feasible for Caldera (or any other organization) to
dictate a change in format or location for configuration data on a Linux
system. COAS supports backwards compatibility with current
administration practices by keeping the primary persistent copy of
configuration data in its original file. Where possible, COAS will be
editor-friendly by preserving formatting and comments in the original
file, and by locking the files to prevent concurrent access. Modules for
COAS should be able to read and manipulate the full set of options and
syntaxes for configuration data files. They should not need to add
warning messages ("don't edit this file by hand") to the files that they
manipulate. This means that administrators can choose to use COAS for
certain difficult administration tasks, without losing the ability to
also edit configuration files directly.
Broad in Scope
--------------
Caldera will provide the COAS infrastructure, as well as many important
modules, in order to provide a substantial arsenal of administration
tools and capabilities. Caldera is firmly committed to the COAS project,
and will continue developing and enhancing COAS in the ensuing years.
However, the success of Linux has demonstrated that a concerted
community-oriented effort to attack a particular need can result in a
reduced time to complete the project, as well as improve the breadth and
quality of the resulting work. Caldera intends for COAS to encompass the
widest possible set of administration tasks, and provide a premiere,
commercial-grade administration tool for the Linux OS.
Community Oriented
------------------
The source code for the COAS project will be released completely under
the GNU Public License. Caldera will provide a Software Development Kit
(SDK) for COAS, documenting the module interfaces, as well as provide
additional important technical documentation for developers. Also,
Caldera will provide internet-based developer support, including a web
site, a mailing list, and regular, announced source releases. A module
certification process and translation services may also be provided,
in order to ensure that community-contributed modules have the same
high quality and universal applicability as modules developed by Caldera.
Outside development is encouraged (indeed, solicited) for work on the
core system, and especially on administration modules.
To the degree possible, development for and use of COAS will be
supported on non-Caldera distributions of Linux. Several features of the
system will support file placement and administration policy differences
between the various extant and popular Linux distributions.
Module Licensing Note
---------------------
Individual modules that plug into COAS may be released under a license
of the author's choosing. This means that propriertary administration
modules may be written and made available in the case where a company or
organization wishes to keep its configuration mechanisms and data
private. In most cases, it is expected that an interpreted language will
be used for COAS modules. However, the tool also supports the use of a
compiled language, which allows for implementation and data details of
an administration module to be kept undisclosed to the general community.
Architecture highlights:
========================
Caldera Loadable Administration Module
--------------------------------------
COAS itself provides a framework into which plug-in administration
modules can be installed. An administration module consists of the
code and data required to perform a set of related administration
tasks (such as editing user and group accounts). Each module will
be called a CLAM (for "Caldera Loadable Administration Module"), and
will consist of the following components:
- a schema definition
- a mapper
- a configurator
- message catalogs
- consistency and activation scripts (optional)
The code for a module may be written in Python (a popular
object-oriented, interpreted language), C++, or both.
The COAS framework will provide an important set of base services
available to all administration modules (such as demand loading of
configuration data, per-module persistent data handling (explained
below), logging of administrator actions, etc.) All COAS modules
will thus automatically have a powerful set of features important
for administration work.
The central COAS program includes the facilities for data manipulation
and tracking, as well as the embedded Python interpreter, and
a generic user interface API.
Each of the parts of a CLAM, as well as other of the facilities provided
by COAS will be described next.
Schema Definition
-----------------
Each CLAM will provide a schema definition file, which provides a single
logical presentation of the data that is manipulated by that module.
For example, the USERS CLAM would provide a file which described what
fields make up a user account, what values each of the fields could
have, and where to find this information on a Linux system.
This definition is written in a schema definition language (newly
created by Caldera). This language allows a module to declare the data
relationship, structure, and other attributes of its configuration data,
and somewhat resembles C type and structure declaration syntax. Some of
the other attributes of configuration data which can be expressed by
this language are:
- syntactical correctness (ie for a particular piece of data,
the language can specify a valid numeric range,
a set of legal values, a regular expressions that
strings must match, etc.)
- default values (when new items are created, what values should
be used for certain fields)
- source file (what native configuration file does a particular
piece of data come from)
In some regards, the schema definition file serves the same purpose for
COAS as does a "MIB" for SNMP management systems. Isolating the data
representation from the rest of the COAS system provides a few important
benefits, including support for referencing configuration data elements
using a single canonical path. While a CLAM configurator might provide
one view of the administration data (in dialogs), other views of the
data (like a tree view) can be constructed automatically. Also, COAS
will support non-interactive (command line) references to individual
configuration items.
The relationships defined by the schema definition file are used to
construct a tree of configuration information, internal to COAS, which
we call the "data model". The data model is actually expressed as two
parallel trees of nodes, representing the schema for the configuration
data, and the actual values (instances) of configuration data items.
Mappers
-------
A mapper is the piece of code in a module which is responsible for
converting configuration data from its original format and file into the
format described by the schema definition (and vice versa). User
interface code (in configurators, discussed next) is isolated from the
mechanisms for parsing and storing configuration data. Mappers perform
this function, and can utilize a library of high-level parsing and
formatting routines provided by COAS. Where possible, mappers will be
written which preserve the existing whitespace (formatting) and comments
of the original configuration file. It is anticipated that COAS will
also include several pre-built mapper classes, to provide newly created
mappers with routines to handle the most common configuration file
syntax and format styles.
Configurators
-------------
A configurator is the actual piece of code in a module which controls
the user interface for manipulating configuration data. It uses
a generic user interface API to present menus, dialogs and screens
which comprise the administration interaction. The generic API
allows a single configurator to be written which will provide the "same"
screens in either the character-based, X-based, or java interfaces.
Other interfaces can be supported in the future as well. Note that
this generic API is available in both C++ and Python.
Configurators instruct the user interface to bind controls (UI widgets)
to configuration data elements in the data model. The configuration code
is isolated from the native configuration data format and location, and
configurators can concentrate solely on the job of actually manipulating
the logical objects represented by the configuration data. Thus the
actual manipulation of configuration data is performed by a user through
the configurator.
However, another class of data exists for the administration system,
which is also manipulated by configurators. Besides data which represent
configuration information stored in regular configuration files, there
is a set of data items which represent important aspects of system
administration policy or preferences. Examples of these include: the
default group assignment policy for user creation, and the home
directory removal policy for user deletion. If managerial preferences
like these cannot be autodetected or stored elsewhere, COAS provides a
persistent repository where modules may store this data for ongoing
use. Thus COAS can be used not only to manage the machine's
configuration data, but also to retain and manage administrative
preferences and policy.
Besides standard module configurators, additional mechanisms will be
provided administrators for direct access to configuration data.
For example, COAS will support command line referencing and manipulation
of configuration data. This non-interactive mode is critical for COAS to
be able to support scripted (or batch) administration tasks. For example,
scripts can be written (either in Python or using any other Linux
programming facility) to perform large sequences of operations. One of
the most common of these would be to automate the creation or deletion
of large number of user accounts (eg in a University setting).
Core engine services
--------------------
The core engine (data model handler) will also provide many additional
services. Some of these services will be automatic, and some can be
optionally used by modules where they are pertinent. Some exmaples
include: logging, version control (not in the first release),
data consistency checks, general persistent data storage, and platform
detection.
CLAM development
================
Caldera and partner support
---------------------------
Caldera will be producing a number of CLAMs for the initial release
of COAS. These include modules to administer kernel modules,
users and group accounts, networking, network services, and many
more. In addition, Caldera will work to provide support for
important major services on Linux, like SAMBA, Apache, PPP, and others.
Enhanced System Technologies, an important provider of backup solutions
(BRU) for Linux, is a Caldera partner, and has committed to provide
an administration module for their system for the COAS platform.
Additional commercial software developers will announce their support
for this project soon.
We hope that others in the general Linux and free software community
will assist us by providing feedback on the COAS architecture, and by
developing modules to administer more aspects of a Linux system.
Philosophies to guide CLAM development
--------------------------------------
While COAS will provide an administration framework, and a rich set of
features applicable to the domain of administration tasks, the real
value of the project will come from the tools it makes available to
end-users and system administrators, through its modules. Caldera will,
therefore, provide a set of guidelines to assist in developing high
quality administration modules. A sampling of these guidelines,
and some of Caldera's philosophy of administration are provided here.
Administration tools are often quickly abandoned by experienced
administrators because they fail to offer enough value beyond the mere
editing of configuration elements. Many administrators find that
once they understand the the thing they are managing, their needs rapidly
grow beyond the capabilities of the administration tool.
COAS (or any other administration tool), needs to provide a value beyond
the ability to edit data items. Wherever possible, a module should
convert free-form entry into selection from a list. It should narrow the
available choices using intelligent heuristics, and provide informed
defaults. It should use syntactic checks to guard against bad values,
while allowing them to be overridden if necessary. It should take care
of the tedious tasks of keeping the configuration data consistent, and
"remember" and adapt to local administration policy. Above all, modules
must be capable of handling even complex setups. The more bookkeeping,
automation, and intelligence that can be placed in the administration
system, the less taxing the chore will be for adminstrators, and the
more likely it will be that the tool, and the Linux system will be
utilized to their fullest.
The value of the administration tool comes by the transferrence of
experience and wisdom in managing a Linux system from the mind of the
module author to that of the new Linux user and administrator.
Conclusion
==========
Caldera has several messages to those who may be interested in this
project. If you are a current Linux end-user or system administrator,
our message to you is that help is on the way. Caldera hopes to move
Linux to the forefront of ease of use and administrability in the OS
realm. If you are a developer or Linux enthusiast, we invite you to help
us plug this administration gap in the total Linux offering. You can
participate with us in making Linux even better. And finally, to our
potential customers and future Linux users: Please recognize that Linux
is a supported OS. Poor administration will no longer be an excuse not
to look at Linux as a real solution in your business or commercial
environment.
--
Can you get your operating system fixed when you need it?
Linux - the supportable operating system. http://www.debian.org/support.html
Bruce Perens K6BP bruce@debian.org NEW PHONE NUMBER: 510-620-3502
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-admintool-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: