On 6 March 2011 16:50, Jonas Smedegaard
<dr@jones.dk> wrote:
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.
From what I've seen of debconf that hooks it provides tend to be limited 'get you up and running' sort of configurations. Let say, for instance, I'm a particular security requirement for my blend that dictate only certain ssh ciphers are allowed. The ssh debconf doesn't provide an interface for that. That leaves only the option of hacking at the file outside of debconf and the openssh-server packages control, which I gather isn't ideal in the Pure Blend model. I could submit a patch to the openssh-server package maintainer. But then so could others for other options particular to their requirements. Before you know, the package is handling every SSH configuration option. Is this the aim? If not, what is controlling those option? What if the user wants to tweak an option? Is that via the debconf interface too?
The docs for the Pure Blend under
http://wiki.debian.org/DebianPureBlends#Preconfigurethepackagesweinstall mention the use of cfengine. How and why does that fit in? Why not use that for most cases and provide consistency? It could even call the debconf bits if need be. Common promises and functions could be distributed as part of the packages. It's like debconf on steroids isn't it?
If debconf isn't the 'One True Way(tm)' what other ways are their that maintain a seamless experience for the user?
How do you see this goal being achieved? Where is the now on the road to
this goal?
What needs to be done?
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.
How does the additional configuration ( I want a pretty wallpaper for my security distro on GNOME) fit into a Pure Blend? Would it be expected that there be a metapackage with the wallpaper in, perhaps with the other dependencies and suggestions?
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.
That looks like it isn't because it's pending an architectural change, just that no patch has been produced for the package to provide the debconf hooks?
How much buy in is there from the broader Debian community?
What does that mean?
The configuration requirements for packages could be quite onerous on the packager. Do packagers generally accept the improvements and requests submitted to them? Do they sign up to the idea of a Debian Pure Blend? Do they even reject patches?
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.
But if I'm managing my zone and I web to add a record through my fancy web UI, who touches the config files? the BIND package debconf hooks, the web app, something else? What about those files at already exist, like the options file? Should the web app be changing that? If it did, doesn't that cause upgrade problems with config merges?
How can duplication of data be avoided?
I don't understand - could you give an example?
Take the SSH example above. Not only do we have a ban on some ciphers in SSH we want them banned across all packages on the system. mod_ssl isn't to use them, neither should any other TLS/SSL using software. If each package is managing it's own config there isn't a central configuration with out providing additional scaffolding. And then it's dependant on the package being able to apply it's configuration.
Kind regards,
Matt