Date: Wed, 28 Mar 2001 09:05:19 -0800 From: Jack Rusher <jar@integratus.com> To: Terry Lambert <tlambert@primenet.com> Cc: "freebsd-arch@FreeBSD.ORG" <freebsd-arch@FreeBSD.ORG> Subject: Re: configuration files Message-ID: <3AC219CF.B1716422@integratus.com> References: <200103281243.FAA03936@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > > > 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). > 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. > 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. > 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. > 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. -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.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?3AC219CF.B1716422>