[Freedombox-discuss] FBx Configuration Management

[Michael Williams]

I'm interested in putting effort towards this too.

To add to what you said, I think we should definitely have fine
grained access control to system-wide configuration. The idea of a
shared server resource between individuals has been dawning on me, so
I really want a way for people to share their FBx with other people,
and still let everyone configure their own services. This same concept
should expand to any type of server, not just plug servers.

Thanks for the sources. I'd love to see the decisions you make between
what you said, so keep us posted.

About the current Plinth set-up, I'm interested in making a per-module
platform using zeromq (http://zguide.zeromq.org/page:all) and zerorpc
(https://github.com/dotcloud/zerorpc-python) instead of python
modules. I like the idea of allowing services to be written in any
language they want, as long as they abide by a common message-passing
protocol. I can imagine the topology being:

client -> front-end -> per-user service -> per-user/per-module service

OR

client -> front-end -> system-wide/per-module service.

I wish I could make a usable example of what I mean before the
hackfest, but I'm busy with other projects.

Cheers,
Michael

On Wed, Jun 20, 2012 at 7:16 PM,  <bnewbold at robocracy.org> wrote:
>
> 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 at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss