dumping master file: tmp-xxx: open: permission denied
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? And why are the slave servers "dumping master file" in the first place? -- Carlin's Third Commandment: Thou shall keep thy religion to thyself. ___ 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
Re: dumping master file: tmp-xxx: open: permission denied
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. > 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. > -- > Carlin's Third Commandment: Thou shall keep thy religion to thyself. > > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
Re: dumping master file: tmp-xxx: open: permission denied
On 13 Jan 2014, at 20:36 , Mark Andrews 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 WILL STOP TALKING ABOUT THE TWELVE INCH PIANIST Bart chalkboard Ep. 3F07 ___ 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
Re: dumping master file: tmp-xxx: open: permission denied
On Tue, 14 Jan 2014, LuKreme wrote: On 13 Jan 2014, at 20:36 , Mark Andrews 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. Dave -- David Forrest e-mail: drf at maplepark dot 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
Re: dumping master file: tmp-xxx: open: permission denied
On 14 Jan 2014, at 09:02 , David Forrest wrote:
> On Tue, 14 Jan 2014, LuKreme wrote:
>
>>
>> On 13 Jan 2014, at 20:36 , Mark Andrews 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?
or are you saying that in options { … I should set
directory “/var/named/etc/namedb/“
If I change the ownership of /var/named/etc/namedb to bind, it gets changed
back to root when bind starts.
--
"Those people who think they know everything are a great annoyance to
those of us who do." - Isaac Asimov
___
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
Re: dumping master file: tmp-xxx: open: permission denied
On Tue, 14 Jan 2014, LuKreme wrote:
On 14 Jan 2014, at 09:02 , David Forrest wrote:
On Tue, 14 Jan 2014, LuKreme wrote:
On 13 Jan 2014, at 20:36 , Mark Andrews 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
Re: dumping master file: tmp-xxx: open: permission denied
On 01/14/2014 08:14 AM, LuKreme wrote:
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?
No. All path names in your configuration file should be relative to the
chroot directory. So /etc/namedb/slave/kreme.com.
You seem to be using FreeBSD. The default named.conf has the
configuration you should start with if you're using the default rc.d
script to start named. Start with that, follow the examples, and only
change things in the default if you're certain you know what the
implications of those changes will be.
Doug
___
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
