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