Linux versus Microsoft

Verfahren der Softwareverteilung im Vergleich

17. Juli 2005, 23:16 Uhr | Matthias Kranz/wg Matthias Kranz ist als Head of Presales und Senior Consultant für Asdis tätig.

Im Linux-Umfeld funktionieren die Abläufe des Client-Managements mitunter anders, als Administratoren es aus der Windows-Welt gewohnt sind. Die Verteilmechanismen und Add-ons der Linux-Distributionen erweisen sich dabei als nützliche Helfer. Für ein unternehmensweites, plattformübergreifendes Client-Lifecycle-Management reichen diese Bordmittel allein allerdings nicht aus.

Für diverse Anbieter ist das Lifecycle-Management für Desktops in der Microsoft-Welt schon lange
ein wichtiges Thema. Aber nicht erst seit sich die Stadt München mit deutlich mehr als 10.000
Arbeitsplätzen dafür entschieden hat, ihre Clients unter Linux zu betreiben, stellt sich die Frage
nach geeigneten Verwaltungswerkzeugen. Diese sollen der IT-Abteilung dabei helfen, typische
Administrationsprobleme zu lösen: Welche Software ist in welcher Version auf welchem Rechner
implementiert? Welche Hardwarekomponenten stecken in wie vielen Systemen? Sind die passenden
Treiber – unter Linux im Regelfall Kernel-Module – installiert? Welcher Kernel ist auf den Desktops
im Einsatz? Gibt es bekannte Sicherheitslücken, für die eventuell schon ein entsprechender Patch
oder ein Update zur Verfügung steht? Wenn ja, wie viele der verwalteten Geräte sind bei einem
Rollout zu berücksichtigen?

Wie leicht zu erkennen ist, ähneln sich die Verwaltungsanforderungen unter Microsoft Windows und
Linux grundsätzlich stark. Teilweise unterschiedlich ist jedoch die Bewältigung beziehungsweise der
Umgang mit diesen Problemen. Denn einerseits bringt Linux als IT-Plattform andere technische
Voraussetzungen zum Management mit. Andererseits haben die Distributoren jeweils eigene Lösungen
für einige der oben genannten Herausforderungen entwickelt. Dazu haben sie Linux als reinen
Betriebssystem-Kernel mit zahlreichen frei verfügbaren und teilweise auch mit kommerziellen
Programmen und Bibliotheken zu einer vollständigen Betriebsplattform gebündelt. Die Schwierigkeit
hierbei: Fast jeder Anbieter hat das Rad für sich neu erfunden, fast jeder verwendet seine eigene,
spezifische Herangehensweise.

Linux ist nicht gleich Linux

In Deutschland haben sich im professionellen Umfeld im Wesentlichen drei Distributionen
etabliert: Red Hat, Suse (das seit Januar 2004 zu Novell gehört) und immer häufiger auch Debian
GNU/Linux. Im Vergleich mit Windows fällt auf, dass Linux in bestimmten Aspekten des
Softwaremanagements wesentliche Vorteile aufweist. So bieten alle relevanten Hersteller jeweils
schon seit einigen Jahren ein relativ ausgefeiltes Paketformat an. Microsoft dagegen hat erst in
der jüngeren Vergangenheit die Bedeutung eines solchen Formats erkannt und mit MSI (Windows
Installer) einen Standard präsentiert. Dieser hat sich inzwischen gut etabliert, und viele
Softwareanbieter stellen ihre Applikationen auch im MSI-Format zur Verfügung. Zudem bietet der
Markt den Administratoren Hilfsprogramme wie Installshield Adminstudio oder Wise Package Studio, um
beliebige Software, die oft noch nicht als MSI vorliegt, zu repaketieren.

Technisch gesehen ist MSI den Linux-Paketformaten sogar teilweise überlegen: So ist es möglich,
ein fertig geschnürtes Paket über zusätzliche Informationen – so genannte Transforms – nachträglich
anzupassen, ohne eine erneute vollständige Repaketierung vornehmen zu müssen. Über diesen Weg sorgt
der Administrator beispielsweise dafür, dass ein Programm in einem anderen Verzeichnis installiert
oder statt des Evaluations- ein passender Lizenzschlüssel verwendet wird.

Beim Einsatz von Linux hat es der Systemverwalter leider mit unterschiedlichen,
anbieterspezifischen Formaten zu tun: Suse und Red Hat arbeiten seit jeher mit Red Hat Package
Management (RPM), während Debian auf das eigene Debian Package (DPKG) vertraut. Die Ähnlichkeit ist
jedoch so groß, dass es Werkzeuge gibt, um das eine Format in das andere zu transformieren.
Voraussetzung dafür ist allerdings, dass die Paketierung möglichst konform zum jeweiligen Standard
erfolgt ist. Jede Distribution bietet außerdem Tools, um einzelne oder kleinere Gruppen von Paketen
über die Kommandozeile beziehungsweise über ein grafisches Frontend zu installieren. Im Hintergrund
arbeiten diese Instrumente mit proprietären Datenbanken. Diese Datenbanken verwalten den jeweiligen
Zustand, Namen und die Version des Pakets.

Paketmanagement

Um ein Paket aus Sicht des Softwaremanagements möglichst einfach verwenden zu können, sind
unterschiedliche Bedingungen zu erfüllen. Die Software muss unbedient, also ohne Interaktion eines
Administrators anwendbar sein. Unter Windows ist es der Benutzer gewohnt, dass nach dem Einlegen
einer CD oder DVD beziehungsweise nach dem Aufruf der setup.exe eines aus dem Internet geladenen
Produkts eine grafische Installationsprozedur startet. Diese erfragt dann allerlei sinnvolle wie
unsinnige Informationen. Dieser Vorgang lässt sich in aller Regel, bei MSI dann auch standardmäßig,
automatisieren.

Unter Linux ist dies bei allen Implementierungstechniken und Paketformaten eher die Regel als
die Ausnahme: Der Administrator ruft das Installationsprogramm zusammen mit einem oder mehreren
Paketen auf, und das Aufspielen erfolgt ohne Rückfrage im Hintergrund – es sei denn, es bestünden
Konflikte bei der Auflösung von Abhängigkeiten zwischen Paketen.

Damit sind wir bei einem wesentlichen Unterschied zwischen Windows und Linux: Die Formate unter
Linux berücksichtigen Abhängigkeiten zu anderen Paketen. Der Paketierer legt im jeweiligen Header
des Pakets fest, welche anderen Pakete in welcher Version vorliegen müssen. Dabei gewähren die
unterschiedlichen Formate in aller Regel die Möglichkeit, relative Bedingungen zu definieren, zum
Beispiel "in Version größer oder gleich x.y". Auf Basis der lokalen Paketmanagementdatenbank fällt
dann die Entscheidung, ob eine Abhängigkeit bereits gegeben ist oder nicht. Im letzteren Fall würde
die Operation nur dann ausgeführt, wenn der Anwender explizit die Überprüfung von Abhängigkeiten
mithilfe einer Option ausgeschlossen hat.

Nach erfolgter Installation einer Applikation oder eines Dienstes bleibt allerdings dem
Administrator die Aufgabe überlassen, die individuelle Konfiguration durchzuführen. Dies ist ein
Unterfangen, das bei hunderten oder gar tausenden zu verwaltender Systeme schnell zum Problem
anwächst. Als Lösung bietet die Open-Source-Welt in diesem Fall Tools wie zum Beispiel cfengine an.
Allerdings ist eine umfangreiche Vorarbeit notwendig, um alle anfallenden Jobs zu bewältigen. Eine
heterogene IT-Landschaft, bestehend aus Windows- und Linux-Systemen, ist auf diese Art nicht zu
beherrschen.

Nützliche Add-ons

Die meisten Linux-Distributionen bieten inzwischen Add-ons zu den eigentlichen
Paketmanagementwerkzeugen an. Diese erlauben die automatische Auflösung von Abhängigkeiten unter
Zuhilfenahme unterschiedlicher Quellen. Debians APT erlaubt es zum Beispiel, neben lokalen
Ressourcen wie CD-ROMs oder einem NFS-Verzeichnis auch Internetserver als Installationsquelle zu
definieren. Möchte der Anwender also ein Paket installieren, überprüft das Tool automatisch, ob die
im Paket definierten Abhängigkeiten bereits erfüllt sind. Ist dies nicht der Fall, fragt es bei den
Quellen an und lädt bei Bedarf die fehlenden Pakete herunter. Auf diese Weise lässt sich auch ein
komplettes Update aller installierten Pakete beziehungsweise ein Upgrade auf eine neue Version
durchführen.

Jedoch besteht ein Nachteil dieser Herangehensweise im Unternehmensumfeld: Eine ausgefeilte,
fein granulierte Steuerung und vor allem Kontrolle lässt sich häufig nur sehr schwer auf Basis der
vorhandenen Bordmittel realisieren. Ein verändernder Eingriff (Change) in das zu administrierende
System im Sinne von ITIL wird damit zum Vabanquespiel. Das Aufspielen eines Pakets unter Nutzung
der oben beschriebenen Technik kann automatisch eine große Anzahl von weiteren Paketen nach sich
ziehen. Diese wiederum beeinflussen eventuell andere Applikationen und Prozesse und führen so zu
einer ungewollten Destabilisierung des Zielsystems.

