Date: Thu, 11 Nov 2004 11:40:52 -0500 From: Gerard Samuel <fbsd-questions@trini0.org> To: Erik Norgaard <norgaard@locolomo.org> Cc: freebsdquestions <freebsd-questions@freebsd.org> Subject: Re: Maybe a bug in 5.3 [Was: Re: BIND9 dump file] Message-ID: <41939614.20406@trini0.org> In-Reply-To: <419376E2.8030708@trini0.org> References: <4192375E.7050603@trini0.org> <4192C57E.8080804@trini0.org> <419331C4.4000000@locolomo.org> <419376E2.8030708@trini0.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Gerard Samuel wrote: > Erik Norgaard wrote: > >> Gerard Samuel wrote: >> >> >> >>>> Im getting a bunch of these in the logs -> >>>> Nov 10 10:30:48 gatekeeper named[312]: dumping master file: >>>> master/tmp-SLtSQEmBBK: open: permission denied >>>> >>>> So I figured a filesystem permissions problem. I chowned >>>> Thanks for any info that you may provide... >>>> >>> >>> Im confused. I've read the named and rc.conf man pages, and didn't >>> find >>> out >>> why named is behaving as it is. >>> >> >> >> I don't know if this will help or is related. I had a problem with named >> not creating the pid-file with a permision denied error (see other >> thread). >> >> I eventually solved it by creating a new chroot-dir and setting >> permissions on that. It still remains a mystery to me why I ever got >> that problem or why this worked. >> > I dont think recreating the chroot will fix it. > According to the docs, the chroot process is automatic in 5.3. > And since, I have no idea where these *automatic* instructions live, > I dont think moving/recreating the chroot will fix it. > I believe the problem lies within the *automatic* instructions. > Even in the docs for DNS in the handbook states that -> > > * > > Create all directories that named expects to see: > > # cd /etc/namedb > # mkdir -p bin dev etc var/tmp var/run master slave > # chown bind:bind slave var/* > > > > <http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-dns.html#CHOWN-SLAVE>; > > named only needs write access to these directories, so that is > all we give it. > > Im not sure why the author assumes that named shouldn't write to the > master directory. > In my case, DHCP can only update master zones (DHCP updates DNS within > the LAN), > not slave zones, so master should be writeable by named. > > What Im going to try is this. > Since the slave directory never seems to change permissions, I'll move > the > LAN's zone files to the slave directory instead of the master directory. > And change named.conf -> > zone "trini0.org" { > type master; > file "slave/trini0.org"; > allow-update { key DHCP_UPDATER; }; > }; > > zone "0.168.192.in-addr.arpa" { > type master; > file "slave/trini0.org.rev"; > allow-update { key DHCP_UPDATER; }; > }; > > Kind of a contradiction if you're a stickler on the naming convention. > > Hopefully if this *automatic* process doesn't recreate the directories > at boot time, > this should work out. > I'll try this, and report any findings. Well its been over 2 hours, and its not reporting any problems in the logs. So Im going to leave it as it is.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41939614.20406>