Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Mar 2001 21:51:30 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        jar@integratus.com (Jack Rusher)
Cc:        tlambert@primenet.com (Terry Lambert), freebsd-arch@FreeBSD.ORG (freebsd-arch@FreeBSD.ORG)
Subject:   Re: configuration files
Message-ID:  <200103282151.OAA12651@usr02.primenet.com>
In-Reply-To: <3AC219CF.B1716422@integratus.com> from "Jack Rusher" at Mar 28, 2001 09:05:19 AM

next in thread | previous in thread | raw e-mail | index | archive | help
> > > Excellent point - I did not consider the need to incrementally (atomically)
> > > update huge configuration stores while the server still acts on the old
> > > configuration.
> > 
> > It's my biggest peeve.  8-).
> 
>   I have always wondered whether it would be worth my while to create a
> VMS style versioning file system (everyone who remembers DEL *.*;* raise
> your hand) to hold configuration files.  It seems like a natural
> mechanism for this (although they didn't use it for that in VMS).

VMS versioning really depends on doing globbing in the kernel
instead of in user space.

Despite the fact that globbing in the kernel makes it so you
can pass back only the data matching your search criterian,
instead of all the data available, after which you iterate
through it again in user space, UNIX people really, really
tend to hate kernel globbing as a concept.

Without kernel globbing, you have to split up the namespace, and
hack both the FS (namespace folding) and the user land tools
(display versioning data from a seperate metadata request as a
result of being given an option to do so).  The result is that
everything except special tools only see the most recent version
of a file.  It ends up being really, really hackish, to the point
of not being worth the effort.


> > I think Apache would accept the change quickly.
> 
>   They have been slowly changing their file format to something XML like
> for ages.  I'm surprised they haven't made the cut over yet.

Yeah; I admit, Apache was an easy call.


> > BIND would probably accept it also, if people could keep their
> 
>   This would, of course, be harder.  It would probably be easier to
> change everything BUT the main configuration file in BIND9; they have
> hooks for zone file storage now.

I admit that that's messay, bit it's workable.  You could pretend
that you had multiple bifurcation points, and use XML metadata as
if the file were a directory, and you were accesseing files by
bifurcation point.  It's kind of the opposite of the namespace
folding you have to do to make versions work in UFS.


> > It would probably be easier to arrange a "takeover" mechanism as a
> > result of getting a HUP, where the open connections complete
> 
>   I appreciate the direction you're taking with this, and I feel your
> pain, but this is (as far as I can tell) a much harder problem than the
> one I am chasing right now.  The HUP mechanism is obviously a holdover
> from another time.  Hell, the whole signal handling mechanism is pretty
> whacked. If UNIX had been designed to support long lived servers, rather
> than short lived timesharing work, we would have a fourth default file
> descriptor called "stdcontrol" for passing out of band commands.  As it
> is, everyone has to fake it in their own special way.  Bummmer.

Uh... kevent? (Ducks).


> > I definitely agree; so long as there is sufficient metadata
> > involved to allow a UI component (text, graphical, libdialog,
> > whatever), it vastly simplifies adding UI to any configuration
> > in that format.
> > 
> > [...]
> >
> > Hierarchy is necessary to distinguish machine, cluster, site,
> > colocation facility, enterprise, and global configurations.  On
> > top of that, there is the concept of "role".  In other words, I
> > may have a set of machines, some of whom have the role "DNS
> > servers", some with the role "web servers", some with the role
> > "mail servers", etc..
> 
>   These are the sorts of things that I would to see become possible.  I
> think we need to build some cleaner infrastructure that doesn't
> immediately grant us any operational benefit in order to open the door
> to this sort of improvement.

People hit me with tomatoes when I say things like that...


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

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?200103282151.OAA12651>