Ham*_*ner 13 centos update automatic-updates
作为我工作的一部分，我管理几十台 CentOS 5 服务器，使用 puppet 进行主要设置。我们大约有一半的服务器具有用于托管各种 django 站点的标准化设置，而其余的则是应用程序的大杂烩。
我正在逐步整理我们的托管实践，现在我已经开始研究如何在操作系统级别管理安全更新。我担心只是有一个 cron 工作做一个，yum -y update但也不希望必须及时检查每个服务器并检查每个有可用更新的包，因为这需要一段时间。
所以我想知道是否有任何好的捷径或工作实践可以最大限度地减少所涉及的风险并最大限度地减少我需要花费的时间。或者换句话说，是否有任何工具或实践可以使大量工作自动化，同时仍能提供控制权。
到目前为止我决定的步骤：
另请注意，我已经查看了yum 安全插件，但它在 CentOS 上不起作用。
那么，您如何管理大量运行异构应用程序阵列的 CentOS 服务器的更新？
有很多工具可以帮助解决这个问题！它概括了包系统以及哪些包去哪里由配置管理处理。这些工具通常不仅仅涵盖 yum 和 rpm，而且会节省您的时间并避免许多令人头痛的问题！
我最熟悉的工具是 puppet，我用它来管理环境中的几乎所有配置。以下是一些专门管理 yum 的 puppet 示例：
http://people.redhat.com/dlutter/puppet-app.html
目前有许多配置管理工具可用，这些工具拥有相当大的用户群：
在环境中实施这些将延长您的寿命。它减少了因系统配置不当而带来的麻烦，并允许轻松升级/更新。这些工具中的大多数还可以提供一些审核级别的功能，这可以大大减少修复配置错误的时间。
关于您有关测试的问题，我一直在使用一个暂存环境，我们将一些客户加载到该环境中（通常是测试版客户或生产流量的一小部分）。在将新代码部署到生产环境之前，我们通常让该集群运行新代码至少几天，最多一周（取决于更改的严重程度）。通常，如果您尝试弄清楚大多数错误需要多长时间才能发现，我发现此设置效果最好。在频繁使用的系统中，这可能需要几个小时的时间，在我见过的大多数环境中，一周的时间足以发现分段/质量检查中甚至不常见的错误。
测试的一个非常重要的部分是数据/使用的复制。您提到您拥有大多数生产硬件的暂存版本。他们是否也有相同的生产数据副本？您可以根据它重放任何生产负载吗？您甚至可以使用流量镜像使其成为生产集群的一部分吗？这通常成为企业愿意在测试/质量保证上花费的资源量之间的直接权衡。测试越多越好，尽量不要自我限制（在合理范围内），看看业务会支持什么（然后想办法多做10%）。