Um die verteilten Linux-Systeme auf dem aktuellen Stand zu halten beziehungsweise den Benutzern
weitere Applikationen zur Verfügung zu stellen, haben die Hersteller Suse und Red Hat außerdem
jeweils eigene Tools entwickelt. Novell hat dabei – durch die Akquisition von Ximian – mit Red
Carpet eine Ergänzung ermöglicht, die bis dahin in Suses Funktionsumfang gefehlt hatte. Bei Red Hat
heißt die Lösung Red Hat Network (RHN). Die Techniken sind prinzipiell vergleichbar: Auf einem
zentralen Server lagern Pakete in so genannten "Channels". Auf dem zu verwaltenden Gerät lässt sich
der jeweilige Client so konfigurieren, dass durch das Abonnement der Channels die Software
automatisch implementiert oder aktualisiert wird. Die Konfiguration des Update- beziehungsweise
Installationsverhaltens der Endsysteme kann der Administrator von zentraler Stelle steuern. Große
Umgebungen erfordern aus Skalierungsgründen in aller Regel den Einsatz weiterer Server, so
genannter Satellite-Server.

Erstinstallation von Betriebssystemen

Der Ersteinsatz von Linux ist durchaus mit dem von Windows vergleichbar. Unterschiedliche
Lösungen unterstützen inzwischen ein Imaging für Linux. Per Imaging lässt sich ausgehend von einem
Referenzsystem eine Kopie erzeugen, neutralisieren und beim späteren Rollout individualisieren.
Teilweise bestehen allerdings Einschränkungen bei der Unterstützung der unter Linux zahlreich
vorhandenen Dateisysteme (Ext2/3, XFS, ReiserFS etc.).

Die meisten Distributionen bieten aber auch eine Methode an, um die native Installationsprozedur
der Betriebsplattform durch die vorhergehende Bereitstellung aller benötigten Informationen
unbedient durchzuführen. Bei Suse heißt die Technik Autoyast2, bei Red Hat Kickstart und bei Debian
FAI. Damit lassen sich alle wesentlichen Konfigurationseinstellungen vordefinieren. Im Vergleich zu
einer Imaging-Lösung ist das "Unattended Setup" eines Linux-Systems in aller Regel zeitaufwändiger.
Dafür bietet es aber mehr Flexibilität, gerade auch im Hinblick auf die Erkennung und Unterstützung
von Hardware, die im Referenzsystem nicht oder in anderer Ausprägung vorhanden war.

Konfigurationen verwalten

Das Problem bei beiden angesprochenen Techniken ist die Anforderung, die installierten Systeme
individuell zu konfigurieren und abhängig von ihrer Funktion mit weiterer Software zu versorgen.
Ein fließender oder sogar integrierter Übergang von der Erstinstallation von Betriebssystemen zu
Software- und Konfigurationsmanagementprodukten ist wünschenswert, aber nur wenige Lösungen decken
dies ab. Dabei ist die Einstellung eines Linux-Systems in den meisten Fällen einfacher zu
automatisieren als bei Microsoft. Technisch gesehen befinden sich die meisten Konfigurationsdaten
in einfach aufgebauten Textdateien und lassen sich mit Bordmitteln patchen. Vergleichbar mit dem
Policy-Ansatz der Windows-Welt lassen sich heute bereits viele Parameter über einen zentralen
Verzeichnisdienst wie OpenLDAP realisieren. Die meisten klassischen Dienste wie zum Beispiel die
Benutzerauthentifizierung verfügen unter Linux über entsprechende Backend-Adapter für LDAP.

Freie und kommerzielle Lösungen

Die Lösungen, die die Distributionshersteller anbieten, sind nur sehr bedingt als frei zu
bezeichnen. In manchen Fällen sind die Client-Komponente oder zumindest Teile davon als Open Source
verfügbar, um die Funktionalität in eigenen Lösungen verwenden zu können. Die Bereitstellung der
zentralen Serverkomponente ist aber in aller Regel mit Lizenzkosten verbunden. Eine Ausnahme bildet
Debian GNU/Linux mit den Modulen APT und FAI.

Eine integrierte, zentrale Managementinstanz zur Steuerung und Überwachung des gesamten
Lebenszyklus sucht man hier allerdings vergebens. Bei den kommerziellen Anbietern im
Lifecycle-Management von Desktops trennt sich recht schnell die Spreu vom Weizen, wenn man nach
plattformübergreifenden Lösungen sucht. Auf den gesamten Lifecycle sind nur wenige
Best-of-Breed-Lösungen spezialisiert.


Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Lampertz GmbH & Co. KG

Matchmaker+