Configuration Management (was: insight from the unixconfig project)

[Francois-Rene Rideau]

On Thu, Feb 28, 2002 at 12:39:40AM -0700, Kevin Holmes wrote:
> I suggest you all check out the unixconfig project
> [unixconfig.sourceforge.net]. Persistant configuration is such a common
> activity that this needs to be abstracted into the operating system.
The failure of unixconfig is in the very use of C by UNIX.
Configuration management is all about metadata and declarative programming.
These don't fit in C, or any of the imperative programming languages
that UNIX people grew to make it manageable (Perl, Python, etc.).

LISP machines have a "namespace" feature for handling system configuration.
Replaces /etc, sits in a server, has a GUI of its own, is programmable from
LISP, has some kind of builtin version control (though I've never done
anything but add stuff). Way ahead of UNIX.

> with respect to configuration it would be useful to:
>     * Undo or revert the system to a previous state. It seems that this
> requires the system to have few side effects.
Undoing can be done with history management.
Because you can't undo the world, it also requires a notion of
partitioning the system into <modules|components|objects|entities|whatever>.
I like the idea of defining each object into first-class nested "zones",
and being able to tweak each zone's persistence/access/history/logging/foo
attributes.

>     * Provide an interface to applications for adding and removing
> configuration in a standard way
C is doomed. LISP-style macros can make it a breeze.

>     * Perform error checking and validation of the configuration.
Better than mere constraint-checking, have constraint-solving!

> These are just a few ideas off the top of my head. I'm sure you all have
> better ones. Just please don't say XML :)
XML

Here is my take for the design of a configuration management system.

* Declarative programming: configuration information is
  a set of rules in a constraint programming language.
* Discovery: all software configuration would flow directly
  to a machine from trusted servers and metaservers (DHCP style).
* Multiple Sources: information comes from multiple sources,
  organized in multiple hierarchies. Some hierarchies can be:
  Hardware hierarchy (such device on such host in such network),
  Application hierarchy (such procedure of such program in such business),
  User hierarchy (such process run, assuming such role, by such user).
  Each combination of points in multiple hierarchies
  can have some configuration rules attached:
  in such process, trace calls to such procedure;
  on such host, allow such role of such user access to such program.
* Configuration Merging: all the rules (global, LAN-specific, host-specific,
  device-specific, procedure-specific, program-specific, business-specific,
  user-specific, role-specific, process-specific, etc.) must be merged
  at bind-time, and the constraints ultimately solved only then.
* Higher-Order Constraint Solving: based on basic data and higher-order rules,
  the constraint solver can deduce complete "routes" toward implementing a
  given functionality (e.g. doing ssh to such remote machine to access such
  file by NFS so as to display it on such remote display to show my dad
  with such plugin to get from such trusted server with my private key).
  Configuration shouldn't include more data than necessary;
  as much as possible must be deduced by the constraint solver.
  The constraint solver replaces "make" among other things.
* Conflict Management: conflicts just happen. When conflicting
  information arises (unsolvable constraint set), there must be meta-rules
  that describe fall-back mechanisms (deny access,
  discard some "weak" constraints, enter debug mode, etc.)
* Access Rights: particular meta-rules tell which existing rules
  a user, process, etc., may override.
* Trust: wherever tampering is physically possible, configuration data
  must be encrypted and signed. Each machine must base its trust
  from a cryptographic keyring enabled early in its boot process
  (if possible in ROM).
* Global Registry: Trust only works if you can reliably name people.
  Replace the DNS with a global crypto registry system.
* Trusted Mobile Profiles: you can login any place in the world
  and have your public configuration information available;
  desktop themes, session information, public bookmarks,
  functions, macros, keybindings, extensions, plugins, etc.
  Then, if you trust the place you're at, you can grant it more access:
  read access to more private data, and/or write access to some data.
  Usually, you don't allow tampering with logging/versioning/trusting rules
  unless at a very trusted console, so you can always revert modifications
  done at less trusted sites and monitor unwanted access.
* History Management: changes break things.
  Working combinations of rules must be remembered,
  so we can narrow the changes that broke things when debugging.
* Component Management: each of the multiple sources of configuration data
  is a separate component with its own management rules,
  with its own cached partial evaluation of constraint solutions, etc.
* Higher-Order Evolution Tracking: when something changes,
  meta-rules can help propagate the change gracefully
  to related configuration rules.
* Front-end independence: everyone is entitled his preferred front-end.
  SEXP, Python syntax, name-your-GUI, or whatever.
* Back-end independence: adapt to legacy  configuration formats
  and storage systems. Internally, use persistent objects.
  Externally, dump /etc/passwd as well as SEXP or (yuck) XML
  or (vomit) /etc/sendmail.cf.
* Meta-level configuration: the configuration of the configurator,
  how it adapts to existing back-ends, etc., is itself a configuration,
  solved by the usual constraint programming language. Of course,
  the bind-time of this configurator happens earlier than the bind-time
  of the systems it builds, so it is possible to maintain
  a bootstrapped system.

Thus, when I access data from my trusted 320x240 palmtop or an untrusted
1600x1200 desktop, the GUI preferences will adapt.
A same process will choose big fonts (e.g. 15x28) to display bulk data
on the desktop's screen, but will choose smaller ones (e.g. 6x13) to
display confidential stuff on the palmtop (a gesture on the palmtop
automatically logged me on the desktop through 802.11 wireless ethernet).
When I login on my trusted 1024x768 laptop, the same application will
show everything on its trusted screen with intermediate sized fonts
(e.g. 10x20). Oh, and it might adapt the font size to the data being
displayed as well as to its knowledge of my eyesight and of the screen
size and resolution, so that I can see as much possible relevant data
as possible, but without straining my eyes.

Hopefully, everything should be deduced from generic configuration data
about me, about each computer's hardware, about the trust I have about
each computer, about the trust each computer's administrator has about me,
about known algorithms to achieve known transformations, etc.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
The reason truth is stranger than fiction is that fiction has to make sense.