Hi again
Seeing as I started all this with my original post. Perhaps I'd better close off by saying a couple of things.
1. It appears that the very process (ensuring no regression errors creep back in) that is stopping this problem being fixed in a reasonable time-scale, is the very same process that failed to stop this particular regression error. Some sort of twisted catch-22 logic there!
2. I put in an easy to monitor workaround, by setting DISABLE_ZONE_CHECKING="yes" in /etc/sysconfig/named. I can always run a manual named-chkconfig if I need to and now I won't get caught out on the next update.
Cheers and thanks for all the valuable insights.
Bill
-----Original message-----
> From:Steven Haigh <[log in to unmask]>
> Sent: Saturday 19th March 2016 8:43
> To: [log in to unmask]
> Subject: Re: named-chroot issue - AGAIN
>
> On 19/03/2016 1:31 AM, Tom H wrote:
> > On Thu, Mar 17, 2016 at 11:17 PM, David Sommerseth
> > <[log in to unmask]> wrote:
> >> On 17/03/16 13:23, Tom H wrote:
> >>> On Thu, Mar 17, 2016 at 12:53 PM, David Sommerseth
> >>> <[log in to unmask]> wrote:
> >>>>
> >>>> 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.
> >>>
> >>> Given the
> >>> https://git.centos.org/blobdiff/rpms!bind.git/d56ed2d3a2736a07a09c268f3b2607cca8f1b6ca/SOURCES!named-chroot.service
> >>> commit, there's probably a lot of hype in RH's QA marketing claims.
> >>> I'm not implying that there's no QA at all but, in this case, if there
> >>> was any, it sucked.
> >>
> >> The people working on CentOS are not the same people working on RHEL,
> >> even if they're working in the same company. And RHEL is still the
> >> upstream source of CentOS.
> >>
> >> So if CentOS decides to fix this on their own, they need to keep track
> >> of this until it's fixed in RHEL and then remove their own fix. Of
> >> course SL could do that as well, but that can be a maintenance burden.
> >>
> >> That's the downside of being a downstream distro.
> >
> > Just because it's on git.centos.org doesn't mean that this is a CentOS
> > change. It's an import from RH. CentOS doesn't diverge from RHEL with
> > downstream patches. And, AFAIK, SL uses pristine RH sources and not
> > those modified by CentOS.
>
> Correct - that was my point. This is part of a change that RH pushed
> internally and to CentOS. The origin is RedHat - and the change shows
> the source of the bug - RedHat :)
>
> --
> Steven Haigh
>
> Email: [log in to unmask]
> Web: https://www.crc.id.au
> Phone: (03) 9001 6090 - 0412 935 897
>
>
|
