Date: Sat, 24 Feb 2001 16:29:51 -0700 From: Wes Peters <wes@softweyr.com> To: Terry Lambert <tlambert@primenet.com> Cc: arch@freebsd.org Subject: Re: Configuration management Message-ID: <3A9843EF.9406F8FB@softweyr.com> References: <200102232342.QAA01378@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:
>
> > > Storing program-specific configuration data for many diverse applications
> > > in a single file is (A) a stupid idea, (B) a stupid idea, and most
> > > importantly (C) ... a stupid idea. Having config parameters all
> > > in one place does not magically make the idiot tring to manipulate
> > > them any better at his job, but it sure makes it more likely that he
> > > will take the whole system down with him when he does make a mistake!
> >
> > <agreement type=violent>
> > Nor does stuffing a GUI on top of said configuration data, no matter where
> > it is located, give somebody the experience to operate a complex system.
> > Knowing how to do something does not imply knowing what to do.
> > </agreement>
>
> The lack of a configuration data API, and a common configuration
> file layout syntax has been a problem with UNIX since day 1.
>
> When you learn how to configure one program, the knowledge is
> not transferrable over to another program; you must relearn it
> for each program, which make UNIX unnecessarily dense, with an
> unnecessarily high learning curve, but with no benefit of having
> achieved a greater altitude for having climbed N of these curves,
> as opposed to N-1 of these curves.
>
> Further, the lack of a single data channel to which the API talks
> means that proxy configuration of a number of machines can't be
> done over a network. Nor can one multiplex the proxy stream to
> change machine independent data on a large number of machines
> simultaneously. Neither can computable machine specific data be
> handled this way (e.g. renumbering a network).
>
> Additionally, when a GUI is provided, even if that GUI is not
> a direct representation of the configuration hierarchy, or it
> abstracts the complexity to a level usable by an end user at
> any given level of capability (as the MVC -- Model, View,
> Controller -- paradigm favored by Activity Theory and HCI --
> Human Computer Interaction -- dictates should be done), it is
> _gratuitously_ difficult to supply, due to the exhausting number
> of back end interfaces which have to be written.
>
> So _you_ don't want a GUI: BFD. So _you_ don't want to do
> cluster configuration: BFD. So _you_ don't want to do role
> based configuration of subsets of a cluster spread over
> multiple colocation facilities: BFD.
>
> The point is that just because some people don't see a need
> for something doesn't make it useless. Ask the next Amish
> person you meet whether or not there should be cars; then
> tell me if you're prepared to give up your car, if you have
> one.
Nothing written in this thread by either myself OR Matt disagreed
with anything you wrote; why do you take such an argumentative
approach?
> Even if we stick with "flat text files", and we continue to
> edit them by hand, instead of using a method with subschema
> inforcement which makes non-sensical configurations impossible
> (per Jordan's XML example), the idea that it should be _possible_
> to easily and efficiently machine parse and write these files
> using a single API, which can be proxied over a network through
> a single data channel, is a valid one.
Nobody said it wasn't. This is, however, one of the dichotomies faced
(and not yet handled) by the UNIX community: the importance of a single
machine vs. the importance of a large pool of machines.
Somebody like Yahoo!, for instance, really wouldn't care much if one of
their thousands of machines was currently not booting, but desperately
needs to be able to manage those thousands as a single entity. Those
running the freebsd.org ftp server, on the other hand, very much need
that one machine to be quickly fixable if it does go down, since it is
the "crown jewel" in that installation.
Your point that facilitating the management of thousands of machines
doesn't necessarily destroy the ability to manage one is true, but so
far I haven't seen a tool that purports to do the former while
preserving the latter. Preserving the latter is critically important
to much of the FreeBSD user base; probably more so than managing
thousands of machines.
I doubt you'll find very many people more experienced at reading and
processing the configuration files on different variants of UNIX than
I. Having a consistent API for processing such data would certainly
improve things, but only if it is done well. Storing configuration
data on a server on the network may work if the network is just as
important as the server, but that is not the case for the average
FreeBSD machine.
There is an interesting opportunity here for somebody adventurous and
not afraid of hard work to set about converting FreeBSD (or any other
source-available operating system) to a test case for a new management
framework. Gathering up all the various configuration files or data
stores on a system and replacing them with, say, an XML representation
of the same data would be an interesting project. Providing legacy APIs,
like getpwent, etc., that used the XML format, as well as providing the
new API you would like to see would be a straightforward, if somewhat
monumental task. This sounds like work for a graduate researcher with
some undergrad (i.e. underPAID) programmers at his disposal.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A9843EF.9406F8FB>