Patchen auf Linux

[Marco Wiese]

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. 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.

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. OK, dann fahre ich den Restore. 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. Und eben 
das nimmt tierisch viel Zeit in Anspruch. Nicht nur Zeit, sondern auch 
Nerven. HP-UX war da wesentlich "stressfreier".

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). 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.

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....

Gruß
Marco


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. 

linux-bounces at lug-owl.de schrieb am 19.07.2006 13:55:37:

> [Bild entfernt] www  Diese EMail erreichte Sie via Internet... / 
> This mail was sent via internet...
> 
> Zitat von \"Frank Guthausen (Club)\" <schach-linux at gmx.li>:
> >
> > P: "Nehme ich diese Woche Gentoo oder LFS?"
> >
> > A: "Warum will mein Chef Gnome, wo doch icewm oder Konsole ausreicht?"
> 
> Wobei sich beim Thema SAP nur die Frage stellt -  nehm ich SLES oder 
RHEL?
> 
> >> Wie haltet ihr bei Euch das Patchen auf Oracle oder auch 
SAP-Maschinen?
> >> Patcht ihr oder patcht ihr gar nicht? Wenn ihr patcht, was genau? 
Kernel
> >> oder nur einige Pakete, oder vielleicht ein komplettes SP ohne Kernel 
oder
> >> doch alles?!?
> >
> > Bevor man patcht, sollte man ausgiebig testen. Sofern der Support den
> > Patch erlaubt und das in einer Testumgebung funktioniert, kann man
> > patchen. Man sollte berücksichtigen, dass man jeden Schritt notfalls
> > rückgängig machen können muss, um wieder ein lauffähiges System zu
> > erhalten.
> 
> Richtig. Und gerade beim Thema SAP gibt es ja die beliebte Drei - System 
-
> Landschaft bestehend aus Development System, QA System und 
Produktivsystem.
> Hier gilt, das der Releasestand von links nach rechts abnimmt (also 
gemäß
> meiner Auflistung). Linux, SAP, Oracle usw. werden klar durchgepatcht.
> 
> 
> > Wer in einer Produktivumgebung mal so eben rumpatcht, muss sich nicht
> > wundern, Gewinner für den Hartz IV Award zu werden.
> 
> Ja, Abhilfe siehe oben.
> 
> Gruß
> 
> Johannes
> 
> 
> -- 
> Linux mailing list Linux at lug-owl.de
> subscribe/unsubscribe: http://lug-owl.de/cgi-bin/mailman/listinfo/linux
> Hinweise zur Nutzung: http://www.lug-owl.de/Mailingliste/hints.epo