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,
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.
In one respect, CentOS 'base' has it easy, in that the source of the updates is provided for them - they only have to rebuild it (not intending to diminish the lengths that they go to to rebuild some of the packages). 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. If you want guarantees...I suppose you buy RHEL.
With specificity to your above worries...you should be greatly concerned because the updates to the very things you mentioned...httpd, ssh (probably some of the etc.) are 'security' updates and by failing to update them, you are risking far more to your installation by not updating them. The truth is...there are packages that are broke and do need fixing but you are choosing to ignore that fact.
While I might suggest flippantly to live on the edge and just do 'yum update' - the fact is, just about everyone on this list does that frequently and some have it do that automatically/unattended. That is the intended use (to frequently run 'yum update')
Craig
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
On Sunday 26 March 2006 09:52 pm, William L. Maltby wrote:
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).
Using a test bed machine is what I used to do. Usually I do that on my notebook, whereas it resembles my current production server. However, since I migrate all my servers from FC4 to Centos4.2, I still haven't got any test machine yet, the notebook is still on FC4.
I guess, I'll make a dual boot on the notebook between FC5 and Centos4.2 soon. Thanks, I'll research into the list archive. Luckily I've never deleted any list emails that I subscribe. :)
Using a test bed machine is what I used to do. Usually I do that on my notebook, whereas it resembles my current production server. However, since I migrate all my servers from FC4 to Centos4.2, I still haven't got any test machine yet, the notebook is still on FC4.
I guess, I'll make a dual boot on the notebook between FC5 and Centos4.2 soon. Thanks, I'll research into the list archive. Luckily I've never deleted any list emails that I subscribe. :)
Dual boot ???
FC5 has Xen ... you can install CentOS within FC5 using XEN
Leonel
Dual boot ???
FC5 has Xen ... you can install CentOS within FC5 using XEN
Indeed, but don't we need a xen-aware kernel? Would that be with FC5 or CentOS as the dom0? Would graphical X work in both OS's? [that actually doesn't matter all that much, you can use remote X or NX just fine for anything that isn't graphics intensive (ie only games), and you'd want to only run games in FC5 I'd assume anyway...
Anybody know if the Xen in FC5 run WinXP on a normal cpu without virtualization extensions?
Cheers, MaZe
On Sunday 26 March 2006 10:25, Maciej Żenczykowski wrote:
Dual boot ???
FC5 has Xen ... you can install CentOS within FC5 using XEN
Indeed, but don't we need a xen-aware kernel? Would that be with FC5 or CentOS as the dom0? Would graphical X work in both OS's? [that actually doesn't matter all that much, you can use remote X or NX just fine for anything that isn't graphics intensive (ie only games), and you'd want to only run games in FC5 I'd assume anyway...
Anybody know if the Xen in FC5 run WinXP on a normal cpu without virtualization extensions?
you can only run an unmodified os in xen with cpu virtualization. so if you want to run an unmodified CentOS you need a cpu that has virtualization extensions. the only other way to do it is patch xen into the CentOS kernel
Dennis Gilmore wrote:
On Sunday 26 March 2006 10:25, Maciej Żenczykowski wrote:
Dual boot ???
FC5 has Xen ... you can install CentOS within FC5 using XEN
Indeed, but don't we need a xen-aware kernel? Would that be with FC5 or CentOS as the dom0? Would graphical X work in both OS's? [that actually doesn't matter all that much, you can use remote X or NX just fine for anything that isn't graphics intensive (ie only games), and you'd want to only run games in FC5 I'd assume anyway...
Anybody know if the Xen in FC5 run WinXP on a normal cpu without virtualization extensions?
you can only run an unmodified os in xen with cpu virtualization. so if you want to run an unmodified CentOS you need a cpu that has virtualization extensions. the only other way to do it is patch xen into the CentOS kernel _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
DOH !!!
I believed it could be done ...
anyway may be with VMWARE ??
leonel
On Sun, 2006-03-26 at 10:25, Maciej Żenczykowski wrote:
Anybody know if the Xen in FC5 run WinXP on a normal cpu without virtualization extensions?
I don't think that's possible, but the free VMware server from http://www.vmware.com would do it.
On Sun, 2006-03-26 at 09:44, Fajar Priyanto wrote:
I guess, I'll make a dual boot on the notebook between FC5 and Centos4.2 soon. Thanks, I'll research into the list archive. Luckily I've never deleted any list emails that I subscribe. :)
If the machine is fairly fast you might like VMware to run both concurrently. (http://www.vmware.com). They have free downloads for both a player version that can't create machines but will run a large selection of pre-build images that you can also download and a server version that can create virtual machines but is currently in beta.
On Sun, 2006-03-26 at 00:51, Fajar Priyanto wrote:
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".
Note that the Centos team and their upstream distribution have exactly the same attitude. That is, if it wasn't broken, there wouldn't be an update available.
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?
There is always a small change that something will go wrong when you change anything, but in this case the chance is very small because everything is well tested before making it into the Centos repositories - and you have to weigh that against the larger chance of things going wrong if you continue to run software with known problems. You may not want the machine to update automatically, but if not you should do manual updates frequently and generally take all of them when they are available.
-
Craig White -
Dennis Gilmore -
Fajar Priyanto -
Leonel Nunez -
Les Mikesell -
Maciej Żenczykowski -
William L. Maltby