Re: system-config-dns?

["Chester R. Hosey" <Chester Hosey gianteagle com>]

On Sat, 2005-07-23 at 08:08 +0800, John Summerfied wrote:
> Chester R. Hosey wrote:
> 
> > I'll not comment because I'm still not clear on how the implementation
> > would work, and I don't grok the high-level description. It's very hard
> > for me to imagine a mechanism which describes a general configuration
> > interface which will allow any program to interact with any
> > configuration tool without any specific glue for each program or
> > interface layer.
> 
> OTOH your difficulty understanding it completely escapes me.
> 
> I don't see that what I describe is so different from what webmin does. 
> The specific objections to webmin I've seen here I can understand 
> because I've used webmin and looked at bits of its code, but those 
> objections don't make the basic idea unsound.

You haven't really provided a description of what it is and how it
functions. You name some random directory as a method of matching an
arbitrary configuration mechanism with an arbitrary set of programs.

That doesn't do much to describe the format of these arbitrary entries.
Does it describe the magic necessary to restart a given service, or to
get it to reload configuration? Does this magic mechanism work if
configuration is stored in LDAP instead of text files? Where can I find
documentation on /etc/integrate-everything-magically.d/?

> > Does it also configure your virtual host setup? What about the myriad of
> > other configuration options? For example, does debconf attempt to set up
> > Apache beyond setting a few system defaults?
> 
> I don't know of any comprehensive tool that configures anything on 
> Linux, using debconf or any other API, excapt maybe Webmin and Linuxconf.
> > 
> > Can you provide a single example of a highly configurable program for
> > which debconf is intended to provide post-installation configuration?
> > 
> > In fact, apt-cache show debconf includes the following description:
> > 
> > 	Debconf is a configuration management system for debian (sic)
> > 	packages. Packages use Debconf to ask questions when they are
> > 	installed.
> > 
> > It says nothing of configuration beyond the initial installation.
> 
> man dpkg-reconfigure

I've used dpkg-reconfigure. The point is that it's meant for
installation-time questions. You can choose other options without
reinstalling the package, but the debconf tools simply aren't intended
for program configuration, only package configuration.

Man dpkg-reconfigure on my Debian machine reads: "dpkg-reconfigure
reconfigures packages after they have already been installed". Packages,
not programs. My interpretation of some statements by Joey Hess is that
he wants debconf to interoperate with text-based configuration, not to
replace it.

Comprehensive configuration doesn't seem to be a goal of debconf. If you
can show me a *single* program with complex configuration needs which
attempts to be fully configurable via debconf, perhaps I'll reconsider
my position, especially if you can point to discussions among Debian
developers that it's "the Debian way" to do it.

> >>>For instance, do you want to run Samba as a daemon or from inetd? It
> >>>affects whether the postinst script will send a -HUP to inetd. It makes
> >>>NO attempt to help you configure Samba itself.
> >>
> >>Here's a Samba question:
> >>
> >>Name: samba-common/dhcp
> >>Default: false
> >>Description: Modify smb.conf to use WINS settings from DHCP?
> >>D
> > 
> > 
> > That deals with the interoperation between two packages, and thus might
> > be a valid meta-question about installation. I don't know details, but a
> > single example isn't conclusive.
> 
> Feel free to take a look at a templates file for yourself.

What does looking at a templates file have to do with it?

Surely someone *could* use debconf for advanced configuration, but I'm
not clear that doing so is the goal of debconf.

In fact, debconf retains its own repository of options you've selected;
it doesn't even attempt to determine whether you've changed the
configuration in the program's main file. If you enable mod_gzip via
debconf later disable the entry in httpd.conf, debconf will happily
reenable it on the next package upgrade. To me, this would indicate that
debconf isn't intended to interact to a significant degree with normal
configuration methods. Forcing the user to use a particular mechanism
doesn't sound like "the Debian way" to me.

Why would debconf maintain a separate repository of configuration
options if it were intended to track *exactly* the same thing that the
actual configuration files do? I could understand *additional* meta-
values that don't belong in the configuration file being tracked, but if
debconf is intended to become an all-singing, all-dancing configurator I
can't see how it serves the purpose well to force configuration values
to be changed in two places; it assumes too much about whether there are
other configuration mechanisms in place.

> >>>Another example is asking whether to install a program as setuid root.
> >>>It's an installation question, not a configuration option.
> >>
> >>:-)
> >>That's a Q should never be asked. Few users are competant to answer it. 
> >>The packager needs to make an executive decision that will work.
> > 
> > 
> > That's why debconf allows priority levels, to allow administrators to
> > indicate how much they want to be bothered by the more mundane
> > decisions. However, it's an appropriate question to ask if the verbosity
> > is set sufficiently high. It's also a great question to ask, because it
> > will allow debconf to remember your preference across upgrades. I didn't
> > say that it was a good question to ask EVERYONE, but it is an
> > appropriate type of question to be asking at install time if the user
> > has requested such a level of choice to be presented, which is
> > orthogonal to the question of configuration mechanism.
> 
> I've not noticed anyone complaining recently about Red Hat choosing to 
> make binaries setuid or not: as I recall Debian asks this about man and 
> cdrecord whereas RH has made an executive decision that works.
> 
> I have seen the question, and while I can make a somewhat-informed 
> decision, my daughter, who has installed Ubuntu, cannot: if she makes a 
> choice it would be almost completely random.
> 
> I don't think Ubuntu asks either. The Ubuntu team has also made an 
> executive decision to use sudo to determine who can administer stuff; 
> while the default setup isn't so very different, it does greatly 
> facilitate distribution of administrative tasks.

Again, quoting myself, "that's why debconf allows priority levels". You
can ask it to make decisions for you, or choose to have it ask you
everything. If the user-as-admin asks the distribution to give them
every possible option, then it's not quite the distribution's fault that
they don't understand what setuid is or is not. A lot of packages will
suggest reasonable defaults even while asking. A lot of the questions I
see are a result of the fact that I explictly *asked* to be given these
choices; had I not done so, I'd never have seen the options either.

A more robust UI might remind them how to reduce the verbosity, but
that's another issue.