Description of problem: BIND overwrites zone files if '/var/named/data' is a symlink to the data directory in the chroot. Setup is as follows; 1. NAMED_CHROOT is '/var/named/chroot' 2. NAMED_DATADIR is '/var/named/data', which means 3. ONDISK_DATADIR is '/var/named/chroot/var/named/data' 4. a relative symlink to ONDISK_DATADIR exists in '/var/named' (data -> chroot/var/named/data) When updating BIND, something (probably the 'bind-chroot' post install scripts) creates symlinks for the zone files residing in ONDISK_DATADIR in the NAMED_DATADIR, overwriting the actual zone files in ONDISK_DATADIR and replacing them with links to themselves. Example; lrwxrwxrwx 1 named named 47 Jul 15 12:41 reverse.local -> /var/named/chroot//var/named/data/reverse.local Which is basically a symlink pointing to itself. -- Expected behaviour; if the chroot exists, the post install scripts should assume correct configuration and not run any actions that change it whatsoever. Or at least check that it does not ever replace files with links, and/or create circular references. Same goes for permissions on the directories and files in the chroot directory by the way. This happens every time an updated package is released, and is caused by the 'bind-chroot-admin' utility, which appeared in 5.x; 4.x releases are not affected it seems Upstream report of CentOS issue 3736; http://bugs.centos.org/view.php?id=3736
Main reason why bind-chroot package exists is to simplify chroot environment maintenance. If you would like to use the bind-chroot you have to follow "standard practices" on Red Hat systems. Otherwise bind-chroot package is not a good idea for you because it will continuously break your configuration. Please read https://bugzilla.redhat.com/show_bug.cgi?id=480156#c4, I wrote there how such configuration should look like. If you would like to use customized chroot then please remove bind-chroot package. I'm closing this bug but if you think I'm not right please reopen it. *** This bug has been marked as a duplicate of bug 480156 ***
I don't have a problem with 'standard practices' or recommended configurations, but the problem here is not that it simply breaks my configuration. We've been keeping zonefiles in the data directory ever since we ran BIND on Red Hat EL 2.1, it worked fine in 3.x, we run this live on CentOS 4.x. The problem did not exist till the 'simplified chroot environment maintenance' was implement in 5.x. If that is not a supported configuration, again, I don't have a problem with that, we can change the configuration. But an automated update script should never, in my humble opinion; * Delete customer data (zone files) * Create invalid symlinks Even a simple check to see if the 'data' directory is a symlink to its equivalent inside the chroot, followed by an exit would already prevent this from happening.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Previously, the bind-chroot-admin script could break the configuration with non-standard chroot layout . With this update, the script terminates without touching the configuration.
=> VERIFIED
Reverified after rebase: https://tcms.engineering.redhat.com/run/14317/?from_plan=2749 for bind-9.3.6-15.P1.el5.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0032.html