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>