Ondřej,
it would be awesome if we could choose a higher quality release instead
to use for our longer support. But we lack any good metric to choose
one. So we update from time to time unless there is something stopping us.
On 4/17/23 14:49, Ondřej Surý wrote:
Petr,
while I understand that you are trying to do a great job maintaining
the BIND 9 packages for RHEL, it is what it is - a random snapshot
defined not by the quality of the chosen version but by the time
availability. This is made even more complicated by applying a set
of patches where the set is defined by the downstream maintainer.
The whole idea that something frozen in time with patches applied
by distribution maintainer must be more stable than the software
actively developed by upstream developers is wrong. This could
perhaps work for slow-paced low complex software, but for anything
that's reasonably complex (as various network servers and clients
are) it's doomed to fail.
Well, depends on how you define "stable". The less changes made makes it
more stable in my opinion. Of course that is not necessary better, but
it suits some people. For people with special demands every release
might bring something important. But most people needs just something
that works and does not require attention often. I do not think our RHEL
is low complex software.
And what's even worse that people will come, use the distribution
package of BIND 9 and think this is the "best" quality they can get.
Quality of the package is hard to measure. We spend more time with
integrating bind into the whole system. I admit we lack people working
on each DNS peculiarities, we spend more time dealing with strange
interactions in some conditions. I think that has also its value. I
think distributions provide good enough packages often. It may not suit
everyone, but it did not seem to me this were that case.
If he wanted bleeding edge
This narrative is wrong. I am not recommending people to
run the latest development release - that would be "bleeding edge".
Okay, bleeding edge were wrong word. Anyway, original question were not
about the latest feature added. Our version can provide automated dnssec
service just fine.
By the way, we have packaged even development version on Fedora under
package bind9-next. Because it conflicts with bind system package, it
were not allowed into EPEL (yet). Until I prepare a package that does
not conflict, my copr can be used for EPEL 8 or 9:
https://copr.fedorainfracloud.org/coprs/pemensik/bind9-next/
The latest stable BIND 9 version is not bleeding edge. You are trying to
frame it as it's something dangerous to use the latest version provided
by the upstream developers who are in all due respect more
knowledgeable about the upstream source code than any downstream
package maintainer could be. Sure, that doesn't mean that mistakes
doesn't happen, they do, but running latest upstream patch release
(or latest stable release) is considerably more safe for BIND 9 than
running BIND 9 release that's many version behind, often EOL and
with considerable amount of patches[1] applied.
Sure, we have quite long list of patches on top of bind 9.11. We still
support dhcp server and client in RHEL8. That depends on bind libraries
functionality, which is not provided by bind 9.16 anymore. We have not
stayed on old version because we are lazy, but because more recent
version does not provide compatible interface anymore. You know that.
I admit knowledge of BIND9 internals is far more advanced at ISC than at
Red Hat, it has to be. I do not ask you to support our old versions. But
just don't tell people to avoid vendor version, just because they are
not sure how to configure relative basic thing. If that does not work
when it should, okay, blame us. We deserve it often. This is not the
case IMHO.
So, no, I am not going to stop telling people to stop using packages
bundled with a distribution unless the distribution follows the latest
patch release.
They do on Fedora, would you recommend that? If latest stable release is
what you want, Fedora Server can provide it. If people choose some
"stable" distribution, they usually want to limit number of changes for
some reason.
Alternatively, the RedHat can dedicate a support team to triage,
answer and fix problems in these versions (taken from DistroWatch):
* RHEL 7 - BIND 9.11.4 - released on 2018-07-11 - 33 patch releases behind -
EOL since March 2022[2]
* RHEL 8 - BIND 9.11.36 - released on 2021-10-27 - 1 patch release behind - EOL
since March 2022[2]
* RHEL 9 - BIND 9.16.23 - released on 2021-11-17 - 16 patch releases behind
And since this is not really going to happen, I will continue people to
use upstream sanctioned packages because that will not waste the user
time and it will not waste the developers time.
You still can tell the user what would work on latest stable version. If
it does not work in our version, tell them where to find more recent one
made by you. Or that their vendor has to fix it. We have our support
teams dedicated to our customers, but the place of our support is elsewhere.
RHEL 7 is in maintenance support 2 phase. We will fix only important
security fixes or critical bugs. Anyone using that old distribution
should understand what it means.
if the only issue in our version is unrelated to the problem investigated?
There were 448 merge requests between BIND version 9.16.23 and 9.16.39,
and 963 commits. So, how do you know that? I don't and I am certainly not
willing to spend my already spread-thin time investigating whether any issue
has been fixed in the last year and half, but I would be thrilled to fix any
issue
found in the latest stable BIND release. We don't make changes to BIND 9
just because we can, there's (usually) a good reason behind every commit
and every merge request.
1. https://git.centos.org/rpms/bind/blob/c8s/f/SOURCES
2. https://lists.isc.org/pipermail/bind-announce/2022-March/001210.html
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
I do not request you to investigate problems already fixed in your
versions, which do not yet have fix in ours. If the error is on our
side, okay, say it. But in this case the user has asked how to configure
automated dnssec deployment. I am pretty sure version 9.16.0 were
capable to do it and our 9.16.23 may be not the latest possible version,
but can too. But I am quite confident it is able to do DNSSEC
maintenance using policies, even if it is 500 merge requests old indeed.
We have a good reasons for our commits updating to new versions too. We
need customer feedback stating they are missing a cool feature or bug
fix you already have. We would have very stable bind if we never hear
demand for updated version. Even if you do exceptional job in
maintaining multiple major versions, still some feature changes breaks
old deployment or require some change in configuration. I am paid to
prevent that in our updates.
I do changes to bind in Fedora just because I can. That makes it follow
your release cycles as close as possible. Any RHEL change needs some
justification. It just won't update to every release you have released.
But that does not mean it is incapable version or is unusable in general.
On 17. 4. 2023, at 13:57, Petr Menšík <pemen...@redhat.com> wrote:
Our CentOS/RHEL 8 package are not just random BIND 9 snapshot. If he wanted
bleeding edge, he would use RHEL 9 or even Fedora. But he uses conservative
package I am looking after. While it may have some known issues, it has all
important fixes it needs. Can you please stop telling people to not use our
packages, if the only issue in our version is unrelated to the problem
investigated?
But I admit we should update to more recent BIND 9.16 release already.
Cheers,
Petr
On 4/13/23 15:40, Ondřej Surý wrote:
On 13. 4. 2023, at 15:25, David Carvalho via bind-users
<bind-users@lists.isc.org> wrote:
I'm using 9.16.23
Just don't.
ISC provides packages for major linux distributions
(https://www.isc.org/download/),
so there's really no reason to shoot yourself into foot to use a random BIND 9
snapshot provided by your distro.
And while you are at it - upgrade straight to latest 9.18, your experience will
be much
smoother.
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
