mysql-server

[Eric Rostetter]

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

> > "Best Practices" dictate that you simply don't do automatic updates on
> > a production machine (whether linux, windows, solaris, or
> > other).  This
> > has nothing to do with FL per se.
> >
> 
> Most would say that being able to download overnight or automatically
> any update that came out, that has passed through QA, and has been maked
> as "critical", in a timely manner is a "best practice". In fact if you

For machines which are not critical, yes.  For critical machines, no.
Critical machines/services (machines or services for which you can not
"afford" in some metric downtime) should never do unattended updates
as they may create a machine/service failure or malfunction.

> have a sever that is in danger of being compromised unless said update
> is done it's not just a "best practice" it's a requirement for continued
> employment.

Maybe you need to look at other ways to protect it instead?  Maybe a 
firewall, or disabling or removing a vulnerable service, or some other
method until you can safely test and install the updates.

In fact, if you could just use automatted updates, then your job is
really in danger (for reduced hours at least) since they don't need
you around to do updates; just turn them on automatically.

> If QA is not robust enough to trust these updates on production servers

No, QA is not, and can not, verify that it will work for all users.

> (and just how many people here are still "playing" with 7.3 or 9?) then

Probably lots are "playing" with it, just as many (myself included) use
them in production (no playing).  Not sure what you mean to imply with
that comment really.

> I think there is an underlying problem.

Yes.  The underlying problem is people incorrectly think they can use
automatic updates on production/critical machines and obviously the
industry in general as well as FL has not done enough to educate people
that this isn't the case.

> > > To limit
> > > people to manually acting on updates devalues FL's service below
> > > Microsoft.
> >
> > No, it differs in no way from Microsofts updates.  Microsoft
> > also states
> > that you should not apply automatic updates to
> > production/critical servers.
> >
> 
> Incorrect!

No, sorry, it is correct.

> All critical updates that M$ puts out are REQUIRED for production
> servers, it's not an option even though many admins think it is (and
> thus look at the number of hacked systems).

The fact that they are "required" does not mean you should automatically
install them.  Microsoft's policy is you should test them first, then 
install them.  They do not recommend you automatically install new patches
on production/critical machines without testing or at least monitoring
the install.

> The patches they put out
> have passed QA and are certified to fix the related issue.

Yes, but they are not certified to not crash your machine, toast your
services, or otherwise shutdown your production.  And even though they
may say they fix the related issue, sometimes they don't (or only partially
fix it).  But that is another issue.  Whether it fixes the issue or not
is not the issue of this thread. The issue of this thread is can you safely
install the updates automatically without any monitoring or testing, and
the answer is no (whether the update comes from Microsoft or FL).

> The same is true for RHEL, the updates they put out are good for prime
> time. It would be worthless to have updates if you first had to try them
> out on a test server just to see if the server will run.

But yet this is the case.  So by your theory RHEL updates are worthless.

I can't count the number of time QA'd software from Dell and Red Hat has
caused problem on production Dell PowerEdge 2650 machines.

> If your stand is that all updates need to be further tested when you
> download them from FL thats just ... eh?

In a perfect world, yes, you would do that for all FL and Microsoft and
Dell and Sun and who-ever-else's updates.  Now in the real world, it
may not be practical, and indeed I don't usually test them first. But
on my critical machines, I only install them by hand.  I'd never install
them automatically.  And once they are installed, I test/verify the
functionality of the machine to make sure (best I can) it still works.

I would notice right away after a mysql update if the mysql server wasn't
running.

> Well yeah maybe if they relate to other apps (or other apps rely on
> them) but where does that figure into the mySQL crash after update?

It doesn't.

> Simply put it doesn't, the package updated fine, didn't break anything,
> and failed to reboot on it's own.

And had you followed minimal best practices (watch the update, test it
after wards) you would have found this out immediately and fixed it.

Personally I wouldn't even update mysql without first making a backup
of the databases, just in case.  That would preclude using an automatted
update tool via cron.

> This happened on a holiday thus
> compounding the problem for a (unlucky) few. It's not biterness but
> concern for future updates and the haphazard way they are being put out.

There is nothing haphazard about the way they are being put out, and they
are being put out asap because that is they way the majority of people 
want them put out.

> But if I'm the only one worried then ... meh. I'll live and I'm sure the
> world won't end if this is pushed aside.

You seem to think it is going to be pushed aside, so much that you don't
seem to want to help.  I don't know why you feel this way.  There is much
that can be done to help with the situation, such as updating the docs
to address the issue, etc.  I have no intention to push this aside, just
as I have no intention to change the way releases are done.

> My point (which has been lost and was an opinion btw) was that to help
> the end users from getting bit by a major package update going south
> that updates be distrubuted in a timely manner but taking into
> consideration that some days of the month are bad days. Since most here
> are euro or american it's not that hard to figure out the big ones.

Yes, as I pointed out, Monday in my time zone is not Monday in other
people's time zone, so it is difficult to do.
 
> Tom actually had a good idea (sarcastic though it was) in that more
> control of yum is needed.

I also suggested maybe modifying yum.  But I guess my opinion is of no
value to you, since I disagree with your primary goal of changing the
way releases are issued.  But then again, yum is a project separate
from FL, so this may not be the best place to discuss this issue.

> To that I say "duh!" now that I see that yum
> works too black/white for most admin's (at least me) needs. Since I'm a
> programmer I'll deal with the random timing of updates that FL puts out
> by controling when yum really updates, not just every freaking day like
> they have it set at.

Good.  That's good progress.
 
> But again I reiterate, releasing updates on certain days is ***IMHO*** a
> bad idea because not all are willing / able to fix yum on their own to
> ensure that they aren't on holiday when the next big package downloads
> then pukes (manually updating not included).

See above.  Best practices dictates that you don't use automatted updates.
If you do, you're assuming the risk inherent in doing so.

> Take MHO for what it's worth or whatever little you *think* it's worth.

I think your opinion is worth the world.  And a lot of good ideas have
come from this discussion, some of which will help FL and its users
in the future.  But, none-the-less, you are fighting a losing battle
trying to change the release schedule; it just isn't practical or 
desirale.  That doesn't mean FL can't help you and others though, in
other ways, to help better the situation.

-- 
Eric Rostetter