[RndTbl] Linux patching best practices

[Sean Walberg]

I think that the answer you gave ignores application specific things.

For example, at a former employer, some code we had broke when Microsoft
issued a service pack. Our code depended on the [broken] way NT would parse
command line options, and that "was fixed" in the service pack.

Red Hat et al seem to be pretty good about just issuing real bug fixes and
not jumping software versions during updates, but I don't get any warm
fuzzies from the updates being regression tested. I would make sure to test
anything related with the language you're using.

Another example, the version of Ruby that used to be in CentOS failed this
test:

should "not have that 1.8.5 bigdecimal bug" do
assert_equal "$1.01", ("$%0.2f" % BigDecimal.new("1.01"))
end

which is roughly the equivalent of sprintf("$%0.2f", 1.01) (it returned
"$1.10", not something you want when you're producing financial reports)

Sean


On Mon, Nov 29, 2010 at 4:55 PM, John Lange <john at johnlange.ca> wrote:

> In theory, regression testing is what you get when you use the the
> licensed versions of RedHat and Suse etc. so if your asking those
> kinds of questions you might want to use a licensed version.
>
> But I'm wondering what other people on this list think about that answer?
>
> >From my personal perspective, on our licensed versions of SLES as well
> as my desktop OpenSUSE I allow auto-update of everything that does not
> require a reboot.
>
> Since I'm stuck with proprietary ATI drivers on my laptop, if I allow
> auto-kernel updates my display stops working. On servers, unscheduled
> unsupervised rebooting is not a good idea so better to plan those
> updates.
>
> --
> John Lange
> www.johnlange.ca
>
> On Mon, Nov 29, 2010 at 11:33 AM, Gilbert E. Detillieux
> <gedetil at cs.umanitoba.ca> wrote:
> > On 2010-11-26 20:43, Adam Thompson wrote:
> >> For CentOS, I'm quite comfortable setting up automatic updates.
> >> It's not "best practices" but I've spent a LOT less time fixing
> >> post-update problems than I would have spent testing each update,
> >> over the years.  (This applies to Red Hat in general since RH2.1.)
> >
> > I would tend to agree here, at least for the repos enabled by default in
> > CentOS-Base.repo, i.e. base, updates, addons and extras.  What I do at
> > work is allow auto-updates for those repos on the various workstations
> > and non-critical servers I maintain.  For my most critical server, I run
> > "yum update" manually, after I've determined that the updates didn't
> > break anything on the other systems.
> >
> > Not necessarily safe for third-party repos, however...  I've had some
> > minor breakage with rpmforge packages, and catastrophic failures with
> > some EPEL updates that were DOA and pushed out without the slightest bit
> > of testing.  (They can also take forever to fix such broken packages.)
> > I'd be sure to test these out on the least critical systems first,
> > before updating anything important.
> >
> >> I think the days of testing patches independently are gone because of
> >> manpower reasons, unless you're running in a high-availability
> >> environment.
> >
> > Again, I mostly agree, but I would make exceptions for certain critical
> > packages and/or critical systems, whether HA or not.  But, yeah, you
> > can't test every update that comes out.
> >
> > --
> > Gilbert E. Detillieux           E-mail: <gedetil at muug.mb.ca>
> > Manitoba UNIX User Group        Web:    http://www.muug.mb.ca/
> > PO Box 130 St-Boniface          Phone:  (204)474-8161
> > Winnipeg MB CANADA  R2H 3B4     Fax:    (204)474-7609
> > _______________________________________________
> > Roundtable mailing list
> > Roundtable at muug.mb.ca
> > http://www.muug.mb.ca/mailman/listinfo/roundtable
> >
>
> _______________________________________________
> Roundtable mailing list
> Roundtable at muug.mb.ca
> http://www.muug.mb.ca/mailman/listinfo/roundtable
>



-- 
Sean Walberg <sean at ertw.com>    http://ertw.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.muug.mb.ca/pipermail/roundtable/attachments/20101129/1da59c65/attachment.html