> From: Eric Rostetter > > Quoting "Pettit, Paul" <ismanager@xxxxxxxxxxx>: > > > 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 -- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
