Date: Sun, 12 Jan 2003 17:53:00 +0100 From: Brad Knowles <brad.knowles@skynet.be> To: Terry Lambert <tlambert2@mindspring.com> Cc: Doug Barton <DougB@FreeBSD.org>, freebsd-chat@FreeBSD.org Subject: Re: Need advice on PHP and MySQL books Message-ID: <a05200f23ba474c2d8565@[12.27.220.113]> In-Reply-To: <3E20D1D6.E9FC60B1@mindspring.com> References: <20030110234309.R12065@2-234-22-23.pyvrag.nggov.pbz> <3E1FF12B.5390D978@mindspring.com> <20030111144619.X22424@2-234-22-23.pyvrag.nggov.pbz> <3E20D1D6.E9FC60B1@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 6:24 PM -0800 2003/01/11, Terry Lambert wrote: > This is actually exactly what we did for the IBM Web Connections > NOC (we used Perl for the CGI to populate the MySQL database, and > we used Java to generate the DNS and SMTP configuration files). I have heard of a number of places that did their own DNS management tools along this sort of lines. Not necessarily using these particular languages, but basically this same idea. Some of those have been re-packaged and turned into commercial systems like QIP from Lucent or QuickDNS Manager from Men & Mice -- the cool thing about QuickDNS Manager is that it will work with the nameserver they wrote themselves as well as stock ISC BIND. However, in terms of the work of this sort that is publicly available, the most advanced project I know of is bind-dlz (see <http://www.nlnet.nl/project/bind-dlz/>). > The next generation would have been able to update in realtime, > without needing to kick servers in the head, or to explicitly > derive the data. Really? I'd love to hear more about that. > It would be very east to do this with an LDAP directory, I think; > much harder to do with a relation database, unless you establish > record references internal to the database which were, themselves, > hierarchical. BIND 9 already provides hooks for back-end databases, and there are already defined profiles for working with PostgreSQL, and a Berkeley DB implementation should be nearly trivial. The problem is that any alternative back-end database you could choose would almost certainly be much, much slower than the built-in in-memory red/black tree that is already used within BIND. The only question should be whether or not the replacement back-end database gives you enough other advantages to make up for the loss in performance. > IMO, you are much better off just sending notifications of changes > to the DNS server (via DNSUPDAT), and modifying the DNS server to > permit zone creation in the primary (minimally). Thinking about this a bit more, if you had multiple primaries pulling data off the same PostgreSQL dictionary, and/or you had your also-notify setting configured to hit the other "primary" servers, then you wouldn't have to worry about the synchronization between the "primary" and the "secondaries", because all machines would be primary. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a05200f23ba474c2d8565>