[bind10-dev] on configuration

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

here are some thoughts about configuration i had after a short discussion with
shane. Consider it thinking-aloud, and very abstract (nothing API yet), just to
start possible discussion.

Traditional configuration:

Read .conf file on startup, config can be re-read by reconfig
command, where some options that require a restart are ignored
i.e. bind -c <config file>



(pure) 'live' configuration:

Instead of a config file, configuration options are set as 'knobs' in an
already running system (think bind-ctl set  <option> <value>). On exit or
specific command, the configuration is stored, and re-read when started
again. This needs:
	- standard on-change functions for every setting (though these
	  could simply do nothing or return an can't-change-like-this
	  error)
	- very conservative defaults on first startup (as it takes time
	  to turn the knop, even if scripted somehow)
	- configuration (de)serialization, for storage and retrieval, and
	  perhaps replication
	- some form of transactions, where changed values aren't applied
	  until the script or administrator is done setting them

If you add a component, it will add it's configurations settings to the
configuration store. By having settings in there, the module could be
automatically included on next start. We could add something like an
'enabled' value, so we could remember settings for disabled components).


If we would be heading this way, we could have a tool that reads bind9
configuration files and translates that into one transaction with a list
of knob-turning events (bind-ctl --import-settings <file), or we could
start with in form of 'fixed config' mode, where the configuration is
read on startup, and every call to change an option in a running system
except 're-read config' returns an error. (bind --bind9-config <file> or
something)

We could also use something like this for replication; just tell a server
to get all its settings from another one (bind --replicate <server>).
This would need some form of authentication, and we would need to figure
out which options are host-specific, and when (interface addresses may be
different for different nodes, but then again, they might not). In this
mode, it should also deny any local changes made. And we would need some
notification system for when something changes in the server we're
replicating from.

The best solution could very well end up being something halfway between
live and static configuration, but if the options aren't clearly separated
(and could live in both) we'd have to be really careful about them getting
out of sync. A big danger is making it way too complicated (which is
actually one of the bigger issues i've heard about bind9 recently), and
the simpler the better.

Jelte


Some quick research notes:

Gconf:

This is the settings manager for GNOME applications.
Containing key-value pairs. While it has a replaceable backed, afaik the
only one currently in use is a filesystem tree of xml files.

A daemon keeps track of the settings and notifies applications if
something has changed. Again, the actual transport used is replaceable,
but at the moment it uses CORBA.

The system seems underfeatured in some regards (no transactions), and
over the top in others, but that's probably because it is more focused on
desktop systems and multiple applications that use it.

http://developer.gnome.org/feature/archive/gconf/impl.html


Firefox:

Firefox uses an in-memory store of (name, status, type, value) tuples.
The name is actually a dot-separated list of names, where grouped
settings share the same prefix. From the API point of view, this results
in a settings tree where you can request either sub-trees or specific
values (getBranch("extensions.noscript") gives you a smaller tree with
all settings for the noscript extension, but this is more of a convention
to fit the API than it is enforced).

If an extension is installed, it will add defaults for the configuration
option it needs to the generate config store.

The store is implemented as an XPCOM service, see
https://developer.mozilla.org/en/Code_snippets/Preferences

You can add observers to settings, providing a callback to be run
whenever the settings change (although most extensions i've seen simply
read the config value whenever they need them, and don't cache them
locally).

Again, unfortunately, no transactions.


Uniconf:

haven't looked much into this yet, but it does look promising; is
sounds like a more general approach to what gconf is trying to achieve
 for the desktop. And it has transactions ;)

http://alumnit.ca/wiki/index.php?page=UniConf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqWfv8ACgkQ4nZCKsdOncVAHgCfeoTLUe5vr28H6TTq2p++xGpA
RqYAnjsvmlrfz6uwxUyVr8Ij+3zc/FdG
=77Qo
-----END PGP SIGNATURE-----