Bug 1278082

It looks like the buggy version went out last night - we got -29 via yum updates overnight and our existing bind-chroot servers broke:

  Sep 03 23:03:59 Updated: bind-chroot.x86_64 32:9.9.4-18.el7_1.5
  Dec 16 01:48:53 Updated: bind-chroot.x86_64 32:9.9.4-29.el7

  Dec 16 02:12:14 ns1 bash: /etc/named.conf:251: open: /etc/named-slaves-internal.conf: file not found

Adding '-t "$ROOTDIR"' to /usr/lib/systemd/system/named-chroot.service resolved the issue (I can't see bug 1236475).

19c19
< ExecStartPre=/bin/bash -c 'if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z /etc/named.conf; else echo "Checking of zone files is disabled"; fi'
---
> ExecStartPre=/bin/bash -c 'if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t "$ROOTDIR" -z /etc/named.conf; else echo "Checking of zone files is disabled"; fi'

This went out with Centos, as well. We explicitly remove the normal /etc/named.conf, so this bug resulted in our named-chroot failing to start as it couldn't run checkconf.

Please see the bug description for the workarounds, which are trivial.

The workarounds are certainly trivial - the trick is each minor bind update clobbers them, and pretty soon a geodiverse cluster of nameservers is a pain to keep updated and up.

Is there any chance that this fix (removing non-chrooted /etc/named.conf has been upstream guidance for a long time) will be included in an update soon?   I'd rather not chattr +i all the .service files, but if it's going to be a while (say, 7.3), I've had N x 3 fixes to redeploy so far so we'll need to and back that out later.

(In reply to Bill McGonigle from comment #9)
> The workarounds are certainly trivial - the trick is each minor bind update
> clobbers them, and pretty soon a geodiverse cluster of nameservers is a pain
> to keep updated and up.

There is not really a need to modify /usr/lib/systemd/system/named-chroot.service manually after each update. You should not really touch that file at all. Instead you should keep the modified service file in /etc/systemd/system/. For more information, please follow [1].

> Is there any chance that this fix (removing non-chrooted /etc/named.conf has
> been upstream guidance for a long time) will be included in an update soon? 
> I'd rather not chattr +i all the .service files, but if it's going to be a
> while (say, 7.3), I've had N x 3 fixes to redeploy so far so we'll need to
> and back that out later.

I can not make any promises on when this issue will be fixed. If this issue is critical to you, please contact the Red Hat support.

Thank you.

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html#sect-Managing_Services_with_systemd-Unit_File_Modify

*** Bug 1294731 has been marked as a duplicate of this bug. ***

(In reply to Tomas Hozza from comment #10)
> (In reply to Bill McGonigle from comment #9)
> > The workarounds are certainly trivial - the trick is each minor bind update
> > clobbers them, and pretty soon a geodiverse cluster of nameservers is a pain
> > to keep updated and up.
> 
> There is not really a need to modify
> /usr/lib/systemd/system/named-chroot.service manually after each update. You
> should not really touch that file at all. Instead you should keep the
> modified service file in /etc/systemd/system/. For more information, please
> follow [1].

Sorry, but I disagree with your logic here. You *WANT* an updated named-chroot.service to be installed over any custom service file in /etc/systemd/system.

Making non-obvious changes to unit files that have the same name in different locations is a very bad idea.

As this bug has now polluted CentOS and Scientific Linux, it should probably get fixed sooner rather than later - as we're already 2 months into it being a known bug....

You don't have to copy the whole file, but rather do change just to the ExecStartPre part. You can use systemd unit drop-in for this purpose.

$ mkdir /etc/systemd/system/named-chroot.service.d
$ vim /etc/systemd/system/named-chroot.service.d/exec-start-pre.conf

# exec-start-pre.conf content
[Service]
ExecStartPre=
ExecStartPre=/usr/sbin/named-checkconf -t /var/named/chroot -z /etc/named.conf

$ init q

You can verify the service file with "systemctl show named-chroot"

Also you can always inspect all the changed done to the unit files on your system by calling "systemd-delta".

Thanks for the recipe, @Tomas.  Since I commented earlier I just want to verify that your suggestion WFM - I've added it to my bind-chroot puppet module for EL7 and pushed it out widely, to good effect.

Hi all,

Lots of blocks & things on this bug - yet it still appears on the latest bind packages that have recently been pushed - once again breaking countless nameservers on the net....

Are we holding back on this fix for a specific reason?

Common sense would seem to dictate that such as simple fix should have been pushed months ago.

For what its worth, this is the commit that caused all this headache:

https://git.centos.org/commit/rpms!bind.git/d56ed2d3a2736a07a09c268f3b2607cca8f1b6ca

Hi Steven.

The bug is approved for RHEL-7.3 update, so there is high possibility it will be fixed in the next RHEL-7 minor update. We already know what caused this unfortunate regression. We also know the fix and there are couple of workarounds mentioned in this bug.

Thank you for your patience.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2233.html