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: +
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:
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:
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):
| 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 | @@ -140,7 +162,8 @@ to INIT which is related to its own initialization)||
| STOP | stop (shutdown) tasks (when the object intends to stop -performing its function) | +performing its function). This can involve unloading data and binaries from +main memory.||
| RUN | primary (work) phase | @@ -210,6 +233,20 @@ used set of parametersCHECK_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...) |
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.
-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.
+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:
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).
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: