Hi. At the moment it seems my machines just update to the latest current release . I install a 6.0 machine and run yum update , and next thing its 6.2 .
I have a requirement where I need machines to only upgrade to even numbered sub releases eg: 6.0 , 6.2, 6.4 and only on my approval. But will allow updates within a given release.
How can I achieve this ?
If I sync the repositories for eg: 6.0 , 6.2, 6.4 separately in Spacewalk and only allow access to the ones I want to give access to, would that work ?
Thanks
G
On Thursday 10 May 2012 17.36.07 Gregory Machin wrote:
There is no provided functionality to do this, that is, CentOS doesn't differentiate between what you call updates and upgrades.
How can I achieve this ?
Normally (default yum config) a machine fetches it's packages from URL.../6/.. You can change this 6 to 6.x. That will prevent you from getting updates belonging to 6.x+1 _but_ will have the negative side-effect of stopping to work when 6.x+1 is released (6.x removed from normal mirrors).
Keeping you own repo (rsynced without --delete) may be the best idea (but requires more work).
/Peter
On 05/10/2012 01:46 AM, Peter Kjellström wrote:
I want to point out that neither does Red Hat.
If you are on the RHEL 6 channel and if you run an update after you install RHEL 6.0, you will be at RHEL 6.2.
6.0, 6.1, and 6.2 are really only point in time freezes of installation media. They are not separate entities or versions. It is like Windows and service packs. Windows 7 Service Pack 1 and Windows 7 Service Pack 2 are both Windows 7. Not many people want to freeze Windows 7 on Service Pack 1 ... and Microsoft does not provide the ability for you to freeze at that point. Nor does Red Hat provide the ability to freeze at 6.1 or 6.0.
As I said, minor releases are about install media, not the distro. The Distribution is CentOS-6 it is not CentOS-6.1 or CentOS-6.2.
If you stay on 6.0 then you do not get security updates. 6.0 + updates = 6.x (whatever that is at the time).
If you want to test the updates before you deploy them (not an unwise thing to do), then you need to maintain separate repositories where you dump tested RPMs in and update your machines from that.
The bottom line is, CentOS supports only CentOS-6 (or CentOS-5) ... if you want something different than that, you need to build your own repositories out of our packages.
On 05/10/2012 04:49 AM, Peter Kjellström wrote:
Sure, and people can and should test things before deployment.
But what I said is true ... there is no real mechanism to do this in Red Hat either, other than to buy a RHN satellite server (or create your own RHEL yum repos) and populate those separately with tested RPMS yourself. If you run updates when subscribed to RHN, it works just like running updates in CentOS ... you get all or nothing unless you take actions manually to prevent it.
There are several solutions to be able to make that happen ... manual repos yourself, mrepo, spacewalk, etc.
On Thu, May 10, 2012 at 4:58 AM, Johnny Hughes johnny@centos.org wrote:
There are several solutions to be able to make that happen ... manual repos yourself, mrepo, spacewalk, etc.
All of those that I've investigated make you manage copies of packages locally which seems like overkill when you aren't changing them locally. Is there any solution that simply lets you tell yum not to install any updates newer than the latest one you've tested? Or more cumbersome but still less so than maintaining repos - a way to have yum duplicate the package/versions that are on your test machines across a set of others?
On Thu, May 10, 2012 at 8:02 AM, Johnny Hughes johnny@centos.org wrote:
Yes, I'd just prefer that since yum runs on my machine that it had been designed to manage the software on my machine instead of acting as an agent for the remote repository or its managers.
But, since yum is generally able to install specified versions as long as they still exist in the repository and it doesn't have to go backwards, I'd think such a thing would be possible by managing package lists instead of the packages.
On 05/10/2012 09:40 AM, Les Mikesell wrote:
You have the misconception that those are your machines?
All your base are belong to us !!!!!!!!!!!!!!!!!!!!
For all you conspiracy nuts ... that is a joke. For reference:
On Fri, May 11, 2012 at 2:40 AM, Les Mikesell lesmikesell@gmail.com wrote:
Hi.
This has been interesting reading.
Since I have to used spacewalk to do reporting on updates and patches, and for automated installs I will use it to mirror the repositories and control the releases.
Thanks for clarifying the RHEL/CentOS release process.
On 5/10/2012 6:52 AM, Les Mikesell wrote:
It seems to me that if you want this "stop on 6.x" feature, it's because you certainly[*] have more than 1 box to manage, which means keeping a local repo with local copies of the RPMs will result in faster updates, with less impact on your Internet link.
So it's a feature.
[*] If you have only 1 box to manage, there can be no need for this, unless you have some third party telling you which 6.x snapshot is blessed. Otherwise, you're testing that 1 box, and after testing, you're updated, so there is no need for a blessed repository.
On Fri, May 11, 2012 at 9:25 AM, Warren Young warren@etr-usa.com wrote:
No, its not what I what. I have multiple boxes but in different locations, all of which have good internet connectivity - better than to each other.. And the people who can verify the application level tests are not the same ones who would be managing a local repo copy so it would be much more cumbersome to mirror a repo to the same rev at all locations to freeze the contents, update a test box from it, have the testing performed, then update the production boxes from those frozen repos - and probably duplicating all that infrastructure for every application since different testing would be involved and the timing overlap would not be predictable.
So far I've been fortunate that breakage from updates is very rare, so I've gotten by by just watching the list of updates that yum intends to perform for changes likely to affect anything between the tested version and the production rollout, but I'd really prefer it if yum had a way to do repeatable operations even if there are additions to the repos.
Like Johnny said - he (and upstream) is in control of what yum will do - and realistically there has been more QA/testing on the code than any individual is likely to match so the possibility of breakage comes down to very specific things about your applications or hardware. Still, there is the suggestion that very controlled testing would be a good thing - but it would be even better if the tools supported it without having to roll out a vast amount of new infrastructure and administration. It seems really crazy to have to mirror an entire repository in every state that you might want to re-use just to be able to pick up updates to a minimally-installed system predictably. If you've included a few programs from EPEL (etc.), do you mirror that too?
On 5/11/2012 9:07 AM, Les Mikesell wrote:
So put the repo server out in the cloud somewhere. Put it on a public-facing box the others all have access to, or rent a VPS somewhere, or grab some EC2 space, or...
If you've included a few programs from EPEL (etc.), do you mirror that too?
Who mentioned mirroring?
A local repo is just a copy of a set of packages that does what you want. It doesn't necessarily have to have everything available in all repos you pull from.
If you think you want the freedom to install random things in an ad hoc fashion, that kind of goes against the idea of a tested repo.
On Fri, May 11, 2012 at 11:49 AM, Warren Young warren@etr-usa.com wrote:
None of the suggested approaches are impossible. They just seem like a lot very unnecessary work to maintain some installations of a distribution whose main feature is that updates are supposed to not break things.
How else can you be sure you have all packages needed for some arbitrary mix of installations?
So the same person has to do the installs of of the all the machines? Or coordinate with a group? That seems somewhat unreasonable.
If you think you want the freedom to install random things in an ad hoc fashion, that kind of goes against the idea of a tested repo.
I don't want my own tested repos containing the same packages that are available in the distribution. I want to be able to tell yum to reproduce the package list/versions that are on the tested system. It knows where to get them. Isn't it overkill to keep a whole repo snapshot copy when you really just need a way to tell yum the package versions you want on the 2nd box? If packages were routinely deleted from the public repos, cloning them to make sure you could get a copy of an older version in the future might make sense, but I don't think that has ever been an issue.
And even simpler than tracking the full package/version list would be a way to tell yum to pretend that any packages in the repo newer than the update on the test box were not there. But, I don't think that meshes with the way repo metadata normally works - it probably would have trouble finding versions newer than installed but not the very latest even though it is trivial to see them in a directory listing yourself.
Can this plugin help?
https://docs.fedoraproject.org/en-US/Fedora/14/html/Software_Management_Guid...
Mihai
On 5/11/2012 11:34 AM, Les Mikesell wrote:
If your trusted repo doesn't have all the packages needed, the system you tested on does not match the installed systems, hence you have no good test.
If you have multiple system configurations, you need to test once on each system configuration. At that point, you will have all the packages you need to upgrade their peers.
You might need one repo per system configuration, if the difference between them is great enough. But the number of such repos needed cannot be large, else you cannot be testing properly. For this whole scheme to work, you have to be able to one test machine for each stable machine, and say, "These two boxes have the same RPM set."
No.
There is no more coupling here than between you and Red Hat. The private repo is a decoupling mechanism. The person updating the private repository does not have to be the one who uses it.
Why all the agida? This isn't difficult:
Step 0, done only once: set up yum repo, and modify the "stable" clients to use it:
http://fedoranews.org/contributors/tony_smith/yum/
Leave the test machines pointing at the official yum repos. But, enable the "keepcache" setting in their yum.conf.
Step 1: When each test machine is deemed stable after a yum update, rsync its /var/cache/yum/updates/packages tree into the yum repo.
Step 2: yum-arch the updated repo
Step 3: yum update the dependent machines.
You can substitute cron discipline for Step 3, so that the yum updates always happen while the repo isn't being changed.
That's it. Some minor setup, then three (or two) easy steps per update.
On Fri, May 11, 2012 at 5:48 PM, Warren Young warren@etr-usa.com wrote:
What is the point of even having revision numbers on packages in the public repositories if I can't trust that installing that package on another system will be that same and instead have to maintain my own snapshot copy to be sure I can reproduce it.
Step 0, done only once: set up yum repo, and modify the "stable" clients to use it:
Repeat for _every_ different system in every state you might want to be able to reproduce...
I just don't understand why such cumbersome multi-step processes and local storage facilities are needed. Why aren't the tools that people need shipped to work as-is?
On 05/09/12 10:36 PM, Gregory Machin wrote:
I have a requirement where I need machines to only upgrade to even numbered sub releases eg: 6.0 , 6.2, 6.4 and only on my approval.
thats a rather strange requirement. 6.1 is 6.0 with updates rolled up.
a more sane requirement would be to only allow pre-tested updates, which you'd do by testing the updates on a staging machine, then posting them to your own internal yum repository which your production machines would update from.
On 05/10/2012 08:55 AM, John R Pierce wrote:
This requirement sounds suspiciously like it was made for software that uses the "even numer = stable release, odd number = development release" versioning method. Since that doesn't apply here the requirement doesn't make sense.
Regards, Dennis
The even number is merely selected as a reference point, nothing to do with stable or unstable .
I'm aiming to create a controlled environment where there is less that users can do to break their systems ...
On Fri, May 11, 2012 at 12:49 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
On May 10, 2012, at 1:36, Gregory Machin wrote:
Others have debated the usefulness of this requirement, so I won't address this here.
How can I achieve this ?
You can easily achieve this by keeping a local mirror of the CentOS repository. I have a cron job every night that does something like this (I update the version manually whenever there is a new CentOS point release):
rsync --archive --delete --partial --stats --verbose \ --exclude="alpha" --exclude="ia64" --exclude="ppc" --exclude="s390*" \ $CENTOSRSYNCREPO/6.2 /local/www/html/CentOS
I also have a symlink from (in the current case) 6 to 6.2:
ls -l /local/www/html/CentOS/ lrwxrwxrwx 1 root root 3 Dec 23 09:17 6 -> 6.2 drwxrwxr-x 10 342 342 4096 Dec 21 06:37 6.2
Finally, I modify the yum repo config files to point to my mirror (this is just a small snippet from /etc/yum.repos.d/CentOS-Base.repo):
[base] name=CentOS-$releasever - Base #mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ baseurl=http://centosmirror.XXX.com/CentOS/$releasever/os/$basearch/
So all my servers and desktops update from my local mirror and I control when I move the symlink to point to the next release. You can achieve what you want in this way as well.
Alfred
On 05/10/2012 12:36 AM, Gregory Machin wrote:
It sounds like you would be happier with the Scientific Linux update paradigm. There by default you stay at a particular point release receiving only later security updates (along with any needed dependencies) until you manually run yum with "releasever=" specifying the point release to which you wish to upgrade. You can still get the RHEL/CentOS automatic upgrade paradigm by editing the .repo files and replacing "$releasever" with "6x" (that's a literal "x"), but that's not how it works by default.
-
Alfred von Campe -
Chris Geldenhuis -
Dennis Jacobfeuerborn -
Gregory Machin -
John R Pierce -
Johnny Hughes -
Les Mikesell -
Mihai T. Lazarescu -
Peter Kjellström -
Robert Nichols -
Warren Young