fau*_*ver 15 linux kernel update patch-management
我很想听听 serverfault 社区在生产中使用Ksplice的经验。
来自维基百科的快速简介：
Ksplice 是 Linux 内核的免费开源扩展，它允许系统管理员将安全补丁应用于正在运行的内核，而无需重新启动操作系统。
和
Ksplice 可以在不重启内核的情况下应用任何只需要修改内核代码的源代码补丁。与其他热更新系统不同，Ksplice 仅将统一的差异和原始内核源代码作为输入，并正确更新正在运行的内核，无需进一步的人工帮助。此外，利用 Ksplice 在系统最初启动之前不需要任何准备（例如，运行内核不需要经过专门编译）。为了生成更新，Ksplice 必须确定内核中的哪些代码已被源代码补丁更改。
所以有几个问题：
稳定性如何？您在内核的“无需重启实时修补”中遇到过什么奇怪的问题？内核恐慌还是恐怖故事？
我一直在几个测试系统上运行它，到目前为止，它一直在按照宣传的那样工作，但我对其他系统管理员在“全力以赴”并将其部署在我们的生产服务器上之前对 Ksplice 的体验感兴趣。
那么，有人在生产中使用 Kspice 吗？
更新：嗯，几个小时后没有看到关于这个问题的任何实际活动（除了一些赞许和收藏）。也许为了引发一些活动，我还会再问几个问题，看看我们是否可以继续讨论……
“如果您知道 Ksplice，您是否有理由不使用它？”
“你是否觉得它仍然过于前沿，未经证实或未经测试？”
“Ksplice 是否不适合您当前的补丁管理系统？”
“您讨厌拥有长时间（且安全）正常运行时间的系统吗？” ;-)
小智 9
（首先，免责声明：我为 Ksplice 工作。）
我们自然而然地在自己的生产基础设施上使用它，但更重要的是，我们的 500 多家企业客户也是如此（截至 10 年 12 月的数量）。
一位系统管理员在 Red Hat Enterprise Linux 用户邮件列表上提出了同样的问题，并得到了许多答案，其中一些摘录如下：
我们已经在十几个主机上运行 Ksplice 几个月了。到目前为止，它的工作原理与宣传的一样。
和
我有超过 500 台机器在我的控制之下，其中大约 445 台连接到上轨（rhel 4 和 5）。在我们有机会重新启动机器之前，我们使用 ksplice 阻止了一些 root 漏洞。由于我们仍在测试中，我们无论如何都推出了新内核，但我已经运行了几个星期 ksplice 没有问题。
人们表达的一个担忧不是稳定性，而是它与现有审计和监控工具的集成：
关于使用 ksplice 的唯一“问题”是目前还没有任何“ksplice-aware”审计工具可用。
正如您所料，这是我们目前正在大力投资的领域。
我听说了 Ksplice，当时我认为这是个好主意。没有停机时间，没有重启。但后来我更深入地研究了它，我害怕尝试它。
我避免它的原因是：
Linux 内核已经非常复杂。Ksplice 增加了复杂性。更多的复杂性 = 更多的失败。
在远程服务器上试验 Ksplice 将是鲁莽的，因为故障会导致长时间停机和昂贵的维修。
在我的情况下，唯一的好处是更高的正常运行时间统计数据。