mysql-server

Eric Rostetter rostetter at mail.utexas.edu
Wed Apr 13 19:46:08 UTC 2005


Quoting "Pettit, Paul" <ismanager at ccbnpts.com>:

> I've read (and now re-read) the MS document, the other one I couldn't open
> for some reason. I disagree that is what the MS document says on security
> updates but YMMV.

How can you disagree with it.  Some excepts are:

"The majority of security updates released are for client side (often browser)
issues. They may or may not be relevant to a server installation. Evaluate the
update, if it's needed, then apply it. If not, assess the risk of applying or
not."

"You should never be worse off by implementing a service pack, hotfix and
security patch. If you are unsure, then take steps to ensure that there is no
doubt when moving them to production systems."

"Before applying any service pack, hotfix or security patch, all relevant
documentation should be read and peer reviewed. The peer review process is
critical as it mitigates the risk of a single person missing critical and
relevant points when evaluating the update."

"All updates, regardless of their type (whether they are service packs, hotfixes 
or security patches), are to be applied on an "as-needed" basis. They need to be
evaluated individually and treated as important optional updates."

"Service packs and hotfixes must be tested on a representative non-production
environment prior to being deployed to production. This will help to gauge the
impact of such changes."

"If all tests in the lab environment are successful, start deploying on
non-critical servers first, if possible, and then move to the primary servers
once the service pack has been in production for 10-14 days."

I fail to see how you can comply with any of the above if you do un-attended
automatic updates on your production machines.  The above dictate that you 
can not do unattended, automatic updates on production machines.  And they
are just a small sampling of the paper, which contains many other statements
against automated installation of updates.
 
> I was going to go into another discourse on best practices and how the real
> world works but it's not worth it.

It is up to you to decide if it is worth your time or not to participate.
But I don't see how you can possibly make an argument for unattended,
automatic updates on a production machine for which you don't want
unplanned downtime.  This goes against everything I've ever heard or
been taught about IT Best Practices from any source.

> I decided that writing up anything at the time would have been a) circular
> filed by you or whoever got it,

I have never done that to a single thing you've wrote.  In fact, I've 
responded to most of your postings (unless I knew someone else had replied
to it before I could).

> b) would not have been very objective

That is something only you can comment on.

> and c)
> your page covered all the important parts of auto-updating and the risks
> involved. So I moved on.

Okay.
 
> Right now I'm just going to go back to lurking (save that test I need to do)
> as it's the safest thing to do right now.

Which is also the surest way to make sure FL doesn't improve.  If everyone
lurks, nothing will get done, and FL will fail.  But you do have the right
to do so; if you want to be a lurker, you have that right.
 
> You have the keys to the car (or at least one set) and if I or anyone should
> say "it might be best to turn left" and you turn right we all are just along
> for the ride.

Exactly, for both you and me.
 
> Paul Pettit

-- 
Eric Rostetter




More information about the fedora-legacy-list mailing list