Tools Architecture: Functional Specifications


Prepared in conjunction with: Project Theseus

Copyright © 2002 by Tom Lisjac.
E-Mail: vlx at users.sourceforge.net


Revision History
Alpha  review release 11-15-2002

Overview

While Linux is making great inroads on the desktop and server room, initial configuration can be a complex and time consuming activity. Most distributions provide a collection of very capable components... but it is left to the user to integrate them into a working whole. If the user is not an experienced Linux administrator, this can be a daunting and even discouraging task.

The Tools Architecture (Top-down Object Oriented Linux System) views the operating system as a unified block of fully integrated services rather then a collection of loosely coupled components. The goal is to encapsulate the details of each service and produce complete and unified server and workstation implementations (nodes) that can be easily installed, monitored and administered from a central nexus. Media abstraction is also a goal of the Tools Architecture where a given installation should be bootable from a hard disk, network, CD, EEPROM or other storage devices without an excessive amount of development and configuration.

While the architecture is currently oriented toward Linux and does not strive to be platform independant, there are no inherent obstacles to applying this general approach with other modular operating systems like the OSKit and BSD family.

This document provides the functional specification for the Tools Architecture. It provides the required overview for the technical specification will define the implementation details and procedures for creating a Tools distribution.

The Tools Compliant Node

The Tools Compliant Node (TCN) is the basic functional component of the Tools Architecture. A TCN defines a maximal degree of automated remote administration along with a rigorous local self test and verification environment. Integrated TCNs provide a network of unified functionality and a real time guarantee of global system integrity.

The Tools Architecture is both recursive and hierarchical. As such, a Tools Compliant Node (TCN) can be a server, workstation, a Tools Configuration Manager (TCM) or all three. A TCN has the following characteristics, properties and methods:
    1. The Tools Architecture implies an underlying LSB compliant system.

    2. A Self Test And Notification System (STANS) that performs the following functions:
      1. Cryptographically based package verification (via the TCM) prior to installation and boot.
      2. System level operational limits test (Periodic: RAM, disk space, CPU load, etc).
      3. Service integration tests. (Periodic: Operational test of all installed services)
      4. Notification system self test. (Periodic)
      5. Peer verification test.

    3. A secure and remotely accessible engage and disengage procedures. These are used for logically joining the system's services to an existing array of Tools nodes and disabling ("floating") the system's services and network presence.

    4. Fail-safe system defaults:
      1. Network services selected during the install are not activated until verified by the TCM. (optional)
      2. The system powers up into a Disengaged state and is placed in service by the TCM. (optional)

    5. An integrated, secure and remote capable administration system.
      1. Fully integrated with all services and system resources.
      2. Capable of remote operation via secure connections and certificate based authentication.
      3. Fully extensible and distribution independant.

    6. TCN Registration and Configuration Procedures
      1. All TCN configuration information is exchanged with it's assigned TCM in a single XML file.
      2. All configuration registration or changes are cryptographically signed and verified prior to activation.
      3. All nodes support configuration and policy "push" from the assigned TCM.
      4. Neither the TCN or TCM requires a monitor, keyboard or mouse for installation or routine operation.

Tools Class Hierarchy

The Figure below illustrates the conceptual class hierarchy of the Tools Architecture. The LBI is a "base class" that consists of a rudimentary, package oriented Linux system. The base class contains no administrative or automated configuration control mechanisms and is similar in composition and functionality to the Linux From Scratch distribution. The Linux Base Image implements the first property of a TCN and has no virtual methods.

The Tools Base Image or TBI adds the TCN properties 2 through 5  (and related virtual methods) to the  base image. Remote administration is available that provides secure boot, system integrity and self test capabilities. All basic network services can also be "floated" to effectively fail out the TCN and remove it from the network. Scripts are fired when a float command is issued that can be used by subclasses to enable them cleanly shut down their functionality. At this point, the available functionality will support self-standing embedded applications.

The Tools Compliant Node or TCN extends the administrative capabilities of the system to include registration and push-pull configuration control via a remote Tools Configuration Manager (TCM). This level implements the last property of a TCN.



While the TCN does not contain any applications or servers, it provides the foundation for building entensible, general purpose Linux systems that can be remotely configured and administered with a maximal degree of automation. Packages that are added to subclasses of a TCN inherit all the characteristics of the the TCN ancestor.

The two major subclasses that are typically derived from a TCN will be client and server applications as illustrated above. While it's possible to have a single subclass that combines client and server functionality, the goal of the Tools Architecture is to provide an object oriented system where each instance node provides well defined functionality.

Tools Example Implementation

The following illustrates a Tools network in a typical enterprise environment. The ETS is used to provide terminal services for a global and several private environments. Other TCN servers and workstations are managed via the distributed TCM clusters where the configuration data for all TCN's are stored. TCM's can, in turn, be monitored and configured by a hierarchy of other TCM's for redundancy and ease of distributed control without introducing new learning curves, control elements or additional system complexity.


Any workstation with network connectivity, a browser and appropriate security credentials (username, password and optional certificate) can administer any TCN.  Access to a TCM will allow the remote administrator to perform automated maintenance operations on the entire network.


Home
This Project is generously hosted by SourceForge.net Logo