1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
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)
|
