Re: system-config-dns?

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

On Thu, 2005-07-21 at 15:46 -0500, Ed Wilts wrote:
> On Thu, Jul 21, 2005 at 01:29:49PM -0700, Shane Stixrud wrote:
> > RedHat is attempting to address 
> > this by creating GUI configuration and management applications but this 
> > effort is hampered by the enormous effort required in writing a custom 
> > application for every subsystem / application, resulting in mostly useless 
> > gui applications.
> > 
> > I believe what enterprises really want is not a "gui application front 
> > end" for every application.  They want an intuitive method for 
> > managing/configuring the system and installed applications, that is 
> > consistent and supportable (i.e. reasonable).
> 
> Nobody has a consistent method for managing and configuring the system
> today.  Not Microsoft, not Sun, not HP, and not Red Hat.

Microsoft Management Console at least provides an interface from which
administrators can make configuration changes, restart services, etc.,
even for remote machines. Programs which include MMC snapins at least
provide the administrator with a single place from which they can
configure and manage services.

> Microsoft gives us a Registry with a strong disclaimer that if you edit
> it, you're on your own.  Every application in Windows has a different
> mechanism for configuring it.  You may have a gui application, you may
> have text-config files, or you may have to edit the registry directly.
> They all suck.

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
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.

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.

Of course if the application could be designed such that the
configuration-loading portion spoke with the rest of the application via
a well-defined interface the problem would be somewhat easier to
approach.

> > The problem is deep rooted in our culture where every 
> > application/subsystem author has written their own method for 
> > configuration and management, not because they needed or wanted too... but 
> > because there is no accepted/standard alternative.
> 
> That's a cross-platform complaint.  It's perfectly valid, though.  

Not with MMC! It provides a unified management interface that isn't even
REMOTELY cross-platform.

*mumbles something about the cure being worse than the symptoms*

Chet