On Feb 14, 2011, at 12:54 PM, Torinthiel wrote:
Dnia 2011-02-14 15:52 Mike Mitchell napisał(a):
I'd keep two copies of the BIND config, one that has all the zones as
"master", and one that has all the zones as "slave". When the
master dies,
run a little script on a slave that freezes the zones, edits the SOA
to make
that server the MNAME and increment the serial, then thaws the zone.
Swap
out the config with the "master" config, and now you have a new
master.
Before the broken master comes back online, swap out its config
with the
"slave" config.
No need for rsync or mysql, BIND replication does all the work for
you.
Just be sure the updates go to the server listed in the MNAME field
of the
SOA.
Nice idea. I'd go even further - why keep two configs? Have a file
with your
list of zones, and two scripts that generate either master or slave
config.
I'm probably going to regret this, but I'm basically doing what you
suggest for some (~15-20) personal domains. Every now and then someone
asks me to run a mailing list for them, please "just host a website",
etc. I got tired of updating named.conf on a bunch of servers, cp ~/
configs/base_bind.db /etc/namedb/example.com, add stuff to apache, go
poke postfix on N mailhosts, kick mailman, etc so I finally invested
the time and effort into setting up puppet -- it was *well* worth it...
Now I have a Python dictionary that looks like:
{
"ac4wk.com": {"bind": "local", "postfix_virtual": True,
"base_web": True, "redirect": False },
"af7.org": {"bind": "local", "postfix_virtual": True,
"base_web": True, "redirect": False },
.....
}
and a little script that creates a set of Puppet arrays. Puppet then
reads these and does magic.
"bind":"local" specifies to use a template that lists my machines as
MX and www and similar
postfix_virtual add the domain to the virtual lines in postfix to the
mailservers know to accept mail for it
base_web creates directories, add the site to the apache config and
copies some base html files.
redirect: Can be set to a different domains and will then setup a
domain to serve a 302 redirect to some other domain..
My master has
# And setup bind.
$bind_type = "master"
include bind
and slaves have:
# And setup bind.
$bind_type = "slave"
$bindmaster = "198.186.192.250"
include bind
bind::db_files {["22.194.204.in-addr.arpa", "58.177.216.in-
addr.arpa"]:}
in the node manifest.
named.conf is automatically generated from a template, containing some
base config and:
// Section managed by Puppet.
<% if bind_type == "master" then %>
<% zones.each do |zone| -%>
// <%= zone %> -- Zone stanza generated by puppet.
zone "<%= zone %>" {
type master;
file "/etc/namedb/<%= zone %>";
auto-dnssec maintain;
update-policy {
grant local-ddns subdomain * ANY;
grant tsig_1.kumari.net. zonesub ANY;
};
allow-transfer { xfer; };
};
<% end -%>
<% else %>
<% zones.each do |zone| -%>
// <%= zone %> -- Zone stanza generated by puppet.
zone "<%= zone %>" {
type slave;
file "/etc/namedb/slave/<%= zone %>";
allow-transfer { xfer; };
masters { <%= bindmaster %>; };
};
<% end -%>
<% end %>
This means that adding a new domain now just involves adding a line to
the python dictionary and running a script to convert the python to
the puppet arrays -- takes all of 20 seconds.
Making a slave become a master (which I've done a few times as a test)
involves simply changing the line in the manifest.
I realize that this is getting off topic, but puppet has made my life
way easier (this part was a insignificant part of it) and I wanted to
share :-P
W
Now you are keeping one common config on both severs, which changes
only
when you add/remove a zone, and two scripts which are almost
identical,
except for one line (master address). This should be easier to
maintain.
Now, just in case, you could put on startup scripts the one that
generates
slave config, so if it reboots you don't have two master servers.
And you could cook up a more complicated script, that tries to ping
the
other server and runs master config generation, freeze, soa change,
thaw,
reload and send you an email - and you have fully automated HA.
Torinthiel
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Some people are like Slinkies......Not really good for anything but
they still bring a smile to your face when you push them down the
stairs.
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
