kspliceの生産準備はできていますか？

本番環境でのKspliceのserverfaultコミュニティの経験を聞きたいです。

ウィキペディアからの簡単な宣伝文：

KspliceはLinuxカーネルの無料のオープンソース拡張機能であり、システム管理者はオペレーティングシステムを再起動することなく、実行中のカーネルにセキュリティパッチを適用できます。

そして

Kspliceは、カーネルを再起動することなく、カーネルコードの変更のみが必要なソースコードパッチを適用できます。他のホットアップデートシステムとは異なり、Kspliceは統一されたdiffと元のカーネルソースコードのみを入力として受け取り、実行中のカーネルを正しく更新します。それ以上の人的支援は必要ありません。さらに、Kspliceを利用するには、システムを最初に起動する前に準備を行う必要はありません（たとえば、実行中のカーネルを特別にコンパイルする必要はありません）。更新を生成するために、Kspliceは、ソースコードパッチによってカーネル内のどのコードが変更されたかを判断する必要があります。

いくつかの質問：

安定性はどうでしたか？カーネルの「リブートレスライブパッチ」で発生した奇妙な問題はありますか？カーネルパニックまたはホラーストーリー？

私はいくつかのテストシステムでそれを実行しており、今のところ宣伝どおりに機能していますが、Kspliceで他のシステム管理者が経験したことに興味があります。

だから、Kspiceを本番で使用している人はいますか？

更新：うーん、数時間後にはこの質問に関する実際の活動は見られません（ある種の賛成票や賛成票を除く）。いくつかの活動を刺激するために、さらにいくつかの質問をして、この議論を進めることができるかどうかを確認します...

「Kspliceを知っている場合、それを使用していない理由はありますか？」

「まだ未熟であるか、実証されていない、またはテストされていないと感じますか？」

「Kspliceは現在のパッチ管理システムにうまく適合していませんか？」

「稼働時間が長い（安全な）システムを持つのが嫌いですか？」;-)

（まず、免責事項：私はKspliceで働いています。）

当然ですが、より重要なことには、500以上の企業顧客（10年12月現在の数）を自社の生産インフラストラクチャで使用しています。

1人のシステム管理者がRed Hat Enterprise Linuxユーザーのメーリングリストで同じ質問をし、いくつかの回答があります。そのうちのいくつかを以下に抜粋します。

Kspliceは数十台のホストで数か月間本番環境で実行されています。これまでのところ、宣伝どおりに機能します。

そして

私の管理下にあるマシンは500台以上あり、そのうち約445台がアップトラックに接続されています（rhel 4および5）。マシンを再起動する前に、kspliceを使用していくつかのルートエクスプロイトをブロックしました。まだテスト中なので、とにかく新しいカーネルを展開しましたが、何週間も問題なくkspliceを実行しました。

人々が表明した懸念の1つは、安定性ではなく、既存の監査および監視ツールとの統合に関するものです。

kspliceの使用に関する唯一の「落とし穴」は、「ksplice対応」の監査ツールがまだ利用できないことです。

ご想像のとおり、これは現在私たちが多額の投資を行っている分野です。

Kspliceについて聞いたとき、それは良いアイデアだと思いました。ダウンタイムなし、再起動なし。しかし、その後、私はそれをもう少し調べて、それを試してみるのが怖くなりました。

それを避ける理由は次のとおりです。

• Linuxカーネルはすでに非常に複雑です。Kspliceは複雑さを増します。複雑さが増すほど、失敗は増えます。

• 障害が長いダウンタイムと費用のかかる修理を引き起こすリモートサーバーでKspliceを試すのは無謀です。

• 私の場合の唯一の利点は、稼働率の統計値が高くなることです。

ホームサーバーでKspliceを使用しています（アップタイムは重要ではありませんが、便利です）。Aptを介したクライアントへの時々の更新、カーネルの更新自体の問題は一切なく、（顕著な）不安定性は一切ありません。

ただし、通常の「YMMV」免責事項が適用されます！;-)

Kspliceはオープンソースのカーネル拡張機能ですが、ソフトウェアは誰でも無料で使用できますが、Linuxパッチ管理を行う会社（「Ksplice」とも呼ばれます）によって特別に作成されていることに留意してください。Ksplice（カーネルmod）は、カーネルにkspliceが使用可能なパッチがある場合にのみ有効です。Ksplice（会社）とサポート契約を結ばない限り、これはおそらく表示されません。

したがって、ksplice（ツール）はかなり成熟していますが、パッチ管理にKsplice（会社）を使用することを検討している場合にのみ、それは本当に関連性があります。

良い質問。私の最初の反応は、の線に沿って何かだろう「なぜない私はこれが必要？」

ほとんどの場合、必要ありません。5-9のセットアップであっても、「スケジュールされたメンテナンス」は多くの場合、この種のダウンタイムを可能にするSLAの条項です。HAがセットアップされている場合は、フェールオーバーに切り替え、一方のボックスにカーネルをインストールし、再起動して、もう一方のボックスで繰り返します。ボックスで5分間のダウンタイムすら許されない場合は、とにかくフェールオーバーのセットアップが必要です。

これは斬新な技術ですが、まだ実用的な使い方はあまり見られません。カーネルのセキュリティ更新はもちろん必要であり、できるだけ早くパッチを当てる必要がありますが、新しいカーネルをインストールして再起動するだけでなく、どれだけの時間/労力/心配を省くことができますか？何かがうまくいかない場合はどうしますか？PXEタイプの回復オプションを使用できるほど幸運であると仮定して、システムを再イメージングすることでどれくらいの時間を失いましたか？

また、前述のように、このような技術をリモートで実験することは、複数のサーバーで問題が発生した場合に大惨事になる可能性があります。テストでは、DCにいるのとまったく同じハードウェアを使用していますか？あるマシンでうまく動作するものは、別のマシンではうまく動作しない場合があります。

ちょうど私の0.02ドル。

かなり前ですが、Kspliceができることはたくさんあります。

• ダウンタイムなしで即座にパッチを適用できるため、セキュリティが向上します。これは、非常に敏感な環境では非常に重要です。

• ダウンタイムなしで即座にパッチを適用できるため、安定性が向上し、再起動の時間がないときに状況を改善できます。

• ダウンタイムなしでオンザフライでパッチを適用し、必要なものだけを必要に応じて適用できるため、パフォーマンスが向上します。

• ダウンタイムなしでオンザフライでパッチを適用できるため、プロアクティビティが改善されたため、ホットパッチのテストファームのセットアップが可能になり、以前の状態に簡単に戻ります。