System Configuration Repository

What is the repository ?

The repository provides a common interface to the system configuration (usually stored below /etc) and status (below /proc).

It abstracts from file formats and architectural dependencies by implementing a common naming scheme and access interface for all data.

In conjunction with the workflow language, the repository can also be used for global data storage.

Data storage

Data is either Transient data īlivesī from itīs creation (at or short after boot time) until shutdown. Persistent data has no predefined end-of-life.

Implementation

The repository uses a disk based file for persistent and private (i.e. not system dependant) data. Information about the running system comes either from the /proc or the /etc filesystems. Both are accessed by agents which have knowledge about the file formats and transform the data to and from the representation used inside the repository library.

Knowledge about data, its type, availability, nameing, etc. is known to the repository library (configuration file at startup). The library decides how to access the data (disk based, via agent, ...).

Agents

Agents are used to access data outside the repository library and its own disk file. This is typically system specific data, e.g. specific configuration files below /etc. This approach allows normal system configuration by editing configuration files to coexist with workflow driven administration. It also prevents inconsistencies by keeping a single data source.

By using write-only agents to reconstruct a configuration file from data stored in the repository database, it's easy to reconstruct configurations destroyed by accident.
This also supports rather complex files (e.g. sendmail.cf) which are constructed by a set of system commands.

Agents may also be used to extend the available data by use of repository servers which provide data common to a set of systems (e.g. clusters).

Configurations

The notion of configurations describes the concept of several co-existing sets of repository data to support changing system environments. This is a typical requirement for laptop users who either work standalone or using a docking station for additional peripherials. Choosing the configuration at boot-up adapts the system to the actual environment.

Versioning

Having configurations leads directly to versioning of repository data to 'go back' after mis-configuration. It may also used to check the system setup for changes and reconstruct a 'safe' setup.

Security

The repository can be used to implement security based on authorization and authentification. Logging actions or tracing data areas (e.g. watchpoints) helps in debugging workflows.

Views

The data repository could be organized as a bag of typed values. Access is provided by views which describe a path to the value.

This approach tries to eliminate inconsistencies by storing each value only once. Different views of the values are possible.

This notion of views is already implemented in the /proc filesystem. Take for example interrupts. /proc/interrupts views interrupts and devices, /proc/pci views PCI cards and their configuration including interrupts. The value interrupt is the same in both views.

To keep track of values, each value is accompanied with
its typeint, string, ip-address, ...
a timestamptime of last changed
a link to the creator/ownercreated by, changeable by
flags
.
.
transient/persistent
enabled/disabled
...

The repository stores data as (value, type) pairs and accesses it with a view. Views can be registered with the repository without actually storing data. This is of particular interest with data coming from agents, which is generated on the fly. Another aspect is documentation. By describing views together with the type of data accessed by the view, module implementors can browse through the repository and find the data they need.


Design parameters