Something to think about before attempting to centrally manage, your
systems actually have to be centrally manageable -- that doesn't happen
automatically and requires extra work.
The just run yum update strategy is only reliable when all packages on the
system were installed from RPM and all software RPMs installed are
properly maintained by the vendor using Yum. Some packages have updates
that are distributed with Yum, but yum updating "breaks" the application,
until a manual update procedure is completed. Sometimes an updated kernel
won't boot. Sometimes, a third-party driver for RAID card X won't load
in the patched kernel, and after a reboot, the OS never comes back up
because it's sitting at a kernel panic message indicating no hard drive
Cacti/OpenNMS are good examples -- after a yum update to a new version,
you must manually invoke, a potentially dangerous "installer" program or
web page has to be used, after a new update, config files, or database
schema have to be edited or patched by hand; until you manually take some
action to "fix" the config, the application is broken after update.
As soon as you attempt to restart the application it will shutdown OK, but
not come back up.
Occassionally, there is a library update that breaks binary compatibility
with existing applications, for example a certain update to
net-snmp-libs in Centos 5.something.
yum-updatesd surely doesn't know when auto-applying an update will cause an
important service to suddenly break
To centrally manage effectively, you basically need a homogenous
environment with a configuration that is very close to stock config, so
that effective testing is possible; homogenous meaning an identical list
of installed packages and software all installed the same way on every
system centrally managed as a group, identical SKUs for every hardware
component in every installation configured identically, same hw revisions,
No "extra" applications or files floating around on a one-off server.
So yum-updatesd would be a bad idea for production systems that have any
even if YUM maintained. And even if YUM maintained, third party YUM
repos may become neglected,
or change into 404 errors, causing yum to break entirely.
Often commercial third-party software used on CentOS systems will be
distributed in another format, such as .tar.gz.
Yum cannot do much with that; the third party package will likely get
neglected and not updated.
Often various applications you require may need versions of libraries or
applications that are not yet
available in RPM format, or they're part of Fedora instead.
In any case, if you wind up rebuilding the RPM for CentOS using rpmbuild or
installing from source, Yum update won't help you with those packages,
and may break their dependencies later.
That might just be a testament to how poor the available packaged software
selections are in CentOS, that commonly needed packages aren't part of the
distribution; and commonly outdated versions of libraries are present.
But YUM-updatesd's usefulness certainly applies to less than 100% of