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@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@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