Patchen auf Linux

Wed Jul 19 16:22:30 CEST 2006

Hallo Marco,
hallo LUG OWL.

On Wed, Jul 19, 2006 at 03:35:22PM +0200, Marco Wiese wrote:
> Ist ja nicht so, dass wir keine Test und QS Umgebung haben. Es dreht sich 
> vielmehr darum, dass es soviele Komponenten auf unseren Linuxen gibt, die 
> alle bestimmte Voraussetzungen haben.

Das muss bei der Systemplanung schon berücksichtigt werden.

Kostet zuerst Zeit, spart hinterher Zeit.

> Bsp: SAP System, dass alleine schon Mindestanforderungen an den Kernel
> hat. Dazu kommt eine Fibrechannel Karte (Emulex), die ihre Treiber hat
> und auch nur mit einem gewissen Kernel arbeitet (Anbindung an EMC DMX
> über EMC Switche). Hinzu kommt außerdem EMC Powerpath (Redundanz der
> Fibrechannels), dass auch wieder ein gewissen Patchstand erwartet.

Aus diesen Parametern muss jeweils ein Mindestparameter extrahiert
werden, der für alles gilt.

> Das alles nur mal als Beispiel. Klar kann ich nun an meinem Testsystem
> hergehen und ein neues SP/einen neuen Kernel einspielen. Möglicherweise
> gehts aber auch in die Hose.

Selbst bei einem Testsystem überlegt man vorher, was für konsequenzen
das Handeln haben kann. Ohne Parameteranalyse patcht man nicht irgendwo
rum, da gibts auch beim Testsystem auf die Mütze, das ist nämlich u.U.
sinnfreie Zeitverschwendung.

> OK, dann fahre ich den Restore.

Wenn das ein umfangreiches System ist und der Restore dann einige TB
umfasst - geht man inzwischen Kaffee trinken ;-)

> Aber es geht ja vielmehr darum, dass wir hier uns die Frage stellen,
> ob sich andere Unternehmen ebenfalls mit diesen Problemen rumschlagen
> und zig Supportmatrizen studieren müssen, ehe sie einen Patch
> einspielen.

Ab einer bestimmten Größe/Komplexität muss man in dieser Art vorgehen.

> Und eben das nimmt tierisch viel Zeit in Anspruch. Nicht nur Zeit,
> sondern auch Nerven. HP-UX war da wesentlich "stressfreier".

Wenn das geplant und vorbereitet ist, die Dokumentation sinnvoll zur
Verfügung steht und die Dinge nachvollziehbar sind, kann das auch
stressarm sein. Man muss halt vorher einige Dinge organisieren und darf
nicht warten, bis man überrollt wird.

Man sollte seine Konfigurationen auch kennen.

> Wenn man dann die Planung für neue Systeme angeht, dann bekommt man
> "Bauchschmerzen", wenn man an eine stabile HP-UX Maschine auf Linux
> umsiedeln will (nur weils billiger wird).

No risk, no fun ;-)

> Hinsichtlich der Patche und neue Kernels, die bei Linux alle Nase lang
> rauskommen, stellt sich hier aber vielleicht nicht der finanzielle
> Aspekt in den Vordergrund, sondern eher der praktische. Und da sehe
> ich im Moment Linux nicht an der Front.

Wieso? Die alte Kernelkonfiguration ist die Vorlage für den neuen
Kernel. Damit sind die wesentlichen Parameter abgedeckt. Mittels
Changelog noch auf möglicherweise kritische Änderungen prüfen und los.
Die gemeinsame Mindestanforderung sollte erfüllt sein, also Einsatz in
der Testumgebung.

> Oder aber man läßt alles beim Alten á la "never touch a running system"
> und patcht gar nicht, wo ich wieder bei meiner Eingangsfrage wäre....

Gar nicht patchen ist eine beliebte Methode, sich in den Fuß zu
schießen. Irgendwann muss man patchen und dann kommt alles auf einmal.
Die Reihenfolge der Patches ist ggf. wichtig, und wenn irgendwo was
fehlt, können die Parameter nicht mehr gemeinsam erfüllt werden. Und
genau dann hat man ein Problem.

Wie war das noch mit den Geheimnissen der Installationsreihenfolge bei
Produkten aus und/oder für ein System aus Redmond?

> Angenommen ich patche mein SAP System mit einem neueren Kernel, dann 
> stelle ich z.B. fest, dass meine FC Karten mit dem neuen Kernel nicht 
> arbeiten. 

Dann sind entweder nicht alle Parameter erfüllt (deine Schuld, Mütze
auf) oder es gibt einen unvorhergesehenen Konflikt, der analysiert
werden muss und idealerweise in einen Bugreport mündet. Für letzteren
Fall sind Testumgebungen.

Richtig übel wird es erst, wenn eine race condition erst nach geraumer
Zeit das System lahmlegt und man das Vergnügen hat, als erster diese
Erfahrung zu machen. Irgendwann muss man schließlich den getesteten
Patch aufs Produktivsystem spielen. Wenn man diese Situation analysieren
darf, dann bitte mit den Möglichkeiten, die freie Software bietet.

Gruss
Frank