更新生产 Ubuntu 的注意事项

Question

我经常登录生产 web/db/tools 框并看到典型消息：

可以更新30个包。16 个更新是安全更新。

我的问题是，你们所有人如何处理生产 Ubuntu 机器的更新？您是否自动执行这些更新？您是否为他们设置了停机时间？问题是，您永远不知道更新何时会破坏某些内容，例如现有的配置文件等。

这个问题的另一部分是，跟上补丁是“一件好事”，但补丁几乎每天都会发布。如果每天都有一个新的安全补丁可用，那么必须进行多少次计划中断？

我认为有关如何管理更新的答案的线程将非常有用。

Answer 1

修补 Ubuntu 与 Windows、RHEL、CentOS、SuSE、debian 等并没有什么特别之处。

在设计补丁程序时，您需要保持的基本心态是假设某些事情会中断。

在设计补丁设置时，我倾向于使用的一些基本准则是：

• 始终使用本地系统在内部集中到安装补丁的网络

这可能包括使用 WSUS 或<your_os_here>内部补丁管理机器的镜像。最好的一种可以集中查询并让您知道安装在各个机器上的补丁状态的软件。

• 在可能的情况下，在机器上预先安装安装。

在可能的情况下，随着补丁的出现，中央服务器将它们复制到各个机器上。这实际上只是节省时间，因此您不必等待它们下载和安装，您只需在补丁窗口期间开始安装。

• 获得一个中断窗口来安装补丁，您可能必须重新启动，并且可能会出现某些问题。确保这些系统的利益相关者知道正在部署补丁。为“这个”不起作用的电话做好准备。

根据我的基本理论，补丁会破坏一些东西，确保你有一个中断窗口来应用足够长的补丁来解决关键问题，并可能回滚补丁。你不需要让人们在补丁后坐在那里测试。就我个人而言，我非常依赖我的监控系统来让我知道一切都在我们可以逃脱的最低水平上运行。但也要准备好在人们开始工作时遇到一些烦人的问题。你应该总是安排有人在那里准备接听电话 - 最好不要是凌晨 3 点才修补箱子的人。

• 尽可能自动化

就像 IT 中的其他一切一样，脚本、脚本然后再编写一些脚本。脚本包下载，安装开始，镜像。基本上你想把贴片窗变成一个婴儿看护任务，如果事情坏了，只需要一个人在那里。

• 每个月有多个窗口

这使您能够不修补某些服务器，如果由于某种原因无法在“指定的夜晚”修补它们。如果您不能在第 1 晚完成它们，则要求它们在第 2 晚有空。还可以让您同时保持打补丁的服务器数量正常。

最重要的是跟上补丁！如果你不这样做，你会发现你自己必须做非常大的 10 多个小时的补丁窗口才能回到你被赶上的地方。引入更多可能出错的点，并使查找导致和问题的补丁变得更加困难。

这个问题的另一部分是，跟上补丁是“一件好事”，但补丁几乎每天都会发布。如果每天都有一个新的安全补丁可用，那么必须进行多少次计划中断？

每月或每隔一个月修补一次服务器是 - 恕我直言 - 一个非常可实现且可接受的目标。不仅如此，而且您将不断地为服务器打补丁，更不用说，您开始遇到需要为每台服务器应用数百个补丁的情况。

至于你一个月需要多少窗户？这取决于你的环境。你有多少台服务器？您的服务器所需的正常运行时间是多少？

9x5 的较小环境可能每月只需要一个补丁窗口就可以逃脱。大型 24x7 商店可能需要两个。非常大的 24x7x365 可能需要每周滚动窗口才能每周修补一组不同的服务器。

找到适合您和您的环境的频率。

要记住的一件事是，100% 保持最新是一个不可能达到的目标 - 不要让您的安全部门告诉您其他情况。尽力而为，不要落后太多。

Answer 2

要做的事情：

1. 进行备份
2. 确保它是可恢复的备份（尽管这两个是一般要点）
3. 尝试在升级时引导流量远离生产盒。
4. 尝试使用带外访问方法，以防万一出现问题，KVM、串行控制台、本地访问或远程手。
5. 在一台服务器上进行测试，然后确保一切正常，然后再将更新部署到更多服务器上
6. 如果可以，请使用 puppet 以确保多个服务器上的版本号相同。（你也可以用它来强制升级）
7. 在测试服务器上，将配置文件的版本与新的（更新安装的）版本进行比较，并确保没有任何事情会严重破坏事情。我似乎记得 dpkg 在安装与当前安装的版本不同的新版本之前询问过。

需要避免的事情：

1. 在一天中间，或周一早上 09:00，或周五下午 5 点进行更新！（感谢@3influence！）
2. 在非常大的数据库服务器上升级 MySQL（重启可能需要很长时间）
3. 一次完成所有服务器（尤其是内核）
4. 做任何可能改变 /etc/networks 的事情（因为你可能会失去连接）
5. 无需您在那里检查一切即可执行上述操作的自动更新没问题。