From owner-freebsd-arch Wed Mar 28 13:51:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 6225A37B722 for ; Wed, 28 Mar 2001 13:51:39 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id OAA00165; Wed, 28 Mar 2001 14:48:09 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpdAAAVRa4ra; Wed Mar 28 14:48:07 2001 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id OAA12651; Wed, 28 Mar 2001 14:51:30 -0700 (MST) From: Terry Lambert Message-Id: <200103282151.OAA12651@usr02.primenet.com> Subject: Re: configuration files To: jar@integratus.com (Jack Rusher) Date: Wed, 28 Mar 2001 21:51:30 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), freebsd-arch@FreeBSD.ORG (freebsd-arch@FreeBSD.ORG) In-Reply-To: <3AC219CF.B1716422@integratus.com> from "Jack Rusher" at Mar 28, 2001 09:05:19 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > 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