Problem with slave server not saving files

John Straiton jsmailing at clickcom.com
Fri Aug 24 18:47:57 UTC 2001


Thanks for all the replies...here are the answers to your suggestions..

> Did you try paired allow-update and also notify options on the
> master and slave?
>
> I believe it is different from allow-transfer
Correct me if I'm wrong, but I believe you do not need the allow-update
definition in a slave. Wouldn't the masters {}; definition be enough? Even
if not, the first thing the server should do is a zone transfer via a pull,
rather than a push. I don't want to set an allow-update for that machine and
then have any old shell user of NS1 be able to send a nsupdate to the
slave...

> I'm a little confused.  Which machines are NS1, NS2, and NS3?
> I'm guessing
> NS1 and NS2 are the two servers that replicate using scp, and NS3 is the
> new slave, right?
Yes

> If the above configuration is for NS3, why does it have an allow-transfer
> statement?  That needs to be in NS1's configuration, so that it allows NS3
> to pull from it.
It's there cause for NS3, I lazily used the same named.conf as a base, then
worked from there. (s/type master;/type slave..masters {}..etc/g) So that
actually exists in both configurations.

> If NS3 will be slaving all of NS1's domains, you can use a global
> also-notify list in the options section instead of replicating it in each
> zone statement.

Ok, I put that in the NS1's config.
options {
	also-notify { NS3_IP; };
	....etc..
	}

> Du you have a working named-xfer within the root-jail, and do you need
> a manually configured path to it ?
>
> Can you run named-xfer manually ?
Yes
#./named-xfer -z domain.com -f test.db NS1
works just fine. However I do not have named-xfer in the jail. It was my
understanding that named-xfer is now within the named binary and no longer
needed as a separate utility... true?

John Straiton
ClickCom, Inc.
jks at clickcom.com
(704)365-9970x101




More information about the bind-users mailing list