CentOS - Jan 2009 - After BIND update owner changed and restart failed

I just applied the BIND updates.

Then I fixed the one file that had a second include of named.ca 
(remembered that from last time) and did a 'service named restart', and 
it failed.  In messages I found:

Jan 10 21:31:17 z9m9z named[31001]: loading configuration from 
'/etc/named.conf'
Jan 10 21:31:17 z9m9z named[31001]: /etc/named.conf:11: open: 
/etc/named.acl: permission denied
Jan 10 21:31:17 z9m9z named[31001]: loading configuration: permission denied
Jan 10 21:31:17 z9m9z named[31001]: exiting (due to fatal error)


Oh, I remember this from the last update...  So off to 
/var/named/chroot/etc and do a 'chown named:named *' then named started.

This apparent changing of file ownership in installing a new set of bind 
updates so that named cannot access the files seems like something is 
broken somewhere.

Robert Moskowitz wrote:
> I just applied the BIND updates.
> 
> Then I fixed the one file that had a second include of named.ca 
> (remembered that from last time) and did a 'service named restart',
and
> it failed.  
Never heard about someone having to apply that fix - do you have a bug entry
from bugs.centos.org or bugzilla.redhat.com handy?

> In messages I found:
>
> Jan 10 21:31:17 z9m9z named[31001]: loading configuration from 
> '/etc/named.conf'
> Jan 10 21:31:17 z9m9z named[31001]: /etc/named.conf:11: open: 
> /etc/named.acl: permission denied
> Jan 10 21:31:17 z9m9z named[31001]: loading configuration: permission
denied
> Jan 10 21:31:17 z9m9z named[31001]: exiting (due to fatal error)
named.acl isn't shipped by CentOS.
> Oh, I remember this from the last update...  So off to 
> /var/named/chroot/etc and do a 'chown named:named *' then named
started.
The files under there belong to root:named and are 644 (except rndc.conf 
which is 640). No file there belongs to named:named. named.acl isn't shipped
with bind.
> This apparent changing of file ownership in installing a new set of bind 
> updates so that named cannot access the files seems like something is 
> broken somewhere.
[root at shutdown etc]# rpm -q --scripts bind|grep -E "chown|chmod"
        [ -e /etc/rndc.key ] && chown root:named /etc/rndc.key
        [ -e /etc/rndc.key ] && chmod 0640 /etc/rndc.key
[root at shutdown etc]#

So where are other files ownerships changed after a bind update? If you think
you fond a bug, then please file it, but make sure that others can recreate
it.

Ralph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL:
<http://lists.centos.org/pipermail/centos/attachments/20090111/f11ef8dd/attachment-0004.sig>

Ralph Angenendt wrote on Sun, 11 Jan 2009 11:10:54 +0100:
> The files under there belong to root:named and are 644 (except rndc.conf 
> which is 640). No file there belongs to named:named. named.acl isn't
shipped
> with bind.
I had named.conf with root.root (and it was working). That got changed by the 
update to root.named. Which apparently is the correct ownership according to 
you and it still works. When I installed bind just a few weeks ago I had to 
create all the files manually as there were none. So, that's why that file
was
root.root.

I didn't notice that before but I see that there are a lot of errors already
before the update:

Jan 11 16:38:00 chacha named[11307]: client 192.168.1.228#1994: view internal: 
update 'bolera.lan/IN' denied

I don't need updates (and I think clients are not configured to try to
update).
Can you tell me how I can fix this? (If I wanted to allow updates and if I 
wanted to have this functionality not available at all.)

Kai

-- 
Kai Sch?tzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com

On Saturday 10 January 2009 9:37:43 pm Robert Moskowitz
wrote:
> I just applied the BIND updates.
>
> Then I fixed the one file that had a second include of named.ca
> (remembered that from last time) and did a 'service named restart',
and
> it failed.  In messages I found:
>
> Jan 10 21:31:17 z9m9z named[31001]: loading configuration from
> '/etc/named.conf'
> Jan 10 21:31:17 z9m9z named[31001]: /etc/named.conf:11: open:
> /etc/named.acl: permission denied
> Jan 10 21:31:17 z9m9z named[31001]: loading configuration: permission
> denied Jan 10 21:31:17 z9m9z named[31001]: exiting (due to fatal error)
>
>
> Oh, I remember this from the last update...  So off to
> /var/named/chroot/etc and do a 'chown named:named *' then named
started.
>
> This apparent changing of file ownership in installing a new set of bind
> updates so that named cannot access the files seems like something is
> broken somewhere.
>
Hi!

This is really strange, I run two different servers with Centos 5.2 and the 
bind provided by centos, and after aplying the latest bind updates, the 
service restarted with no issues at all, so it seems the updates are not 
broken for everybody.


Cordialmente,


GERMAN ANDRES PULIDO F.
Ingeniero de Proyectos
GLOBAL TECHNOLOGY SERVICES - GTS S.A.
-------------------------------------
Tel: (571) 658 34 10 ext 110
Carrera 7b No. 123-46
Bogot?-Colombia
Sitio Web: www.gtscolombia.com

Robert Moskowitz wrote:
...
> Oh, I remember this from the last update...  So off to 
> /var/named/chroot/etc and do a 'chown named:named *' then named
started.
I see the same problem every time bind is updated.

My /var/named/chroot/var/named files are writable by named because
I have a DDNS setup. After every bind update, the files are no longer
writable by named.

Mogens

-- 
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Mobile: +45 22 12 53 25
Email: mk at crc.dk Homepage: http://www.crc.dk

