Hide Forgot
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 bind-chroot. 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): bind-9.2.3-18 How reproducible: Always 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. Additional info:
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 created. o The existing /etc/named.conf and /etc/rndc.key are always copied to /var/named/chroot/etc (The rpm install used to create these as empty files!) o /var/named/chroot/var/named/slaves is now created, with ownership named:named
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?