On Thu, Aug 1, 2013 at 6:07 PM, Steven Haigh <[log in to unmask]> wrote:
> On 02/08/13 02:26, Vincent Liggio wrote:
>>
>> On 08/01/2013 12:16 PM, Elias Persson wrote:
>>>
>>>
>>> All the more reason to read up on the differences, and if it's
>>> only one system 'yum remove yum-autoupdate' is hardly a big deal.
>>> If it's 1200 systems, what difference would an option in anaconda
>>> make? It's not like you'll be stepping through that hundreds of
>>> times, right?
>>
>>
>> No, when I have to migrate to a new OS (which won't be a 6.4 derivative,
>> it will be a 7.0 one, so probably 8-9 months from now), then I'll worry
>> about the differences. When I'm testing a piece of hardware that
>> requires a specific kernel release on an OS I don't run, whether a new
>> option is installed by default or not is not on the top of my list of
>> things to worry about.
>
>
> If you really do have 1200 systems to worry about, I'd be looking at things
> like satellite. I have ~20-25 systems and yum-autoupdate is fantastic. It
> does what it says on the box and relieves me of having to watch / check for
> updates every day. I get an email in the morning that tells me what was
> updated and if there were any problems.

It's exceedingly dangerous in a production environment. I've helped
run, and done OS specifications and installers for a system over
10,000 hosts. and you *never*, *never*, *never* auto-update them
without warning or outside the maintenance windows. *Never*. If I
caught someone else on the team doing that as a matter of policy, I
would have campaigned to have them fired ASAP.

A simple "yum check-update" cron job reporting to root or to a
designated email address  is far, far, far safer. Safer yet, if you
have Nagios or Icinga up and running for production, is to install and
use the "nagios-plugins-check-updates" package from EPEL, which allows
graceful remote Nagios monitoring of the system status in an organized
fashion across the network.

In a production environment, unannounced or unplanned restarts of
critical daemons such as httpd, mysql, named, snmpd, nagios, mrtg, or
especially the Java based services such as tomcat6 can cause cascading
failures across the whole environment. You may have the spare
resources to do "monkeywrench" failures across your environment all
the time to try to avoid this sort of thing, but very few facilities
do.

It's also nasty when you have software that is incompatible with
contemporary versions of upstream published software. Take a look over
at https://github.com/opentusk/OpenTUSK-SRPMS  for some work I did
last year. Some of the components listed there were more modern than
those in SL 6, but many of those whose names start with "tusk-",  were
built to avoid the automatic updates to contemporary release of of
that software which was incompatible with the existing codebase.

And some software updates, such as database updates, are *not
reversible* without enormous engineering pain. When SL 5 updated from
subversion-1.4.2 to subversion-1.6.11, it auto-updated the local
Subversion repositories the next time you opened them, and *they can't
be turned back!!!* and are incompatible with older versions of
Subversion.