在生产服务器上通过cron运行apt-get update -y是否安全？
这可能是安全的，或者更准确地说，风险水平可能与您的舒适度有关。 风险水平将取决于几个因素。
你有一个好的备份系统，可以让你快速恢复，如果有什么突破？
你是否将服务器上的日志转发到远程系统，如果这个盒子变坏了，你会知道发生了什么？
你是否愿意接受这样的可能性，即某些事情可能会破坏，如果事情失败，你可能需要在系统上快速恢复/还原？
您是否自己手动编译过任何东西，或者绝对安装在系统上的所有东西都来自官方存储库？ 如果你在本地安装了某些东西，上游的更改可能会破坏你本地的维护/安装软件。
这个系统的作用是什么？ 如果它死了（例如，一个辅助DNS服务器），或者它是您的基础设施（如LDAP服务器或主文件服务器）的核心部分，它是几乎不会被遗漏的东西。
你想设置这个，因为没有人负责服务器有时间来维护安全补丁？ 未修补漏洞的潜在风险可能高于潜在的不良更新。
如果你真的认为你想这样做，我build议你使用已经在那里的工具之一，如cron-apt。 他们有一些逻辑更安全，然后只是一个盲目的apt-get -y update 。
它通常是安全的，但我不会推荐它有一个简单的理由：
在生产环境中，您需要确切地知道它上面或者上面应该是什么，并且能够轻松地重现这个状态。
任何变更都应该通过变更pipe理stream程来完成，在变更pipe理stream程中，公司充分意识到他们正在进入的内容，以便他们以后可以分析出什么问题等等。
每晚更新使得这种分析变得不可能，或者更难做到。
是的，只要你在说更新而不是升级 。 如果你放行的话，Apt甚至会为你做：
APT::Periodic::Update-Package-Lists "1";
在/etc/apt/apt.conf.d/
我可能会在稳定或Ubuntu上，但不是在一个不稳定的分支，甚至testing分支。
虽然，当我把系统pipe理员帽子放在上面时，我相信我应该手动应用所有的更新，这样我可以保持服务器之间的一致性，并且如果有一天服务中断了，我知道我上次更新服务。 这是我可能不会检查更新是否自动进行。
在我们的大部分Debian系统上，我们使用稳定的计划apt-get升级（与我们的微软“补丁星期二”更新一致）。 它运作良好。 我们还将所有升级事件logging到Nagios中，以便我们可以查看上次在任何服务器上执行升级的历史logging。
当你指定这是一个“生产”服务器，这是否意味着有开发和testing服务器呢？ 如果是这样，在安装到生产箱之前，应该在这些系统上testing这些补丁。
我不会这样做。 不好的补丁确实发生了，我不想在半夜或者我无法使用的时候系统出现故障。 当pipe理员可用于监视更新时，应将其推入维护时段。
我记得以前的工作是这样做的; 我结束了生产服务器上的问题，因为更新自动重写了一个configuration文件。
因此，我build议你监督更新。
如果替代scheme是不定期地应用更新，那么您不会主动遵循安全更新，而且您正在运行一个vanilla stable Lenny，那么自动更新可能会提高您的计算机的安全性，因为您将更快地更新已知的安全漏洞。
Ubuntu服务器有一个可以自动更新安全更新的软件包。 它也允许你将某些应用列入黑名单。 它还谈到了apticron，当有更新可用于您的服务器时，它将通过电子邮件发送给您。
您可以在以下页面find更多关于它的信息，具体取决于您运行的是哪个版本的Ubuntu服务器。
编辑：假设你正在运行Ubuntu。 尽pipe我敢打赌，Debian上也有相同的软件包和解决scheme。
看看cron-apt。 它只默认下载列表和软件包文件，但您可以调整它发送邮件，甚至升级系统。
这取决于你的基础设施。 如果我有一台机器，那么通常我会查看更新，看看我需要什么，或者我可以避免什么。 如果我使用集群，我有时会在一台机器上展开更改，然后看看它们是如何去的，如果一切正常，则将其展开到其他机器上。
数据库升级我总是密切关注。
如果你有一个支持快照的文件系统，对于快照系统，应用更新，然后在出现可怕的错误时可以select回滚更改。
试着找出为什么一个软件包正在升级？ 是错误修复？ 安全修复？ 是本地命令还是远程networking服务？ 软件是否已经过新的更新testing？
内核更新应该更加谨慎。 试着找出为什么内核正在升级？ 你真的需要这些改变吗？ 会影响你的申请 我需要申请这个安全吗？
10次软件更新中的9次将会顺利进行，但这是罕见的时候，它会让您成为一堆垃圾，有一个回滚或系统恢复计划。