Interesting clash between the
bind 9.8.2 package for CentOS 6.4 and puppet:
When puppet updates
/etc/named.conf it's not visible in the
chroot setup for named. The named startup script uses bind mounts to
make configuration files visible within the chroot environment.
root@geodns01:~# mount | grep named.conf
/etc/named.conf on /var/named/chroot/etc/named.conf type none (rw,bind)
root@geodns01:~# md5sum /etc/named.conf /var/named/chroot/etc/named.conf
d028cfee6cf1a1f77993da7c769273ad /etc/named.conf
82d1717bb34db23804f67ad855e090ea /var/named/chroot/etc/named.conf
I first thought this was some form of caching, but a suggestion was the
way the files were replaced by puppet: if puppet creates a new file and then
renames the old one and the new one, the file will have a different inode
after that action. I tested for this:
root@geodns01:~# mkdir test
root@geodns01:~# touch file.conf
root@geodns01:~# touch /root/test/file.conf
root@geodns01:~# mount --bind file.conf /root/test/file.conf
root@geodns01:~# ls -il /root/file.conf /root/test/file.conf
652873 -rw-r--r-- 1 root root 0 Mar 26 19:20 /root/file.conf
652873 -rw-r--r-- 1 root root 0 Mar 26 19:20 /root/test/file.conf
root@geodns01:~# vim --cmd 'set backup' file.conf
root@geodns01:~# ls -li file.conf* test/file.conf
652876 -rw-r--r-- 1 root root 7 Mar 26 19:25 file.conf
652873 -rw-r--r-- 1 root root 0 Mar 26 19:20 file.conf~
652873 -rw-r--r-- 1 root root 0 Mar 26 19:20 test/file.conf
This confirms that replace-by-rename will clash with bind mounts being
actually inode based. The workaround isn't that hard:
the startup script for named explicitly tests for an existing
non-zero-byte
/var/named/chroot/etc/named.conf and will skip the
mount --bind part in that case. Time to learn puppet about this feature,
puppet now manages both
/etc/named.conf and
/var/named/chroot/etc/named.conf.