Re: system-config-dns?

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

On Fri, 2005-07-22 at 08:05 +0800, John Summerfied wrote:
> Chester R. Hosey wrote:
> 
> > 
> > MMC sucks, but it sucks somewhat less because at least it provides a
> > single management point for administrators. If someone were sufficiently
> > demented they could probably do something similar with UNIX tools;
> > provide an extensible general console interface to which one could add
> > plugins for Apache, BIND, Nagios, ...
> > 
> > The problem is being able to manage integration without making the
> > original service dependent upon the configuration console. This means
> 
> Why is that bad?

Because when you can use various methods of configuring the program, it
works for someone wanting to write an MMC plugin for Apache, or a nifty-
KDE-config-tool plugin, or using the read-the-conf-file plugin...

It lets people maintain the status quo or use additional tools where
available. It also lets the programs integrate more naturally into the
environment where appropriate.

> > that the plugins would have to be able to parse and make changes to the
> > original configuration files; obviously this is a fun problem and one
> > that many people find more appealing than, say, working on new
> > functionality or bug fixes or taking out the trash.
> Use a directory:
> /etc/configurator.d/
> 
> Nothing to parse/edit. Lots of tools do that sort of thing already, it's 
> an established standard way of doing it.

I'm not sure what you mean by that. I typically use something
like /etc/apache/vhosts/ to store broken-out configuration snippets for
individual virtual hosts. This doesn't remove the requirement that
current tools be able to parse the configuration files -- what if I want
to change the serverroot for www.example.com? How does splitting a
configuration file up suddenly remove the need to be able to parse or
edit the configuration file?

> > The advantage of being Microsoft is that they're able to devote
> > resources to making all of their applications conform to their standards
> > to some degree; when you have the power to tell the IIS team that they
> > WILL do configuration via MMC you're better off than Red Hat trying to
> > tell the Apache guys that their configuration methods are now deprecated
> > whether they like it or not.
> 
> RH (and/or Fedora community) do the tools, Someone called RH has to 
> provide leadership.

If that is their goal, and I wish it were, then I agree wholeheartedly.

> Note that KDE has a plug-in configuration tool already, has had for 
> years. Gnome did, but whatever it does now sucks badly.
> 
> Note too that Debian has a standard configuration tool: it's called 
> debconf. _I_ don't particularly like it, and I especially don't like the 
> way many packages use (or don't use it, but it is there and lots of 
> people value it,
> 
> It has the ability to run in text-only environment (dialog), X-Windows 
> (xdialog) and I think there's a Gnome front-end for it too. It can also 
> use text editor as its front end, and it can be turned off.
> 
> Debian has the problem that, like RH*L, there's no central repository to 
> show what can/should be configured. /etc/configurator.d would provide that.

I'm not sure I understand /etc/configurator.d.

I believe that you're mistaken about the role of Debconf. Debconf is
meant to provide integration into the current environment and to let the
package configuration tools know about things that might affect it. It's
meant to configure the _package_ more than the program within the
package.

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.

Another example is asking whether to install a program as setuid root.
It's an installation question, not a configuration option.

> Some years ago I installed Mandtake and had a bit of a look at it. On 
> root's desktop there was a folder of configuration tools.
> 
> I've not use SuSE but from comments I've read, yast _is_ a centaralised 
> configuration tool.
> 
> 
> Note that tools need to work in text mode. Properly, The other dayI 
> wantedto tweek selinux, so I fired up system-config-security. All it let 
> me change was firewall stuff. However, run it on an X environment and I 
> can also tweek selinux. Not to the extent I wanted though.

Red Hat's tools have many shortcomings (I realize that EVERYONE's tools
have many shortcomings, Red Hat just seems to care less). I don't know
whether their goal is to be able to claim that they offer graphical
tools, or whether their goal is to actually provide useful ones. I'd
imagine that the tools are there more to allow them to tell customers
that they offer graphical tools -- they don't seem to be very concerned
with the shortcomings in the tools themselves.

Chet