Re: two bind9 masters
On Thu, Oct 11, 2007 at 12:46:06PM -0400, Dan MacNeil wrote:
> We decided not to use bind's replication mechanism because it required us
> to add zones to each server by hand.
so?
more to the point, it didn't "require" you to add zones by hand, you
chose to do that because you weren't sufficiently lazy :-)
laziness is a virtue because it motivates you to do things the smart
easy way rather than the hard dumb way.
> For example in our named.inc
>
> zone "lbgc.org" {
> type master;
> file "db.lbgc";
> };
do you realise how trivially easy it is to generate config fragments like
that?
this is part of what perl (and sh and other scripting languages) are FOR
- to automate generation of repetitive and tedious config fragments like
bind config, apache virtualhost config, mailing list config, etc etc
etc.
for a primary zone, the only thing that differs is the zone name and
maybe the file name (although the filename can be the same as the zone
name or derived from it).
for a secondary, the only things that change are the zone name and the master
server's IP to secondary it from.
so, a text file like this:
master master1.example.com
master master2.example.com
secondary sec1.example.com 192.168.1.1
secondary sec2.example.com 192.168.1.1
secondary sec3.example.com 172.31.1.1
(or you can skip the first word if you have one text file for masters
and another text file for secondaries - in fact, if you secondary for
several other ISPs you could have one secondary file per ISP. or it
could be pulled out of a database)
with a trivial line perl script could generate a named config file
which could be included into named.conf.
the script would look something like the one below. it's trivial - i
wrote it from scratch for this email, with just the memory of doing
something similar years ago to guide me.
it's written as a filter. input on stdin, output on stdout. redirect as
needed. most of my systems automation scripts are written that way - i
find it far more useful and flexible than hard-coding input and output
filenames...and allows easy testing of changes by piping output into
less or to a /tmp/ file.
#! /usr/bin/perl
$Default_Primary_IP = '192.168.1.1';
while (<>) {
chomp;
s/#.*//;
next if (/^$/);
my ($Type, $Zone, $ZSource) = split ;
if ($Type =~ /^(master|primary)$/io) {
# Zone filename defaults to same as Zone if blank
$ZSource = $Zone if ($ZSource eq '') ;
print <<__EOF__;
zone "$Zone" {
type master;
file "$ZSource";
};
__EOF__
} elsif ($Type =~ /^(secondary|slave)/io) {
# Use default primary IP if ZSource is blank
$ZSource = $Default_Primary_IP if ($ZSource eq '');
print <<__EOF__;
zone "$Zone" {
type slave;
file "$Zone";
masters {
$ZSource;
} ;
};
__EOF__
};
};
NOTE: untested but It Should Work<tm>. there may be minor syntactic
errors because i wrote it without referring to any documentation - in
particular, i can never remember whether it's 'eq' or '==' for comparing
strings until i look it up in the perlop man page.
a script like this, combined with a Makefile to automate the generation
(and scp-ing or rsync-ing of files) when the source text files have
changed can completely automate management of DNS zones - and even
automatically check in changes to a revision control system like RCS or
Subversion.
in fact, subversion can serve a double use as the delivery mechanism
to get updates to other machines. check-in the files on one machine,
check them out on others. then you can edit the files on any of the
machines and know that the changes will be replicated to all the others.
i have used this technique to replicate my (generated) apache virtual
host config from one load-balanced web server to others in the same
load-balanced web farm.
once the automation scripts are written and tested, updating things
is as simple as editing one small text file and running "make" - the
Makefile automates everything, and does everything else in precisely the
correct order.
craig
--
craig sanders <cas@taz.net.au>
Other than that, Mrs. Lincoln, how did you like the play?
Reply to: