Re: system-config-dns?

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

On Tue, 2005-07-26 at 10:07 +0800, John Summerfied wrote:
> I propose a directory as the means of locating the configuration tools 
> because it's a concept that's well-understood, well-tested and which 
> works well.
> 
> As to what's actually stored there and its format, I don't care a lot. 
> _I_'d not use XML because I don't understand it and it looks too 
> complicated to me. However, XML seems the be the current fad.

I'm not talking about the base format, but what is the structure and
type of the actual information to be stored.

> In this case, we might have a means of calling elinks to run SWAT to 
> configure Samba.
>
> I do not propose any means of accessing files because there are so many 
> file formats and (as you note) storage media such as LDAP and MySQL.
> 
> What the individual tools do, I don't care a lot but editing & checking 
> configuration data is pretty obvious. Interfacing to chkconfig and 
> update-rc.d (Debian) & service to control when daemons run seem sensible.

So it's a matter of merely launching an external program for
configuration purposes, perhaps with some extra scripts for
starting/stopping/restarting? Sounds... not very robust.

> I would hope that at some point the individual configuration tools 
> become part of the code-base for their application; when ISC adds some 
> new syntactic element to their BIND or DHCP or INN products, it would be 
> a Good Thing if the configuration tool can recognise and check new 
> elements immediately.

So you're proposing that individual applications write their own
configuration tools? That makes sense to the extent that it might be
useful in a minimal way, but what about network-transparent
configuration? If I have to ssh into each machine to perform tasks,
that's a point against an argument for that tool. I can ssh in now; I
know how to restart services now, and it's not difficult; I can
reconfigure each tool now, and again it's not generally difficult. The
idea is to have a tool which allows systematic configuration from one
place.

A menu calling vendor-supplied configuration tools is papering over the
problem to some extent. Does it solve it? To some degree. Does it offer
many advantages over the current situation? That's debatable. You'll
still have differing configuration mechanisms unless you declare that
the world *must* use some well-defined mechanism which provides front-
ends for a terminal, X, Windows, etc. Unless you can pull that off you
*still* haven't solved the initial problem of having completely
different systems. You have, however, given it a pretty menu interface.

> > 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.
> 
> I mentioned debconf because
> a. It is a standard way of configuring stuff
> b. It has a variety of user interfaces including both text and GUI 
> alternatives.

Aye, and those are points against which I'm not arguing.

> Whatever it is intended to do, as far as I can see there is quite a deal 
> it _can_ do, that it _does_ do. It sets the port number for Apache. Is 
> that application configuration or package configuraton?

You seem to be arguing that the line isn't clear. I agree with you, but
again debconf doesn't parse the app configuration files and it doesn't
attempt to do so. Your argument that debconf is a standard configuration
mechanism and offers several UI choices doesn't change the fact that
it's not a generic configurator, but a tool designed for a specific task
(allowing admins to make installation choices which persist across
upgrades) which wouldn't be appropriate for others (allowing users to
edit the configuration files while also using debconf for
configuration).

In this case, there *might* be a mechanism by which, say, someone
writing a firewall tool can poll debconf to find out what port Apache is
supposed to be listening on so that it knows to make the port available
externally.

You could thus make a case that this is something which might affect
external packages that don't necessarily need to know how to parse an
Apache configuration file.

> It does not do a complete job of configuring apache, but that's a packer 
> decision.

Only in that it's not really the point of debconf. Could it do the job?
Sure! Would it make everyone mad when it constantly overwrote your
Apache configuration because debconf makes no effort to track changes to
the configuration file itself? Absolutely!

That's a big complaint I've heard about other tools (poor config file
integration). Don't make people hate debconf too.

> > 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;
> 
> Indeed. I think it's a bad idea, and I quickly decided not to use esmith 
> because it does just that.

It's not a bad idea for a tool that isn't intended for generic
configuration.

> I don't put it forward as a complete configuration tool, and its 
> shortcomings (on which we seem to agree) are not relevant to the point I 
> sought to make.

Then I'm mistaken -- it seemed to me that you were. Take that as a fault
in my interpretation; we do seem to agree on things more than it
initially seemed to me.

I keep wanting to say something about how I don't understand why Red Hat
doesn't attempt to do more to address this and other problems, but Ed
Wilts has already addressed that in an earlier response in which he
reminded me that Red Hat doesn't sell applications, only the packaging
and support services.

I suppose Red Hat and I differ regarding the extent to which I think
that "packaging" should include a commitment towards integration into a
coherent whole. They do make efforts in certain areas, but in the area
this thread originally tried to address they don't seem to be committed
at this point (I submit as proof the lack of update to the documentation
and the suggestion that one not expect the GUI tools to serve all
configuration needs for even simpler tasks).

Chet