Strom sparender Computereinsatz hilft nicht zuletzt auch Kosten zu senken. ADMIN 02/2011 geht der Frage nach, was Administratoren tun können, damit ihre ... (mehr)

Hoch und nieder

Prinzipiell könnte man versuchen, nur einzelne Pakete durch die jeweils ältere Version zu ersetzen – angefangen natürlich bei der Glibc. Dies setzt aber voraus, dass der Admin genau weiß, welche Pakete er austauschen muss. Außerdem ist der Mischbetrieb mit Paketen aus zwei verschiedenen Distributions-Versionen nicht gerade empfehlenswert. Unerwünschte Seiteneffekte bis hin zur Instabilität sind die Folge, insbesondere, wenn eine zentrale Komponente wie die Glibc beteiligt ist.

Glücklicherweise beherrscht Yum seit Version 3.2.27 die Option »downgrade« und erleichtert den Schritt von Fedora 14 zurück zu Fedora 13 erheblich. Diese Funktion lässt sich allerdings nur auf einzelne Pakete anwenden. Der Administrator muss somit zuerst eine entsprechende Paket-Liste generieren. Ohne Verwendung der History-Option von Yum führt der einfachste Weg über »rpm -qa --queryformat '%{NAME}\n' |xargs yum downgrade« . Leider war auch dieses Unternehmen in der Realität nicht von Erfolg gekrönt (siehe Abbildung 1).

Abbildung 1: Yum erleichtert den Weg von Fedora 14 zu Fedora 13 – erfordert dabei aber immer noch etwas Handarbeit.

Das prinzipielle Problem besteht darin, dass Fedora 14 einzelne Software-Pakete anders auf RPMs aufteilt als Fedora 13. In den meisten Fällen hilft es, das konflikterzeugende Paket zu über »rpm -e Paket1 --nodeps« zu entfernen und anschließend das jeweils andere Paket durch »yum downgrade Paket2« auf die ältere Version zu bringen. Nach ein paar Iterationen dieser Prozedur sollten alle Konflikte aufgelöst sein und der Admin kann das Gesamtsystem auf die ältere Version zurücksetzen. Ein finaler Reboot aktiviert den alten Kernel und die System-Bibliotheken und siehe da, auch der VMware-Server ist wieder zufrieden und tut seinen Dienst.

Ein neuer Versuch

Der Fallback ist allerdings nur eine kurzfristige Lösung. Früher oder später muss entweder ein aktuelleres Betriebssystem oder eine andere Variante der Virtualisierungssoftware her. Für den Moment ist die Lage aber entspannt und der Admin kann sich in Ruhe Gedanken über die endgültige Lösung machen. Der vorliegende Fall der Unverträglichkeit von Glibc und Vmware-Server war nicht wirklich unbekannt in der Linux-Gemeinde. Die im Netz vorgestellten Lösungen verwendeten allesamt den oben beschriebenen Ansatz der Parallel-Installation einer älteren glibc-Version. Sollte dies doch der richtige Weg sein? Vielleicht gibt es noch versteckte Abhängigkeiten, beispielsweise weitere Bibliotheken, die der Admin in einer älteren Version parallel installieren muss. Ein Blick auf das Executable »/usr/sbin/vmware-hostd« offenbart, dass dies nur ein Shell-Skript ist. Die eigentliche Binär-Datei liegt im Verzeichnis »/usr/lib/vmware/bin« . Ein »ldd /usr/lib/vmware/bin/vmware-hostd« zeigt tatsächlich, dass noch weitere Objekte relevant sind, nämlich insgesamt sechs Pakete (siehe Listing 3).

Listing 3

Bibliotheken von vmware-hostd

 

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019