From bb3718de30dbba6f6b411db9ce57fc58bd4d18f5 Mon Sep 17 00:00:00 2001 From: abial Date: Sun, 1 Nov 1998 19:52:47 +0000 Subject: Added info on Unified Configuration Interface Project. Several people contributed their ideas to this document, among them Terry Lambert and Bryan Mann, both @whistle.com. Thanks! --- release/picobsd/doc/src/UCI.html | 855 +++++++++++++++++++++++++++++++++++++ release/picobsd/doc/src/intro.html | 4 +- 2 files changed, 857 insertions(+), 2 deletions(-) create mode 100644 release/picobsd/doc/src/UCI.html (limited to 'release') diff --git a/release/picobsd/doc/src/UCI.html b/release/picobsd/doc/src/UCI.html new file mode 100644 index 0000000..03fb729 --- /dev/null +++ b/release/picobsd/doc/src/UCI.html @@ -0,0 +1,855 @@ + + + +

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 +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.

+ +

(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 is work in progress - I'm aware that many pieces +are either completely missing or misplaced. Please send any comments and +changes you seem appropriate either directly to me, or better to +freebsd-small@freebsd.org. I'll gladly welcome anyone who can help with +design and/or implementation.

+ + +

+ +

Unified Configuration Interface +

+ +

+
Let's first introduce distinction between 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 +something which needs to be discussed. +
- +user interface - a method (and agent) for presenting data stored in +management base in such a way that it can be viewed and modified by +legitimate users. +
- +configuration agent - an entity performing actual configuration +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), +or passing requests to other entity which acts as user interface. +
+
+
One possible approach to storing the management data is to use already +existing framework known as MIB, as defined in applicable RFCs.
+ +
This approach has several advantages: it represents well thought-out work +of many experienced individuals and teams, it has already proven to be +useful, it's widely used and accepted, it's easily extensible, it's able to +represent quite complicated objects, etc.
+ +
It has some drawbacks, as well: e.g. there is no standard mechanism for +representing events and indirectly related objects, it tends to create +deep and narrow trees which require to descent several levels to change some +commonly used parameters, it doesn't say anything about the mutual +dependencies between objects and parameters (except parent-child-sibling), +and about required sequence to properly set their parameters, etc.
+ +
These issues are not directly addressed in standards, and real +implementations (known to me) have to implement these additional mechanisms +"behind the scenes", so that their workings are not obvious nor easily +accessible (let alone changeable).
+ +
So, if we decide to use it, we need to address these issues somehow. +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).

+ +

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

+its internal state, possibly consisting of several parameters and currently +performed functions, but represented to the rest of the system as a symbolic +state, one of set of states common to all objects. +
+a temporary space for new sets of parameters, which are being supplied by +other subsystems, prior to their actual application, +
+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 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).

+ +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name	Meaning
INIT	the subsystem is initializing itself
CHECK	performing consistency check on newly supplied parameter values
READY	ready to start performing its primary function, but not started
START	start-up tasks (related to its primary function, as opposed +to INIT which is related to its own initialization)
STOP	stop (shutdown) tasks (when the object intends to stop +performing its function)
RUN	primary (work) phase
IDLE	waiting for some external event to happen
BUSY	the subsystem is busy (either with performing some +high-priority task, or just simply hung), and cannot be interrupted without +complete restart,
ERROR	this object is either improperly configured, or +malfunctioning
(other...)	(other...)

+ +

The set of possible actions may include the following actions:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name	Meaning
LIST_EV_REQ	get list of events the subsystem can generate
LIST_ACT_REQ	get list of actions the subsystem can respond to
GET_DEF_REQ	get definition of given parameter (the arguments, and +valid ranges)
SET_REQ	set given parameter to given value (this value will +be used only after COMMIT_REQ)
GET_REQ	get currently used value of given parameter
COMMIT_REQ	commit changes supplied in last transaction to currently +used set of parameters
ROLLBACK_REQ	revert last commit
INIT_REQ	perform initialization tasks
START_REQ	start performing primary function
STOP_REQ	stop performing primary function
RESTART_REQ	restart operation, possibly forcefully
NOTIFY_REQ	notify me of any changes in your state
CHECK_REQ	perform self-consistency check
(other...)	(other...)

