mysql-server

[Pettit, Paul]

> From: Eric Rostetter 
> 
> Quoting "Pettit, Paul" <ismanager at ccbnpts.com>:
> 
> > Since there is no way to cache the downloads for 
> implienting manually I
> > guess I'm SOL.
> 
> No automatted way.  This is a feature missing in yum...
> 
> > I don't want to go to each and every machine (I have more 
> than 1) and
> > manually run yum to update them.
> 
> Do you run mysql on all of them?  If not, then maybe you 
> should exclude
> mysql from updates on the servers where you need it running, 
> and update
> those by hand.  But allow all other updates on the other machines. Or
> some similar method of controlling updates of critical software on 
> critical machines.
> 

On the ones I update using yum yes, they all have mysqld service running
for local DB hosting duties. I've added mySQL (mysql*) to the excludes
list as of Monday.

> > It defeats the purpose of having cron.
> 
> No.  Yum and cron have nothing in common.  In fact, I would run yum in
> cron in with check-update so it mails you a list of updates, 
> so you know
> that you need to update those packages on those machines.  So it in no
> way "defeats the purpose of having cron."
> 

This is in referance to having yum.cron by default listed in cron.daily.
Yes, I know that they are not related except in that cron governs when
yum updates if the yum daemon is running (via 'service' and
'chkconfig'). 

Running yum as 'check-update' requires editing the yum.cron script or by
rolling your own. I'm not adverse to doing that (done it enough) but
it's not much better than going to each machine in turn and running 'yum
update' individually. It is an option I'll grant you.

> > In fact Fedora Legacy's own documentation has a specific 
> step for adding
> > automatic updates (step 4 - 7.3 documentation).
> 
> Under the header "Decide if you want automatic updates" which implies
> you must think about this first before doing it!  There is a reason
> it is disabled by default!
> 

Disabled by default means nothing when it comes to wanting to automate
update downloads. People will turn it on as soon as they reach Step 4 in
the documentation. We all want timely updates and don't want to sit and
watch a program run (unless we are worried it will bomb) for this
purpose. 

> > There is no mention that
> > this process is NOT recommended by FL nor would I expect one.
> 
> We do not recommend it, nor do we say you shouldn't.  We say 
> you should
> decide if you want them, and if so, here is how to do it.
> 
> "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
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.

If QA is not robust enough to trust these updates on production servers
(and just how many people here are still "playing" with 7.3 or 9?) then
I think there is an underlying problem.

> > 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!

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 patches they put out
have passed QA and are certified to fix the related issue.

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. 

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

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?
Simply put it doesn't, the package updated fine, didn't break anything,
and failed to reboot on it's own. 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.
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.

> > As I seem to be a minority I will shut up now. Still I 
> appriciate the
> > work put into the updates.
> 
> You should not shut up, you should ask for better solutions 
> to your problems.
> Maybe yum could be modified to allow you to download the 
> updates to the
> cache without installing them (I think apt allows this, 
> though I'm not sure).
> Maybe you simply need to create a policy that works for you (exclude
> critical-to-you services/features from auto-update, while 
> allowing others
> to have auto-update), or choosing some machines for auto-update while
> making others be a manual update process.
> 

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.

Tom actually had a good idea (sarcastic though it was) in that more
control of yum is needed. 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.

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).

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

> > Paul Pettit
> > 
> > p.s. fedoralegacy.org is refusing connections. :(
> 
> I'm able to see it.  Anyone else seeing problems?  Can you 
> traceroute it,
> or dnslookup it to see if we can find a problem?
> 
> -- 
> Eric Rostetter
> 

It was the web site and it's back up now.

Peace.

Paul Pettit