From 5edc4e61b849ce6b63de11b4b5a7451b4ea5c16b Mon Sep 17 00:00:00 2001 From: abial Date: Wed, 25 Nov 1998 11:08:54 +0000 Subject: New revision of UCI project document. Comments are welcome... --- release/picobsd/doc/src/UCI.html | 201 +++++++++++++++++++++++++++++---------- 1 file changed, 152 insertions(+), 49 deletions(-) (limited to 'release') diff --git a/release/picobsd/doc/src/UCI.html b/release/picobsd/doc/src/UCI.html index 03fb729..bb0f955 100644 --- a/release/picobsd/doc/src/UCI.html +++ b/release/picobsd/doc/src/UCI.html @@ -1,25 +1,33 @@ - +

Unified Configuration Interface Project

Here's a preliminary attempt to organize all (well, most) -configuration tasks and parameters of PicoBSD system in hierarchy -of categories.

- -

This forms a sort of framework, basing on which one can implement -consistent configuration file(s), and configuration utilities.

- -

However, the idea behind this project is to completely replace currently +

The idea behind this project is to completely replace currently used configuration approach, which is based on several shell scripts, and to provide ability to change system behaviour basing on set of well-defined -parameters' hierarchy. This approach makes it relatively easy to write -consistent user interfaces, either command-line or with GUI front-ends.

+parameters' hierarchy. One of the goals is also to provide an object +oriented model of the OS management and structure, instead of currently +used (inconsistent) procedural model of system/service startup/shutdown.

(BTW. this effort is called UCIP for short, which is pronounced -"You See IP" and relates to intuitive way you can configure your IP -services with this approach.. :-))

This project involves such issues as: +

+providing consistent view of the system and its functional subsystems as +a set of interrelated objects equipped with certain properties. +
+providing global approach to user interface, either command-line or with GUI +front-ends. +
+managing system resources and subsystems. This includes managing +static and dynamic interdependencies between subsystems, ability to +upgrade/downgrade specific subsystems on-the-fly. +

This is work in progress - I'm aware that many pieces are either completely missing or misplaced. Please send any comments and @@ -35,13 +43,13 @@ design and/or implementation.

-
Let's first introduce distinction between the following terms: +
Let's first introduce the following terms:
- management base - the actual structure holding configuration and information data according to defined structure. This structure will most probably have a form of tree (possibly with cross-branch links or some other -mechanism representing mutual dependencies) - the way it's stored is also +mechanism representing mutual dependencies) - the way it's stored is something which needs to be discussed.
- @@ -50,12 +58,20 @@ management base in such a way that it can be viewed and modified by legitimate users.
- -configuration agent - an entity performing actual configuration +system monitor - an entity performing actual configuration and monitoring tasks, from one side dealing with management base, and from the other -dealing with the system resources, and from yet another dealing either -directly with the user (thus acting as a user interface), +dealing with the system resources and subsystems, and from yet another dealing +either directly with the user (thus acting as a user interface), or passing requests to other entity which acts as user interface.
- +subsystem - a package containing programs, configuration data, as well +as installing/deinstalling/start/stop stubs, which form together one logical +entity performing specific services on behalf of the system. Each subsystem +is viewed as an object with specific properties, dependencies, which is able +to generate events, service general requests common to all such subsystems, +and provide specific services to other subsystems. +
@@ -85,10 +101,10 @@ The next point presents one possible approach to this dilemma.

The term "object" used in the following discussion represents a functional subsystem, such as system service, usually performed by some specific -process (or, a set of global system parameters, in which case the configuration -agent is the service itself).

+process (or, a set of global system parameters, in which case the system +monitor agent is the service itself).

Each object stored in management base can be characterized by +

Each object represented in management base can be characterized by following properties:

@@ -107,7 +123,10 @@ FSM definition, describing state transitions in reaction to received events, list of events it can generate and accept,
-list of dependencies on other objects' states, +list of dependencies on other objects' states and services, +
+list of requests it can handle,

list of parameters it can accept and/or provide, with their valid ranges. @@ -118,7 +137,9 @@ list of parameters it can accept and/or provide, with their valid ranges.

A few words on system startup: the system startup routines should ensure that dependencies can be unwound into linear, ordered list. If it's not possible, they should detect possible deadlocks at runtime, and act as an -arbiter between conflicting parties (or signal an error).

+arbiter between conflicting parties (or signal an error). In case of +unsatisfied dependency on some missing subsystem, the system monitor will +act appropriately as described below (in paragraph on request handling).

The set of symbolic states may consist of the following states, depicting object's current internal state (as described by its FSM): @@ -126,7 +147,8 @@ depicting object's current internal state (as described by its FSM):

- + @@ -140,7 +162,8 @@ to INIT which is related to its own initialization) +performing its function). This can involve unloading data and binaries from +main memory. @@ -210,6 +233,20 @@ used set of parameters + + + + + + + + +

Name	Meaning
INIT	the subsystem is initializing itself	INIT	the subsystem is initializing itself, possibly loading +necessary data and binaries from permanent storage.
CHECK	performing consistency check on newly supplied parameter values
STOP	stop (shutdown) tasks (when the object intends to stop -performing its function)
RUN	primary (work) phase	CHECK_REQ	perform self-consistency check
UPGRADE_REQ	upgrade the subsystem - this possibly involves +downloading necessary pieces via network to permanent storage area. The +upgrade process should be transactional, and should save the older version +of the subsystem in case the DOWNGRADE_REQ should be issued.
DOWNGRADE_REQ	downgrade the subsystem - restore the previous +version of the subsystem from the copy on permanent storage.
UNINSTALL_REQ	uninstall the subsystem completely - possibly +freeing the space on permanent storage.
(other...)	(other...)

