我应该多久更新一次Linux服务器？

我负责管理我们的生产服务器（邮件，Web，数据库都在一台服务器上）和测试服务器。两者均基于Debian构建。但是，由于我是系统管理的新手，我只是在安装更新时遇到一些需要更新的内容，以便可以拥有更新的功能并修复错误。目前，这是一个非常特别的过程，我想减少它。

所以我想知道知道自己在做什么的人如何处理这个问题？您多久在服务器上执行一次升级？测试和生产之间的升级过程是否有所不同？您是否总是先升级任何测试服务器？您是否对所有软件进行了完整更新，还是仅安装了选定的更新？

我运行apt-get update -qq; apt-get升级-duyq每天。这将检查更新，但不会自动进行。

然后，我可以在观看的同时手动运行升级，并可以纠正可能出错的任何问题。

除了维护补丁系统的安全问题外，我发现如果在补丁之间放置的时间过长，我最终会得到一堆想要升级的软件包，这不仅使我升级，还使我恐惧很多。每周大约两个。因此，我倾向于每周执行一次升级，如果优先级较高，则每天进行一次。这样做还有一个好处，那就是知道哪个软件包破坏了系统（例如，一次只升级几个）

我总是先升级不太重要的系统。我也有一个“回滚计划”，以防万一我无法修复系统。（由于我们的大多数服务器都是虚拟服务器，因此此回滚计划通常包括在升级之前拍摄快照，如有必要，我可以还原为快照）

话虽这么说，我认为升级在过去4年中只破坏了一次或两次，而那是在高度定制的系统上进行的-因此您不必太过偏执:)

除了先前的答案之外，还有一些Debian的具体事情：您应该订阅debian-security-announce和debian-announce和/或查看Debian Security页面。

假设您正在运行Debian的稳定版本，则大多数补丁将与安全性或漏洞相关，这意味着在任何给定软件包的版本之间不会有太多重大变化。根据debian补丁策略，补丁在被维护者转移到稳定分支之前也应该已经测试了一段时间。显然，这不会在修补时阻止破损，但在大多数情况下应防止破损。

请确保您的测试服务器保持最新状态，并且任何具有影响您和您的服务器的错误的软件包都应保持最新状态。一旦知道补丁是稳定的，应立即更新所有具有安全建议的软件包。

Debian通常是一个非常稳定的操作系统，并不是您应该过度担心破坏的操作系统，但是在更新之前，请务必先阅读要更新的内容，并留意任何看起来很奇怪的东西。我也在/ etc /目录中使用VCS，以确保可以通过'git diff'命令看到任何配置文件更改。

我先进行试运行，看看将要更新什么。有时，库（在本示例中为libfoo）会更改其API，这会破坏我们自己编写/安装的程序。如果某些关键库已更新，我将获取源文件并尝试在更新之前针对它重建我们的东西。

我还检查了一下我们是否没有跳到某些公共服务的中间版本，例如apache等。我宁愿落后一年，也不会遇到随机损坏，除非更新很关键。

如果您是系统管理员，则应该从诸如Secunia之类的站点提取RSS feed，如果您的发行版要推送一些补丁程序，则应该让您提前知道。

永远不要盲目升级/更新。不幸的是，知道发生了什么的任务落在您身上，而不是您的发行版程序包管理器，尤其是在您的系统支持程序员的情况下。

在我工作的地方，我们有一个相当广泛的过程，涉及使用称为PatchLink的软件来通知我们最重要的与安全相关的更新，并且我们会在测试后逐包应用这些更新。我们有数千台服务器。

如果只有两台服务器，则过程应该简单得多。虽然我不认为“ apt-get更新/升级”是最好的选择。

我将监视正在运行的软件的补丁程序，并根据这些版本中的修补程序来决定何时升级。

显然，由于您具有测试服务器，因此请始终在应用更新之前先对其进行测试。

如此处所述，手动更新最好，因为您可以看到正在发生的事情。但是，对于大量服务器而言，这可能变得不切实际。空运行是一种标准做法，实际上，大多数包装经理会在进行操作之前询问您。

