Re: dotdee: a proposal for improving conffile management in Debian
On Tue, May 3, 2011 at 1:30 AM, Guillem Jover <guillem@debian.org> wrote:
> Hi!
>
> On Fri, 2011-04-29 at 11:03:39 -0500, Dustin Kirkland wrote:
>> IN PRACTICE
>
>> Once integrated with dpkg, I'd like dotdee to be a utility that human
>> system administrators could run to manually turn a generic conffile
>> into a ".d" style configuration directory, such that they could append
>> their own changes to some numbered file in the dotdee directory, avoid
>> the interactive dpkg-conffile-changed prompts.
>
> This does not take into account admins dropping the file under the
> directory and then the package picking up the new file automatically,
> they have to generate it manually afterwards. You mention apache, and
> its framework (another good example is pam), but I don't think that
> much is usually needed, just having the application support .d config
> directories should be enough, and that usually implies less than around
> 50 lines of C. This also benefits upstream and all its downstreams,
> and people building directly from sources. Also this implies the
> configuration file cannot be directly edited, and if done so the
> changes will get lost on the next regeneration.
>
> As a counter example, a package that provides something similar to
> dotdee, there's exim4. And while I think the efforts by their
> maintainers to provide a more manageable way to configure it are
> worthwhile, it's also one of the reasons I always use the user managed
> single concatenated file. It's too annoying modifying a file and
> forgetting to run update-exim4.conf.
Postfix, too. I am certainly familiar with this problem :-)
> At some point in the future I
> should just sit down and propose a patch for native .d support.
I've had that feeling, I know. And I'm feeling that way about more
and more and more utilities. I just don't think I, you, or any of us
is going to actually getting around to "fixing" every service to
support a .d style configuration structure.
And that's at the crux of this discussion (whether it's dotdee that
solves this, or something else completely different). I'm
wondering/hoping/thinking about other ways we could approach this
problem, as a distribution, and talking to you, the maintainers of the
dpkg system itself. The landscape has changed quite a bit since the
original dpkg configuration file management policies were written.
a) there's what, 20K or 30K packages in Debian now?
b) people are deploying 10s of thousands of "managed" Debian and
Ubuntu servers in clouds, grids, and other data centers
c) these systems are managed by things like puppet, chef, and other
management systems, above and beyond individual package management
> In addition the combination of "diverting" the conffile, merging it
> back by a tool, and then using alternatives, seems pretty convoluted
> and a quite possible source of confusion and fragility.
Agreed, especially in the near term, it will be confusing to some.
The update-alternative part of dotdee's implementation is not entirely
necessary. It was simply used to make the alternatives discoverable,
and to manage the symlinks themselves in a well defined manner.
Further out, though, I think there's ample opportunity for
documentation and education.
>> More importantly, I would like one package's postinst maintainer
>> script to be able take another package that it depends upon and turn
>> its conffile into a dotdee managed file, such that it could append or
>> prepend configuration information necessary for proper operation.
>> This, of course, would require significant buy-in from Debian, and
>> entail various appropriate policy updates.
>
> That in essence is just diverting conffiles, and I think it's at least
> for distributions a bad idea, for personal use I don't see any problem
> with it though. If a package needs to modify the behaviour of another
> one it should do it in concordance with the other package, and not
> under its feet. Usually in that case the package provides an interface
> to modify the configuration file, or provides a .d config directory.
> That should currenty be described already in policy.
Understood. It's that part of the policy that I would like to see a
tool designed to work within the spirit of, but perhaps modernized and
extended a bit.
>> In terms of supported configuration file types, dotdee would
>> eventually need some code for handling some particular configuration
>> file types. The current, basic implementation works well for
>> sequentially evaluated file types (like sourced shell scripts), python
>> config parser, and even windows ini file syntax. On the other hand,
>> something like XML would not immediately work in the current dotdee
>> implementation. For that, I've thought a bit about a similar
>> approach, constructing the conffile from a quilt directory of numbered
>> patch files. If you're interested in this approach, I can describe
>> that in more detail, too, and perhaps implement another prototype.
>
> To be honest, that sounds like a hack to me. :) But if you are
> interested to still go this route, then maybe Config::Model might be
> useful to you? In any case, the application handling the configuration
> files is in the best place to know its internal layout, and how to
> handle it.
Oh, it's no doubt a hack! The current implementation of dotdee was
less than a day's worth of work and smoke testing. The goal was
simply to put together enough of a functional hack to generate some
discussion about it, and propose the idea as a potential approach.
Thanks for the Config::Model reference, as yes, this would be a useful library.
> So all in all, I don't think this is the right way to solve the problem
> you describe. And while I also think the conffile handling in dpkg can
> be improved, in this case the correct solution seems to me, to be to
> add .d support to the needed applications.
I'm a little de-motivated by that assessment, and I'd like to think
that we could do better in Debian, Ubuntu, and dpkg, but in any case,
thank you for your careful review!
--
:-Dustin
Dustin Kirkland
Ubuntu Core Developer
Reply to: