Update strategies (was Re: [TriLUG] Re: Newbie question reguarding YUM and Linux.)

[Rick DeNatale]

On 1/11/06, Chad Thomsen <chad.thomsen at gmail.com> wrote:
> I know this is not linux realated but I work as a Windows/AS400/Linux
> admin.  Patched my citrix servers over night.  Came in the next morning and
> they did not work.  That right there is grounds not to allow auto patching.
> In that situation, an in all server patching situations, I allow for "extra"
> time the day after to deal with any for seen issues.
>
> I asked the question because I was wondering if Linux was any better/worse
> the windows in THIS reguard.  My guess was right, and it is basically the
> same.  From a patching/fix point of view, an operating system is an
> operating system, with  the exception that some OSes have a history of
> releasing bad patches or patches that cause issues with other software.

I'm not sure that the contents of the thread adds up to the conclusion
that Linux==Windoze as far as the safety of applying patches.

My analysis is that several respondants offered the OPINION that it
wasn't a good idea to apply patches automatically.  And an intimation
that Red Hat has, in the past, released at least one borked RPM, but
this was followd by Jon Carne's observation that this/these
anecdote(s) come from earlier days and that Red Hat in particular, and
the Linux community as a whole has matured.

I'd be interested in RECENT experiences of linux updates, which have
caused problems.  Not saying that they haven't occured, just that I
haven't experienced them.

I used to be a RH user, starting with RH 9 and moving to FC 2 and 3
before switching over to Debian/Ubuntu for both server (mail, apache
with various LAMP apps, dns, ssh etc.) and client  The closest thing
to a problem caused by updating a system that I've experienced was
caused by my own misconfiguration of the RPM based port of apt-get (or
maybe it was yum, I can't recall for sure) and the lack of consistency
in repository versioning schema between Fedora and add-on RPM
repositories, which put me into a dead-end as far as keeping certain
packages current. I never saw an update cause a functional problem
though.

That said, it's still probably not a good idea to do unattended
updating. Just in case something goes wrong, it's better to have a
good idea that it happened right after an update, and that's somewhat
more likely if you (rather than a cron job) just pushed the button, or
entered the command to do the update.  In my case, on my server, I do
run a nightly apt-get chron job, but only to download any new patches,
not to install them automatically.

There seem to be several issues of interest here:

1) How to set a policy on WHEN to update.  It seems that there are
people who NEVER update except in dire circumstances. At the other end
are people who update as soon as they become aware of available
updates.  I'm curious how various Triluggers approach this question,
and how the packaging scheme and dependency resolvers they use affect
that decision.

2) How to determine the probability that a given update or set of
updates is safe BEFORE they are applied.  I'd be really interested in
any wisdom about how to do this, particularly for those of us not
fortunate enough to have spare machines to do testing on before
deploying changes to "production."

3) How to test for problems AFTER a set of updates is applied so as to
find the problems asap.

I suspect that most base their decision on the first issue on gut
instincts, do very little, if anything, about the second unless they
do have test machines available, and do various levels of testing
ranging from nothing, through a quick sniff (are the daemons still
running, do they keep running if they need to be manually restarted),
to extensive regression testing.

I'm interested in what light others might be willing to share about
how they approach these issues.

--
Rick DeNatale

Visit the Project Mercury Wiki Site
http://www.mercuryspacecraft.com/