[lug] best practices yum updates centos server

Kevin Fenzi kevin at scrye.com
Thu Feb 22 22:56:09 MST 2007


On Thu, 22 Feb 2007 11:44:32 -0800 (PST)
horlenkarl at yahoo.com (karl horlen) wrote:

> I just installed a centos web server that I'd like to
> be a production 24x7 live server.

Sounds like a reasonable idea. ;) 
> 
> I like the idea of using yum to keep the system up to
> date with the latest security packages and generally
> latest packages period.

Thats a good idea. 

> My concern is that if I let yum automate this for me,
> it will install a package that's going to break my
> system.  Since the yum update will be automated, I
> might not know about a break until / if I manually
> check it to make sure everything is ok.

You can monitor the security announce mailing lists and apply updates
as you see them and do testing after you apply them?

> I'm wondering how others handle this.
>
> RELIABILITY EXPERIENCE 
> 
> Based upon first hand experience with yum/centos:
> 
> a) how rock-solid are the package updates? are the
> repo pkgs guaranteed to install cleanly assuming you
> haven't manually installed conflicting packages
> outside of the repository suite?  

Pretty solid. There are occasionally problems, but usually minor and
corrected quickly. 

> b) how often have you experienced a bad package update
> and when it happens, was it very easy to determine
> that there was a problem and fix it?  what I mean is
> that some pkgs just won't install if there's a problem
> and notify you of it.  on the otherhand, other pkgs
> either don't notify you of an install problem or
> install cleanly but then you have a problem with a
> config file or some other dependency which is harder
> to track down?

CentOS/RHEL is pretty good about that. RedHat does quite a bit of
testing and qa before releasing a update. Also, backports are done
instead of software version upgrades... so the chances of something
like a config file change happening are very low. 

> I know question 1 is somewhat open-ended.  I'm just
> wanting to know how good auto updates work and how
> nebulous it is to track down a problem related to an
> installed pkg that doesn't flag an error but produces
> side-effects (intermittent or otherwise hard to track
> down) after the install.

I suspect it also depends on your data/setup. 
If you have a complicated php application say, it would be more likely
to potentially have a problem with a php update than just a server
serving static pages. 

> BEST PRACTICES
> 
> 1) do you automate the yum updates or do you do them
> manually so you can see what it's doing when you run
> the update?

We don't automate them. We monitor the announce list, then schedule the
updates at a known window. This allows people to see that the update is
coming and also test after it's been applied. 

> 2) how often do you do them (weekly, monthly, etc)?

Daily. For things like security updates you really don't want to be
much out of date. Once an update is released everyone can see the
vulnerability that was just fixed and look for machines that were not
updated. 

> 3) where do you monitor (sites/email lists) for
> special show stopper security updates or other fixes
> that you might want to manually install as one-offs in
> between your normal update cycle

http://lists.centos.org/mailman/listinfo/centos-announce

> 4) any config options that you think are really useful
> to making this work well?

Nothing I can think of off hand.

> 5) any benefits to creating a local yum repo first and
> then updating from that versus pulling directly from
> web?

You would get some BW savings if you have a number of machines that you
need to update, otherwise not too much. 

> I know that's a lot but look forward to hearing from
> anyone with first hand experience.
> 
> thanks

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20070222/b5ab223d/attachment.pgp>


More information about the LUG mailing list