更新生产Ubuntu的盒子和注意事项

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

在devise补丁程序时，您需要考虑的基本状态是假设某些事情会中断。

在devise补丁设置时，我倾向于使用的一些基本指导原则是：

• 始终使用本地系统从内部集中到安装补丁的networking

这可能包括将WSUS或<your_os_here>镜像用于内部修补程序pipe理机器。 最好能够集中查询并让你知道安装在你的个人机器上的补丁的状态。

• 在机器上预安装 – 如果可能的话 –

当有可能的时候，补丁出来后，中央服务器把它们复制到各个机器上。 这真的只是一个节省时间，所以你不必等待他们下载和安装，你只需在补丁窗口中启动安装。

• 获取停机窗口来安装补丁程序，您可能需要重新启动，而且有可能会中断。 确保这些系统的利害关系人知道有补丁正在部署。 准备好“这个”不工作的电话。

根据我的基本理论，补丁破坏事物，确保你有一个停机时间窗口来应用补丁足够长的时间来解决关键问题，并可能将修补程序回滚。 在修补程序之后，你并不需要让人们坐在那里testing。 就我个人而言，我非常依赖我的监控系统，让我知道所有的function都在最低水平，我们可以逃避。 但也要为人们开始工作时所要求的一些小唠叨问题做好准备。 你应该总是有人安排在那里准备好接电话 – 最好不是那个一直到凌晨3点才打补丁的家伙。

• 尽可能自动化

就像IT中的其他一切，脚本，脚本，然后再编写一些脚本。 脚本包下载，安装启动，镜像。 基本上你想把补丁窗口变成一个婴儿坐的任务，只需要一个人在那里，以防万一事情破裂。

• 每月有多个窗口

这使您无法修补某些服务器，因为无论什么原因，无法在“指定的夜晚”进行修补。 如果你不能在晚上做他们1，要求他们在晚上免费2.也让你保持服务器数量同时补丁。

最重要的是跟上补丁！ 如果你不这样做，你会发现自己不得不做很大的10多个小时补丁窗口才能回到你被追上的地步。 在可能出现问题的地方引入更多的观点，并且找出哪个补丁更加困难。

这个问题的另一部分是，跟上补丁是一件好事，但补丁几乎每天都会发布。 如果每天都有一个新的安全补丁，那么有多less计划中断？

一个月或一个月一次修补服务器是 – 恕我直言 – 一个非常可行的，可以接受的目标。 更重要的是，你将不断地修补服务器，更less的，你开始进入你需要应用每个服务器数百个补丁的情况。

至于你需要一个月多less个窗户？ 这取决于你的环境。 你有多less台服务器？ 你的服务器需要多长时间？

较小的9×5环境可能每个月都会有一个补丁窗口。 大型24×7商店可能需要两个。 非常大的24x7x365每个星期都可能需要一个滚动窗口来每周修补一组不同的服务器。

find适合您和您的环境的频率。

有一点要记住的是，100％的最新是不可能实现的目标 – 不要让你的安全部门告诉你。 尽你所能，不要落后太多。

要做的事：

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

要避免的事情：

1. 在一天中午或者星期一早上9点，或者星期五下午5点进行更新！ （谢谢@ 3影响！）
2. 在真正的大型数据库服务器上升级MySQL（重启可能需要很长时间）
3. 一次做所有的服务器（特别是内核）
4. 做任何可能会改变/ etc / networks的东西（因为你可能会失去连接）
5. 自动更新，可以做到上述没有你在那里检查一切是好的。

还有一点值得：如果你习惯于Windows，大部分Linux更新不需要停机或重新启动，你会感到惊讶。 一些做，如内核更新。 但是需要重新启动或停机的更新通常会被标记为这样，并且可以单独处理。

我们的Ubuntu机器都运行LTS版本。

我们只是自动安装所有的更新 – 确定它不是“最佳实践”，但我们是一个相对较小的商店，没有每个服务的testing/开发/生产环境。 无论如何，LTS更新通常都经过相当好的testing和微创。

升级到新版本显然是多一点涉及。

我们处理更新下面的方式为Ubuntu LTS系统：

1. Maitain一套验收testing，可以检查我们软件中的所有关键path
2. 每天早上4点安装无人值守安全升级，并立即进行验收testing。 如果有什么失败的话，工程师会被分页，并有足够的时间在上午9点之前修复或回滚。 迄今为止，这种情况在五年内只发生过两次 – LTStesting稳定。
3. 我们每周都会自动重新部署我们的整个基础架构（digitalocean），部署蓝/绿部署，使所有软件包保持最新版本。 如果新部署未通过验收testing，则部署将暂停，直到工程师debugging问题。

对我们来说，下一个合理的步骤是消除内存中的会话信息，这样我们可以每天甚至每天多次重新部署基础架构，而不会影响客户并消除步骤（2）。

这种方法是低维护，完全避免维护窗口。

我build议的一件事是处理软件包的回滚。 有关如何执行此操作的build议，请参阅“ 与Debian进行交易和回滚” ，因为有时您需要快速修复某个升级，从而破坏某些内容。