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 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:
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:
- The Tools Architecture implies an underlying LSB compliant system.
- A Self Test And Notification System (STANS) that performs the following functions:
- Cryptographically based package verification (via the TCM) prior to installation and boot.
- System level operational limits test (Periodic: RAM, disk space, CPU load, etc).
- Service integration tests. (Periodic: Operational test of all installed services)
- Notification system self test. (Periodic)
- Peer verification test.
- 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.
- Fail-safe system defaults:
- Network services selected during the install are not activated until verified by the TCM. (optional)
- The system powers up into a Disengaged state and is placed in service by the TCM. (optional)
- An integrated, secure and remote capable administration system.
- Fully integrated with all services and system resources.
- Capable of remote operation via secure connections and certificate based authentication.
- Fully extensible and distribution independant.
- TCN Registration and Configuration Procedures
- All TCN configuration information is exchanged with it's assigned TCM in a single XML file.
- All configuration registration or changes are cryptographically signed and verified prior to activation.
- All nodes support configuration and policy "push" from the assigned TCM.
- 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.
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.
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.
