[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dotdee: a proposal for improving conffile management in Debian



Hi,

On Fri, 29 Apr 2011, Dustin Kirkland wrote:
> As Ubuntu Server Core Developer and Packager, I'm quite keen on
> improving two problems we encounter frequently, with respect to
> conffiles:

I would also like to solve those problems.

> PROPOSAL
> 
> Here, I'm proposing a tool called "dotdee" that I think would greatly
> benefit Debian and Debian-derived distributions such as Ubuntu.  Its
> stated goal is to turn any given flat file on your system to a
> dynamically concatenated flat file generated from a unique ".d"
> directory dedicated to that particular file.  With such a dedicated
> and well-formed directory, system administrators, Debian packagers,
> and distributions could conveniently place additional configuration
> snippets in particular conffile's dedicated ".d" directory.

I don't want to go into details but I also do not believe that dotdee is
a complete answer to the problem. It just doesn't scale to all the
configuration file format that we can encounter and it's not clean enough
to be able to use it in other packages.

Let me explain what I would suggest to solve the problem. The root problem
is that dpkg is not flexible enough to manage the configuration files, and
it probably never will be. It just doesn't have the required knowledge.
However it knows when the package tries to upgrade the configuration file
and it installs the file itself.

I propose that we take out of dpkg the knowledge required to install a
configuration file. dpkg would still provide the default configuration
handler that implements the prompt that we know today but we should be
able to replace it easily.

By default, dpkg would use a program named dpkg-conffile-handler to
install new configuration files. That program would in fact be an
alternatives pointing by default to the default configuration file handler
provided by dpkg (the one we have now and that prompts us).  Other
configuration handlers could be registered in the alternative... for
example one using a VCS to manage the configuration files, etc.

It would also be possible to override the choice of the default
configuration file handler for specific configuration files using
configuration snippets put in .d directories:
- /lib/dpkg/conffile-handling.d/ could be used by packages that want
  to generate their configuration files or use something more complicated
  than what dpkg offers (for example with ucf, or a script using Config::Model)
- /etc/dpkg/conffile-handling.d/ could be used by the local admin to
  further override everything

dotdee could be one tool that the administrator could use as configuration
file handler but it doesn't need to be the only one. And you don't need to
divert the original file, dpkg takes care of all that part implicitly. The
admin would just do something like this:
# echo "handler /etc/foo.conf dotdee" >/etc/dpkg/conffile-handling.d/foo
# dotdee --setup /etc/foo.conf

With this solution it's also easy for a package to setup a custom conffile
handler to take over another conffile or to pre/post-process it.

There's quite some work left to define the interface that the
dpkg-conffile-handler programs must implement, and to the way the override
would work but I think this would be a clean solution to all the problems
that annoy you.

What do you think ?

> But in the mean time, what do you think?  Have you encountered similar
> problems before?  What other approaches have been taken to try and
> solve this?  What parts of this proposal do you think are reasonable?
> Are any parts completely unreasonable?  Are there extensions or
> changes you propose?

While dotdee could be acceptable for local admins to use, I think it's far
from being acceptable for official Debian packages. It really looks like
taking over other files without any way for the local admin to keep
control on his configuration files.

I think my proposal is way better in this regard.

Up to now, all the people who have had those problems dealt with them with
tools that overwrite entirely the configuration files and never took care
to think about proper integration in packages.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)


Reply to: