Date: Thu, 13 Feb 2003 16:46:52 -0000 From: "Paul Robinson" <paul@iconoplex.co.uk> To: "Terry Lambert" <tlambert2@mindspring.com> Cc: <arch@FreeBSD.ORG> Subject: RE: syslog.conf syntax change (multiple program/host specifications) Message-ID: <IPEDKJGCDFHOPEFKLIDHAEFCCCAA.paul@iconoplex.co.uk> In-Reply-To: <3E4BC495.E3A2FB66@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > You *really* do not want to go around shooting "bind" in the > head, like the "Life Magazine" cover shot of the Khymer Rouge; > if you end up with a ton of dependencies, then you end up with > a huge accumulated delay, any time there's a state change. It's > no good. Cached Data Considered Harmful (and all that). Agreed. Although there is another approach which gets rid of the dependancies, gives the flexibility people are talking about here, but requires a re-write of almost all Unix software (hey, PAM wasn't that hard was it?): You have an XML file describing where the configuration data lives. That means you have a file that describes to (for example) BIND, "traditional zone file lives in /etc/namedb" or equally "zone info held in this SQL database, in this format" or "take every third byte out of this jpeg and use that to construct zone info". This was an idea I had some time back but never implemented because it got scary, and quite frankly it's too big an issue for one guy to handle on his own. The result though, would be cool. What you have is a standard way of configuring daemons throughout the system, in that the XML represents traditional Unix config files, and that in itself becomes a standard. However, if I want my POP3 software to authenticate using PAM which is pulling info out of SQL, I can do so by changing the XML file, not the software itself. Equally, if somebody wants exactly what ships now with qpopper, they can do so. You implement the flexibility but without the problem of introducing non-standard config files. Of course, the draw here is that all processes then have to talk to a central daemon to do the data collection for it, that in turn understands the XML files, SQL, dbm, whatever else. Big project, big overheads, but still a nice idea. Anyway, it's unimplementable, so I'm rambling, but I thought I'd share in case somebody could adapt it to something realistic. -- Paul Robinson 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?IPEDKJGCDFHOPEFKLIDHAEFCCCAA.paul>