Configuration Management (was: insight from the unixconfig project)

[Joerg F. Wittenberger]

Hello,

This is a commented crosspost from the TUNES mailing list.  I hope a
few comments might be interesting to tunes as well, hence that mail
list is on cc.

I strongly agree with Francois's points regarding configuration.
There are a few comments down here, how that points are expressed in
Askemos.

Francois-Rene Rideau <fare@tunes.org> writes:

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

Is there any source, where I could read more about those LISP
machines?  From what I understand such a namespace would be the "entry
point" or any central, application related place in Askemos.

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

That's the easy part, we're already used to, aren't we, Frank (µ)?

> 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!

Uh, yes.  Don't panic, we'll save that for later.

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

;-)

(Remark for the TUNES people, Askemos (www.askemos.org) is in theory
all XML only and in fact more or less some persistant S-Expressions.)

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

Bind time: in terms of Askemos, that's the moment, wenn you link a
place to some name in some namespace (each place has it's own).

> * 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).

This gives me a chance to explain what the (my-oid) place is good for:
all system security in Askemos is based on the provision that this
place absolutely inaccessiable and never leaves a particular physical
machine.  (And it is the only one, for which this is garantied.)

It will keep the secret key of the machine.

> * Global Registry: Trust only works if you can reliably name people.
>   Replace the DNS with a global crypto registry system.

That's why users are represented by their entry points, which gives
them a globally unique id.

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

OK, that's what Askemos is about anyway.

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

;-) Did I write somewhere that we share views?  We do.

> * 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.
-- 
The worst of harm may often result from the best of intentions.