On Sun, 2006-03-26 at 05:26 -0700, Craig White wrote:
> On Sun, 2006-03-26 at 13:51 +0700, Fajar Priyanto wrote:
> > Hi all,
> > Regarding packages updates using yum, all this time I only upgrade packages
> > that I think is important, but also at the same time is having little risk of
> > breaking my installation. Such as httpd, ssh, etc.
> >
> > But there are many packages that waits to be updated such as lvm, mdadm, etc.
> > I'm worried that it will break my installation (web and mail server). Like
> > the saying "if it ain't broken, don't fix it".
> >
> > Is there any pitfall that I should avoid of when upgrading packages using yum?
> > Or is it completely save to let yum update the machine automatically?
> > Thank you very much,
> ----
> One of the reasons that you choose one distribution over another would
> have to be the quality of package maintenance and the timeliness of
> updated packages both for functional fixes and security issues.
>
> <snip>
> The intention of the upstream provider and by extension,
> CentOS is to provide updates that don't break production systems. Of
> course, there are no guarantees. <snip>
If you are behind so far that many 4.2 upgrades got overlooked, be
careful. SEL, and some other issues, had some folks struggling. A couple
of folks have claimed their system is hosed by the current update.
>
> With specificity to your above worries...<snip>
Yes, exactly. First, use the mailing list archives and search for
postings related/time-of 4.2 update and see what problems folks had and
how they solved them. I did that *at-the-time* and had no problems
(maybe just lucky, but I did integrate all that information into my
process). No one here will be able (or want to) regurgitate all the good
information contained in the archives. Like school, homework helps the
learning process.
A personal suggestion: break the updates into small chunks, based on
date, and install all or part of them, wait a few days to see if things
are stable. If so, apply the next chunk. The reason for this is problem
isolation and reduction of risk caused by "massiveness". Recent
complaints include folks having yum fail to complete properly and they
are left with substantial effort to back out and re-do.
Third suggestion:, as Craig states, the reason for using an enterprise-
class is timeliness, among other things. Keep current. Use good
procedures to either enable quick back-out/recovery (2nd choice, but
needed regardless) or do at least minimal (but exhaustive (semi?) is
preferable) testing before installation. Actually both are desirable.
As Craig stated, risk from security vulnerabilities *probably* is higher
than risk from updates *if* you are doing things "The Right Wayz" (TM).
HTH
BILL
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.centos.org/pipermail/centos/attachments/20060326/9b2c476c/attachment.bin
