Linux-Systeme benötigen, wie alle anderen Betriebssysteme auch, regelmäßige Patch-Installationen. In der professionellen IT installiert man bekanntlicherweise aber nicht einfach alles, was zur Verfügung steht. Bei produktiven Systemen ist man in der Regel applikationsseitig an Supportverträge gebunden. Diese Verträge beinhalten oftmals eine Supportmatrix, die gewisse Releases ausschließen oder erst verspätet freigeben.
Bei CentOS / RedHat findet ein Releasewechsel in der Regel mit der Installation eines aktualisierten Kernels statt. Möchte man beim alten Release bleiben und dennoch Patche installieren, darf der Kernel (inklusive Header und Sourcen) nicht aktualisiert werden.
Je nach System sind ggf. spezielle Kernel installiert, weswegen es sich empfiehlt, vorher zu schauen, welche Kernel aktualisiert werden würden:
# yum check-update | grep -i kernel
Bei einem Standard-System würde der Aktualisierungsvorgang ohne Kernel-Upgrade folgendermaßen aussehen:
# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.1 (Santiago) # yum --exclude=kernel* --exclude=redhat-* update # shutdown -r now ... # cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.1 (Santiago) # yum check-update | grep kernel | cut -d" " -f 1 dracut-kernel.noarch kernel.x86_64 kernel-firmware.noarch kernel-headers.x86_64
Du kannst auch einzelne Pakete in der jeweiligen Repo Datei in ‘/etc/yum.repos.d/’ aufführen.
Hier sind sogar Wildcard Einträge Möglich wie z.B.:
exclude=kernel* dracut*
Works for me.
Hi!
Korrekt, das geht natürlich auch.
Aktuell habe ich auf einigen meiner Servern das Problem, dass trotz o.g. Ignorierung der Kernel-Updates sich dennoch das Release ändert. Hast Du eine Ahnung, was man da noch tun kann? Mithilfe von Google findet man da leider nicht so viel.
Gruß!
Das Problem liegt wohl eher darin, dass unter Fedora, CentOS mit einem Release Paket das “Update” erfolgt.
Unter Fedora heißt dies fedora-release.noarch.
Siehe: yum info fedora-release.noarch
Das sollte es auch bei CentOS etc. geben, vielleicht heißt es anders, mir fehlt gerade die passende Testumgebung um das zu beweisen.
Das könntest man noch mit in die exclude ergänzen.
Zu dem Paket müsste es auch gewisse Abhängigkeiten geben die andere Pakete blockieren. Dazu müsste man mal durch die SPEC Dateien schauen.
Hi!
Ah, okay. Das werde ich mir morgen mal auf einem meiner RHEL-Server anschauen. Das könnte tatsächlich die Lösung meines Problems sein. 😉
Danke für den Tipp.
Auf der Froscon bin ich dieses Jahr sogar mal wirklich anwesend – vielleicht läuft man sich ja über den Weg. 😉
Gruß.
Übrigens kannst Du dich auf die Froscon eingeladen fühlen, zu finden bin ich dort mit vielen anderen Fedora / CentOS / Redhat Freunden als Aussteller dort.
http://www.froscon.de/startseite/
Das freut, wie gesagt ich bin als Aussteller für Fedora Linux auch über beide Tage am Stand.