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 type | int, string, ip-address, ... |
a timestamp | time of last changed |
a link to the creator/owner | created 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
Abstract view on configuration and system data
Configurations
Networking
repository server as common database for e.g cluster nodes
authorization ?
distributed, hierachical database (e.g. company - department - team - user) ?
versioning
restoring a running configuration
data import/export
cloning a configuration