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

Reply via email to