Hello, all. Hope all is well Is it possible to install kernel and support files from 6u7 into a base 6u5 image to achieve full broadwell support in 6u5? We are "locked", clearly not fully since willing to up jump kernels, on 6u5.
Thanks for any and all help
On 6/15/2016 2:48 PM, jsl6uy js16uy wrote:
Hello, all. Hope all is well Is it possible to install kernel and support files from 6u7 into a base 6u5 image to achieve full broadwell support in 6u5? We are "locked", clearly not fully since willing to up jump kernels, on 6u5.
"Locked", meaning you're running a ~3 old OS with no security or bugfix updates? thats not good.
All centos 6 systems are the same base version 2.6.32 kernel, with fixes and updates backported. If you're asking, can you run the 2.6.32-573 kernel with a 6u5 everything-else, well, everything else was never tested with that kernel.
Thanks much for the the reply! Some sec updates/bug fixes have been applied thru the run of 6u5 and after, but yes, still firmly in 6u5 land. Guess will have to test. Broadwell cpus do run in the OS, but "6u5" is stated as not supporting 26XXv4 chipsets.
regards
On Wed, Jun 15, 2016 at 4:56 PM, John R Pierce pierce@hogranch.com wrote:
On 6/15/2016 2:48 PM, jsl6uy js16uy wrote:
Hello, all. Hope all is well Is it possible to install kernel and support files from 6u7 into a base 6u5 image to achieve full broadwell support in 6u5? We are "locked", clearly not fully since willing to up jump kernels, on 6u5.
"Locked", meaning you're running a ~3 old OS with no security or bugfix updates? thats not good.
All centos 6 systems are the same base version 2.6.32 kernel, with fixes and updates backported. If you're asking, can you run the 2.6.32-573 kernel with a 6u5 everything-else, well, everything else was never tested with that kernel.
-- john r pierce, recycling bits in santa cruz
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 06/15/2016 05:10 PM, jsl6uy js16uy wrote:
Thanks much for the the reply! Some sec updates/bug fixes have been applied thru the run of 6u5 and after, but yes, still firmly in 6u5 land. Guess will have to test. Broadwell cpus do run in the OS, but "6u5" is stated as not supporting 26XXv4 chipsets.
Theoretically, it should be possible to run the latest kernel with other older CentOS-6 packages. It may or may not function correctly. That setup would NOT be supported for RHEL (for example). You would therefore need to test it to see if it works well enough for you to use.
But theoretically it is also possible to run whatever workload you are trying to run on the latest '6.7 + updates'.
You would need to test both scenarios to see which one supports your workload the best.
I would point out that we provide CentOS-6, which is defined as all the latest updates installed. Point releases are just a mechanism to create installable trees and new installers for new hardware at a point in time. It has never been a tested scenario to only pick and choose updates while not installing all of them.
There have been more than one CRITICAL update to CentOS since the 6.5 tree and installable media were released, including several updates that correct security issues which have their own name and website. Many of those issues are remotely exploitable .. the actual definition of a 'CRITICAL' update from Red Hat's perspective is:
"This rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. These are the types of vulnerabilities that can be exploited by worms. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as Critical impact."
Taken from: https://access.redhat.com/security/updates/classification
I would think that a customer who had data stolen or was somehow hurt by an entity who purposely ran servers that came into contact with the internet and also purposely ran software that had CRITCAL and correctable security flaws present would be very upset. I would also think that they would expect an entity to install every security update to protect their data .. But what do I know.
Thanks, Johnny Hughes
On Wed, Jun 15, 2016 at 4:56 PM, John R Pierce pierce@hogranch.com wrote:
On 6/15/2016 2:48 PM, jsl6uy js16uy wrote:
Hello, all. Hope all is well Is it possible to install kernel and support files from 6u7 into a base 6u5 image to achieve full broadwell support in 6u5? We are "locked", clearly not fully since willing to up jump kernels, on 6u5.
"Locked", meaning you're running a ~3 old OS with no security or bugfix updates? thats not good.
All centos 6 systems are the same base version 2.6.32 kernel, with fixes and updates backported. If you're asking, can you run the 2.6.32-573 kernel with a 6u5 everything-else, well, everything else was never tested with that kernel.
On 6/15/2016 8:18 PM, Johnny Hughes wrote:
I would point out that we provide CentOS-6, which is defined as all the latest updates installed. Point releases are just a mechanism to create installable trees and new installers for new hardware at a point in time. It has never been a tested scenario to only pick and choose updates while not installing all of them.
+100
I would think that a customer who had data stolen or was somehow hurt by an entity who purposely ran servers that came into contact with the internet and also purposely ran software that had CRITCAL and correctable security flaws present would be very upset. I would also think that they would expect an entity to install every security update to protect their data .. But what do I know.
+100^2
On 06/15/2016 10:18 PM, Johnny Hughes wrote:
On 06/15/2016 05:10 PM, jsl6uy js16uy wrote:
Thanks much for the the reply! Some sec updates/bug fixes have been applied thru the run of 6u5 and after, but yes, still firmly in 6u5 land. Guess will have to test. Broadwell cpus do run in the OS, but "6u5" is stated as not supporting 26XXv4 chipsets.
Theoretically, it should be possible to run the latest kernel with other older CentOS-6 packages. It may or may not function correctly. That setup would NOT be supported for RHEL (for example). You would therefore need to test it to see if it works well enough for you to use.
But theoretically it is also possible to run whatever workload you are trying to run on the latest '6.7 + updates'.
And '6.8 + updates' .. did I forget that I released that less than a month ago :)
You would need to test both scenarios to see which one supports your workload the best.
I would point out that we provide CentOS-6, which is defined as all the latest updates installed. Point releases are just a mechanism to create installable trees and new installers for new hardware at a point in time. It has never been a tested scenario to only pick and choose updates while not installing all of them.
There have been more than one CRITICAL update to CentOS since the 6.5 tree and installable media were released, including several updates that correct security issues which have their own name and website. Many of those issues are remotely exploitable .. the actual definition of a 'CRITICAL' update from Red Hat's perspective is:
"This rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. These are the types of vulnerabilities that can be exploited by worms. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as Critical impact."
Taken from: https://access.redhat.com/security/updates/classification
I would think that a customer who had data stolen or was somehow hurt by an entity who purposely ran servers that came into contact with the internet and also purposely ran software that had CRITCAL and correctable security flaws present would be very upset. I would also think that they would expect an entity to install every security update to protect their data .. But what do I know.
Thanks, Johnny Hughes
On Wed, Jun 15, 2016 at 4:56 PM, John R Pierce pierce@hogranch.com wrote:
On 6/15/2016 2:48 PM, jsl6uy js16uy wrote:
Hello, all. Hope all is well Is it possible to install kernel and support files from 6u7 into a base 6u5 image to achieve full broadwell support in 6u5? We are "locked", clearly not fully since willing to up jump kernels, on 6u5.
"Locked", meaning you're running a ~3 old OS with no security or bugfix updates? thats not good.
All centos 6 systems are the same base version 2.6.32 kernel, with fixes and updates backported. If you're asking, can you run the 2.6.32-573 kernel with a 6u5 everything-else, well, everything else was never tested with that kernel.
On 16/06/16 13:18, Johnny Hughes wrote:
.. the actual definition of a 'CRITICAL' update from Red Hat's perspective is:
"This rating is given to flaws that could be easily*exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction*. These are the types of vulnerabilities that can be exploited by worms. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as Critical impact."
Taken from: https://access.redhat.com/security/updates/classification
I think it's time to add a another link to the mailman suffix.
That bold section should scare anyone storing public data on their servers without keeping up with security updates whether critical or not! I'd say that whole paragraph needs to be added to the Wiki somewhere and the email suffix modified to include a link to it. This would give us a place to point people to - such as - *S**ee link at bottom of signature, you <insert what you feel necessary here>*.
ak.
PS: Here's what my suggestion might look like: <new_sig> ---------- CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos Latest CentOS Release - 7.v.wxyz - https://wiki.centos.org/read-this-if-centos-version-not-at-7.v.wxyz </new_sig>
And just as Johnny said - but what the heck do I know?
Thanks very much all for the responses Apologies for delayed had a back injury keeping afk Definitely have some food for thought
thanks all again
On Sat, Jun 18, 2016 at 10:51 PM, Anthony K akcentos@anroet.com wrote:
On 16/06/16 13:18, Johnny Hughes wrote:
.. the actual definition of a 'CRITICAL' update from Red Hat's perspective is:
"This rating is given to flaws that could be easily*exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction*. These are the types of vulnerabilities that can be exploited by worms. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as Critical impact."
Taken from: https://access.redhat.com/security/updates/classification
I think it's time to add a another link to the mailman suffix.
That bold section should scare anyone storing public data on their servers without keeping up with security updates whether critical or not! I'd say that whole paragraph needs to be added to the Wiki somewhere and the email suffix modified to include a link to it. This would give us a place to point people to - such as - *S**ee link at bottom of signature, you <insert what you feel necessary here>*.
ak.
PS: Here's what my suggestion might look like:
<new_sig> ---------- CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos Latest CentOS Release - 7.v.wxyz - https://wiki.centos.org/read-this-if-centos-version-not-at-7.v.wxyz </new_sig>
And just as Johnny said - but what the heck do I know?
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-
Anthony K -
John R Pierce -
Johnny Hughes -
jsl6uy js16uy