On 08/12/2011 04:14 AM, Andreas Petzold wrote:
On Friday, August 12, 2011 12:50:12 carlopmart wrote:
On 08/12/2011 12:22 PM, Morten Stevens wrote:
On Fri, 12 Aug 2011 11:58:19 +0200, carlopmart wrote:
Thanks Andreas, but security updates are applied?? For example, last
kernel version for SL6.0 is kernel-2.6.32-71.29.1, and for SL6.1 is
2.6.32-131.6.1. When I will launch "yum update", kernel will updated
with 71.29.1 version or with 131.6.1 version?? It is only an example,
but I am referrering to all packages for SL6.0 version ...
Hi,
After yum update the kernel will be updated to 2.6.32-131.6.1. (SL6.1)
Otherwise you would have to exclude the kernel update in your yum
configuration.
For example:
/etc/yum.conf
exclude=kernel*
Best regards,
Morten
After read your mail, Is it correct to say: "you can't stay at SL6.0
with security updates applied. Always, you will be upgraded to latest
SL6.x + security patches", right??
no. Your notion of upgrade/security fix is a bit different from RH/SL.
There simply is no such thing as an updated 2.6.32-71.29.1 kernel. That's what
kernel 2.6.32-131.6.1 is.
If you install 6.0 and only do "yum update", you will never automatically go
to 6.1. You will get security fixes, but no new features like for instance
some new RH tech preview stuff.
As I said before, if you really need a specific version of a package, you
should exclude it in the yum config. Of course, you won't get security
updates, since that is a version change.
Cheers,
Andreas
I have a suggestion for a better solution, one that may exist internally
at Red Hat (it did at HP for HP-UX, a commercial SVR4
release/distribution) but that does not seem to be at the community.
Some upgrades fix bugs, some upgrades fix security holes, some upgrades
improve performance, some upgrades simply clean up highly patched code
that is approaching "spaghetti" or "ravioli" depending upon the paradigm
used, and some upgrades introduce new packages/utilities/drivers.
If this were made clear in a searchable data base with fixed key words,
or the equivalent matrix, then the matter could be resolved.
An example may help to make this clear. Suppose package foobar contains
utility foobar1 and libraries foobarlib.so and foobarlib.a . Suppose it
was found, say by CERT or reports thereon, that the backwards weavil
upside down needle (I am making up a name but this sort of name appears
in the literature) attack exploits a memory leak in foobarlib-N.m
allowing a root shell exploit. This is fixed in foobarlib-X, X > N.m .
Moreover, a change in package foobar requires that packages muckup,
rollover, and regurg all need to be updated as these depend upon package
foobar and will not function with the newer, fixed package.
Were this security issue to be made clear by searchable keyword, then a
systems maintenance person could make an informed decision as to the
security (or driver or ... ) fixes of any package upgrade, implementing
the exclusion of the specific package as she or he requires. This is
with the understanding that such an excluded update system produces a
hybrid in some state between RHEL X.k and RHEL X.k+n, n>0 .
Note that the upgrade issues typically are made clear by a detailed
reading of the release notes or update history of package foobar,
usually maintained at the upstream vendor and evidently reproduced in
some form in the SL package notes. However, there does not seem to be a
simple searchable keyword database.
My suggestion does not address the EOL (or EOS) issues at which epoch an
update may be regarded as mandatory.
Yasha Karant
