Ist die ksplice-Produktion fertig?

Es würde mich interessieren, welche Erfahrungen die Serverfault-Community mit Ksplice in der Produktion gemacht hat.

Schneller Klappentext aus Wikipedia:

Ksplice ist eine kostenlose Open Source-Erweiterung des Linux-Kernels, mit der Systemadministratoren Sicherheitspatches auf einen laufenden Kernel anwenden können, ohne das Betriebssystem neu starten zu müssen.

und

Ksplice kann, ohne den Kernel neu zu starten, jeden Quellcode-Patch anwenden, der nur den Kernel-Code ändern muss. Im Gegensatz zu anderen Hot-Update-Systemen verwendet Ksplice nur einen einheitlichen Diff und den ursprünglichen Kernel-Quellcode als Eingabe und aktualisiert den laufenden Kernel korrekt, ohne dass weitere menschliche Unterstützung erforderlich ist. Darüber hinaus ist für die Nutzung von Ksplice keine Vorbereitung erforderlich, bevor das System ursprünglich gestartet wurde (der ausgeführte Kernel muss beispielsweise nicht speziell kompiliert worden sein). Um ein Update zu generieren, muss Ksplice ermitteln, welcher Code im Kernel vom Quellcode-Patch geändert wurde.

Also ein paar Fragen:

Wie war die Stabilität? Haben Sie irgendwelche seltsamen Probleme mit dem 'Rebootless Live Patching' des Kernels? Kernel Panik oder Horrorgeschichten?

Ich habe es auf einigen Testsystemen ausgeführt und bis jetzt hat es wie angekündigt funktioniert, aber ich bin daran interessiert, was andere Sysadmins mit Ksplice erlebt haben, bevor sie all-in gegangen sind und dies auf unseren Produktionsservern implementiert haben.

Also, wer benutzt Kspice in der Produktion?

update: hmm, ich sehe nach ein paar Stunden keine wirkliche Aktivität zu dieser Frage (abgesehen von ein paar positiven Stimmen und Favoriten). Vielleicht werde ich noch ein paar Fragen stellen, um etwas Aktivität zu entfachen und um zu sehen, ob wir diese Diskussion in Gang bringen können ...

"Wenn Sie Ksplice kennen, gibt es einen Grund, warum Sie es nicht benutzen?"

"Fühlen Sie sich immer noch zu blutig, unbewiesen oder ungetestet?"

"Passt Ksplice nicht in Ihr aktuelles Patch-Management-System?"

"Hassen Sie es, Systeme zu haben, die lange (und sichere) Betriebszeiten haben?" ;-)

(Erstens ein Haftungsausschluss: Ich arbeite für Ksplice.)

Wir nutzen es natürlich in unserer eigenen Produktionsinfrastruktur, aber was noch wichtiger ist, genauso wie unsere 500 Unternehmenskunden (Stand: Dezember '10).

Ein Sysadmin stellt dieselbe Frage auf einer Red Hat Enterprise Linux-Benutzer-Mailingliste und erhält eine Reihe von Antworten, von denen einige im Folgenden aufgeführt sind:

Wir haben Ksplice für ein paar Monate auf ungefähr einem Dutzend Hosts in Produktion gebracht. Soweit funktioniert es wie angekündigt.

und

Ich habe> 500 Maschinen unter meiner Kontrolle, von denen ungefähr 445 mit dem Uptrack verbunden sind (Rhel 4 & 5). Wir haben ksplice verwendet, um einige Root-Exploits zu blockieren, bevor wir die Möglichkeit hatten, Computer neu zu starten. Da wir noch testen, haben wir den neuen Kernel trotzdem rausgebracht, aber ich habe wochenlang ksplice'd ohne Probleme ausgeführt.

Ein Anliegen der Leute ist nicht die Stabilität, sondern die Integration in bestehende Prüfungs- und Überwachungsinstrumente:

Das einzige "Problem" bei der Verwendung von ksplice ist, dass es noch keine "ksplice-fähigen" Überwachungstools gibt.

Wie zu erwarten ist, investieren wir in diesem Bereich jetzt kräftig.

Ich habe von Ksplice gehört und damals dachte ich, dass es eine gute Idee ist. Keine Ausfallzeit, kein Neustart. Aber dann habe ich ein bisschen weiter hineingeschaut und hatte Angst, es zu versuchen.

Meine Gründe, es zu vermeiden, sind:

• Der Linux-Kernel ist bereits sehr komplex. Ksplice erhöht die Komplexität. Mehr Komplexität = mehr zum Scheitern.

• Es ist leichtfertig, mit Ksplice auf einem Remote-Server zu experimentieren, bei dem ein Ausfall zu langen Ausfallzeiten und kostspieligen Reparaturen führen würde.

• Der einzige Vorteil in meinem Fall wäre eine höhere Verfügbarkeitsstatistik.

Ich habe Ksplice auf meinem Heimserver verwendet (wo die Verfügbarkeit nicht kritisch ist, aber eine nette Sache ist). Hatte überhaupt keine Probleme damit - gelegentliche Updates über Apt an den Client, nie Probleme mit den Kernel-Updates selbst und keine (merkliche) Instabilität.

Es gilt jedoch der übliche "YMMV" -Haftungsausschluss! ;-)

