From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510
Description of problem:
/var/named/slaves belongs to bind, but
/var/named/chroot/var/named/slaves doesn't; it should belong to
I also noticed that /dev/null and /dev/random are no lonfwe in the
bind-chroot package (and from the chroot). They should be, otherwise
named warns when started up within the chroot.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.start bind with a config file that requires slave zones to be stored
in the slaves dir, in the chroot
Actual Results: The dir isn't there, can't be created, and the
devices are reported as missing in /var/log/messages
Expected Results: It should just work.
This is now finally fixed in bind-9.2.4rc6-3 .
Unlike in previous versions:
o Required /dev/random and /dev/zero device nodes are created.
o If the /var/named/chroot directory does not exist, it will be
o The existing /etc/named.conf and /etc/rndc.key are always copied
(The rpm install used to create these as empty files!)
o /var/named/chroot/var/named/slaves is now created, with ownership
I think silently overwriting existing named.conf and rndc.key in the
chroot is a bad idea. I mean, they're the primary config files, so if
someone tweaked them, it was in these files, and when you copy the
files in the root into the chroot, you're overwriting the changes.
I suggest adding the chroot conf files to the bind-chroot package, and
letting rpm take care of it, just like we let it take care of the conf
files for the root filesystem in the bind package.
I've noticed recent bind updates no longer break name resolution due
to overwriting the config file in the chroot. It still noisily
attempts to re-create the device nodes, even though they're already
there, but this is not a big deal. Feel free to close if you like.
OK, next bind version will check for device nodes existence
and not attempt to create them if they exist (bind-9.2.4rc7-9).
Confirmed, thanks. I think this should have been marked
closed/rawhide, not closed/currentrelease, no? Or did you issue an
update fixing this bug in the current release?