On 17/03/2016 10:53 PM, David Sommerseth wrote:
> On 17/03/16 12:40, Steven Haigh wrote:
>> On 17/03/2016 10:25 PM, David Sommerseth wrote:
>>> On 17/03/16 06:36, Bill Maidment wrote:
>>>> Hi guys
>>>> Another named update and still the named-chroot.service file has not been fixed. It is really annoying to have to manually fix it every time, just to get DNS working after an update.
>>>> Why is the -t /var/named/chroot option included in the ExecStart but not in the ExecStartPre
>>>>
>>>> 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'
>>>> ExecStart=/usr/sbin/named -u named -t /var/named/chroot $OPTIONS
>>>>
>>>> Surely named-checkconf should be run with the same named.conf file as named !!!
>>>>
>>>> This was reported back in November 2015
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1278082
>>>> This should have been fixed by now. How hard is a one line change to fix ???
>>>
>>> This bug has severity set to medium. That means it has most likely not been
>>> considered critical enough by Red Hat to go into an errata in the 7.2 life
>>> cycle. But as the status is ASSIGNED (not NEW, which is the first status
>>> level) - it means someone is working on it.
>>>
>>> If you do not like this pace, you can log in to the Red Hat customer portal
>>> and get in touch with Red Hat support.  If you can provide them with good
>>> technical arguments why this must be added in the 7.2 life cycle, then you
>>> might see this fixed sooner.
>>>
>>> If you do not have Red Hat subscription with support ... well, then you need
>>> to patiently wait.  Scientific Linux builds on the source RPMs Red Hat releases.
>>>
>>> And the reason for these things to take time is that every BZ for RHEL goes
>>> through several steps of quality control before a fix gets released. It means
>>> Red Hat needs to allocate resources getting these bugs fixed, verified and
>>> tested before users see the update. This is the key concept of enterprise
>>> distributions, to put efforts into avoiding regressions or new bugs as much as
>>> possible and to try to deliver a stable distribution which is properly
>>> maintained and updated over many years.
>>
>> I would agree with you if they didn't remove that option in a release.
>> the -t /blah was actually removed in a commit - which QA failed to pick
>> up (and likely chroot bind setup wasn't tested at all).
>>
>> I don't think this is a great example of what RedHat does well - this is
>> an example of what they do *really* bad.
> 
> Not going to argue that this could have been done better, I agree with you
> here.  On the other hand, maybe *that* is one reason it takes time to get this
> issue resolved too?  That Red Hat QE is working on improving the situation,
> adding needed regression tests and so on for this use case.  I know I'm
> speculating now, but I also know that these guys really do their best to avoid
> painful experiences for users and customers.  Unfortunately, they do mistakes
> - as we all do from time to time.

Oh, I agree. I really hope RH can learn from this one - and I have no
problems from this simple mistake making it to a release. What I do have
a problem about is that we're nearly 5 months after discovery of this
mistake - and *still* no resolution.

This really should have been a "Whoops, ok - push a single commit with
the fix and get the package out". That could have been addressed, with
QA time included in under two weeks.

At least then, the official line could have been "Oh, yeah - our bad.
The fix is already available" and the issue would have been resolved
before most people even restarted their instance of bind!

The impact of this though - is that because you don't see it straight
away, you find out about this bug report after a reboot - and your DNS
server doesn't work. That's always a bad thing :)

-- 
Steven Haigh

Email: [log in to unmask]
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897