(Each request includes source service identifier and credentials of +the sender)

+ +

The set of events which can be generated by subsystems may include +the following:

+ + + + + + + + + + + + + + + +

Name	Meaning
EV_ACK	positive acknowledge of the last operation
EV_NACK	negative acknowledge of the last operation
EV_CHANGE	change notification (includes the name of changed +parameter)
(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.

+
Actual user interface is still quite another story: I've seen UIs which +merely followed the standard MIBs, and menus were composed of actual OID +numbers plus DESCRIPTION field. In my experience, they are (barely) +acceptable, though due to the usual width and depth of MIB trees you had to +traverse several levels down and up in order to change some (protocol-wise) +related parameters.
+ +
More acceptable UI would collect interrelated items under common menu +entries, irrespectibly of their actual position in the MIB tree.
+ +
A worthwhile goal to pursue is to create such an UI which could guide +you through the most common configuration tasks, while at the same time +allowing for unrestricted and quick use by power users. This can be done +either as a set of configuration "wizards" or extensive hinting, command +completion, etc.
+
+
The management database should be easily exportable via standard +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.
+ +
It's worthwhile to consider also use of other protocols such as +DHCP (and BOOTP), Service Location Protocol (SLP - RFC2165) for easy +integration with LAN resources, easy initial configuration, and peer +discovery.
+
+
All operations performed by configuration 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.
+ +
This probably means that each object (subsystem) should be able to store +not only its current configuration data, but also the newly supplied config +data that are to be applied after the transaction ends successfuly.
+ +
Operations should be verified against allowed values, as well as against +allowed credentials, and basing on this either committed or aborted.
+
+
A few notes on possible implementation of configuration agent:
+
- +let's assume that all configuration information is read on startup +by some specialized daemon (this can be part of init(8) as well), +which then performs role of communication agent through which passes +all configuration information, be it request for change, request +for info, request for start / shutdown, or notification about the change. +
- +configuration information itself is stored either in binary database, or as +a filesystem hierachy mimicking configuration items hierarchy. +
- +each user-level program performing some task (such as routing daemon, inetd +etc) is either equipped with the ability to communicate with config agent, or +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.
  +
- +each subsystem performing some task requests its initial config data +from config agent, 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 +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 +appropriate parties. +
- +user interface is then just one of clients of config agent, albeit possessing +special privileges. +
- +one of important tasks of configuration agent, 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. +
+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.
+

+ +

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

+ +

+System configuration. +
1. + Boot device and file
  + Name of the boot device (possibly networked) and boot + image. +
  1. + (Enumeration of available devices) +
    1. + (Enumeration of available files) +
    +
  +
2. + Config file
  + Configuration file management - loading and saving, either + local or remote (if applicable). +
  1. + Load / Save +
    1. + Source / Destination
      + (Enumeration of available storage places, possibly + networked) +
    +
  2. + Edit directly (geek mode) +
  +
3. + Loadable modules
  + Optional hardware, services and protocol modules management. + +
  1. + (Enumeration of available loadable modules) +
    1. + Load / unload / status +
    +
  +
4. + Resource management +
  1. + Memory consumption
    + This is entry point to a subtree, which allows to set + up various resource limits for subsystems, services and + processes. +
  2. + Task priorities +
    1. + List / Modify +
    +
  +
5. + System console +
6. + Virtual consoles (if applicable) +
7. + System Date / Time Zone +
8. + Banner +
9. + Logging +
  1. + Local logging +
  2. + Remote logging +
  +
+
+Network configuration. +
1. + Hostname and Domain +
2. + Interfaces +
  1. + (Enumeration of physical interfaces)
    + (Enumeration of virtual interfaces, if applicable)
    + (Options for creating virtual interfaces, if applicable) +
    1. + Interface options (speed, media, encapsulation, + description, etc.) +
    2. + ARP +
    3. + Bridging +
    4. + IP +
      1. + Adress / netmask / alias +
      +
    5. + IPX +
    6. + AppleTalk +
    +
  +
3. + Protocol Options +
  1. + IP, UDP, TCP, ARP, IPX, ATM ...
    + (Enumeration of available protocols) +
    1. + (Enumeration of protocol specific options, such as + buffer sizes, algorithms, ARP tables etc) +
      1. + List / Add / Delete / Modify / Set (where + applicable) +
      +
    +
  +
4. + Routes +
  1. + List +
  2. + Static +
    1. + Add / Delete / List +
      1. + (route expression) +
      +
    +
  3. + Dynamic +
    1. + (Enumeration of available routing protocols) +
      1. + Add / Delete / List +
        +
        + (route expression) +
        +
        +
      +
    +
  +
5. + Network services +
  1. + DNS +
    1. + Hosts +
      1. + Add / Delete / List +
        +
        + (hosts definitions) +
        +
        +
      +
    2. + Resolvers +
      1. + Add / Delete / List +
        +
        + (hosts addresses) +
        +
        +
      +
    3. + Local DNS server config +
    +
  2. + PPP +
    1. + Server +
    2. + Client +
    +
  3. + NFS +
    1. + Server +
    2. + Client +
    +
  4. + NIS +
  5. + DHCP +
    1. + Add / Delete / Reserve / List +
      1. + (IP address expressions) +
      +
    +
  6. + SNMP +
    1. + Protocol version +
    2. + Send traps to... +
    3. + Access Control Lists
      + (This is either full-blown ACL system in case + of SNMPv2, or a community string for SNMPv1.) +
    +
  7. + Printing +
    1. + Local / Remote +
      1. + Printers +
        +
        + Add / Modify / Delete / List +
        +
        +
      2. + Queues +
        +
        + Priority / Delete / List +
        +
        +
      +
    +
  8. + SMB services +
  9. + Network Address Translation +
  10. + Packet filters +
  11. + Bandwidth Manager +
  12. + NTP +
  13. + Remote Access +
  +
+
+User management. +
1. + User accounts +
  1. + Add / Delete / Modify / List +
    1. + Name / Password / ACL +
    +
  +
2. + User profiles +
  1. + Access Control Lists. +
    1. + Add / Delete / Modify / List +
      1. + Name / Template / Definition +
      +
    +
  2. + ACL Templates +
    1. + Add / Delete / Modify / List +
      1. + Name +
        +
        + Command restrictions list +
        +
        + Location restrictions list +
        +
        + Resources restrictions list +
        +
        + Time restrictions list +
        +
        + Authentication methods +
        +
        + Unix passwd +
        +
        + S/Key +
        +
        + Kerberos +
        +
        + Radius +
        +
        + TACACS +
        +
        +
        +
        +
      +
    +
  +
+
+Other services +
1. + Cron tasks +
+
+Filesystems. +
1. + Local / Remote +
  1. + (Enumeration of available FS-s) +
    1. + FS / Mounting point / Options +
    +
  2. + Swap Partition / Swap File +
    1. + Create / Turn on +
    +
  +
+
+Environment +
1. + Set / Unset / List +
+
+System status +
1. + (Enumeration of available status items) +
+
+Diagnostics +
1. + Debug +
  1. + (Enumeration of subsystems hierarchy, those of which can + provide debugging data) +
    1. + Set / Clear / Level +
    +
  +
2. + System messages +
3. + Ping / traceroute / rtquery +
+

+ +

+ +
Please send your comments to +Andrzej Bialecki
+
Last modified: +Sat Oct 24 19:33:45 CEST 1998 +
+ + + + diff --git a/release/picobsd/doc/src/intro.html b/release/picobsd/doc/src/intro.html index df129cb..b7912f8 100644 --- a/release/picobsd/doc/src/intro.html +++ b/release/picobsd/doc/src/intro.html @@ -1,5 +1,5 @@ - + PicoBSD @@ -156,7 +156,7 @@ version 0.4 it's a part of official FreeBSD CVS and lives in src/release/picobsd. I also create the snapshots of this source tree - keep in mind that they are not so up-to-date as the tree in FreeBSD CVS. You can get the snapshot I made on -Mon Oct 12 00:53:02 PDT 1998 +Sun Nov 1 11:48:32 PST 1998 here.

Now, if you don't like the setup of PicoBSD, or you miss -- cgit v1.1