Date: Sat, 11 Jan 2003 18:24:22 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Doug Barton <DougB@FreeBSD.org> Cc: freebsd-chat@FreeBSD.org Subject: Re: Need advice on PHP and MySQL books Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Barton wrote: > Well, "DNS Management Tool" is a little bit oversimplified. I'm actually > not looking to drive the name server from the database, I'm actually > looking to store information about hosts in a relational db, then spit out > a number of different types of files (DNS zone files, dhcpd.conf files, > etc.) based on what's stored there. This is OK; it involves head-kicking. For 100,000 domains on a machine with moderately fast multiprogram I/O (e.g. SCSI instead of IDE), this will take under about 1 minute (speaking from personal experience). It's much better if you can handle database triggers, and do a DNSUPDAT, instead, so that there is no downtime involved for your primary DNS server (if you have a secondary, though, all that is added is latency). You can actually permit zone creation via DNSUPDAT (it's s six line change to the bind code), and get away with no zone issues on the primary. Zone creation is a problem, since a secondary does not create new zones automatically, based on their creation in the primary. The creation of secondary zones via DNSUPDAT is not possible, without creating an additional security association, and coming up with some mirroring relationship, and defining a configuration mechansim to deal with it. It's a lot of work. Most likely, you will need to also recreate the zones on the secondary, and kick it in the head, as well (even if you make the minor mod to the primary, and avoid the head-kicking there). The time on 100,000 zones there will be about 45 seconds (you only create SOA's, and then it zone transfer from the primary to update its per domain data data). 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). 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. > Eventually, I also want to be able to run bind 9 plugged directly > into the database (or a similar database) without zone files at all. 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. 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). > > If this is for internal use, you can ignore the GPL, since it only > > really applies if you distribute the code. > > Yeah, this is just for internal use. Does postgres have a friendlier > license? That might actually be a point in its favor, since the initial > version of this project won't have to be super high performance. I might > want to make money off this some day. :) If you aren't selling the systems, you don't give a damn about the license; they're infrastructure. You might have a license issue on sale of your comapny, if you flip it to another service provider. That's only if there's a license conflict that would make the code non-distributable (e.g. you were using a GPL'ed XFS in your FreeBSD boxes in your hosting farm, and the farm was sold as part of the sale, resulting in a transfer of ownership). This is usually not a problem, if you sell the company, rather than the companies assets, since you are not technically engaging in "distribution" at that point. If there is an issue that has to do with aggregation, you can just add a "reaggregation clause" to the terms sheet, which requires them to type "make ; make install" in a directory, immediately following the sale, with the agreement that you are not selling them the binaries. Basically, there are legal ways around the GPL, if you are not intent on selling the resulting combined software commercially; worst case, you can simply lease the software to the new system owners. For MySQL, if you aren't relying on replication, just use a copy that's old enough that it's under the previous license. But to get back on the technical track... I think in your case, I would consider Postgres anyway, because it permits triggers. A trigger is something you will need to have to do realtime updates of the DNS and SMTP data, when the data in the SQL database changes the configuration out from under it. Without triggers, you are going to have a difficult time automating this task (you may not be able to automate it at all). With triggers, it's a matter of getting the updates to the DNS and SMTP servers. Actually, LDAP is better for SMTP servers, as well, FWIW, since email addresses are hierarchical. -- Terry 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?3E20D1D6.E9FC60B1>