Hi CentOS developers - I’ve been happily using CentOS for several years now, so thanks for all the good work. In the last week, however, I noticed that while the items in RHSA-2015:1443 has shown up as updates (and announced on centos-announce), the analogous update for CentOS 6, RHSA-2015:1471 (according to https://access.redhat.com/security/cve/CVE-2015-4620), doesn’t seem to be there. Is there any reason why those of us using CentOS 6 are left behind, and/or any idea when a CentOS 6 bind update will be available?
thanks, Noam
On 07/29/2015 11:51 AM, Noam Bernstein wrote:
Hi CentOS developers - I’ve been happily using CentOS for several years now, so thanks for all the good work. In the last week, however, I noticed that while the items in RHSA-2015:1443 has shown up as updates (and announced on centos-announce), the analogous update for CentOS 6, RHSA-2015:1471 (according to https://access.redhat.com/security/cve/CVE-2015-4620), doesn’t seem to be there. Is there any reason why those of us using CentOS 6 are left behind, and/or any idea when a CentOS 6 bind update will be available?
It's currently in the CentOS CR repository and will be released when CentOS 6.7 drops soon. If you want it now then just enable cr and you'll get it with yum update: http://wiki.centos.org/AdditionalResources/Repositories/CR
Peter
On Jul 28, 2015, at 18:48, Peter peter@pajamian.dhs.org wrote:
On 07/29/2015 11:51 AM, Noam Bernstein wrote:
Hi CentOS developers - I’ve been happily using CentOS for several years now, so thanks for all the good work. In the last week, however, I noticed that while the items in RHSA-2015:1443 has shown up as updates (and announced on centos-announce), the analogous update for CentOS 6, RHSA-2015:1471 (according to https://access.redhat.com/security/cve/CVE-2015-4620), doesn’t seem to be there. Is there any reason why those of us using CentOS 6 are left behind, and/or any idea when a CentOS 6 bind update will be available?
It's currently in the CentOS CR repository and will be released when CentOS 6.7 drops soon. If you want it now then just enable cr and you'll get it with yum update: http://wiki.centos.org/AdditionalResources/Repositories/CR
Why didn’t it just go into CentOS 6.6 like a dozen other packages this week?
-- Nate Duehr denverpilot@me.com
On Jul 29, 2015, at 18:20, Nathan Duehr denverpilot@me.com wrote:
On Jul 28, 2015, at 18:48, Peter peter@pajamian.dhs.org wrote:
On 07/29/2015 11:51 AM, Noam Bernstein wrote:
Hi CentOS developers - I’ve been happily using CentOS for several years now, so thanks for all the good work. In the last week, however, I noticed that while the items in RHSA-2015:1443 has shown up as updates (and announced on centos-announce), the analogous update for CentOS 6, RHSA-2015:1471 (according to https://access.redhat.com/security/cve/CVE-2015-4620), doesn’t seem to be there. Is there any reason why those of us using CentOS 6 are left behind, and/or any idea when a CentOS 6 bind update will be available?
It's currently in the CentOS CR repository and will be released when CentOS 6.7 drops soon. If you want it now then just enable cr and you'll get it with yum update: http://wiki.centos.org/AdditionalResources/Repositories/CR
Why didn’t it just go into CentOS 6.6 like a dozen other packages this week?
Disregard, I guess for whatever reason when a new dot-release is going on, things go into CR, but otherwise they go into the dot-release. Or so I just read in the notes about the current repo state.
Yay, another goofy annoying thing to remember and another thing to go add to ansible code to deploy and undeploy this goofy CR repo, just to check machines properly for security updates.
Not that I don’t love ya, volunteers, but I really hate waiting on security updates while they bounce through CR… that doesn’t make any sense at all. Bug fixes, sure… security, no.
Nate
Am 30.07.2015 um 02:27 schrieb Nathan Duehr denverpilot@me.com:
On Jul 29, 2015, at 18:20, Nathan Duehr denverpilot@me.com wrote:
On Jul 28, 2015, at 18:48, Peter peter@pajamian.dhs.org wrote:
On 07/29/2015 11:51 AM, Noam Bernstein wrote:
It's currently in the CentOS CR repository and will be released when CentOS 6.7 drops soon. If you want it now then just enable cr and you'll get it with yum update: http://wiki.centos.org/AdditionalResources/Repositories/CR
Why didn’t it just go into CentOS 6.6 like a dozen other packages this week?
Disregard, I guess for whatever reason when a new dot-release is going on, things go into CR, but otherwise they go into the dot-release. Or so I just read in the notes about the current repo state.
Yay, another goofy annoying thing to remember and another thing to go add to ansible code to deploy and undeploy this goofy CR repo, just to check machines properly for security updates.
Not that I don’t love ya, volunteers, but I really hate waiting on security updates while they bounce through CR… that doesn’t make any sense at all. Bug fixes, sure… security, no.
If "such" security requirements are in your place, then I suggest an upstream subscription ... to get updates faster.
-- LF
On 07/29/2015 07:27 PM, Nathan Duehr wrote:
On Jul 29, 2015, at 18:20, Nathan Duehr denverpilot@me.com wrote:
On Jul 28, 2015, at 18:48, Peter peter@pajamian.dhs.org wrote:
On 07/29/2015 11:51 AM, Noam Bernstein wrote:
Hi CentOS developers - I’ve been happily using CentOS for several years now, so thanks for all the good work. In the last week, however, I noticed that while the items in RHSA-2015:1443 has shown up as updates (and announced on centos-announce), the analogous update for CentOS 6, RHSA-2015:1471 (according to https://access.redhat.com/security/cve/CVE-2015-4620), doesn’t seem to be there. Is there any reason why those of us using CentOS 6 are left behind, and/or any idea when a CentOS 6 bind update will be available?
It's currently in the CentOS CR repository and will be released when CentOS 6.7 drops soon. If you want it now then just enable cr and you'll get it with yum update: http://wiki.centos.org/AdditionalResources/Repositories/CR
Why didn’t it just go into CentOS 6.6 like a dozen other packages this week?
Disregard, I guess for whatever reason when a new dot-release is going on, things go into CR, but otherwise they go into the dot-release. Or so I just read in the notes about the current repo state.
Yay, another goofy annoying thing to remember and another thing to go add to ansible code to deploy and undeploy this goofy CR repo, just to check machines properly for security updates.
Not that I don’t love ya, volunteers, but I really hate waiting on security updates while they bounce through CR… that doesn’t make any sense at all. Bug fixes, sure… security, no.
Of course it makes sense. Those security updates are not released in a vacuum, and all the things they are built on/against also need to be released and installed for them to work.
The source code for the ssecurity updates you are talking about are built against RHEL-6.7, not 6.6 by Red Hat. They don't necessarily work on 6.6 without the other updates installed. They also will not necessarily work correctly if built against 6.6 and then used later on 6.7. We don't do this because it is fun. In fact, it is exact opposite of fun, it is quite a PITA. We do it because in order to run the updates (and have them work correctly), you also have to be running the rest of 6.7.
We are providing CR .. SO .. you can get all the updates if you want them early .. WHILE .. we also test and release 6.7. It is double the work.
Because we do CR, CentOS users had access to the 6.7 updates a full 3 days before anyone else made them available and CR was released less than 5 days after the release of RHEL 6.7.
Thanks, Johnny Hughes
On 07/30/2015 04:37 AM, Johnny Hughes wrote:
On 07/29/2015 07:27 PM, Nathan Duehr wrote:
On Jul 29, 2015, at 18:20, Nathan Duehr denverpilot@me.com wrote:
On Jul 28, 2015, at 18:48, Peter peter@pajamian.dhs.org wrote:
On 07/29/2015 11:51 AM, Noam Bernstein wrote:
Hi CentOS developers - I’ve been happily using CentOS for several years now, so thanks for all the good work. In the last week, however, I noticed that while the items in RHSA-2015:1443 has shown up as updates (and announced on centos-announce), the analogous update for CentOS 6, RHSA-2015:1471 (according to https://access.redhat.com/security/cve/CVE-2015-4620), doesn’t seem to be there. Is there any reason why those of us using CentOS 6 are left behind, and/or any idea when a CentOS 6 bind update will be available?
It's currently in the CentOS CR repository and will be released when CentOS 6.7 drops soon. If you want it now then just enable cr and you'll get it with yum update: http://wiki.centos.org/AdditionalResources/Repositories/CR
Why didn’t it just go into CentOS 6.6 like a dozen other packages this week?
Disregard, I guess for whatever reason when a new dot-release is going on, things go into CR, but otherwise they go into the dot-release. Or so I just read in the notes about the current repo state.
Yay, another goofy annoying thing to remember and another thing to go add to ansible code to deploy and undeploy this goofy CR repo, just to check machines properly for security updates.
Not that I don’t love ya, volunteers, but I really hate waiting on security updates while they bounce through CR… that doesn’t make any sense at all. Bug fixes, sure… security, no.
Of course it makes sense. Those security updates are not released in a vacuum, and all the things they are built on/against also need to be released and installed for them to work.
The source code for the ssecurity updates you are talking about are built against RHEL-6.7, not 6.6 by Red Hat. They don't necessarily work on 6.6 without the other updates installed. They also will not necessarily work correctly if built against 6.6 and then used later on 6.7. We don't do this because it is fun. In fact, it is exact opposite of fun, it is quite a PITA. We do it because in order to run the updates (and have them work correctly), you also have to be running the rest of 6.7.
We are providing CR .. SO .. you can get all the updates if you want them early .. WHILE .. we also test and release 6.7. It is double the work.
Because we do CR, CentOS users had access to the 6.7 updates a full 3 days before anyone else made them available and CR was released less than 5 days after the release of RHEL 6.7.
For those interested, here is a bit longer explanation:
When you build C (the language) programs on GNU/Linux, the vast majority of programs on CentOS or any other Linux distro are C or C++, you use a compiler called gcc and run against a standard c library called glibc.
The gcc and glibc packages are updated almost every point release in CentOS.
Also, most programs have other "Build Requirements" where they build against other other "devel" packages as well. A "devel" has headers that reference libraries and one program "links" against another program and uses that other program's libraries in order to run.
I will use a build in the latest CentOS-7 tree as all our build logs for CentOS-7 are public.
Let us look at build of the package ipa-4.1.0-18.el7.centos.3.x86_64.rpm. It was built on timestamp 20150326124151 (March 26th, 2015 at 12:41:51 UTC), and the logs can be found here:
http://buildlogs.centos.org/c7.01.u/ipa/20150326124151/4.1.0-18.el7.centos.3...
If you look at the root.log file, you will see a group of files starting with bash after a line:
DEBUG util.py:282: Installing:
That is the 24 packages CentOS Linux uses to create our x86_64 build root. Those 24 packages "bring in" another group of packages and there are 153 total packages in the build root. You can see the versions of each of those packages in the root log.
The only 'devel' packages in the generic build root are glibc-devel (part of the gcc source) and libstdc++-devel (part of gcc source). The gcc package is 4.8.3-9.el7 and the glibc package is 2.17-78.el7. If using older gcc or glibc packages, it is possible to have issues calling something that does not exist. That means this is ipa package is only TESTED to run on gcc and glibc higher than 4.8.3-9.el7 and 2.17-78.el7. If you use older ones, there could be issues. So, this package should be used with only CentOS version 7.1.1503 or newer as those versions of glibc and gcc were introduced at that point. (Note: newer versions of gcc and glibc are normally compatible, older versions may or may not be, hence newer than 7.1.1503 should always work correctly, older maybe not).
Now, lets look at the 'build requirements' that ipa brings in. If you find another line called:
DEBUG util.py:282: Installing:
With 389-ds-base-devel after it, you see that there are 53 specific requirements called out .. and you can see the versions that are used. Those 53 requirements pull in an additional 163 packages (216 total). You can see the versions of each of those packages in the root log.
The ipa libraries could link against any of the 'devel' packages that are in the build root (I quickly counted 33 besides gcc and glibc).
So, that means there are as many as 35 possible library dependencies that ipa has. Using this version of ipa with any of those dependencies earlier than the ones used to build it could cause issues.
That is what every update that Red Hat puts out says this in the text (let's look at the release of Red Hat's same version of IPA):
https://rhn.redhat.com/errata/RHSA-2015-0728.html
Look at the 'Solution' section, it says this:
* Before applying this update, make sure all previously released errata relevant to your system have been applied. *
It does not say all security updates or all the cherry picked updates that you think you might want to install .. it says "all errata". All errata includes all Bug Fixes, all Enhancement Updates, all Security Updates that are applicable for the packages that you have installed.
Is that "REALLY" necessary? Maybe. Running ipa without any of the updates used to build ipa "COULD" result in calls to things that don't exist. Could look in the shared libraries at different spots, call things in different ways, etc. That could introduce bugs that do not exist if all the updates are installed. Some of those newly introduced bugs COULD have security implications .. OR .. it might work fine with the older stuff. An in-depth analysis would be required to determine that.
But that is why Red Hat says that you have to "make sure" to install "all previously released errata relevant to your system" when installing that version of ipa though. Because that group of packages is tested and it works.
That is why I can't just cherry pick a bind update or a libuser update built on the CentOS-6.7 package set and release it in 6.6 or 6.5 or 6.4 .. it may or may not work and it may or may not be secure in that environment.
Thanks, Johnny Hughes
Am 30.07.2015 um 12:53 schrieb Johnny Hughes johnny@centos.org:
On 07/30/2015 04:37 AM, Johnny Hughes wrote:
Because we do CR, CentOS users had access to the 6.7 updates a full 3 days before anyone else made them available and CR was released less than 5 days after the release of RHEL 6.7.
For those interested, here is a bit longer explanation:
Thanks to take the time for this explicit explanation. In particular because this "missing piece" resurfaces the same discussions. A candidate for the wiki (if not already there).
... That is why I can't just cherry pick a bind update or a libuser update built on the CentOS-6.7 package set and release it in 6.6 or 6.5 or 6.4 .. it may or may not work and it may or may not be secure in that environment.
Is it a good idea to reflect this consequently via %{dist} (e.g el5_11 el6_7)?? This should not conflict with upstreams package versioning. Despite that some packages stay on the same version while the distribution is moving forward. But it shows the relation like acme.1.el6_4.3 is for 6.4 or higher. Not sure if upstream is using it in that conceptual manner: Following upstream listing shows some ambiguous %{dist} tags, thought.
httpd-2.2.15-5.el6.src.rpm httpd-2.2.15-9.el6.src.rpm httpd-2.2.15-9.el6_1.2.src.rpm httpd-2.2.15-9.el6_1.3.src.rpm httpd-2.2.15-15.el6.src.rpm httpd-2.2.15-15.el6_2.1.src.rpm httpd-2.2.15-26.el6.src.rpm httpd-2.2.15-28.el6_4.src.rpm httpd-2.2.15-29.el6_4.src.rpm httpd-2.2.15-30.el6_5.src.rpm httpd-2.2.15-31.el6_5.src.rpm httpd-2.2.15-39.el6.src.rpm httpd-2.2.15-45.el6.src.rpm
-- LF
On 07/30/2015 08:00 AM, Leon Fauster wrote:
Am 30.07.2015 um 12:53 schrieb Johnny Hughes johnny@centos.org:
On 07/30/2015 04:37 AM, Johnny Hughes wrote:
Because we do CR, CentOS users had access to the 6.7 updates a full 3 days before anyone else made them available and CR was released less than 5 days after the release of RHEL 6.7.
For those interested, here is a bit longer explanation:
Thanks to take the time for this explicit explanation. In particular because this "missing piece" resurfaces the same discussions. A candidate for the wiki (if not already there).
... That is why I can't just cherry pick a bind update or a libuser update built on the CentOS-6.7 package set and release it in 6.6 or 6.5 or 6.4 .. it may or may not work and it may or may not be secure in that environment.
Is it a good idea to reflect this consequently via %{dist} (e.g el5_11 el6_7)?? This should not conflict with upstreams package versioning. Despite that some packages stay on the same version while the distribution is moving forward. But it shows the relation like acme.1.el6_4.3 is for 6.4 or higher. Not sure if upstream is using it in that conceptual manner: Following upstream listing shows some ambiguous %{dist} tags, thought.
httpd-2.2.15-5.el6.src.rpm httpd-2.2.15-9.el6.src.rpm httpd-2.2.15-9.el6_1.2.src.rpm httpd-2.2.15-9.el6_1.3.src.rpm httpd-2.2.15-15.el6.src.rpm httpd-2.2.15-15.el6_2.1.src.rpm httpd-2.2.15-26.el6.src.rpm httpd-2.2.15-28.el6_4.src.rpm httpd-2.2.15-29.el6_4.src.rpm httpd-2.2.15-30.el6_5.src.rpm httpd-2.2.15-31.el6_5.src.rpm httpd-2.2.15-39.el6.src.rpm httpd-2.2.15-45.el6.src.rpm
Normally, Red Hat uses longer dist tags (.el6_5, .el7_1, etc) for updates that happen between point releases. So, if they do an update after the RHEL 6.7 release, before they release 6.8, it will likely have a dist tag of .el6_7
For releases that happen on a point release (ie, for the 6.7 GA release) .. OR into their FasTrack repo, they normally use .el6 (or .el7, etc).
CentOS Linux normally also follows the upstream dist tags, except for packages where we make changes, where we use .el6.centos on those to denote we have modified them.
On Tue, 2015-08-04 at 07:06 -0500, Johnny Hughes wrote:
CentOS Linux normally also follows the upstream dist tags, except for packages where we make changes, where we use .el6.centos on those to denote we have modified them.
I thought, mistakenly perhaps, that Centos = RHEL without the RHEL branding.
Why would Centos modify a RHEL package before offering the package to its devoted and appreciative Centos users ?
This is what I thought, too, and without all the RHEL-centricities such as RHN.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Always Learning Sent: Tuesday, August 04, 2015 4:40 PM To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] why no recent bind update for CentOS 6?
On Tue, 2015-08-04 at 07:06 -0500, Johnny Hughes wrote:
CentOS Linux normally also follows the upstream dist tags, except for packages where we make changes, where we use .el6.centos on those to denote we have modified them.
I thought, mistakenly perhaps, that Centos = RHEL without the RHEL branding.
On Tue, 2015-08-04 at 15:12 -0700, Gordon Messmer wrote:
On 08/04/2015 02:40 PM, Always Learning wrote:
I thought, mistakenly perhaps, that Centos = RHEL without the RHEL branding.
Why would Centos modify a RHEL package before offering the package to its devoted and appreciative Centos users ?
To remove the RHEL branding?
No. Johnny wrote
"CentOS Linux normally also follows the upstream dist tags, except " for packages where we make changes, where we use .el6.centos on " those to denote we have modified them."
On 08/05/2015 11:30 AM, Always Learning wrote:
No. Johnny wrote
"CentOS Linux normally also follows the upstream dist tags, except " for packages where we make changes, where we use .el6.centos on " those to denote we have modified them."
Yes, certain packages have to be modified to remove RedHat branding. Certain other packages have to be modified to point to CentOS repositories, etc. In extremely rare cases there may be a critical security vulnerability which the CentOS developers feel merits an update before RedHat release theirs, in these cases the updated RedHat package will take precedence once it is released.
CentOS is, in as much as is reasonably possible, a clone of RHEL, but it cannot be an exact duplicate of all the packages.
Peter
On 08/04/2015 06:40 PM, Peter wrote:
On 08/05/2015 11:30 AM, Always Learning wrote:
No. Johnny wrote
"CentOS Linux normally also follows the upstream dist tags, except " for packages where we make changes, where we use .el6.centos on " those to denote we have modified them."
Yes, certain packages have to be modified to remove RedHat branding. Certain other packages have to be modified to point to CentOS repositories, etc.
peter is correct here .. we have to modify certain packages to remove RHEL branding .. or to point to our repos instead of Red Hat ones .. when we do that, we use .el<num>.centos where num is 5 or 6 or 7 for centos-5 or centos-6 or centos-7.
In extremely rare cases there may be a critical security vulnerability which the CentOS developers feel merits an update before RedHat release theirs, in these cases the updated RedHat package will take precedence once it is released.
And there might be a critical issue where we would publish a fix early .. for example we did for Heartbleed .. and what peter said is true there too. It would be announced and explained as to why we did it, etc.
CentOS is, in as much as is reasonably possible, a clone of RHEL, but it cannot be an exact duplicate of all the packages.
I don't like the word clone .. but certainly CentOS is a rebuild of RHEL source code with the fewest changes possible to meet the trademark/branding requirements as the goal.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/06/2015 12:33 PM, Johnny Hughes wrote:
CentOS is, in as much as is reasonably possible, a clone of RHEL, but it cannot be an exact duplicate of all the packages.
I don't like the word clone .. but certainly CentOS is a rebuild of RHEL source code with the fewest changes possible to meet the trademark/branding requirements as the goal.
Fair enough, clone is a bad word in this regard. Rebuild is definitely a much better word.
Peter
On 08/04/2015 04:40 PM, Always Learning wrote:
On Tue, 2015-08-04 at 07:06 -0500, Johnny Hughes wrote:
CentOS Linux normally also follows the upstream dist tags, except for packages where we make changes, where we use .el6.centos on those to denote we have modified them.
I thought, mistakenly perhaps, that Centos = RHEL without the RHEL branding.
Why would Centos modify a RHEL package before offering the package to its devoted and appreciative Centos users ?
We have to modify the source code to remove the branding .. as I explained in the other post.
BUT, I do want to point out that the CentOS Team has never said CentOS = RHEL.
CentOS is a rebuild of RHEL source code, built in the order that it is released by Red Hat. And we do modify it to meet the Red Hat trademark requirements (ie, remove Red Hat branding).
Just because we build the source code in the order that it is released does not mean it is an exact copy of RHEL .. and in fact, CentOS Linux certainly is NOT an exact copy of RHEL, nor has it ever been.
This is because both build systems (the CentOS one and the RHEL one) are "closed systems" and they are certainly not identical.
Why is that?
Red Hat freezes a Fedora tree to start a new RHEL tree at some "point in time" and they start stabilizing that tree. For RHEL 7, that was near the Fedora 18/19 time frame. They remove many packages that they are not going to use and they develop a set of binary packages that they are going to use as their initial binary tree. They then spend a long time on that tree , building many packages iterations, before they release their RHEL public beta. Just as a point of reference, Fedora 18 was released on 2013-01-15 (Jan 15, 2013) and Fedora 19 was released on 2013-07-02 (July 2, 2013). Their RHEL7 initial tree was likely sometime between those dates.
RHEL-7 Beta was released on 2013-12-11 (December 11th, 2013) .. so Red Hat likely spent somewhere between 4 and 11 months (closer to 11, I would think) stabilizing that beta tree.
When they released the RHEL-7 beta on December 11th, 2015, the CentOS team had that set of Source Code and binary RPMs and Fedora 18 and Fedora 19 to use to do our initial build. Red Hat had a closed and staged build system with any number of intermediary builds in their build root, not just 2 fedora builds and the 1 RHEL beta.
When we built our Beta from that limited set of packages, there is no way that we could duplicate the exact intermediary builds .. no one outside of the people who have access to that closed Red Hat build system even KNOWS the iterations in that build system.
Red Hat then took input from their beta release (from users and testing) and did an RC on April 3rd, 2015, and a final QA release on June 9th, 2014 (6 months later). We (the CentOS team) did not get any of their closed build system info then either. We had our beta (based on their beta), our RC (based on their RC), and Fedora 18 and Fedora 19. They had a closed build system with like several thousand other package iterations in it.
So, that is why CentOS is NOT a CLONE of RHEL .. it is instead a rebuild of the RHEL source code in way to produce a Linux distribution which is "functionally compatible" (meaning it does the same things) as RHEL. But you will find, if you do direct comparisons of all the binaries and libraries, that almost every single one of the CentOS files is different in md5sum from the RHEL counterparts.
To reiterate, CentOS is built using the RHEL source code .. but it is NOT even close to being a CLONE of RHEL.
Hello.
But what version is recommended to use ? RHEL release or ISC ? From RHEL is 9.8 and ISC 9.10...
-----Mensagem original----- De: centos-bounces@centos.org [mailto:centos-bounces@centos.org] Em nome de Always Learning Enviada em: quinta-feira, 6 de agosto de 2015 01:03 Para: CentOS mailing list Assunto: Re: [CentOS] why no recent bind update for CentOS 6?
On Wed, 2015-08-05 at 21:59 -0500, Johnny Hughes wrote:
To reiterate, CentOS is built using the RHEL source code .. but it is NOT even close to being a CLONE of RHEL.
Thank you for your explanation.
Best wishes,
Paul. England, EU. England's place is in the European Union.
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thu, Aug 06, 2015 at 01:54:21PM +0000, Leonardo Oliveira Ortiz wrote:
But what version is recommended to use ? RHEL release or ISC ? From RHEL is 9.8 and ISC 9.10...
I suggest re-reading this whole thread.
Use the package that's provided by CentOS.
Am 06.08.2015 um 16:29 schrieb Jonathan Billings billings@negate.org:
On Thu, Aug 06, 2015 at 01:54:21PM +0000, Leonardo Oliveira Ortiz wrote:
But what version is recommended to use ? RHEL release or ISC ? From RHEL is 9.8 and ISC 9.10...
I suggest re-reading this whole thread.
and https://access.redhat.com/security/updates/backporting
Use the package that's provided by CentOS.
-- LF
Am 06.08.2015 um 04:59 schrieb Johnny Hughes johnny@centos.org:
We have to modify the source code to remove the branding .. as I explained in the other post.
BUT, I do want to point out that the CentOS Team has never said CentOS = RHEL.
CentOS is a rebuild of RHEL source code, built in the order that it is released by Red Hat. And we do modify it to meet the Red Hat trademark requirements (ie, remove Red Hat branding).
Just because we build the source code in the order that it is released does not mean it is an exact copy of RHEL .. and in fact, CentOS Linux certainly is NOT an exact copy of RHEL, nor has it ever been.
This is because both build systems (the CentOS one and the RHEL one) are "closed systems" and they are certainly not identical.
Why is that?
Red Hat freezes a Fedora tree to start a new RHEL tree at some "point in time" and they start stabilizing that tree. For RHEL 7, that was near the Fedora 18/19 time frame. They remove many packages that they are not going to use and they develop a set of binary packages that they are going to use as their initial binary tree. They then spend a long time on that tree , building many packages iterations, before they release their RHEL public beta. Just as a point of reference, Fedora 18 was released on 2013-01-15 (Jan 15, 2013) and Fedora 19 was released on 2013-07-02 (July 2, 2013). Their RHEL7 initial tree was likely sometime between those dates.
RHEL-7 Beta was released on 2013-12-11 (December 11th, 2013) .. so Red Hat likely spent somewhere between 4 and 11 months (closer to 11, I would think) stabilizing that beta tree.
When they released the RHEL-7 beta on December 11th, 2015, the CentOS team had that set of Source Code and binary RPMs and Fedora 18 and Fedora 19 to use to do our initial build. Red Hat had a closed and staged build system with any number of intermediary builds in their build root, not just 2 fedora builds and the 1 RHEL beta.
Despite the different context I want just to jump in because some question are not clearly here as we start to migrate our services to C7 now.
The above mentioned set of source code respectively pkgs are clearly available for RHEL-6, RHEL-5 and older via upstreams ftp service (as provided by RH itself). Git.centos.org was communicated as the canonical upstream for the sources of C7 (not RHEL-7).
Is RH importing the pkgs into the git repository directly? RHEL-7 vs C7: Are the sources equal or the same? Are other rebuilders consuming the RHEL-7 sources only via git.centos.org?
Hope that this aren't to many questions at the same time - thanks,
-- LF
On Thu, Jul 30, 2015 at 5:37 AM, Johnny Hughes johnny@centos.org wrote:
On 07/29/2015 07:27 PM, Nathan Duehr wrote:
On Jul 29, 2015, at 18:20, Nathan Duehr denverpilot@me.com wrote:
On Jul 28, 2015, at 18:48, Peter peter@pajamian.dhs.org wrote:
On 07/29/2015 11:51 AM, Noam Bernstein wrote:
Hi CentOS developers - I’ve been happily using CentOS for several years now, so thanks for all the good work. In the last week, however, I noticed that while the items in RHSA-2015:1443 has shown up as updates (and announced on centos-announce), the analogous update for CentOS 6, RHSA-2015:1471 (according to https://access.redhat.com/security/cve/CVE-2015-4620), doesn’t seem to be there. Is there any reason why those of us using CentOS 6 are left behind, and/or any idea when a CentOS 6 bind update will be available?
It's currently in the CentOS CR repository and will be released when CentOS 6.7 drops soon. If you want it now then just enable cr and you'll get it with yum update: http://wiki.centos.org/AdditionalResources/Repositories/CR
Why didn’t it just go into CentOS 6.6 like a dozen other packages this
week?
Disregard, I guess for whatever reason when a new dot-release is going
on, things go into CR, but otherwise they go into the dot-release. Or so I just read in the notes about the current repo state.
Yay, another goofy annoying thing to remember and another thing to go
add to ansible code to deploy and undeploy this goofy CR repo, just to check machines properly for security updates.
Not that I don’t love ya, volunteers, but I really hate waiting on
security updates while they bounce through CR… that doesn’t make any sense at all. Bug fixes, sure… security, no.
Of course it makes sense. Those security updates are not released in a vacuum, and all the things they are built on/against also need to be released and installed for them to work.
The source code for the ssecurity updates you are talking about are built against RHEL-6.7, not 6.6 by Red Hat. They don't necessarily work on 6.6 without the other updates installed. They also will not necessarily work correctly if built against 6.6 and then used later on 6.7. We don't do this because it is fun. In fact, it is exact opposite of fun, it is quite a PITA. We do it because in order to run the updates (and have them work correctly), you also have to be running the rest of 6.7.
We are providing CR .. SO .. you can get all the updates if you want them early .. WHILE .. we also test and release 6.7. It is double the work.
Because we do CR, CentOS users had access to the 6.7 updates a full 3 days before anyone else made them available and CR was released less than 5 days after the release of RHEL 6.7.
Thanks, Johnny Hughes
OK, sorry to bring this up again, but why then is CentOS doing "rolling updates" for CentOS 7 with different version numbers/base builds from RedHat?
Based on what you said here, the CentOS 7 strategy doesn't make any sense to me.
On Jul 30, 2015, at 03:37, Johnny Hughes johnny@centos.org wrote:
Of course it makes sense. Those security updates are not released in a vacuum, and all the things they are built on/against also need to be released and installed for them to work.
The source code for the ssecurity updates you are talking about are built against RHEL-6.7, not 6.6 by Red Hat. They don't necessarily work on 6.6 without the other updates installed. They also will not necessarily work correctly if built against 6.6 and then used later on 6.7. We don't do this because it is fun. In fact, it is exact opposite of fun, it is quite a PITA. We do it because in order to run the updates (and have them work correctly), you also have to be running the rest of 6.7.
We are providing CR .. SO .. you can get all the updates if you want them early .. WHILE .. we also test and release 6.7. It is double the work.
Because we do CR, CentOS users had access to the 6.7 updates a full 3 days before anyone else made them available and CR was released less than 5 days after the release of RHEL 6.7.
Thanks, Johnny Hughes
Fair enough. Standard library dependency hell, I know… with everything the entire OS is built on at the foundation level, a continually moving target.
Didn’t mean to complain TOO loudly… you guys do a great job with what you have to work with from upstream. (Not just meaning RH, but all the never-ending updates from all their upstreams. Because you know… “software is getting better!”… ROFLMAO… 20 years of hearing that… hasn’t come true yet! GRIN!)
I certainly wouldn’t mind if my employer wasn’t too cheap to buy the real deal from RH and have all the nice patching and auditing tools, but alas… it is what it is. At least we have CentOS! Plus I’m dumb enough not to mandate it, trying to be the “good guy” and save them some $. (GRIN)
I was cranky yesterday - I was patching Windoze servers, which is way less safe to do, and way more annoying. Apologies for the tone. :) :) :)
Honestly I don’t know how you guys do it…
-- Nate
On Jul 30, 2015, at 20:09, Always Learning centos@u64.u22.net wrote:
On Thu, 2015-07-30 at 11:45 -0600, Nathan Duehr wrote:
Honestly I don’t know how you guys do it…
By not using Windoze ?
I meant the time… the time… involved… so much time…
:-)
-- Nate Duehr denverpilot@me.com
On Wed, 29 Jul 2015 12:48:14 +1200 Peter peter@pajamian.dhs.org wrote:
On 07/29/2015 11:51 AM, Noam Bernstein wrote:
Hi CentOS developers - I’ve been happily using CentOS for several years now, so thanks for all the good work. In the last week, however, I noticed that while the items in RHSA-2015:1443 has shown up as updates (and announced on centos-announce), the analogous update for CentOS 6, RHSA-2015:1471 (according to https://access.redhat.com/security/cve/CVE-2015-4620), doesn’t seem to be there. Is there any reason why those of us using CentOS 6 are left behind, and/or any idea when a CentOS 6 bind update will be available?
It's currently in the CentOS CR repository and will be released when CentOS 6.7 drops soon. If you want it now then just enable cr and you'll get it with yum update: http://wiki.centos.org/AdditionalResources/Repositories/CR
And currently there's a 2nd reason to visit CR and pick up security updates:
libuser local root, RHSA-2015-1482 / CVE-2015-3245, CVE-2015-3246
/Peter K
-
Always Learning -
Gordon Messmer -
Johnny Hughes -
Jonathan Billings -
Leon Fauster -
Leonardo Oliveira Ortiz -
Nathan Duehr -
Noam Bernstein -
Peter -
Peter Kjellström -
Phelps, Matthew -
Robert Wolfe