@@ -229,17 +266,41 @@ the following:

EV_CHANGEchange notification (includes the name of changed -parameter) +parameter, and/or FSM state change) + + +EV_DEPsignal the dependency on another subsystem - ask for +existence of the service. Probably there should be two types of the dependency: +a soft one (where the subsystem can still function even if the dependency is +unresolved) and a hard one (when the existence and proper functioning of the +other subsystem is mandatory for its function). (other...)(other...) - -

Ideally, the configuration agent will be equipped with routines to -serialize this data into human-readable form, so that it's easily stored, -backed up, and repaired in case of inconsistencies.

One of event attributes can be a flag which says that this particular event +is a directed, or broadcast message. In case of directed message, it should +be forwarded only to interested parties. Broadcast message is sent to all +subsystems.

+ +

System monitor agent will process these events and route them to +appropriate subsystems which are registered with it. Generally, if some +subsystem is dependent on some other, it will want to also receive all events +generated by the other subsystem.

+ +

In case the subsystem +is missing, and the system monitor received events signalling that some other +subsystem is depending on it, the system monitor should arrange either for +installing necessary pieces from some media (be it permanent storage, or the +network), or to send an EV_NACK to the requesting subsystem. It's the +responsibility of the requesting subsystem to deal with such case +appropriately to the type of dependency (i.e. either "hard" or "soft"). + +

Ideally, the system monitor agent will be equipped with routines to +serialize the management data into human-readable form, so that it's easily +stored, backed up, and repaired in case of inconsistencies.

Actual user interface is still quite another story: I've seen UIs which @@ -265,7 +326,10 @@ protocols, such as SNMP or LDAP.

Most known to me (if not all) implementations of agents for these protocols are (contrary to their name) quite heavy-weight - so their use should be either optional, or replaced with some other light-weight -protocol and a proxy agent running on other machine.
+protocol and a proxy agent running on other machine. One example of +such proxy agent is existing UCD-SNMP implementation which in +significant part follows the sysctl(3) tree, merely exporting it as +a part of the MIB trees.

It's worthwhile to consider also use of other protocols such as DHCP (and BOOTP), Service Location Protocol (SLP - RFC2165) for easy @@ -273,7 +337,7 @@ integration with LAN resources, easy initial configuration, and peer discovery.
-
All operations performed by configuration agent should be transactional, +
All operations performed by system monitor agent should be transactional, i.e. it should be possible to commit a set of changes as one logical entity, and be sure that either it's applied in whole, or not at all. This includes also ability to abort processing in the middle.
@@ -286,7 +350,7 @@ data that are to be applied after the transaction ends successfuly.
allowed credentials, and basing on this either committed or aborted.
-
A few notes on possible implementation of configuration agent:
+
A few notes on possible implementation of system monitor:
- let's assume that all configuration information is read on startup @@ -306,44 +370,48 @@ is relinked with special stub which fakes to the program necessary config files and events (such as signals to reread configuration).
  This probably means also that some libc routines would have to be replaced, because they assume reading configuration from certain disk files.
  + +
  Since each such subsystem needs to implement some common actions such as +installing, deinstalling, start/stop etc, we could use already present +system of packages (with some minor modifications) to easily achieve +part of the goals (i.e. install/deinstall/upgrade/downgrade/stop/start).
- each subsystem performing some task requests its initial config data -from config agent, at the same time registering with it to receive +from system monitor, at the same time registering with it to receive configuration events, such as request to re-read data, to provide currently used config data, return status, react for signals, restarts, etc...
- -configuration agent acts as meeting point for all producers and consumers +system monitor acts as a meeting point for all producers and consumers of events and config data. It needs to maintain a table of registered subsystems, set of events they provide, set of events they want to receive, -etc.. Basing on this table, it passes appropriate information to +etc.. Basing on this table, it routes appropriate information to appropriate parties.
- -user interface is then just one of clients of config agent, albeit possessing +user interface is then just one of clients of system monitor, albeit possessing special privileges.
- -one of important tasks of configuration agent, in case given +one of important tasks of system monitor, in case given object (subsystem) registers with it to be notified about certain events, is to ensure that such type of event can be possibly generated. This is to prevent subsystems from waiting for events coming from other non-existent -subsystems. +subsystems. See the discussion above on satisfying dependencies.
NOTE: this is one possible approach - a centralized one. It's worth to consider other approach, distributed, in which case each object (subsystem) sends and listens to the data at a meeting point specific to each other -object. This eliminates (or drastically minimizes) the role of configuration -agent which is a single point of failure in centralized case.
+object. This eliminates (or drastically minimizes) the role of system +monitor which is a single point of failure in centralized case.

Here is my initial proposal, which perhaps can be used as a model for -user interface hierarchy, if not for the management base itself.

Here is my initial proposal for the User Interface hierarchy:

@@ -385,15 +453,43 @@ System configuration.
- Loadable modules
- Optional hardware, services and protocol modules management. - + Subsystems
1. - (Enumeration of available loadable modules) + Module management
  + Optional hardware drivers and protocol modules + management. +
  1. + (Enumeration of available loadable modules) +
    1. + Load / unload / status +
    +
  2. + Package management
    + Management of basic and optional system services.
    1. - Load / unload / status + (Enumeration of locally available packages) +
      1. + Start / Stop / Status / Configure +
      +
    2. + Default source of service packages
      + Where to automatically get the missing packages from. + +
      1. + (Enumeration of available media)
        + (local and remote disks, ftp, http)
    3. + Space consumption
      + (Things like minimal free space on permanent storage..) + +
    4. Task priorities + This includes not only currently running tasks, but all + which can possibly be started.
      1. List / Modify -- cgit v1.1