Hello CentOS Community Members,
What is RH's be-all end-all justification for staying with an ancient code base for such important programs as BIND et al?
A similar problem (to BZ561299) was first reported five (5) years ago on the isc.org mailing list.
Is there any support among the CentOS community for a REPO of current vintage for such important functions as BIND et al?
That question is based on the presumption that time is taking us to a more complete and correct implementation of the basic functions like DNS.
IOW, is CentOS philosophy of tracking RH so nailed-to-the-wall that it is blasphemy to propose a REPO of current editions of certain very important functions?
kind regards/ldv
A quote from a long term mentor now at Internet2:
"It's fundamentally wrong for RedHat to attempt to backport security patches for such a fundamental service. I'd cuss a blue streak about this point, in fact, except that I don't want to trigger the anti-cuss features at Dr. Vaughn's place of employment."
===
Reported: 2010-02-03 05:32 EST by Duncan (see https://bugzilla.redhat.com/show_bug.cgi?id=561299):
Additional info:
Works fine in Fedora 4,8,9 and 11, Red Hat Enterprise Linux ES release 4 release 4 (Nahant Update 8) and Red Hat Enterprise Linux Server release 5.1 (Tikanga)
Fails in 5.4 and Fedora 10.
On 02/02/2011 05:22 PM, Larry Vaden wrote:
What is RH's be-all end-all justification for staying with an ancient code base for such important programs as BIND et al?
Did you ask them ? what did they say ?
Is there any support among the CentOS community for a REPO of current vintage for such important functions as BIND et al?
you mean like the bind97 available in c5-testing right now, that should be in 5.6 soon ?
- KB
On Wed, Feb 2, 2011 at 11:22 AM, Karanbir Singh mail-lists@karan.org wrote:
you mean like the bind97 available in c5-testing right now, that should be in 5.6 soon ?
Karanbir,
WIth a lot of due respect, no, not exactly, since 9.7.0-P2 (if I'm reading it correctly) was released almost a year ago by isc.org.
I was thinking more along the lines of /isc/bind9/9.7.2-P3/, released 2 months ago.
Is there that much distrust of the current output of leading authors that we need to "wait a long while"?
kind regards/ldv
On 02/02/2011 06:02 PM, Larry Vaden wrote:
I was thinking more along the lines of /isc/bind9/9.7.2-P3/, released 2 months ago.
If you feel that its the version you need or want, CentOS wont mind if you were to build it and run it yourself.
Is there that much distrust of the current output of leading authors that we need to "wait a long while"?
absolutely. Because I dont trust the authors of component XX to be working on every other component also released that is impacted either upstream or downstream in an app stack. Its the reason why policy and site testing happens.
Expand that to cover the entire component base of whats in the distro and then see how that would fail so spectacularly. If you want a very small taste of what it can be, I'd suggest running rawhide with nightly yum upgrades. Then try to scale that to multiple machines working with different app stacks.
The moment your focus shifts from delivering a service to running code, its game over in the user world. And I do honestly feel that the stabilisation and the expected long life of a nearly -guaranteed- abi/api compliant model in the *EL world makes it a lot easier to retain focus on the service delivery angle.[1]
- KB
[1]: I say that with a pinch of salt though - EL6 is a tad overdue. A lot of new projects and services need a codebase newer than whats on offer in C5.
On 02/02/2011 06:10 PM, Karanbir Singh wrote:
If you feel that its the version you need or want, CentOS wont mind if you were to build it and run it yourself.
btw, if you were to go down that route, the CentOSPlus repo would be a great place to host such a package :)
One of the best advantages of CentOS is that we're not tied down to the EL codebase in any repo outside the [os] and [updates]
- KB
On Wed, Feb 2, 2011 at 12:14 PM, Karanbir Singh mail-lists@karan.org wrote:
On 02/02/2011 06:10 PM, Karanbir Singh wrote:
If you feel that its the version you need or want, CentOS wont mind if you were to build it and run it yourself.
btw, if you were to go down that route, the CentOSPlus repo would be a great place to host such a package :)
One of the best advantages of CentOS is that we're not tied down to the EL codebase in any repo outside the [os] and [updates]
Your approach is a superior approach to others advocating "roll your own" because if for no other reason most folks' skill sets can not be compared to those who "do this every day" vs. once a release for the important stuff like BIND et al.
In short, not enough GOOD GDP/GNP results from "roll your own." "Rolling your own" is "working harder, not smarter."
As far as "providing current services" e.g., I can't recall how long it has been since I attended the first ISC meeting at NANOG to discuss DNSSEC and yet it would surely be interesting to determine how many of the world's DNS servers remain open to exploits solved years ago.
Along those lines, I'll let http://ftp.isc.org/isc/bind9/9.7.2-P3/RELEASE-NOTES-BIND-9.7.2-P3.html speak for itself.
On Wed, Feb 2, 2011 at 12:14 PM, Karanbir Singh mail-lists@karan.org wrote:
btw, if you were to go down that route, the CentOSPlus repo would be a great place to host such a package :)
One of the best advantages of CentOS is that we're not tied down to the EL codebase in any repo outside the [os] and [updates]
Is one expected to support all of the archs?
If not, which set is the minimum to be considered for contribution?
On Wed, Feb 2, 2011 at 12:10 PM, Karanbir Singh mail-lists@karan.org wrote:
[1]: I say that with a pinch of salt though - EL6 is a tad overdue. A lot of new projects and services need a codebase newer than whats on offer in C5.
I agree with you 100%+.
On Wed, Feb 2, 2011 at 12:10 PM, Karanbir Singh mail-lists@karan.org wrote:
[1]: I say that with a pinch of salt though - EL6 is a tad overdue. A lot of new projects and services need a codebase newer than whats on offer in C5.
Karabir,
Should the effort to build community support for an auxiliary repo of current release RPMs be moved to another list?
Check out http://pkgs.org/search/?keyword=wordpress&search_on=smart&distro=0&arch=32-bit&exact=0, e.g.
Or, if you are interested in more fundamental Internet functions that must be as close to complete and correct, see
http://pkgs.org/search/?keyword=bind&search_on=smart&distro=0&arch=32-bit&exact=0.
kind regards/ldv
On February 2, 2011 10:02:03 am Larry Vaden wrote:
Is there that much distrust of the current output of leading authors that we need to "wait a long while"?
You don't need to wait at all. Build your own packages or install from source.
On Wed, Feb 2, 2011 at 1:02 PM, Larry Vaden vaden@texoma.net wrote:
On Wed, Feb 2, 2011 at 11:22 AM, Karanbir Singh mail-lists@karan.org wrote:
you mean like the bind97 available in c5-testing right now, that should be in 5.6 soon ?
Karanbir,
WIth a lot of due respect, no, not exactly, since 9.7.0-P2 (if I'm reading it correctly) was released almost a year ago by isc.org.
I was thinking more along the lines of /isc/bind9/9.7.2-P3/, released 2 months ago.
Is there that much distrust of the current output of leading authors that we need to "wait a long while"?
kind regards/ldv
I appreciate the long roadmap and release schedule.
At my work we need to do two to three year forecasts. Budgets may allow infrastructure updates every three or four years. If upgrading to a newer package means breaking backwards compatibility (i.e., it's an upgrade versus an update), we cannot associate the work and resources to a maintenance budget and may need to find other sources of funding.
That's the business case...
On the technical side, for every application we deploy we need to go through an entire certification process. So updating bind does not mean that we run a few dig queries against the new server, but doing a complete regression test against all applications that rely on bind. This would include revenue generating websites, authentication mechanisms, SSL, NFS mappings, and other apps that require name resolution (and it's surprising how many apps need more than just name/ip).
A few months ago there was an Active Directory update. It had repercussions for a CIFS service running on a human resources server. This affected payroll processing. Now we need to find resources to upgrade that application and we cannot use the same budget.
On Wed, Feb 2, 2011 at 12:41 PM, Kwan Lowe kwan.lowe@gmail.com wrote:
I appreciate the long roadmap and release schedule.
At my work we need to do two to three year forecasts. Budgets may allow infrastructure updates every three or four years.
As a rural ISP investing budget dollars in wireless infrastructure to serve our formerly dialup customers, we run it until it breaks. Nukes and repaves have never been necessary.
Our credit card processing system may soon be 10 years old:
Red Hat Linux release 7.3 (Valhalla) drwxr-xr-x 2 root root 4096 Jun 21 2001 initrd
The compatibility of the systems over a decade+ has been truly amazing.
Speaking budget, I noted the other day in a discussion with a mentor at Internet2.edu that you can now spend $8600 on RH, and, he does, regularly.
That's the rough equivalent of 100 wireless CPEs for 100 new customers, which generate about $3000/month of top line revenue.
I'm impressed that, e.g., /etc/sysconfig/iptables has been in the same place for over a decade, even absent an industry-wide agreed upon file layout for Linux (which would have been a big plus IMHO); in fact, our backup NMC runs Ubuntu 10.10 just so my 64 year old neurons are challenged weekly with "where did they put that?"
IMHO, a nice addition to www.centos.org would be an "About Us" page (Google 'site:www.centos.org "about us"' comes up more or less empty of said).
Long live CentOS, Karanbir, Tru, et al!!! More modest souls would be far too difficult to find.
kind regards/ldv
Larry Vaden, CoFounder Internet Texoma, Inc. Serving Rural Texomaland Since 1995 We Care About Your Connection!
It takes fewer resources to back-port for and support a single suite of software over the lifespan of a major revision than would be needed to fix issues introduced by the major evolution of a large number of packages over the course of a 5-7 year product cycle.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Larry Vaden Sent: Wednesday, February 02, 2011 9:22 AM To: CentOS mailing list Subject: [CentOS] Blasphemous? any support for a REPO of current edition BIND, et al (e.g., BZ561299)?
Hello CentOS Community Members,
What is RH's be-all end-all justification for staying with an ancient code base for such important programs as BIND et al?
A similar problem (to BZ561299) was first reported five (5) years ago on the isc.org mailing list.
Is there any support among the CentOS community for a REPO of current vintage for such important functions as BIND et al?
That question is based on the presumption that time is taking us to a more complete and correct implementation of the basic functions like DNS.
IOW, is CentOS philosophy of tracking RH so nailed-to-the-wall that it is blasphemy to propose a REPO of current editions of certain very important functions?
kind regards/ldv
A quote from a long term mentor now at Internet2:
"It's fundamentally wrong for RedHat to attempt to backport security patches for such a fundamental service. I'd cuss a blue streak about this point, in fact, except that I don't want to trigger the anti-cuss features at Dr. Vaughn's place of employment."
===
Reported: 2010-02-03 05:32 EST by Duncan (see https://bugzilla.redhat.com/show_bug.cgi?id=561299):
Additional info:
Works fine in Fedora 4,8,9 and 11, Red Hat Enterprise Linux ES release 4 release 4 (Nahant Update 8) and Red Hat Enterprise Linux Server release 5.1 (Tikanga)
Fails in 5.4 and Fedora 10. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 02/02/2011 09:22 AM, Larry Vaden wrote:
What is RH's be-all end-all justification for staying with an ancient code base for such important programs as BIND et al?
Directives in the configuration files have changed. Users of RHEL expect to be able to update their systems without anything breaking.
At Wed, 2 Feb 2011 11:22:12 -0600 CentOS mailing list centos@centos.org wrote:
Hello CentOS Community Members,
What is RH's be-all end-all justification for staying with an ancient code base for such important programs as BIND et al?
A similar problem (to BZ561299) was first reported five (5) years ago on the isc.org mailing list.
Is there any support among the CentOS community for a REPO of current vintage for such important functions as BIND et al?
That question is based on the presumption that time is taking us to a more complete and correct implementation of the basic functions like DNS.
IOW, is CentOS philosophy of tracking RH so nailed-to-the-wall that it is blasphemy to propose a REPO of current editions of certain very important functions?
The rpmforge repo has more current releases of some packages. I don't know is bind is one of them. There is also rpmfusion with newer versions as well.
The centosplus repo has newer versions of some packages. Again I don't know if bind is one of them.
Nothing is really stopping you from fetching the Fedora src RPMs and rebuilding them under CentOS. Something like bind would probably build cleanly with little or no messing with the spec file or patching the code, etc., since it probably does not depend on a complex collection of packages (eg like GTK+ or something like that).
kind regards/ldv
A quote from a long term mentor now at Internet2:
"It's fundamentally wrong for RedHat to attempt to backport security patches for such a fundamental service. I'd cuss a blue streak about this point, in fact, except that I don't want to trigger the anti-cuss features at Dr. Vaughn's place of employment."
===
Reported: 2010-02-03 05:32 EST by Duncan (see https://bugzilla.redhat.com/show_bug.cgi?id=561299):
Additional info:
Works fine in Fedora 4,8,9 and 11, Red Hat Enterprise Linux ES release 4 release 4 (Nahant Update 8) and Red Hat Enterprise Linux Server release 5.1 (Tikanga)
Fails in 5.4 and Fedora 10. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Alan Hodgson -
David Brian Chait -
Gordon Messmer -
Karanbir Singh -
Kwan Lowe -
Larry Vaden -
Robert Heller