

Re: Configuration management

Hi Matt,

On Sun, Mar 06, 2011 at 03:55:49PM +0000, Matt Willsher wrote:
I have an interest in automation and configuration management and became aware of Pure Blends on another list thanks the Jonas' input.

If I understand correctly, in Pure Blend ideal, configuration is controlled as a function of the software packages via debconf. This then provides a consistent interface packaging a variety of target distributions of Debian with much of the heavy lifting done at image creation time. This system is then used to provide a consistent way of applying user configuration items to the individual packages once the system is deployed. This has many benefits: the package maintainer has control over the changes so can best manage how they integrate, there is a standard way of configuring software, it allows for a module approach to software management as the person dealing with a package doesn't need to know about the internal configuration format used by the software.

So, some questions:

Is the above a fair assessment of the current state?

To some extend, yes.

Debconf is not an "Only True Way (tm)", it just happens to be the most sensible for handling some (not all) configuration needs.

How do you see this goal being achieved? Where is the now on the road to
this goal?
What needs to be done?

These cannot be answered generally: It depends on the configuration needs of each specific Debian Pure Blend.

Some blends are so well integrated that they are not called "Debian Pure Blends" at all - e.g. "GNOME Desktop" and "KDE Desktop". They unfold nicely from standard Debian install routines. Not to say there is no room for improvements at lots of places, just that these can be considered well beyond the "prdouction ready" mark.

Some blends need more complex configuration which is not yet possible in Debian. An example is Debian Edu - see http://bugs.debian.org/370342 for an example of their (very few remaining!) needs.

How much buy in is there from the broader Debian community?

What does that mean?

How would complex configurations be handles? (e.g. BIND configuration and zone files) ?

Depends on each package involved - both technically on its configfile formats (e.g. ability to consume config.d folders) and practically on the interest of the package maintainer(s) in taking the responsibility to _maintain_ the wanted configuration flexibility.

One possible construct with bind9 could be to a) provide the zone files in a separate package, b) have the bind9 package improved to include all config snippets below /etc/bind/include.d and then c) provide with the zone file package an appropriate config snippet.

Another construct with bind9 could be to a) have the bind9 package improved to provide debconf mechanism to create zones. This IMO would be a lousy approach, however, as debconf is geared towards few general questions which is seldom enough to setup a senible zone file.

One _approach_ could be to first file a wishlist bugreport about the needed configuration flexibility, then try implement the envisioned mechanism locally provide patches.

Would make good sense to join forces with e.g. the package maintainers of resolvconf, as they no doubt are running into similar problems.

How can duplication of data be avoided?

I don't understand - could you give an example?


 - Jonas

 * Jonas Smedegaard - idealist & Internet-arkitekt


Attachment: signature.asc
Description: Digital signature

Reply to: