configuration management

1 files changed, 101 insertions, 0 deletions

diff --git a/configuration.page b/configuration.page
new file mode 100644
index 0000000..8619b4a
--- /dev/null
+++ b/configuration.page
@@ -0,0 +1,101 @@
+# 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
+
+[http://augeas.net/index.html](Augeas) 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.
+
+[https://github.com/dod38fr/config-model/wiki](Config::Model) 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.
+
+[http://devstructure.github.com/blueprint/](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.
+
+### Other Tools
+
+* OpenWrt's UCI and LuCI
+* Puppet [http://www.aosabook.org/en/puppet.html](design writeup) (from "Architecture of Open Source Applications")
+* Chef: [http://www.cfengine.com/](Knife), 
+  http://wiki.opscode.com/display/chef/Chef+Solo
+* [http://joeyh.name/code/etckeeper/](etckeeper)
+* [https://en.wikipedia.org/wiki/Salt_(software)](Salt)
+* gconf
+* Quattor,
+* [https://juju.ubuntu.com/](Ubuntu JuJu)
+* SNMP
+* bcfg2
+
+### Reference
+
+* http://wiki.debian.org/FreedomBox/BoxConfiguration