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/
_______________________________________________
Freedombox-discuss mailing list
Freedombox-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
