[Freedombox-discuss] FBx Configuration Management

[bnewbold at robocracy.org]

General purpose "Configuration Management" seems to be a crucial component 
of the FreedomBox software stack/distribution. It needs to be secure, 
accessible (elegant user experience for diverse userbase), reliable, 
robust, etc.

As I see it there are a few overlapping needs: a way to make configuration 
changes programmatically, safely, and immediately on the devices 
themselves (eg, an API called by higher level user interfaces), a way for 
developers to define defaults and track those defaults over time (eg, 
version control for the default/skeleton /etc directory), a way for owners 
to backup and restore entire configuration profiles/snapshots, and a 
mechanism for independent package maintainers to define tweak-able 
variables as easily as possible (aka, minimize "repackaging" for use with 
FBx). It would be a nice feature if users could "undo" configuration 
changes atomically. It's unclear to me if we need fine grained access 
control to system-wide configuration or if this is all owner/root level 
(eg, should installed packages be allowed access to the centralized 
configuration interface?). It's also unclear how to handle syntax or 
logical errors with configuration.

The existing plan (based on a wiki page[0] and my fuzzy memory) is to use 
some combination of [DebConf], [Config::Model], and [Augeas] (perhaps with 
[1]) to manage and implement configuration. DebConf is how the debian 
package system manages configuration of packages ("dpkg-reconfigure"), 
Augeas is a C library to allow editing of many different text-based config 
file syntaxes through a single tree/node interface, and Config::Model is a 
newish set of Perl libraries that build upon the other two, as well as 
basic GUI and ncurses interfaces to those libraries. I'm not sure what 
Plinth calls down to right now, but I assume it would call in to 
Config::Model (via a Python wrapper?).

Other previous work includes the very mature [UCI] (Unified Configuration 
Interface) from OpenWRT (which underlies the LuCI web interface and 
handles a lot of tricky problems), deployment-oriented tools like [Puppet] 
and [Chef], Bcfg2, [CFEngine], and the recent [Blueprint] configuration 
reverse engineering tool (with interoperates with Chef and Puppet, handles 
manual changes, based on git and python).

My questions are:

whether there is a firm commitment to Config::Model (also if anybody has 
experience with it and is comfortable with perl);

whether it covers FBx's minimal needs (maybe my feature list above is too 
long);

and whether programmatic access control is required.

I don't have much experience with any of these tools (I personally ignore 
DebConf and found the Puppet learning/pain curve steep), but I'll be at 
the upcoming hackfest in NYC and would be interested in hacking on this 
stuff then (with guidance). I'll also update the wiki with anything 
learned from this thread.

-bryan

[0]: http://wiki.debian.org/FreedomBox/BoxConfiguration
[1]: http://cpansearch.perl.org/src/DDUMONT/Config-Model-Backend-Augeas-0.111/README
[Augeas]: http://augeas.net/
[Config::Model]: https://github.com/dod38fr/config-model
[UCI]: http://wiki.openwrt.org/doc/uci
[Blueprint]: http://devstructure.github.com/blueprint/
[CFEngine]: http://cfengine.com/