Hi,
We started using patterns with NSD 4.0 to host zones of out customers.
I am trying to setup a slave server for backup. It works fine if I run
"nsd-control addzone" for each zone on both the master and the slave.
Is it possible to make the slave get the new zones when they are added to
the master?
Hi,
a message of 73 lines which said:
nsd-control -s $master addzone $zone mpattern
nsd-control -s $slave addzone $zone spattern
Note this solution is not atomic: if the network has a glitch, you may
end up with the zone configured on the master and not on the slave.
Hi Stephane,
Hi Stephane,
a message of 73 lines which said:
nsd-control -s $master addzone $zone mpattern
nsd-control -s $slave addzone $zone spatternNote this solution is not atomic: if the network has a glitch, you may
end up with the zone configured on the master and not on the slave.
Sure. That's why I said "basically". In a more real implementation you would have to add verification of whether the different operations succeeded or not and what to do if they did not(*).
But that is needed regardless, i.e. if there was control magic between the master and the slave, where changes on the master triggers changes on the slave, then the same possibility of a network glitch exists. And has to be dealt with.
Wouter wrote:
The zonelist files are plain text and (if the server is stopped) can
be synced/diffed/copied.It is also possible to add it to (an include file of) the config file.
And then nsd-control -s $server -c $server.keys.conf reconfig.
Exactly. And this is basically what we do at present for part of our operations, i.e. generate new configs, verify correctness, distribute new configs in dependable way, ask servers to re-read configs in the right order.
I maintain my position that this type of problem is better dealt with outside the actual nameservers. We have a distributed infrastructure, network glitches are a fact of life, no control magic can remove that fact and then I'd rather have to deal with it explicitly than have it hidden under the hood as magic control goop that may or may not do the right thing if there's a serious outage.
Regards,
Johan Ihrén
(*) I see that if I try to add the same zone twice I get the error:
error could not add zonelist entry
While it is good to get an error in this situation I think it would be useful to be able to distinguish between things like "could not add because zone with that exact config is already there", "could not add because zone with *different* config (i.e. other pattern) is already there", "could not add because of an error writing to disk", etc.
I.e. at present if I wanted to improve on my trivial script I admit that I'm not entirely sure how to construct the actual test for whether the addzone command completed or not. And this is yet another reason that we do this outside of our nameservers, because then we have full control over the integrity of the propagation of updated configurations.
Another thing that struck me is that if I was to use "addzone" in production I'd really appreciate a "nsd-control testzone foo.example." command which should return the config entry from the zonelist file. Then verification of propagation would become much easier.
I expected the new zones to be replicated, after setting the configuration
parameters under pattern. Maybe it is because of my limited DNS experience.
I do not think the workarounds are problem-free. Using a script for adding
and removing zones, would lead to operator error. Same treatment does not
required to reload them. Using the script can easily be forgotten.
Replication the zonelist file may be a better solution. It includes all
zones from all patterns. We can try it as we have only one pattern and
restarting the server is not a problem; but, while doing that we can also
rsync the zone files.