Hello,
So I've watched a few threads about the new 5.0 vs. 5.1 upgrade and have a couple of (hopefully) practical questions about this:
Context - I'd like to stick to 5.0 at least for a while until the dust around 5.1 settles down (and I'm back from holidays). As an example - In Debian, as long as I stick to "stable" I can be sure that the only updates I receive there are for heavily tested very important bugs and security issues, so I should generally apply them.
1. If I read the FAQ correctly, in order to force yum to stay with 5.0 should I just manually edit /etc/redhat-release from:
CentOS release 5 (Final)
to:
CentOS release 5.0 (Final)
(i.e. add ".0" to the version)? If not then what should I do?
2. I am hoping that yum-security will allow me to stick to the latest security updates for 5.0 without forcing me to upgrade to 5.1 until the dust settles down. Am I correct that this is possible with yum-security and the repositories provided by CentOS? Will "yum update --security" update packages with later versions only if those versions fix security issues? Are security updates maintained for 5.0? Here is what I get right now on one of my systems (without doing the change I asked about in (1)):
# yum --security list updates Loading "security" plugin Loading "installonlyn" plugin Setting up repositories base 100% |=========================| 1.1 kB 00:00 updates 100% |=========================| 951 B 00:00 addons 100% |=========================| 951 B 00:00 extras 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files Limiting package lists to security relevant ones No packages needed, for security, 196 available
If I drop the "--security" flag I indeed get a list of196 packages to upgrade.
So to clarify my question - is my system secure (in terms of package versions) by sticking to "yum update --security"?
Thanks,
--Amos
Amos Shapira wrote:
Context - I'd like to stick to 5.0 at least for a while until the dust around 5.1 settles down (and I'm back from holidays).
ok, so what do you mean by sticking to 5.0 ? you mean you dont want any updates at all for those machines, even if they might be security issues ?
As an example - In Debian, as long as I stick to "stable" I can be sure that the only updates I receive there are for heavily tested very important bugs and security issues, so I should generally apply them.
CentOS does not follow the debian release model.
- If I read the FAQ correctly, in order to force yum to stay with 5.0
should I just manually edit /etc/redhat-release from:
CentOS release 5 (Final) to: CentOS release 5.0 (Final)
no, there is no such mention abut anything in the FAQ or anywhere else that I can find. What made you believe that changing stuff in that text file will change the repo's your machine is looking at ?
- I am hoping that yum-security will allow me to stick to the latest
security updates for 5.0 without forcing me to upgrade to 5.1 until
read the release notes about yum-security
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Karanbir Singh wrote:
Amos Shapira wrote:
- If I read the FAQ correctly, in order to force yum to stay with 5.0
should I just manually edit /etc/redhat-release from:
CentOS release 5 (Final) to: CentOS release 5.0 (Final)
no, there is no such mention abut anything in the FAQ or anywhere else that I can find. What made you believe that changing stuff in that text file will change the repo's your machine is looking at ?
Possibly this: http://wiki.centos.org/FAQ/CentOS5#q8
- -- David Goldsmith, SANS NOC SANS Institute (www.sans.org)
On 12/12/2007, David Goldsmith dgoldsmith@sans.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Karanbir Singh wrote:
Amos Shapira wrote:
- If I read the FAQ correctly, in order to force yum to stay with 5.0
should I just manually edit /etc/redhat-release from:
CentOS release 5 (Final) to: CentOS release 5.0 (Final)
no, there is no such mention abut anything in the FAQ or anywhere else that I can find. What made you believe that changing stuff in that text file will change the repo's your machine is looking at ?
Possibly this: http://wiki.centos.org/FAQ/CentOS5#q8
Yes, exactly - the text there explains how to find out on which branch you are, but not about how to tell CentOS on which branch you want to be.
Is there such a thing or is 5.0 abandoned as soon as 5.1 is out and I practically MUST upgrade to 5.1 to stay secure?
Thanks,
--Amos
Amos Shapira wrote:
Is there such a thing or is 5.0 abandoned as soon as 5.1 is out and I practically MUST upgrade to 5.1 to stay secure?
Basically: Yes.
5.1 is the *first* iso respin of CentOS 5 (5.0 being the first iso spin). This contains some feature updates. At the moment (and it has been like that for *all* CentOS releases this far) 5.1 is the *only* CentOS 5 which exists. CentOS 5.0 *does not* exist anymore. CentOS 5.0 does *NOT* get *ANY* updates.
Ralph
David Goldsmith wrote:
no, there is no such mention abut anything in the FAQ or anywhere else that I can find. What made you believe that changing stuff in that text file will change the repo's your machine is looking at ?
Possibly this: http://wiki.centos.org/FAQ/CentOS5#q8
I read it again, and I still dont see how you might infer that changing the string in redhat-release is going to change your repo interface.
Karanbir Singh wrote on Wed, 12 Dec 2007 13:19:17 +0000:
I read it again, and I still dont see how you might infer that changing the string in redhat-release is going to change your repo interface.
Well, you changed it ;-) Before the change I read it the way that if the release string would be "5.1 (final)" yum would not automatically update to 5.2, only within the 5.1 stream. As it seems there will now also be minor version releases?
Kai
Kai Schaetzl wrote:
Karanbir Singh wrote on Wed, 12 Dec 2007 13:19:17 +0000:
I read it again, and I still dont see how you might infer that changing the string in redhat-release is going to change your repo interface.
Well, you changed it ;-) Before the change I read it the way that if the release string would be "5.1 (final)" yum would not automatically update to 5.2, only within the 5.1 stream.
you can still read the version from before my change - and even there it clearly states that you need to change yum configs etc to make changes to the repos your system seems. There is no mention or indication to anything requiring a change in the redhat-release file.
As it seems there will now also be minor version releases?
I've just changed it a bit - mostly to signify that there is no such thing in 5.0.z - that will only start with 5.2 release.
Karanbir Singh wrote on Wed, 12 Dec 2007 14:03:10 +0000:
As you see from quite a few inquiries over the last days that parapgraph is *easily* misread. Don't take it personal ;-) Apart from those questions from people who didn't read it at all there a several questions about the content that all go in the same direction or simply don't understand it.
you can still read the version from before my change - and even there it clearly states that you need to change yum configs etc to make changes to the repos your system sees.
No, it says "manually telling yum to do so" which could just mean "edit that release file!" in this context. Beat me and others, but that's what we read in it.
There is no mention or indication to
anything requiring a change in the redhat-release file.
I just re-read the paragraph again carefully and I think it is the first sentence that creates the confusion. It says "for a period of time next to the latest version of the 5 series" one can wonder about a minute what this really means) and then at the end it says "and you will not move to a newer release without ...". This *seems* to indicate that if the release file contains "5.1" yum is going to provide updates for 5.1 and stop with updating when 5.2 comes out. And you would either have to set it to 5.2 or 5 to continue with updating. Especially that "newer release" seems to indicatethis. As I read it now what actually is going to happen is that upstream *branches* beginning with 5.1 to 5.1.1, 5.1.2 etc. and they will keep providing updates for 5.1.1, 5.1.2 and the "main" 5 stream until the main stream support cycle ends. But this won't be determined of the release file, it's only an indicator.
Kai
All of this is good feedback, lets take this on board and see how we can make that text clearer!
Kai Schaetzl wrote:
Karanbir Singh wrote on Wed, 12 Dec 2007 14:03:10 +0000:
As you see from quite a few inquiries over the last days that parapgraph is *easily* misread. Don't take it personal ;-) Apart from those questions from people who didn't read it at all there a several questions about the content that all go in the same direction or simply don't understand it.
you can still read the version from before my change - and even there it clearly states that you need to change yum configs etc to make changes to the repos your system sees.
No, it says "manually telling yum to do so" which could just mean "edit that release file!" in this context. Beat me and others, but that's what we read in it.
There is no mention or indication to
anything requiring a change in the redhat-release file.
I just re-read the paragraph again carefully and I think it is the first sentence that creates the confusion. It says "for a period of time next to the latest version of the 5 series" one can wonder about a minute what this really means) and then at the end it says "and you will not move to a newer release without ...". This *seems* to indicate that if the release file contains "5.1" yum is going to provide updates for 5.1 and stop with updating when 5.2 comes out. And you would either have to set it to 5.2 or 5 to continue with updating. Especially that "newer release" seems to indicatethis. As I read it now what actually is going to happen is that upstream *branches* beginning with 5.1 to 5.1.1, 5.1.2 etc. and they will keep providing updates for 5.1.1, 5.1.2 and the "main" 5 stream until the main stream support cycle ends. But this won't be determined of the release file, it's only an indicator.
thats mostly correct, except for the fact that there will be only 3 releases in any branch, so while /5/ will continue to be supported for the 7 years + that a EL version is, the 5.1 will only exist for 18 months, after which, your machine is looking at orphan repos ( or maybe redhat will workout some cleaver way of bringing the machine back upto /5/ - which would be quite drastic and mostly a bad idea , since the package change set from 5.1 to 5.4 ( which is what /5/ will be at the time ) - could be quite large.
Karanbir Singh wrote on Wed, 12 Dec 2007 15:41:49 +0000:
thats mostly correct, except for the fact that there will be only 3 releases in any branch, so while /5/ will continue to be supported for the 7 years + that a EL version is, the 5.1 will only exist for 18 months,
Yes, that is clear. But now I'm still not sure about the "point releases" (minor version no.s) and their life cycle. There will be 5.1.1, 5.1.2 and 5.1.3. no more? How long will their support cycle be? As long as 5? As long as 5.1?
"for a period of time next to the latest version of the 5 series"
I think I misunderstand this again (in my last reply). The "latest version of the 5 series" would be (for me) the latest version of the 5 series that ever comes out. So, basically, it means the end of the life cyle of 5 (7+ years). That's obviously not what it means. We should rather read it as "the latest version at this point in time" which would be "the current version at that time"? So, 5.1.1 branch will be supported as long as 5.1 is supported, then both go to 5.2?
Kai
Kai Schaetzl wrote:
I think I misunderstand this again (in my last reply). The "latest version of the 5 series" would be (for me) the latest version of the 5 series that ever comes out.
That is a (common) misinterpretation coming from our native language. What you mean would be the "last version of the 5 series". The latest means current (as in "the latest and greatest version of them all").
Cheers,
Ralph
Ralph Angenendt wrote on Wed, 12 Dec 2007 17:27:44 +0100:
That is a (common) misinterpretation coming from our native language. What you mean would be the "last version of the 5 series". The latest means current (as in "the latest and greatest version of them all").
Oh, well. I *do* know the difference, but it seems in this context I got it wrong. I'm not so sure, though, if "current" would have made a difference. I still think the use of "latest" and "point" (or "current") release is ambiguous, as these "values" shift over time. Wouldn't this be better (also note the second example at the end):
Starting from CentOS 5.1 the Upstream OS Provider will be providing updates for each minor version release (5.1.1,5.1.2 ...) for a period of time next to the corresponding major version release (5.1).
Kai
Kai Schaetzl wrote:
Karanbir Singh wrote on Wed, 12 Dec 2007 15:41:49 +0000:
thats mostly correct, except for the fact that there will be only 3 releases in any branch, so while /5/ will continue to be supported for the 7 years + that a EL version is, the 5.1 will only exist for 18 months,
Yes, that is clear. But now I'm still not sure about the "point releases" (minor version no.s) and their life cycle. There will be 5.1.1, 5.1.2 and 5.1.3. no more?
redhat will do 5.1.1 5.1.2 5.1.3 - we will do 5.1.z and just call it that. which is what makes it different from /5/
and yes 18 months = 3 6monthly updates, which is what upstream seem to be doing at the moment. so when you get to 5.1.3, its end of the road. So you can see why we dont really want people to default into that zone. and why redhat is actually asking people to pay more money to get into a branch.
How long will their support cycle be? As long as 5? As long as 5.1?
no. I already answered this question in my last email.
"for a period of time next to the latest version of the 5 series"
I think I misunderstand this again (in my last reply). The "latest version of the 5 series" would be (for me) the latest version of the 5 series that ever comes out. So, basically, it means the end of the life cyle of 5 (7+ years). That's obviously not what it means. We should rather read it as "the latest version at this point in time" which would be "the current version at that time"? So, 5.1.1 branch will be supported as long as 5.1 is supported, then both go to 5.2?
you are confusing yourself beyond what is required. So let me restate this again.
There is 1 Distro - its called CentOS-5, and its what most people run.
Every 6 odd months, the ISOS are rebuilt to include all updates released in the last 6 months and also some bugfix's. These new ISOS are called 5.x ( so 5.1 and 5.2 etc ). So that people know what ISO set they have downloaded and installed. Its no - as some people seem to be confused about - a new Distro or a completely new release.
What Redhat is now also going to offer in about 6 months time, is the ability for people to just stay within one branch of the release ( so, people who installed 5.1 might want to stay within the 5.1 package set and not get any enhancements, or bugfix's or package updates - they just get a very small subset of security fixs ). And to do that you would need to put your machine into a Branch, which will be called 5.x.<something>. ( eg. for the entire life of 5.1.* your redhat-release file on centos is going to say : CentOS release 5.1.z (Branch) )
If you still dont get it, dont worry - just sit back for 6 months. The situation will hopefully clear itself out in that time. There is nothing that needs to be done now, and there is no 5.0.* Branch.
What Redhat is now also going to offer in about 6 months time, is the ability for people to just stay within one branch of the release ( so, people who installed 5.1 might want to stay within the 5.1 package set and not get any enhancements, or bugfix's or package updates - they just get a very small subset of security fixs ). And to do that you would need to put your machine into a Branch, which will be called 5.x.<something>. ( eg. for the entire life of 5.1.* your redhat-release file on centos is going to say : CentOS release 5.1.z (Branch) )
If you still dont get it, dont worry - just sit back for 6 months. The situation will hopefully clear itself out in that time. There is nothing that needs to be done now, and there is no 5.0.* Branch.
I don't see a great benefit for more than a very small subset of users with this. Most people shouldn't even worry about it. If you need this option, you probably are already paying a support contract, and your feedback probably got the ball rolling in the first place.
Karanbir Singh wrote on Wed, 12 Dec 2007 16:32:33 +0000:
redhat will do 5.1.1 5.1.2 5.1.3 - we will do 5.1.z and just call it that.
Oh, that's not clear from the FAQ as well. I though "z" just stands as a variable to be replaced by 1, 2 or 3. Using "z" implies that the lifetime of each single minor version update is *not* 18 months? I mean:
5.1 - 18 months 5.1.1 - 6 months 5.1.2 - another 6 months 5.1.3 - another 6 months 5.2 - next update release cycle
the FAQ seems to imply: 5.1 - 18 months 5.1.1 - 18 months 5.1.2 - 18 months 5.1.3 - 18 months 5.2 - next update release cycle
which one is correct? Using "z" implies to me no differentiation between 5.1.1 etc, so how would you be able to determine at which release point you are if you want to maintain 18 months for each minor branch?
you are confusing yourself beyond what is required. So let me restate this again.
That's possible. What do you think about my proposed new formulation in my reply to Ralph from today?
Kai
Kai Schaetzl wrote:
5.1 - 18 months 5.1.1 - 6 months 5.1.2 - another 6 months 5.1.3 - another 6 months 5.2 - next update release cycle
That is not correct
the FAQ seems to imply: 5.1 - 18 months 5.1.1 - 18 months 5.1.2 - 18 months 5.1.3 - 18 months 5.2 - next update release cycle
that is a little more correct, however still wrong.
here is how its going to work.
CentOS-5 Update via 5.1 ( just released )
-- 6 months or so --
CentOS-5 update via 5.2
And a CentOS-5.1 security only update via 5.1.1 ( this will have no bugfix's or feature addons or enhancements, and there will most likely be no new ISOS either, were not sure yet. )
-- 6 months or so --
CentOS-5 update via 5.3
And a CentOS-5.1 security only bump via 5.1.2 And a CentOS-5.2 security only bump via 5.2.1
-- 6 months or so --
CentOS-5 update via 5.4
And a CentOS-5.1 security only bump via 5.1.3 And a CentOS-5.2 security only bump via 5.2.2 And a CentOS-5.3 security only bump via 5.3.1
-- 6 months or so --
CentOS-5 update via 5.5
And a CentOS-5.2 security only bump via 5.2.3 And a CentOS-5.3 security only bump via 5.3.2 And a CentOS-5.4 security only bump via 5.4.1
( as you can see redhat expects everyone with 5.1 Branched machines at that time to just either fall off the face of the earth or reinstall their machines since the delta between them and the real CentOS-5 will be so large that an update might actually be the same as a reinstall )
So, as you can see - we only imagine a very small minority of people actually sticking onto a branch release, while everyone just stays with CentOS-5
Also, considering we have gone through all this to try get the situation clear for you, I hope you are going to now create a wiki page that details the situation and explains it in a way that someone who had no idea about it - like you did 2 days back, is able to read it and make sense out of it!
on 12/13/2007 8:03 AM Karanbir Singh spake the following:
Kai Schaetzl wrote:
5.1 - 18 months 5.1.1 - 6 months 5.1.2 - another 6 months 5.1.3 - another 6 months 5.2 - next update release cycle
That is not correct
the FAQ seems to imply: 5.1 - 18 months 5.1.1 - 18 months 5.1.2 - 18 months 5.1.3 - 18 months 5.2 - next update release cycle
that is a little more correct, however still wrong.
here is how its going to work.
CentOS-5 Update via 5.1 ( just released )
-- 6 months or so --
CentOS-5 update via 5.2
And a CentOS-5.1 security only update via 5.1.1 ( this will have no bugfix's or feature addons or enhancements, and there will most likely be no new ISOS either, were not sure yet. )
-- 6 months or so --
CentOS-5 update via 5.3
And a CentOS-5.1 security only bump via 5.1.2 And a CentOS-5.2 security only bump via 5.2.1
-- 6 months or so --
CentOS-5 update via 5.4
And a CentOS-5.1 security only bump via 5.1.3 And a CentOS-5.2 security only bump via 5.2.2 And a CentOS-5.3 security only bump via 5.3.1
-- 6 months or so --
CentOS-5 update via 5.5
And a CentOS-5.2 security only bump via 5.2.3 And a CentOS-5.3 security only bump via 5.3.2 And a CentOS-5.4 security only bump via 5.4.1
( as you can see redhat expects everyone with 5.1 Branched machines at that time to just either fall off the face of the earth or reinstall their machines since the delta between them and the real CentOS-5 will be so large that an update might actually be the same as a reinstall )
So, as you can see - we only imagine a very small minority of people actually sticking onto a branch release, while everyone just stays with CentOS-5
Also, considering we have gone through all this to try get the situation clear for you, I hope you are going to now create a wiki page that details the situation and explains it in a way that someone who had no idea about it - like you did 2 days back, is able to read it and make sense out of it!
If you wanted to re-install every 12 to 18 months, you might as well use Fedora! This just seems to go "bass ackwards" to what an enterprise distro means. I guess RedHat is just trying to play to a bigger audience to maybe boost their revenue stream a bit, which I don't fault them for, because a business needs to be in the black to stay open.
Scott Silva wrote:
If you wanted to re-install every 12 to 18 months, you might as well use Fedora! This just seems to go "bass ackwards" to what an enterprise distro means. I guess RedHat is just trying to play to a bigger audience to maybe boost their revenue stream a bit, which I don't fault them for, because a business needs to be in the black to stay open.
you would only get onto that situation of reinstall or major upgrade every 18 months or so, if you kept getting into the release branches. Which, honestly, I dont imagine most people will want to do. If you stay with CentOS-5, you are fine for the normal 7 to 11 years support cycle. Which is how CentOS always worked as.
yes, the situation is somewhat confusing, however, thats only for the people who want to break their distro or do their own branching. For everyone else, its business as usual.
Karanbir Singh wrote on Thu, 13 Dec 2007 16:03:56 +0000:
Also, considering we have gone through all this to try get the situation clear for you, I hope you are going to now create a wiki page that details the situation and explains it in a way that someone who had no idea about it
I don't have a wiki account. Your posting is a perfect explanation. Wouldn't it make sense to just add a link to it? I looked it up: http://lists.centos.org/pipermail/centos/2007-December/091189.html
Kai
Kai Schaetzl wrote:
I don't have a wiki account.
it takes a few seconds to get one.
Your posting is a perfect explanation. Wouldn't it make sense to just add a link to it? I looked it up: http://lists.centos.org/pipermail/centos/2007-December/091189.html
Rather than having split bits of info all over the place, the whole aim of the wiki is to try and consolidate info into one place so people dont need to repeatedly ask the same thing.
On 12/12/2007, Karanbir Singh mail-lists@karan.org wrote:
Amos Shapira wrote:
Context - I'd like to stick to 5.0 at least for a while until the dust around 5.1 settles down (and I'm back from holidays).
ok, so what do you mean by sticking to 5.0 ? you mean you dont want any updates at all for those machines, even if they might be security issues ?
(I also replied to David's message)
No. I'm trying to understand where does 5.0 stand now that 5.1 is out - should I abandon 5.0 and upgrade to 5.1 if I want to stick to secure, stable releases or is 5.0 going to be maintained in parallel to 5.0 for security issues?
From your response so far I suspect that it's the former (must upgrade to 5.1).
As an example - In Debian, as long as I stick to "stable" I can be sure that the only updates I receive there are for heavily tested very important bugs and security issues, so I should generally apply them.
CentOS does not follow the debian release model.
This idea is beginning to sink in :^).
I just though that RHEL/CentOS is all about providing rock-solid, tested stable releases but there are some noises on the net that the new release might be giving early adopters some rough time.
- If I read the FAQ correctly, in order to force yum to stay with 5.0
should I just manually edit /etc/redhat-release from:
CentOS release 5 (Final) to: CentOS release 5.0 (Final)
no, there is no such mention abut anything in the FAQ or anywhere else that I can find. What made you believe that changing stuff in that text file will change the repo's your machine is looking at ?
It doesn't explicitly say so but as David pointed out, http://wiki.centos.org/FAQ/CentOS5#q8 talks about the content of this file as a way to know where the system thinks it belongs to now.
I now noticed the last sentence saying "you are in the update release stream for the 5.1 series and you will not move to a newer release without making changes to the yum config.". What kind of changes does this refer to? Overriding the $releasever in the repository URL's to hard-coded "5.0" or what?
Thanks,
--Amos
Amos Shapira wrote:
On 12/12/2007, Karanbir Singh mail-lists@karan.org wrote:
Amos Shapira wrote:
Context - I'd like to stick to 5.0 at least for a while until the dust around 5.1 settles down (and I'm back from holidays).
ok, so what do you mean by sticking to 5.0 ? you mean you dont want any updates at all for those machines, even if they might be security issues ?
(I also replied to David's message)
No. I'm trying to understand where does 5.0 stand now that 5.1 is out
- should I abandon 5.0 and upgrade to 5.1 if I want to stick to
secure, stable releases or is 5.0 going to be maintained in parallel to 5.0 for security issues?
From your response so far I suspect that it's the former (must upgrade to 5.1).
As an example - In Debian, as long as I stick to "stable" I can be sure that the only updates I receive there are for heavily tested very important bugs and security issues, so I should generally apply them.
CentOS does not follow the debian release model.
This idea is beginning to sink in :^).
I just though that RHEL/CentOS is all about providing rock-solid, tested stable releases but there are some noises on the net that the new release might be giving early adopters some rough time.
- If I read the FAQ correctly, in order to force yum to stay with 5.0
should I just manually edit /etc/redhat-release from:
CentOS release 5 (Final) to: CentOS release 5.0 (Final)
no, there is no such mention abut anything in the FAQ or anywhere else that I can find. What made you believe that changing stuff in that text file will change the repo's your machine is looking at ?
It doesn't explicitly say so but as David pointed out, http://wiki.centos.org/FAQ/CentOS5#q8 talks about the content of this file as a way to know where the system thinks it belongs to now.
I now noticed the last sentence saying "you are in the update release stream for the 5.1 series and you will not move to a newer release without making changes to the yum config.". What kind of changes does this refer to? Overriding the $releasever in the repository URL's to hard-coded "5.0" or what?
Thanks,
--Amos _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi Amos
My understanding is that unless you choose not to update your system at all you can not freeze on a point release. So install from any 5.* media and when you update you will go to the latest point release.
What I would suggest if you are really worried about this is to configure /etc/yum.conf with a keepcache higher than 1 so that if an update is done you can roll back the rpm
I hope this helps
On 12/12/2007, Clint Dilks clintd@scms.waikato.ac.nz wrote:
Hi Amos
My understanding is that unless you choose not to update your system at all you can not freeze on a point release. So install from any 5.* media and when you update you will go to the latest point release.
What I would suggest if you are really worried about this is to configure /etc/yum.conf with a keepcache higher than 1 so that if an update is done you can roll back the rpm
I hope this helps
Hi Clint,
Thanks for your reply. That answers my question.
I'll just try to avoid updates for now.
Cheers,
--Amos
Amos Shapira wrote:
I'll just try to avoid updates for now.
Why? It is *highly* unlikely that 5.1 will break *anything* for you. I mean: Those are still the *SAME* software versions as in 5.0. And those are the same software versions which will be in CentOS 5.5. Or 5.7.
You will *NOT* get any security updates that way, you are leaving your machines vulnerable - and that for *NO* reason.
Ralph
On 13/12/2007, Ralph Angenendt ra+centos@br-online.de wrote:
Amos Shapira wrote:
I'll just try to avoid updates for now.
Why? It is *highly* unlikely that 5.1 will break *anything* for you. I mean: Those are still the *SAME* software versions as in 5.0. And those are the same software versions which will be in CentOS 5.5. Or 5.7.
You will *NOT* get any security updates that way, you are leaving your machines vulnerable - and that for *NO* reason.
I just got the impression from the subject in the mailing list for the last couple of weeks that 5.1 introduced some problems to people who upgraded. Going through the archive today I see that it looks like all problems resulted from people deviating from the recommended path (just "yum update") by having their own kernels or mixing 5.1 with packages from other sources.
Thanks.
--Amos
Amos Shapira wrote:
On 13/12/2007, Ralph Angenendt ra+centos@br-online.de wrote:
Amos Shapira wrote:
I'll just try to avoid updates for now.
Why? It is *highly* unlikely that 5.1 will break *anything* for you. I mean: Those are still the *SAME* software versions as in 5.0. And those are the same software versions which will be in CentOS 5.5. Or 5.7.
You will *NOT* get any security updates that way, you are leaving your machines vulnerable - and that for *NO* reason.
I just got the impression from the subject in the mailing list for the last couple of weeks that 5.1 introduced some problems to people who upgraded. Going through the archive today I see that it looks like all problems resulted from people deviating from the recommended path (just "yum update") by having their own kernels or mixing 5.1 with packages from other sources.
Thanks.
--Amos
Amos,
Sure there are a couple of problems with the updates. We have had more that 2 million machines get updates in the last month.
There are a handful of problems reported ... what, 10-15 accounts of something going wrong on the list.
The vast majority of problems are usually caused by yum .repo file configuration problems or some other instance of non supported (ie, non centos software installed) problems.
There was a major nfs/autofs issue that is now corrected ... and I am sure there are a couple other problems, but > 99.9% of the upgrades went perfectly.
So, not upgrading is probably not warranted.
Thanks, Johnny Hughes
Amos Shapira wrote:
On 12/12/2007, Karanbir Singh mail-lists@karan.org wrote:
Amos Shapira wrote:
Context - I'd like to stick to 5.0 at least for a while until the dust around 5.1 settles down (and I'm back from holidays).
ok, so what do you mean by sticking to 5.0 ? you mean you dont want any updates at all for those machines, even if they might be security issues ?
(I also replied to David's message)
No. I'm trying to understand where does 5.0 stand now that 5.1 is out
- should I abandon 5.0 and upgrade to 5.1 if I want to stick to
secure, stable releases or is 5.0 going to be maintained in parallel to 5.0 for security issues?
I think your confusion comes from the fact that you consider 5.1 to be a new release, and not what it really is : 5.0 + updates + some bug fix's.
I suggest you read up on how the whole EL codebase moves.
I now noticed the last sentence saying "you are in the update release stream for the 5.1 series and you will not move to a newer release without making changes to the yum config.". What kind of changes does this refer to? Overriding the $releasever in the repository URL's to hard-coded "5.0" or what?
no, when branches are created - they will involve you installing a new centos-release rpm.
Amos Shapira wrote:
Hello,
So I've watched a few threads about the new 5.0 vs. 5.1 upgrade and have a couple of (hopefully) practical questions about this:
Context - I'd like to stick to 5.0 at least for a while until the dust around 5.1 settles down (and I'm back from holidays). As an example - In Debian, as long as I stick to "stable" I can be sure that the only updates I receive there are for heavily tested very important bugs and security issues, so I should generally apply them.
- If I read the FAQ correctly, in order to force yum to stay with 5.0
should I just manually edit /etc/redhat-release from:
CentOS release 5 (Final)
to:
CentOS release 5.0 (Final)
(i.e. add ".0" to the version)? If not then what should I do?
- I am hoping that yum-security will allow me to stick to the latest
security updates for 5.0 without forcing me to upgrade to 5.1 until the dust settles down. Am I correct that this is possible with yum-security and the repositories provided by CentOS? Will "yum update --security" update packages with later versions only if those versions fix security issues? Are security updates maintained for 5.0? Here is what I get right now on one of my systems (without doing the change I asked about in (1)):
# yum --security list updates Loading "security" plugin Loading "installonlyn" plugin Setting up repositories base 100% |=========================| 1.1 kB 00:00 updates 100% |=========================| 951 B 00:00 addons 100% |=========================| 951 B 00:00 extras 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files Limiting package lists to security relevant ones No packages needed, for security, 196 available
If I drop the "--security" flag I indeed get a list of196 packages to upgrade.
So to clarify my question - is my system secure (in terms of package versions) by sticking to "yum update --security"?
Thanks,
--Amos
I would also like to address this whole subtree (or z series) issue.
First ... The upstream guys have not offered this service yet. When they do, it will offer a subset of updates for some people who really want to have only a very small subset of updates for their equipment for 18 months.
It is explained fully (at least as it has been explained to us) in this post to the list:
http://lists.centos.org/pipermail/centos/2007-December/091189.html
Second ... Since this is not really implemented (in practice) by upstream, it is currently vaporware. When they implement it, then we can see in practice what they actually do and emulate it.
Third ... What happens to the 5.1.3 people (automatically) at the "5.1.3 EOL / 5.5" point is the one major issue that I see as problematic. I would guess that they would move up to the 5.2.3 tree ... then on the 5.6 release (5.2.3 EOL), they would have to move up to the 5.3.3 tree ... then on 5.7 (5.3.3 EOL) to the 5.4.3 tree, etc. What to do to those people automatically is critical, and we will have to see what upstream does to make our decision.
If upstream stays as conservative as they currently are between point releases (ie, 5.0 to 5.1, 5.1 to 5.2), moving from 5.1.3 to either 5.2.3 OR 5.5.0 should be equally possible. However, I have heard tell of things between point release sets MAYBE becoming a bit less conservative between the 5.1 and 5.2 branches after they get the z series stuff implemented. If that is the case, then moving between branches MAY become a little bit harder.
HOWEVER, until the vaporware becomes reality and until we can actually see what the version schemes REALLY DO (and if the changese between branches become less conservative), this whole thread is just speculative conjecture. Let's see the programs in action and see what happens at 5.1.3 EOL time, etc.
In the mean time, people who want security updates need to do what they RHEL people did ... update. There is no channel for the upstream people to do only security updates right now, they run yum and they get all the latest updates ... the same thing happens in CentOS.
Also ... the "yum --security" feature would only tell you CVE and other security information about a package. It does not actually perform security only updates, it just provide security information if a package is a security update. As posted in other places in this thread and the 5.1 release notes, the CentOS version of yum does not have this feature.
Thanks, Johnny Hughes
-
Amos Shapira -
Clint Dilks -
David Goldsmith -
Johnny Hughes -
Kai Schaetzl -
Karanbir Singh -
Ralph Angenendt -
Scott Silva