Skip site navigation (1)Skip section navigation (2)
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>