Ralph Angenendt wrote:
> Robert Moskowitz wrote:
>   
>> I just applied the BIND updates.
>>
>> Then I fixed the one file that had a second include of named.ca 
>> (remembered that from last time) and did a 'service named
restart', and
>> it failed.  
>>     
>
> Never heard about someone having to apply that fix - do you have a bug
entry
> from bugs.centos.org or bugzilla.redhat.com handy?
>
>
>   
>> In messages I found:
>>
>> Jan 10 21:31:17 z9m9z named[31001]: loading configuration from 
>> '/etc/named.conf'
>> Jan 10 21:31:17 z9m9z named[31001]: /etc/named.conf:11: open: 
>> /etc/named.acl: permission denied
>> Jan 10 21:31:17 z9m9z named[31001]: loading configuration: permission
denied
>> Jan 10 21:31:17 z9m9z named[31001]: exiting (due to fatal error)
>>     
>
> named.acl isn't shipped by CentOS.
>   
Oh course it is not.  But if you are doing an internal view, you want 
(need?) an .acl.
>   
>> Oh, I remember this from the last update...  So off to 
>> /var/named/chroot/etc and do a 'chown named:named *' then named
started.
>>     
>
> The files under there belong to root:named and are 644 (except rndc.conf 
> which is 640). No file there belongs to named:named. named.acl isn't
shipped
> with bind.
>   
And therein hangs my snafu.  named.acl only had 600 for permissions so 
when the group was changed to root by the update, the named process 
could no longer access the file even with the owner being named.  Go 
figure.  So I just need to fix my permissions to 644 and I will be OK 
for the next update....
>   
>> This apparent changing of file ownership in installing a new set of
bind
>> updates so that named cannot access the files seems like something is 
>> broken somewhere.
>>     
>
> [root at shutdown etc]# rpm -q --scripts bind|grep -E
"chown|chmod"
>         [ -e /etc/rndc.key ] && chown root:named /etc/rndc.key
>         [ -e /etc/rndc.key ] && chmod 0640 /etc/rndc.key
> [root at shutdown etc]#
>
> So where are other files ownerships changed after a bind update? If you
think
> you fond a bug, then please file it, but make sure that others can recreate
> it.
>

Ralph Angenendt wrote:
> Ralph Angenendt wrote:
>   
>> Robert Moskowitz wrote:
>>     
>>> And therein hangs my snafu.  named.acl only had 600 for permissions
so
>>> when the group was changed to root by the update, the named process
>>> could no longer access the file even with the owner being named. 
Go
>>> figure.  So I just need to fix my permissions to 644 and I will be
OK
>>> for the next update....
>>>       
>> As said (and see below): No script in one of the bind packages changes
>> ownership and/or modes on any of the files in there.
>>     
>
> Okay, as has been pointed out: /usr/sbin/bind-chroot-admin does all
> this. You could report that as a bug upstream, but I doubt it will get
> fixed. My fault, I didn't see that.
I figure the best is to learn what it is doing and make sure you have 
permissions and the like so that most of the time an update does not 
kill you....

On Mon, 12 Jan 2009 23:31:19 +0100, Kai Schaetzl wrote
> Craig White wrote on Mon, 12 Jan 2009 07:45:22 -0700:
> 
> > by default, BIND will ignore attempts by clients to register dynamic
dns
> > after getting an ip address from dhcp - that is what is being logged.
> 
> so, the 
> Jan 11 16:38:00 chacha named[11307]: client 192.168.1.228#1994: view 
> internal: 
> update 'bolera.lan/IN' denied
> 
> is just normal logging that I can't avoid?
AFAIK the DHCP client has no authority to register dynamic dns regardless of
how the client machines are configured.  It's the DHCP server that decides
to
update BIND and this can be turned on or off.  My guess is your DHCP server is
configured to update BIND when clients get new leases.  Hence the errors
reported by BIND when these attempts are made.  Read up on the man pages for
dhcpd.conf.  In particular review the ddns-update-style and ddns-updates
options.

Scott

-- 
Registered Linux user #395249, http://counter.li.org
Nothing goes to waste when Little Fish are near!
(http://www.littlefish.ca)

On Wed, 14 Jan 2009 17:31:26 +0100, Kai Schaetzl wrote
> Scott Mazur wrote on Tue, 13 Jan 2009 08:08:22 -0600:
> 
> > AFAIK the DHCP client has no authority to register dynamic dns
regardless of
> > how the client machines are configured.  It's the DHCP server that
decides to
> > update BIND and this can be turned on or off.  My guess is your DHCP
server is
> > configured to update BIND when clients get new leases.  Hence the
errors
> > reported by BIND when these attempts are made.  Read up on the man
pages for
> > dhcpd.conf.  In particular review the ddns-update-style and
ddns-updates
options.
> 
> Hm, man says that "ignore client-updates;" is what I want to set.
> However, this is already set in the file. I just checked my logs 
> again and now I know why I didn't ever notice it before. It seems 
> that happened only from Jan. 8 to 11. Not before 
> (as far as log goes back, which is only four weeks), not after. I 
> did the named update on Jan. 11, but this seems to be coincidence. 
> And it's been always the same client. Go, figure.
"the server can be configured either to honor the client's intentions
or
ignore them. This is done with the statement allow client-updates; or the
statement ignore client-updates;"

This refers to the client updating its own A record.  Ignore/allow here
won't
stop the DHCP server from attempting updates to BIND.

"The DHCP server must be configured to use one of the two
currently-supported
methods, or not to do dns updates. This can be done with the ddns-update-style
configuration parameter"

You want to set ddns-update-style to 'none'.  This should end the BIND
update
attempts (and failure logging).

Scott

-- 
Registered Linux user #395249, http://counter.li.org
Nothing goes to waste when Little Fish are near!
(http://www.littlefish.ca)