On Tue, 14 Jan 2014, LuKreme wrote:
On 14 Jan 2014, at 09:02 , David Forrest <d...@maplepark.com> wrote:
On Tue, 14 Jan 2014, LuKreme wrote:
On 13 Jan 2014, at 20:36 , Mark Andrews <ma...@isc.org> wrote:
In message <8919443e-8f62-48cd-8da4-9c9632fc5...@kreme.com>, LuKreme writes:
OK, I am getting this error "dumping master file: tmp-xxx: open:
permission denied", occasionally, on both my slave DNS servers and I
can't seem to fix it.
The dns slave files are being written into /var/named/etc/namedb/slave
which is owned by bind
8 drwxr-xr-x 2 bind wheel 1024 Jan 13 19:46 /var/named/etc/namedb/slave
DNS changes are getting propagated to both servers from the master, so I
don't know where the permission denied is coming from. Where is this
tmp file being (attempted to be) written?
It's trying to write the the working directory which I doubt is
/var/named/etc/namedb/slave. I suspect you have a bad "file"
directive.
Hmm. OK, there is a /var/named/etc/namedb/working/ which is also owned by bind.
Where might this bad file directive be? The only ‘file’ in named.conf are in
the form “slave/example.com” and the pid-file setting.
And why are the slave servers "dumping master file" in the first place?
So the slave can start up and serve the zone content when the master
server is down.
Oh? Coolness :)
I've been tripped up on this before as there is a default directory and the default can
be overridden by a "directory" option statement. Using a chroot adds the
current definition into the chrooted directory. It can get quite confusing and I have
found that just using full paths on all zone files just cuts out any question. Usually
the slave server will get a new copy master fairly quickly if you don't save it but it is
cleaner if it has a fairly recent copy locally.
so I should change
zone "kreme.com" { type slave; masters { 75.148.37.67; }; file
"slave/kreme.com"; };
to
zone "kreme.com" { type slave; masters { 75.148.37.67; }; file
“/var/named/etc/namedb/slave/kreme.com"; };
and that will eliminate the errors?
This works for me. At least I then know where it is going.
or are you saying that in options { … I should set
directory “/var/named/etc/namedb/“
No. this just sets up another redirection to work out. YMMV though
If I change the ownership of /var/named/etc/namedb to bind, it gets changed
back to root when bind starts.
I'm on CentOS65 and it seemed to not notice I was running as named -u named and
this tripped me up too in my init so I added a statement just before it
executes (around line 170 in /etc/rc.d/init.d/named) the start daemon to
change the ownerships to named; like this:
169 chown -hR named:named /var/named ## DRF
170
171 daemon --pidfile "$ROOTDIR/$PIDFILE" /usr/sbin/"$named" -u named ${OPTIONS};
But I am sure there is a proper way to do this. Expediency usually bites.
Maybe some can tell us
--
David Forrest e-mail: drf at maplepark dot com
Maple Park Development http://www.maplepark.com
St. Louis, Missouri
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
