Date: Wed, 28 Mar 2001 12:43:43 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jonathan@graehl.org (Jonathan Graehl) Cc: freebsd-arch@freebsd.org Subject: Re: configuration files Message-ID: <200103281243.FAA03936@usr05.primenet.com> In-Reply-To: <NCBBLOALCKKINBNNEDDLCEEDDNAA.jonathan@graehl.org> from "Jonathan Graehl" at Mar 27, 2001 05:29:50 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > The problem with this approach is that you are, in effect, making > > your server unreliable, in exchange for making the changes take > > effect more quickly. > > 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-). > > It is simply not acceptable to have to take on the maintenance burden > > of teching every open source package on the planet how to do its own > > link management, without a centralized policy enforcement mechanism. > > I agree. Similarly, we can't expect every package to spontaneously > come up with a common configuration file format ;) I think Apache would accept the change quickly. BIND would probably accept it also, if people could keep their fingers limited to the configuration data itself, and not muck with the BIND code proper. Representing better than two dimensional hierarchical relationships requires metadata. The sendmail.cf file is an excellent example of of a confiugration file containing complex relationships, formed out of rules segments, with those segments indexed and activated several ways, including implicitly, or as a result of metadata causing rules to be invoked by particular mailer definitions, which are in turn themselves invoked by routing rules. I'd really hate to have it be my job to XML-ify sendmail configs; I guess I could do it, if I were paid enough for the task, and it wasn't going to turn into an ongoing nightmare, where I was chained to the desk as maintainer for the rest of eternity. Sort of like unclogging sewers: someone has to do it, but it's not a job people line up around the block to do, unless there is serious money on the table. It would probably be easier to arrange a "takeover" mechanism as a result of getting a HUP, where the open connections complete processing, and the open listen sockets, if they are still relevent, get taken over once a forked copy of the daemon, entirely up on the new configuration, is ready to start processing requests. Part of the whole socket thing kind of breaks down at this point, since part of the cached state we need to avoid is that sockets are bound to IP addresses, instead of interfaces, so if you change the IP address, you need to rebind (whereas if you were to bind to an interface instead, the IP address could bounce all over the map, and you really wouldn't care). > > ACAP is one option. My personal preference would be LTAP, if the > > LDAP server modifications for asynchronous notification could be > > pried free from Lucent. LDAP would work, if a simple transaction > > extension were added (nesting would not be required, if data were > > properly normalized). The back end data store for the protocol > > server could be XML (or ROT-13 binary files; it doesn't matter). > > First I've heard of the two ... > > http://asg.web.cmu.edu/acap/ > ACAP RFC: ftp://ftp.isi.edu/in-notes/rfc2244.txt > (looks like a nice idea; web page seems to be neglected) > > http://www-db.research.bell-labs.com/project/ltap/ > (patent filed?) > LTAP looks like a gateway to a backend that lacks triggers, where > you access the backend through the gateway and you can request > notifications when certain accesses are made by others? Do you > like their protocol, or just the idea? The idea. The protocol lacks acknowledgement of the asynchronus update notifications, which would permit listeners to "veto" a change (this would have to be at a transaction level, not a simple datum level). For example, if you had a machine with two network cards, you really don't want to permit both cards to have the same network address. Yes, this is a contrived example, since the real answer to that problem is to use IPv6 stateless autoconfiguration (or IPv4 stateless autoconfiguration into link.local and then NAT). > > I have to say I'm violently opposed to signaling as a catch-all; > > I understand that it's the standard means of informing a daemon > > of a configuration change, but an overly simplistic, low granularity > > approach is exactly what must be avoided. > > Well, like it or not, it is the easiest way to do things. A basic > configuration file meta-format and signaling mechanism would still > be good. I agree that more fine-grained stuff for updating in-use > configuration data should be developed, and that such a beast might > as well have nothing to do with XML (except that an XML language > could describe the interfaces/data types :). Actually, we already have the "easiest" approach: do nothing. It requires no additional work. I like the idea of "right" vs. "expedient", which has traditionally been a hallmark of BSD engineering. > In cases where static configuration files make sense, I would like > those configuration files to be XML (or some other unified > meta-format which can be programmatically operated on without > case-specific coding). 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. I also think that XML would be near ideal, in terms of back up and restore of configuration information. Which brings up the next issue, if we can agree to the metadata requirement (which implies interfaces that act on the data based on the content of the metadata): arbitrary hierarchical grouping of data. It's a real common problem that people want to solve these days... "how do I have the minimum set of machine and/or site specific configuration information, and how do I share as much of the configuration data as possible between multiple machines?". 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.. > > I'm (I guess) known for the statement "standard plus extensions > > is not standard". I think that deviations from standards render > > code practically useless. > > The "extension" I was referring to was that of augmenting a DTD such that it > still has enough in common with the "standard DTD" that programs will still be > able to get the standard information out of your document. I was not referring > to an extension to XML itself. A protocol for passing around bits of XML data > is outside the scope of the XML standard itself. I'm still very leery of this; historically, SNMP has been very problematic because of just this approach. You would have to build some brakes into the process, so that they could be stomped on with force, should things start to go to hell. There are plenty of SNMP standards in RFC form from the IETF, but everyone either ignores them ("We're Cisco: we ARE the standard"), or tries to follow them, only to find that they think they need "just a tweak" so that they can "add value", or, worse "achieve market differentiation" (code for "we don't run from their config data, but they can run from ours, so you should buy ours"). > I didn't realize that people passed around XML documents without publicizing > their DTDs. That sucks. I'm not sure a requirement to include the DTD to be > "standards compliant" would prevent people from being proprietary if they still > want to. It's a common practice, actually. Mostly it has to do with how easy it is to set up private interfaces, and then not document them because your not proud of them, or because they would give hooks into your internals, and you haven't really protected them from arbitrary interfacing ("Always set <version>3</version>, or it will core dump the server"). As the saying goes, "never attribute to malice...". Not that there isn't malice out there, it's just not, IMO, what's driving non-interoperability and the non-publication of DTD's. It's pretty much why Diamond didn't used to tell you how to program their RAMDAC's to get X windows running: they changed the PAL code and ROM data at the same time, but they never provided a standard layout or meand of identifying the RAMDAC data in the ROM. As a result, it wasn't possible for software to find out, from an arbitrary video card, how to program modes not covered by the VGA/SVGA/XVGA specifications (which themselves assumed INT 10 calls with interrupts disable to do a lot of the work). Because it was possible to fry the hardware with bad data, they would have had to reveal all of their RAMDAC settings (which were in the ROM data: they were just opaque to everything but the ROM code that hooked the INT 10 BIOS), AND all of the information necessary to identify their cards. At which point, they could be easily reverse engineered by clone card manufacturers. In other words, an initial engineering mistake, which led to their hardware being practically unusable outside the environements they anticipated. Diamond finally relented on documentation, when people started reverse engineering to build drivers anyway, and they have since been more careful about their assumptions, and are now generally regarded as being friendly. 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?200103281243.FAA03936>