diff options
Diffstat (limited to 'research/configuration.page')
| -rw-r--r-- | research/configuration.page | 108 |
1 files changed, 108 insertions, 0 deletions
diff --git a/research/configuration.page b/research/configuration.page new file mode 100644 index 0000000..0357b79 --- /dev/null +++ b/research/configuration.page @@ -0,0 +1,108 @@ +# Configuration Management + +A significant improvement over the status quo of router configuration +management interfaces is one of the most important design challanges for the +rooter software stack. + +The problem could be split between "configuration management tools" (which +would present a unified low-level interface to system and application +configuration) and any "configuration interface" (which could be a web/http UI, +command line apps, remote APIs, whatever) built on top of those tools. + +### Needs + +The scope of configuration includes routing and firewall policy, package +versioning, web applications, mesh or tunneling configuration, radio channels +and power, authentication and accounts, and more. + +Technical goals: + +* as complete as possible (twiddling all knobs through the same interface) +* version controlled and transferable +* low hassle for new software packages (aka, minimal "porting" effort) +* UI agnostic libraries + +Usability goals: + +* auto-updatable without overwriting local customizations +* ability to report the impacts of changesets before commiting +* able to revert any individual change, and take named/dated snapshots/profiles +* easy to share and apply configuration "patches" + +### Open Questions + +* how are type checking and exception recovery handled? +* should applications have access to system configuration? +* have fine grained access control or all root/admin powers? +* provide "expert system" advice and warnings? + +### OpenWrt's UCI and LuCI + +OpenWrt's approach to configuration management is the Unified Configuration +Interface (UCI); the LuCI web interface programatically generates configuration +forms based on UCI definitions. It's written in Lua. + +UCI defines it's own standard configuration file format and stores +configurations for each service in /etc/config/ (these can be edited from the +command line). It then wisely (catching many corner cases) and efficiently +(only restarting the services that need to be restarted) implements any +differences between the configuration files and the running state of the +system. + +Any additional services (in OpenWrt's ipkg package repository) need to +implement UCI/LuCI compatability on their own, sometimes with a seperate +*-luci helper package. + +### Augeas, Config::Model, Blueprint + +[Augeas](http://augeas.net/index.html) is a C library and collection of +"lenses" which allow the manipulation of many types of configuration files +through a standard treee/heirarchy interface. It is careful about not +overwriting locally edited changes or even whiping out comments. It does not do +any type checking of files. + +[Config::Model](https://github.com/dod38fr/config-model/wiki) is a perl project +that both replicates a lot of the functionality of Augeas and can be run on top +of Augeas. It seems to be debian specific, unclear how far along implementation +is. + +[Blueprint](http://devstructure.github.com/blueprint/) is a system to "reverse +engineer" configuration changes on Linux (UNIX?) systems. It is written in +python and makes use of git for a storage backend. It includes tools for +generating, version controlling, diffing, sharing, etc. It captures dpkg and +rpm package information, locally edited configuration files, upstart/init.d +configuration, and even source-installed software in /usr/local. It is not +particularly fast out-of-the-box (might be possible to speed up), and is not +oriented towards making small changes and having them applied immediately. + +I think that a good set of tools for rooter would be to use Augeas +for micro-scale tasks (like configuration files "in real time") and Blueprint +for macro-scale tasks (like snapshotting, sharing "patches", and version +controlling defaults). Also needed is a layer on top of Augeas to manage higher +level logic and service restarts; Config::Model might fill that role, or +perhaps components of UCI could be extracted. + +### Bonus Features and Ideas + +Could host a (centralized?) configuration sharing and upvoting site where +anybody could post snazzy configuration patchsets. Searchable by tags? +Mark/vote as insecure or problematic? Comment/discuss/improve? + +### Other Tools + +* OpenWrt's UCI and LuCI +* Puppet [http://www.aosabook.org/en/puppet.html](design writeup) (from "Architecture of Open Source Applications") +* Chef: Knife, [Solo](http://wiki.opscode.com/display/chef/Chef+Solo) +* Cfengine ([http://blog.normation.com/2011/02/23/why-we-use-cfengine-memory-footprint](2011 blog post on low memory usage)) +* [etckeeper](http://joeyh.name/code/etckeeper/) +* [salt](https://en.wikipedia.org/wiki/Salt_(software)) +* gconf +* Quattor +* [Ubuntu JuJu](https://juju.ubuntu.com/) +* SNMP +* bcfg2 + +### Reference + +* [FBx configuration](http://wiki.debian.org/FreedomBox/BoxConfiguration) + |