Les Mikesell <lesmikesell@xxxxxxxxx> 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?
--
Bryan J. Smith | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
