SCIENTIFIC-LINUX-USERS Archives

March 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"~Stack~" <[log in to unmask]>
Reply To:
~Stack~
Date:
Wed, 19 Mar 2014 07:41:10 -0500
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (2136 bytes) , signature.asc (265 bytes)
On 03/18/2014 10:48 AM, Ken Teh wrote:
> I've had 2 successful upgrades from 6.4 to 6.5 with the sl6x.repo
> enabled.  In the past, I've never done upgrades, preferring to re-install.
> 
> I'd like to know what folks are doing with respect to enabling the
> sl6x.repo.  Is it "just enable it!, it's ready from primetime" or are
> you still disabling it, doing a test drive on a test machine before
> reenabling across all machines?

Greetings,

On my personal builds and on the very few desktop systems I manage, I
leave it alone. None of those are very critical and I haven't had a huge
problem. Plus it provides a nice testing ground for possible problems.

On my servers, I control the repo server. I rsync a local mirror from
upstream that the dev boxes all update from. When I am ready and after
the updates seem to all be working, then I rsync from that local mirror
to the production mirror and let all the boxes auto update from it. All
6.X links are just symlinks to 6 which is what I rsync into (leaving
sl6x out completely on production).

So when it was time to update 6.4, well 6.4 was a symlink to 6 which
just got a 6.5 rsync update and a new 6.5 symlink was created. All of
the boxes saw new updates and updated on their own. Except kernel
updates; I have had too many auto-upgrades fail on the kernel for me so
we still have a guy who schedules downtime for large chunks of machines
at a time and manually parallel update/reboots into the new kernel
fixing anything that goes wrong. We also don't upgrade the kernel unless
it is a security update.

If you have a few boxes, a local repo probably doesn't help and will
probably just be ~50-60GB of used space and bandwidth. However, when you
are managing multiple hundreds of boxes from Desktops to a variety of
different server types, the local repo saves a lot of time and
bandwidth. It also gives you the flexibility to allow your servers to
only see the packages you want them to see.

Also, if you aren't using something like puppet to manage your repo
files on that many boxes, I found it very nifty to set a local DNS CNAME
to redirect the default baseurl to my local server. :-)

Hope that helps.
~Stack~



ATOM RSS1 RSS2