Linux-Magazin Clean Linux (Vorschau)

des Kernels. Zweitens bleiben die Änderungen
am System dadurch klar separiert.
Im Falle eines Fehlverhaltens lässt
sich einfacher feststellen, ob es auf den
neuen Kernel oder auf andere Systemänderungen
zurückzuführen ist.
Kernelupdates 09/2013
Titelthema
Alles neu
Abbildung 1: Beim Booten kann der Admin den zu startenden Kernel auswählen und gegebenenfalls wieder auf
die bewährte Version zurückgreifen, hier beim SLES 11 SP2.
Woher weiß der Admin, welche Änderungen
seine Server durch den neuen Kernel
erfahren? Etwas zu optimistisch ist der
Ansatz, einfach den Betriebssystemkern
auszutauschen und hinterher zu prüfen,
ob der Fix wirkt oder die Software nun erwartungsgemäß
arbeitet. Gibt es Release-
Notes des Linux-Distributors, empfiehlt
sich deren Lektüre. Wer es ganz genau
wissen möchte, der organisiert sich den
Quelltext der zu vergleichenden Kernel
und holt sich die gewünschten Informationen
auf diesem Level ab.
Kommt vorwiegend eine bestimmte Distribution
zum Einsatz, lohnt es sich,
Informationen bezüglich ABI- und API-
Stabilität einzuholen. Im günstigsten Fall
verfügt der Hersteller über eine Liste von
Funktionen, deren Schnittstellen für einen
bestimmten Releasezyklus konstant
bleiben. Für Software, die genau dieses
ABI benutzt, ist eine Änderung des Kernels
an sich transparent. Alle anderen
Programme müssen sich wohl oder übel
Tests unterziehen.
In Enterprise-Setups finden sich grundsätzlich
zwei Ansätze zum Thema
Schnittstellen-Stabilität. Red Hat publiziert
eine Liste von Funktionen (siehe
Listing 1), die der Distributor während
einer Major-Release konstant hält [1]. Mit
Lebenszyklen von zehn Jahren für aktuelle
RHEL-Versionen [2] bedeutet dies
zumindest erheblichen Aufwand und
kann sogar hinderlich sein. Beispielsweise
basiert RHEL 6 auf dem Kernel
2.6.32. Bestimmte Funktionen und Features
aus neueren Kernels lassen sich
rückportieren, aber ein echter 3.x-Kernel
wird trotzdem nicht daraus.
Oracle und auch Suse gehen einen anderen
Weg. Hier lautet das Versprechen,
das Userspace-ABI konstant zu halten,
nicht aber unbedingt die Schnittstellen
innerhalb des Kernels ([3], [4]). Das
ermöglicht diesen Distributoren, neuere
Kernel einzusetzen und den Aufwand
fürs Backporting deutlich zu reduzieren.
Das hat aber auch seinen Preis, der
sich in vermehrten Tests mit Software
von Drittherstellern niederschlägt, wenn
diese Kernelmodule benutzt.
Unterbrechungsfrei
Das Linux-Magazin 08/​08 [5] stellte
das Ksplice-Verfahren [6] vor. Unter
bestimmten Voraussetzungen kann der
Admin damit den Kernel ohne den lästigen
Reboot patchen. Das Tool analysiert
dabei alten und neuen Code auf der Objektebene.
Auszutauschende Funktionen
landen in einem Kernelmodul, das das
Werkzeug in den laufenden Kernel lädt
und aktiviert (Abbildung 2).
Seit 2011 gehört diese Technologie Oracle
[7]. Fedora und Ubuntu-Desktop-Benutzer
können kostenfrei der Online-
Patcherei frönen. Im Enterprise-Umfeld
bekommt es der zahlende Oracle-Linux-
Admin als kostenlose Zugabe zum UEK
(Unbreakable Enterprise Kernel). Auch
die Red-Hat-Fans sparen sich gegen Entgelt
einige Reboots.
Suse- beziehungsweise SLES-Fans schienen
lange Zeit außen vor. Die Teilnehmer
der Susecon 2012 durften aber schon
mal durch das Schlüsselloch einen Blick
auf Version 12 der Enterprise-Produkte
werfen: Ksplice – besser gesagt die zugrunde
liegende Technik – soll es dann
dort ebenfalls geben, und zwar direkt aus
dem Hause Suse. Unabhängig vom verwendeten
Linux sollte dem Admin aber
klar sein, dass die Aufgabe von Ksplice
primär das schnelle und schmerzfreie
Patchen von Sicherheitslücken im Kernel
ist. Operative Notwendigkeiten und Sicherheitsanforderungen
lassen sich damit
unter einen Hut bringen.
Das Online-Patchen ist dazu gedacht,
einen Kernel jahrelang laufen zu lassen
und immer neue Ksplice-Updates draufzupacken.
Dennoch gibt es technische
Grenzen für Online-Updates. Generell
lässt sich sagen, dass ein Upgrade von
Kernelversion 3.x auf 3.y in Ksplice nicht
vorgesehen ist. Größere Umbauten im
Kernel würden den Aufwand ins Uner-
Listing 1: ABI-Whitelist für RHEL
6.3 (x86_64)
01 [root@rhel]# head /lib/modules/kabi‐rhel63/
kabi_whitelist_x86_64
02 [rhel6_x86_64_whitelist]
03 ___pskb_trim
04 __alloc_pages_nodemask
05 __alloc_percpu
06 __alloc_skb
07 __bdevname
08 __bitmap_and
09 __bitmap_complement
10 __bitmap_empty
11 __bitmap_weight
12 [root@rhel ~]# wc ‐l /lib/modules/kabi‐rhel63/
kabi_whitelist_x86_64
13 1607 /lib/modules/kabi‐rhel63/kabi_whitelist_x86_64
www.linux-magazin.de
43