Ksplice ist eine Open-Source-Kernel-Erweiterung. Bedenken Sie jedoch, dass die Software zwar kostenlos und für jedermann verfügbar ist, jedoch speziell von und für ein Unternehmen entwickelt wurde, das Linux-Patch-Management betreibt (auch "Ksplice" genannt). Ksplice (der Kernel-Mod) ist wirklich nur nützlich, wenn Sie ksplice-verwendbare Patches für Ihren Kernel haben, die Sie wahrscheinlich nie sehen werden, es sei denn, Sie haben einen Supportvertrag mit Ksplice (der Firma).

Obwohl ksplice (das Tool) relativ ausgereift ist, ist dies nur relevant, wenn Sie Ksplice (das Unternehmen) für Ihr Patch-Management in Betracht ziehen.

Gute Frage. Meine anfängliche Antwort lautete: "Warum brauche ich das?"

Wahrscheinlich brauche ich es nicht . Selbst bei einer Konfiguration mit fünf Neunen ist die "geplante Wartung" häufig eine Klausel in einem SLA, die diese Art von Ausfallzeit ermöglicht. Wenn Sie ein HA-Setup haben, wechseln Sie zum Failover, installieren Sie den Kernel auf einer Box, starten Sie ihn neu und wiederholen Sie ihn auf der anderen. Wenn Sie sich nicht einmal fünf Minuten Ausfallzeit für eine Box leisten können, benötigen Sie trotzdem ein Failover-Setup.

Obwohl es sich um eine neuartige Technologie handelt, sehe ich noch keine pragmatische Verwendung dafür. Sicherheitsupdates für den Kernel sind natürlich erforderlich und sollten so schnell wie möglich gepatcht werden. Wie viel Zeit, Mühe und Sorge ersparen Sie sich jedoch, wenn Sie nur einen neuen Kernel installieren und neu starten? Was ist, wenn etwas schief geht? Wie viel Zeit haben Sie durch ein erneutes Imaging des Systems verloren, vorausgesetzt, Sie haben das Glück, über eine Wiederherstellungsoption vom PXE-Typ zu verfügen?

Wie bereits erwähnt, kann das Remote-Experimentieren mit einer solchen Technologie eine Katastrophe sein, wenn auf mehreren Servern ein Fehler auftritt. Verwenden Sie in Ihren Tests genau dieselbe Hardware wie im DC? Was auf einem Computer gut läuft, läuft auf einem anderen möglicherweise nicht gut.

Nur meine 0,02 $.

Es ist lange her, aber was Ksplice für Sie tun kann, ist viel ....

• Verbesserte Sicherheit, da Patches im laufenden Betrieb ohne Ausfallzeiten möglich sind. Dies kann in hochsensiblen Umgebungen äußerst wichtig sein.

• Verbesserte Stabilität Da Patches im laufenden Betrieb ohne Ausfallzeiten möglich sind, können sich die Dinge verbessern, während keine Zeit für einen Neustart verfügbar ist.

• Verbesserte Leistung, da Patches im laufenden Betrieb ohne Ausfallzeiten ausgeführt werden können. Wenden Sie genau das an, was Sie benötigen.

• Verbesserte Proaktivität, da Patches im laufenden Betrieb ohne Ausfallzeiten möglich sind. So kann eine Testfarm für aktuelle neue Patches eingerichtet werden, ohne dass der vorherige Status verloren gehen muss.