定期更新往往是最好的选择，尽管这可能有点平衡。频繁的更新意味着更少的一口气和更少的一次出错。如果事情确实出错了，检查的候选人就更少了。软件包也可以在较小的步骤中更好地进行更新，通常来说，当程序员进行更新时，他们正在考虑从上一个版本升级到下一个版本，它们是否会在最后一个版本之外给予其他关注可能会有所不同，尽管这往往很重要主要用于快速发展的软件。

并非所有更新都是非破坏性的。您需要注意这一点。有些会重新启动服务，导致停机。

在理想的设置中，您可能需要以下配置：

• 表面上切换服务器的一种方法（A / B或壁虱）。这意味着您可以在工作台上更新一个，然后将流量从当前的交换到新的。对于诸如数据库之类的服务，这可能更加复杂。
• 测试更新的能力。您应该拥有实际上是生产克隆的测试服务器（但不连接任何生产服务）。这些将使您可以首先测试更新。
• 一个好的备份策略，增量式是理想的。你永远都不会知道。安全总比后悔好。
• 请注意哪个时间活动最多，可以容忍的停机时间水平是多少。
• 知道如何回滚更新或特定程序包。
• 具有自己的软件包镜像，因此更新在服务器之间是一致且可预测的。这是迈向可信赖的体面无人值守系统的第一步。这意味着您可以更新镜像，在一台或多台测试计算机上运行更新，然后如果可以的话让它自动退出。我度过了非常愉快的时光，可以适当地管理大约800台EPOS机器。
• 高度的一致性，这样您就可以知道如果某些东西可以在这里工作，那么它将在那里工作。

对于小规模的安装，其中一些可能会在不同程度上造成过大的杀伤力，但应牢记。

一般来说，对于服务器发行版而言，更新通常相对容易。这是因为它们几乎总是只坚持错误修复和安全更新。但是，如果人们对系统做了奇怪的事情，或者您添加了其他软件包资源，则可能会遇到问题。

尽管这种情况相当少见，但它们偶尔还是会犯错误并破坏次要软件包版本之间的兼容性。

我喜欢cron-apt来自动执行此过程，但是正如@dinomite在有关更新的另一个问题上指出的那样，专门配置它以自动执行与安全性相关的更新是一个非常聪明的想法-然后可以手动更新所需的内容。我一直在使用cron-apt进行所有更新，但实际上根据他的回答对此进行了更改。如果喜欢，您可能应该投票赞成他的答案，而不是这个答案。

在debian上，我安装了cron-apt并编辑其配置文件，以便对这些内容进行任何更改。这样，我会收到通知，了解我的系统是否有更新，并手动进行更新

与cron-apt相同，您应该查看无人值守升级包http://packages.debian.org/lenny/unattended-upgrades。

它非常易于配置，使您能够自动下载和应用安全更新，但保留其他更新以进行手动升级（或自行决定升级所有内容！）。

官方的《 Ubuntu Server指南》有相当详细的部分，涵盖了无人值守升级包https://help.ubuntu.com/9.04/serverguide/C/automatic-updates.html的使用

注意：根据您的谨慎/偏执程度，您可以首先在一组测试服务器上进行滚动升级，然后如果没有问题，请更新生产版本，尽管我个人没有遇到安全更新方面的任何麻烦破坏迄今为止的破坏（敲木头）...

一旦应用了此安全更新，还有一个配置选项可向您发送每个安全更新的结果。另外，如果在更新过程中出现任何对话框或交互式提示，则需要系统管理员手动调整，也将提及这些提示。

我个人关闭自动更新，并且不定期在我的环境中的服务器上对软件包进行任何形式的更新，除非：（a）我的系统中的一个软件包有重要的CERT咨询；（b）由于特定原因，我需要升级单个软件包；（c）操作系统或程序包即将终止，不再受支持，我们需要继续获得支持。我的理由是，升级时不知道要更改的内容，也不知道为什么会留有太大的破损空间。我已经做了14年这样的事情，而且效果很好。

除了提到的内容外，您还应该使用某种监视工具（Nagios或任何漂浮在您船上的东西）来提醒您更新。

关于频率：只要有可用的更新！