Les Mikesell lesmikesell@gmail.com wrote:
But then it would have to change when I build/update a machine here and ship it or the disk to another location.
So what do you do about other site-specific system settings?
Actually I just prefer not to break all my machines at once...
That's why you test on one system _first_. I don't care if you're doing it automated or manually, there is absolutely _no_ difference!
It's really not that hard to paste an update command into several windows or ssh it to the next machine after the previous one is rebooted and back in the load balancer pools.
But it takes a lot less time (and is much safer) to: 1) Download updates to 1 system 2) Test that system 3) Pull the files from its APT/YUM cache 4) Redistribute them to all other systems
I actually didn't know about automated YUM tools to do #3/#4 until that previous thread a month or two back.
I either just leveraged my existing configuration management structure to distribute files from APT/YUM caches -- or more formally -- just maintained my own local APT/YUM mirrors, my own "enterprise release" tags on the package sets, etc...
So, are we going to _continue_ going round and round on this? I'm not saying what you're doing is "wrong." I'm just saying there _are_ other ways to deal with your problem, and they _are_ very efficient for most of us other administrators. ;->
I'm sure you know as well as anyone that you need to be working with fedora to know what to expect from the next version of Centos. And working with fedora is frustrating enough to make you try some other distos whenever you have time.
I'm just telling you what's in store in the future. I'm doing it so you can stop asking for things from CentOS on this list that _are_ being addressed by the upstream provider who _can_ do such!
Do you have to take everything and make it either an insult about a distro or a threat to use another? Honestly, I don't think we need more Linux users -- excuse me, administrators -- like yourself.
The only thing I'm guilty of is taking the time to explain extensive technical options people have -- to make things easier. You may like one way, but it's _not_ the only way -- and if there is another option, one that might save you time, I'm going to offer it. Especially when you're "bitching" for solutions that CentOS can_not_ give you. ;->
Then there's the k12ltsp and SMEserver variations on the Centos base.
Then setup 1 system, download the updates, and rip/distribute from their APT/YUM caches. I've been doing that for _years_ (with my own scripts) when the organization is small enough I don't have a local mirror setup.
And it gets ugly when you have lots of machines running an assortment of different distributions.
Again, pick 1 system per distro. Pick a user who doesn't mind "experimenting" if you don't have a spare system. They download the updates first. If they work and pass mustard, then use his/her APT or YUM cache to feed _all_ others. Done.|
Otherwise, how are you maintaining any management over these systems?
Just not quite ugly enough to make it worth reinstalling
Huh? Who said _anything_ about re-installing?!?!?! @-o
just to make it all the same (if that's even possible due to hardware and application differences) or holding back on new things.
Huh? You just lost me. Why would you re-install?