I replied over on the WISPA list, but here it is again: Scheduling a 'yum -y update' is really not a good idea.
Updates can be tricky, but in larger shops, I often use Pulp to manage yum repositories for fleets of RHEL/CentOS boxes. I sync RHEL/CentOS repositories to my Pulp repos nightly, and then take snapshots of these repos for "non-production" and "production" hosts. The servers themselves point to the 'snapshot' repositories (non-production hosts point to the non-production snapshot, production hosts point to the production snapshot). This allows me to promote bleeding edge/new packages to non-production hosts and test them before promoting to production hosts. This also gives me the ability to cherry-pick very important updates (eg, critical security updates) and quickly promote them to all hosts. From there, I typically use Puppet/mcollective to trigger "yum updates" on the remote hosts. You can also use the pulp-consumer client which would be installed on each host and would allow you to "push" updates out to the hosts from your central Pulp server. Again - this may be overkill for smaller shops. There are several 'home-grown' things you can do as well (using SSH to execute simultaneous yum updates across environments, etc) that may fit your environment better. Josh On Wed, Jan 7, 2015 at 9:38 AM, Mike Hammett <[email protected]> wrote: > In Windows, there's WSUS, SCCM, etc. for managing the update process on a > bunch of machines. How are you guys managing that in Linux? I have mostly > (if not completely) CentOS and Debian, ranging from version 5 (I hope not > any older) to version 7. > > I'd like to think that I'd want something more elegant than a cron that > does yum update -y daily or weekly, but really, I never check the packages > I do upgrade, I just upgrade them all. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com >
