On 01/18/2012 08:05 AM, Sorin Srbu wrote:
I would like to expand on this a little. Once you get a certain number of machine it probably makes sense to have your own internal mirror.
Is there any particular approximate number of machines you'd say this would apply to?
based on personal experience, I'd say that number was at the '9' mark. Once you go double digit, and you have those many machines in one location, a local repo is the way to go. Perhaps then with one of them ( either a machine or a VM instance ) doing auto nightly updates, and running a test to make sure all is still well and sending out a small email to the admin with a OK or 'Trouble found in updates'
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Karanbir Singh Sent: den 18 januari 2012 11:15 To: CentOS mailing list Subject: Re: [CentOS] anyone doing automatic yum updates via yum-updatesd on production servers?
On 01/18/2012 08:05 AM, Sorin Srbu wrote:
I would like to expand on this a little. Once you get a certain number of machine it probably makes sense to have your own internal mirror.
Is there any particular approximate number of machines you'd say this would apply to?
based on personal experience, I'd say that number was at the '9' mark. Once you go double digit, and you have those many machines in one location, a local repo is the way to go. Perhaps then with one of them ( either a machine or a VM instance ) doing auto nightly updates, and running a test to make sure all is still well and sending out a small email to the admin with a OK or 'Trouble found in updates'
Thanks. Will be looking into local repos it seems.
We've expanded our local calculation farm to now include mid-teen numbers, and manual updates is becoming a PITA...
On Wed, Jan 18, 2012 at 4:15 AM, Karanbir Singh mail-lists@karan.org wrote:
On 01/18/2012 08:05 AM, Sorin Srbu wrote:
I would like to expand on this a little. Once you get a certain number of machine it probably makes sense to have your own internal mirror.
Is there any particular approximate number of machines you'd say this would apply to?
based on personal experience, I'd say that number was at the '9' mark. Once you go double digit, and you have those many machines in one location, a local repo is the way to go. Perhaps then with one of them ( either a machine or a VM instance ) doing auto nightly updates, and running a test to make sure all is still well and sending out a small email to the admin with a OK or 'Trouble found in updates'
I've always thought yum should have its own 'reproducible updates' concept so you could update a test machine, then tell all the others to update to exactly that state even if some new things had been added to the repositories - without having to make complete snapshots of repositories containing stuff you don't even have installed just to hold the state. That is, that should have been a design goal for yum since that is the way people should manage multiple machines - and yum does sort-of know how to do that if you specify every package version number. But it really should just need a timestamp of the latest thing in the repo at the time of the test/master update and ignore anything newer when you want it repeated.
--- Les Mikesell lesmikesell@gmail.com
On Wed, Jan 18, 2012 at 8:51 AM, Les Mikesell lesmikesell@gmail.com wrote:
I've always thought yum should have its own 'reproducible updates' concept so you could update a test machine, then tell all the others to update to exactly that state even if some new things had been added to the repositories -
Kind of hard to do if the older versions have been removed from the mirrors.
without having to make complete snapshots of repositories containing stuff you don't even have installed just to hold the state.
Your local mirror doesn't have to be a full copy. Granted, it is easier to manage if it is, and drive space is cheap.
That is, that should have been a design goal for yum since that is the way people should manage multiple machines
Yum's design goal was/is to be a dep-solver, not a management system.
On Wed, Jan 18, 2012 at 8:33 AM, William Hooper whooperhsd@gmail.com wrote:
On Wed, Jan 18, 2012 at 8:51 AM, Les Mikesell lesmikesell@gmail.com wrote:
I've always thought yum should have its own 'reproducible updates' concept so you could update a test machine, then tell all the others to update to exactly that state even if some new things had been added to the repositories -
Kind of hard to do if the older versions have been removed from the mirrors.
Failing is OK. There are all kinds of reasons an update might fail and you have to be able to handle that. Even if you had your own mirror it might be down or unreachable. What you shouldn't have to handle is installing some unexpected thing when you are just repeating a command. Besides, if something has been removed from the mirrors, it is a pretty good hint that there is a better use of your time today than pushing that package into production.
That is, that should have been a design goal for yum since that is the way people should manage multiple machines
Yum's design goal was/is to be a dep-solver, not a management system.
Yes, that's what I mean. It is too bad the distribution doesn't have a reasonable management system when it shouldn't be hard at all to get the same versions of the same packages on two different machines - and that is something almost everyone using an 'enterprise' distribution needs.
-
Karanbir Singh -
Les Mikesell -
Sorin Srbu -
William Hooper