Deutsche Post World Net

Der Markt für Software-Verteilsysteme ist riesig und unübersichtlich. Die Kurzvorstellung einiger interessanter Lösungen kann erste Anhaltspunkte bei der Auswahl des richtigen Systems bieten. Die fünf hier vorgestellten Kandidaten richten sich an verschiedene Zielgruppen.

Niemand wird bestreiten, dass automatisierte Softwareverteilung ab einer gewissen Anzahl von Clients im Netz absolut nötig ist. Und Umgebungen mit 40000 Clients sind in der wirklichen Welt keine Seltenheit: Der typische Anwendungsfall ist der mit einer hohen Anzahl von Desktop-Rechnern mit nahezu identischer Software-Ausstattung. Aber auch für Server – man denke nur an Serverfarmen – und selbst für komplizierte, stark heterogene Netze kann sich Softwaremanagement lohnen.

Die Anforderungen sind jedoch grundverschieden. Hersteller wie etwa Asdiris[1] bieten deshalb unterschiedliche Produkte an. Die Auswahl des richtigen Systems zählt zu den kompliziertesten und außerdem folgenreichsten Entscheidungen, die überhaupt in der IT-Welt möglich sind. Wer hier danebengreift, muss jahrelang leiden.

Softwaremanagement wird nämlich früher oder später tief mit den Prozessen eines Unternehmens vernetzt sein, ob strategisch geplant oder nicht. Hakeligkeiten und Bugs sind auch und gerade bei etablierten Rundumlösungen nicht selten und sie greifen auf die Abläufe in der Firma durch und sorgen für immer wiederkehrenden Frust bei den Administratoren und erschüttern das Vertrauen in die IT beim Anwender.

Komplexe Szenarien

Typische Probleme bei sehr vielen (homogenen) Clients sind der Aufbau und die Wartung der Verteilserver an mehreren Standorten und vor allem die Steuerung der Netz- und Serverlast. Multicast-Verfahren sollten hier zwar Abhilfe bringen, aber oft versprechen die Hersteller mehr als sie halten. Außerdem muss die Hardware, Router und Switches, neu konfiguriert werden.

Beim Softwaremanagement für Server steht hingegen vor allem der unterbrechungsfreie Betrieb bei Updates im Vordergrund, hier ist Cleverness beim Starten und Stoppen voneinander abhängiger Services gefragt. Bei Softwareverteilung in heterogenen Umgebungen mit stark divergierenden Nutzungsprofilen wird hingegen oft die Vielzahl der Möglichkeiten zum Problem.

Venus für heterogene Systeme

Venus des Tübinger Unternehmens Science und Computing ist eine Software zur automatisierten Systemverwaltung speziell für heterogene Umgebungen. Softwaremanagement ist ein zentraler Bestandteil des Gesamtsystems.

Die Ursprünge von Venus liegen mehr als zehn Jahre zurück. Es begann als Sammlung von Skripten, um bestimmte, immer wiederkehrende Administrationsaufgaben zu erledigen. Mittlerweile sind die anfänglichen Schwächen der Skriptlösung beseitigt, es entstand eine Architektur, die aus einem Framework als Basis und fünf einzelnen Modulen besteht, die darauf aufsetzen und unabhängig voneinander zu betreiben sind. Neben der Softwareverwaltung gibt es Module für die Benutzer- und Systemverwaltung, basierend auf NIS, NFS und Automount, sowie Module für Monitoring, Inventarisierung und das Konfigurationsmanagement.

Die Bedienung folgt einem einheitlichen Konzept. Traditionell kommen spezielle Befehle an der Kommandozeile zum Einsatz, die jetzt aktuelle Version 2.0.1 besitzt aber auch eine Java-basierte, Browser-fähige Oberfläche, mit der der größte Teil anstehender Verwaltungsaufgaben erledigt werden kann. Venus hat seinen Einsatzschwerpunkt bei den Netzen für Entwicklungsabteilungen in der Automobilindustrie und anderen Industriezweigen mit hohem Aufwand für Forschung und Entwicklung sowie Forschungseinrichtungen. Es findet seinen Weg aber zunehmend auch in weniger technische Umgebungen.

In heterogenen Welten mit stark unterschiedlichen Nutzungsprofilen treten zwei orthogonale Umgebungs-Kategorien auf: einerseits Architektur-spezifische Konfigurationen, die etwa bei Linux anders sind als bei AIX oder Windows NT, andererseits Site-abhängige Daten, die sich beispielsweise von Abteilung zu Abteilung unterscheiden.

Ein grundlegendes Konzept von Venus besteht darin, diese beiden Kategorien zu trennen. So sind systemnahe Methoden in der Regel Architektur-spezifisch, aber Site-unabhängig. Den Site-abhängigen Teil der Konfiguration legt der Kontext der jeweiligen Methode fest. Es gibt also Kontext-Variablen, auf die verschiedene Methoden zugreifen. Die Trennung in Site- und Architektur-spezifische Variablen lässt sich jedoch nicht immer sauber vollziehen.

Ein weiteres Venus-Prinzip ist, dass eine zentrale Systemarchitektur immer nur als Sonderfall der dezentralen verstanden wird. Daraus folgt, dass es auch beim Softwaremanagement keinen grundlegenden Unterschied macht, ob es im Netz nur einen Server gibt, der die Software vorhält – Depotserver genannt – oder ob in manchen Abteilungen ein weiterer Depotserver steht.

Der Hersteller hat für Venus ein eigenes Paketformat entwickelt, das zusätzlich zu den Programmen die Parameter für die Installation enthält, daneben Skripte, die bei der Installation oder Deinstallation ausgeführt werden, Informationen zur Software selbst, Voreinstellungen der Software und so genannte Requirements. Das sind jene Anforderungen, die die Software an das Client-System hat, auf dem es installiert werden soll.

Was der Client zu bieten hat, steht für jeden Venus-Client in den Provides, einer speziellen Datei. Das System muss somit nur noch überprüfen, ob sich Requirements und Provides decken. Zusätzlich ist es möglich, Skripte zum Paket hinzuzufügen, um weitere Voraussetzungen zu überprüfen und den Installationsprozess davon abhängig zu machen.

Abbildung 1: Die Ursprünge von Venus sind kommadozeilenorientiert. Ab Version 2.0 hat die Software aber auch ein zeitgemäßes GUI.

Zentrale Architektur als Grenzfall

Es ist möglich, auch andere, Architektur-abhängige Pakete zu installieren, für Linux beispielsweise RPM- oder Deb-Pakete. Hier obliegt es jedoch dem Administrator, die Installationsbefehle in entsprechende Venus-Methoden zu packen, die darüber hinaus sicherstellen, dass der Venus-Client von den Änderungen am Systemzustand erfährt. Besonders kritisch wird dies, wenn Pakete versuchen, Abhängigkeiten, etwa von Bibliotheken, aufzulösen.

Das Venus-Paketformat selbst geht diesen Problemen aus dem Weg, indem es keine Abhängigkeiten auflöst. Das heißt natürlich, dass hier der Softwarehersteller gefordert ist, alle erforderlichen Bibliotheken mitzubringen oder falls erforderlich sogar statisch zu linken. Wenn nicht, muss entweder schon der Hersteller oder dann der Administrator dafür sorgen, dass es keine Konflikte mit unterschiedlichen Versionen dynamisch geladener Bibliotheken gibt.

Das Erstellen eines Venus-Softwarepakets ist ein vergleichsweise aufwändiger Vorgang. Der Administrator benötigt dazu ein Referenzsystem, das dem späteren Client-System entsprechen sollte. Dort führt er alle Schritte lokal durch, die zur Installation der jeweiligen Software notwendig sind.

Lizenziert wird Venus pro verwaltetem Client. Die Lizenzkosten beginnen bei etwa 80 Euro pro Client.

SC Venus
Hersteller: Science+Computing AG Tübingen Infos: [http://www.science-computing.de/products/scvenus.html] Schwerpunkt: Management technischer Workstations und Server Systeme: Linux, diverse Unixe, MS-Windows Open Source: nein Preis: 80 bis 700 Euro pro Client (Dauerlizenz)

Powercockpit 2.0 für Server

Im März hat die kalifornische Firma Mountain View Data von Turbolinux deren Produkt Powercockpit übernommen. Die Gründer von Mountain View sind auch im alten Haus gute Bekannte: Iris und Cliff Miller, die einstigen Gründer von Turbolinux.

Obwohl Mountain View Data vozugsweise im Bereich Storage unterwegs ist, bewirbt der neue Besitzer das Softwaremanagement-Werkzeug Powercockpit recht offensiv. Seiner Herkunft entsprechend ist es vor allem für die Administration von Servern und Serverfarmen in weniger komplexen beziehungsweise eher homogenen Umgebungen geeignet. Turbolinux hatte nämlich einige Zeit lang versucht, sich als Cluster-Spezialist zu profilieren, hier liegen auch die Wurzeln von Powercockpit, das mittlerweile in Version 2.0 vorliegt.

Die Software arbeitet nach einem einfachen Prinzip. Sie sammelt Images von funktionierenden Servern im Netz, verwaltet diese Sammlung und sorgt dafür, dass die Images – mit eventuell erforderlichen Anpassungen – schnell auf andere Rechner gespielt werden können. Das ist ideal für Serverfarmen mit identischer oder ähnlicher Hardware und vergleichbarem Aufgabenspektrum. Die Images liegen entweder als Tar-Files oder direkte »dd«-Kopien vor. Die Installation auf einem neuen Knoten erfolgt in mehreren Schritten.

Das System bootet über Floppy oder Netz (PXE), wobei bereits ein Powercockpit-Client installiert wird. Der nimmt Kontakt zum Server auf und lädt die Administrationsdaten in eine RAM-Disk. Danach wechselt er in den Administrations-Modus, greift auf das entsprechende Imagefile zu, das auf dem Cockpit-Administrations-Server liegt, und installiert es. Anschließend startet der neue Knoten einen Konfigurationslauf für die frisch installierte Software. Die Parameter für diese Konfiguration hat der Administrator über ein grafisches Nutzer-Interface vorher festgelegt.

Fernsteuerung inklusive

Dieses Interface bietet auch zahlreiche Features, die über das bloße Softwaremanagement hinausgehen. So ist es möglich, Shell-Kommandos gleichzeitig auf einer beliebigen Auswahl von Knoten abzusetzen und beispielsweise auch deren Ergebnis zu vergleichen, Dateien gleichzeitig an mehrere Knoten zu schicken oder RPMs dort zu installieren. Filetransport und RPM-Installation lassen sich auch kombinieren. Zusätzlich zum GUI, das übrigens in GTK+ realisiert ist, ist es auch möglich, das System in Perl zu skripten.

Mit Perl greift der Administrator auf die gleiche Objektstruktur zu, die auch die grafische Oberfläche nutzt, die Oberfläche führt nicht die Skripte aus wie bei Venus, sondern Skripting-Interface und GUI sind gleichberechtigt. Skripte können auch durch Ereignisse gesteuert, also getriggert werden. Bestimmte Aktionen werden dann automatisch ausgeführt, wenn etwa ein neuer Rechner hinzukommt, ein Deployment abgeschlossen ist, die Netzwerkverbindung ausfällt oder Ähnliches.

Powercockpit 2.0
Hersteller: Mountain View Data Infos: [http://mountainviewdata.com] Verwendung: Server, Serverfarmen, zusätzliche Fernwartungs-Möglichkeiten Preis: auf Anfrage

Unicenter von Computer Associates

Bei Computer Associates (CA) ist das Softwaremanagement in der Produktfamilie Unicenter angesiedelt. CA betreibt eine etwas andere Produktpolitik als beispielsweise IBM mit Tivoli. Ein separates Framework, auf dem die einzelnen Produkte aufsetzen, muss der Kunde vorher nicht installieren (und damit auch nicht lizenzieren). Stattdessen bringt jedes Produkt – hier also Software Delivery – alles an Common Services mit, was es zum Betrieb braucht. Entscheidet sich der Kunde später für weitere CA-Produkte, nutzen diese die Common Services der schon vorhandenen Software natürlich mit.

Unicenter Software Delivery liegt derzeit in Version 3.1 vor, Version 4.0 wurde im März angekündigt, die Auslieferung beginnt aber erst jetzt. Software Delivery folgt einem mehrstufigen Client-Server-Prinzip, der zentrale Server für die Auslieferung wird Local Server genannt. Davon muss in einem Netzwerk mindestens einer vorhanden sein.

Werden verschiedene Standorte bedient, können dort Staging Server mit Proxy-Funktionalitäten zum Einsatz kommen. Bei ganz großen Systemen ist oft auch der Einsatz eines Enterprise Servers sinnvoll, der in der Hierarchie über dem Local Server angesiedelt ist. Clients oder Gruppen von Clients können innerhalb dieser Hierarchie jedoch beliebig zugeordnet werden.

Keine Framework-Lizenz erforderlich

Auch die Zuordnung von Clients in Gruppen gestaltet sich sehr flexibel. So lassen sich sowohl einzelne Rechner als auch einzelne Nutzer Gruppen zuordnen. Letzteres ist bei wechselnden Arbeitsplätzen sinnvoll oder wenn ein Nutzer an mehreren Clients arbeitet. Gruppen können wiederum Untergruppen enthalten. Sie lassen sich auch anhand von Abfragen aus der Datenbank direkt bilden. Hierfür ist besonders interessant, dass Unicenter Software Delivery bereits rudimentäre Möglichkeiten für die Inventarisierung enthält und somit die Datenbank mit Informationen über die Clients füttern kann.

So fragt es beispielsweise Hardware-Attribute wie Prozessortyp oder Grafikkarte, aber auch die genaue Bezeichnung des Betriebssystems ab. In den meisten Fällen kommt aber laut Aussage von CA zusätzlich eine Asset-Managementsoftware zum Einsatz. Eine ganz spezielle Form der Gruppen sind die Template Groups. Diese legen eine Policy fest, nach der ein Client auf einem bestimmten Level der Software-Ausstattung gehalten werden kann.

Skripte auf Client und Server

Laut Computer Associates ist Unicenter zum Softwaremanagement sowohl für Desktop-Clients und Handhelds geeignet, als auch für Serverumgebungen. Mit Client-seitigen Skripten kann der Administrator genauer festlegen, was bei der Installation oder dem Update einer Software genau passieren soll. Bei Servern können etwa ein Daemon definiert gestoppt und mit dem neu eingespielten Binary wieder gestartet und Abhängigkeiten einzelner Serverdienste untereinander aufgelöst werden und so weiter. Die Client-seitige Skriptsprache ist eine Eigenentwicklung von CA und entspricht in Syntax und Umfang etwa einem Basic-Dialekt.

Der Administrator hat zur Steuerung des Softwaremanagements drei verschiedene Interfaces zur Verfügung. Am komfortabelsten ist ein natives Konsolen-Interface unter MS-Windows, das allerdings Managementserver auch unter anderen Systemen steuert, außerdem gibt es eine Browser-basierte Managementsoftware mit Client-seitigem Java und eine Kommandozeilen-Schnittstelle. Diese ermöglicht das Server-seitige Skripting mit beliebigen Sprachen. Unicenter Software Delivery benötigt zur Verwaltung eine relationale Datenbank. CA unterstützt hier nur den SQL-Server von Microsoft und das betagte hauseigene RDBMS Ingres, das aber auf vielen Plattformen, auch auf Linux, zur Verfügung steht.

Unicenter Software Delivery
Hersteller: Computer Associates Info: [http://www.cai.com/unicenter] Verwendung: Desktop-Clients, universell Open Source: nein Preis: auf Anfrage

Tivoli Software Delivery

Bei IBM ist Tivoli das Synonym für Systemmanagement. Tivoli ist sowohl ein Framenwork als auch eine Kollektion von Anwendungen, die darauf aufsetzen. Sie enthalten das komplette Universum des Systemmanagements. Softwaremanagement und Inventarisierung sind ab der aktuellen Version 4.2 unter dem Oberbegriff Configuration Manager zusammengefasst.

Voraussetzung für dessen Einsatz ist das Vorhandensein des Tivoli Management Frameworks (TMF). Es enthält einen Service zur Softwareverteilung namens MDist2. Das Framework ist Corba-basiert, seine Clients, die Tivoli Management Agents (TMAs), müssen auf jedem verwalteten System installiert sein. Auf ihnen kann dann wiederum spezielle Client-Software aufsetzen, beispielsweise der Tivoli Desktop oder das Software-Verteilungstool Pristine.

Das Softwaremanagement von Tivoli versteht sich ebenso wie das von CA Unicenter als Rundum-Lösung für Computer aller Art, vom Datenbankserver bis zum Handheld. Selbst der Nokia Communicator erfährt als Endpunkt offizielle Unterstützung von IBM.

Linux-Pakete inklusive

Version 4.2 ist die erste, die Linux sowohl als Client als auch als Server nahezu komplett unterstützt, vorzugsweise jedoch etwas ältere Versionen von SuSE (bis 7.1), Red Hat und Turbolinux. Als Managementkonsole für den Server ist jedoch ein MS-Windows-Rechner empfehlenswert, für den Software Package Editor sogar erforderlich. Tivoli kennt drei verschiedene Arten von eigenen Paketformaten, unterstützt jedoch auch viele Paketformate potenzieller Zielsysteme, für Linux jedoch nur RPM und nicht das Deb-Format von Debian. Bei der Unterstützung dieser nativen Paketformate geht Tivoli jedoch weiter als viele andere Systeme.

Sie können nicht nur wie etwa bei Venus in das eigene Format umverpackt werden, sondern sind soweit wie möglich eigenständiger Teil des Gesamtsystems. Beispielsweise ist ein Interface für das »rpm«-Kommando in das Management-GUI eingearbeitet. Ebenso scannt das Inventory-Subsystem vorhandene RPM-Datenbanken von Linux-Rechnern im Netz, wenn es ein Verzeichnis vorhandener Software anlegt. Tivoli-Experten empfehlen aufgrund dieser engen Integration, möglichst die nativen Paketformate der Betriebssysteme zur Softwareverteilung zu nutzen.

Neuerungen in Version 4.2 sind die Integration mit Directory-Diensten, unter anderem auch mit OpenLDAP, und eine Multicast-Option bei der Verteilung, die laut IBM-Angaben ein 20 MByte großes Softwarepaket bei einer Bandbreite von 500 KByte pro Sekunde in 40 Sekunden an 300 Clients verteilen kann. Ein herkömmlicher Mechanismus (Unicast) müsste dafür über drei Stunden laufen. Von IBM derzeit stark propagiert wird der zusätzliche Einsatz eines Web-Gateways, das ein Softwaredepot vorhält, von dem sich der User mittels Pull die für ihn bestimmten Teile lädt. Dazu ist zusätzlich IBM Websphere nötig.

Tivoli Configuration Manager
Hersteller: IBM Info: [http://www.ibm.com/tivoli] Verwendung: Desktop-Clients, Server Preis: auf Anfrage

Red Hat Enterprise Network

Red Hats Antwort auf zum Teil schon seit Jahrzehnten vorhandene (teure) Softwaremanagement-Systeme heißt Red Hat Enterprise Network (RHEN). Red Hat versucht damit, genau wie beispielsweise mit Contentmanagement-Systemen und anderen Angeboten, von seinem Image als reiner Linux-Anbieter loszukommen. RHEN ist eine Erweiterung des bekannten Red Hat Network (RHN). Beide beruhen auf dem Channel-Prinzip. Der Nutzer abonniert also bestimmte Softwaregruppen seiner Wahl und holt die Pakete per Pull ab.

Über ein Webinterface ist die Fernbedienung des eigenen Servers möglich. RHEN erlaubt das Zusammenfassen von Clients zu Gruppen. Dies muss jedoch manuell über eine Auswahlmaske erfolgen. Bei mehreren tausend Clients ist das keine leichte Aufgabe. Der größte Nachteil des Programms: Es ist nur für das Softwaremanagement von Red-Hat-Clients zu gebrauchen. Firmennetze, die nur aus Red-Hat-Computern bestehen, sind aber eher die Ausnahme. Zumindest für Windows-Rechner wäre dann ein separates Produkt nötig, was natürlich die Komplexität erhöht.

Für die Softwareverteilung im Unternehmen ist nicht die kostengünstige Basisversion RHN geeignet, sondern RHEN Enterprise, das aus einer Vielzahl von Komponenten besteht. Der Client ist jedoch der Gleiche wie beim normalen RHN. Dieser ist freie Software. Deshalb wäre es möglich, ihn selbst an andere Systeme anzupassen oder anpassen zu lassen. Im Vergleich zum Programmieraufwand, der ohnehin oft bei Softwareverteilungs-Systemen betrieben wird, wohl sogar eine realistische Option.

Abbildung 2: Das Red Hat Enterprise Network beruht auf einem Channel-Prinzip. Nach und nach integriert Red Hat hier Drittanbieter wie BEA.

Channel auch für Drittanbieter

Wer von Red Hat oder seinen Partnern (derzeit etwa BEA) bereitgestellte Software installieren muss, braucht nur die Clients und eine Internetverbindung. Zur Verteilung eigener Pakete gibt es zwei Möglichkeiten: Ein Proxy-Server wäre der einfachste Weg. Dieser fungiert in erster Linie als Depot für Red Hat und Drittanbieter, erlaubt aber auch die Verteilung eigener Daten. Dabei ist der Proxy-Server jedoch in die zentrale RHN-Struktur eingebunden und schickt beispielsweise die Header-Daten der RPMs an Red Hat, auch wenn es die eigenen sind. Vor allem dann, wenn im Unternehmen nicht nur Software, sondern zunehmend auch Dokumente, Preislisten für den Vertrieb zum Beispiel, über diese Infrastruktur verteilt werden, ist das nicht unbedingt eine vertrauensbildende Maßnahme.

Wer das nicht will, braucht den RHEN Satellite Server, muss aber tiefer in die Tasche greifen und wesentlich mehr Aufwand treiben. Der Satellite Server arbeitet unabhängig vom RHN, braucht dazu aber eine Oracle-Datenbank, die zwingend auf einem separaten System installiert sein muss. Der Hersteller empfiehlt, den Satellite Server vom Red-Hat-Support installieren zu lassen. Satellite Server kostet 27000 Dollar pro Jahr, die Installation ist inbegriffen. Der Proxy kostet 12000 Dollar pro Jahr.

Red Hat Enterprise Network
Hersteller: Red Hat Infos: [http://www.redhat.com] Verwendung: Clients und Server, standardmäßig nur Red-Hat-Systeme Open Source: nur Client Preis: Client-Lizenz null bis 95 US-Dollar, Proxy-Server 12000 US-Dollar pro Jahr, Satellite-Server 27000 US-Dollar pro Jahr

Fazit

Schon die hier vorgestellte kleine Auswahl an Programmen zeigt, wie vielfältig die Welt der Softwareverteilung ist. Die Praxis zeigt erst recht, dass ein System von der Stange den Anforderungen der meisten Admins ohne weitgehende Anpassungen kaum gerecht werden kann. Daher sind jene Systeme im Vorteil, die diese Anpassungen besonders leicht machen. Die gängigen Paketformate unter Linux und die Unix-Philosophie der einzelnen kleinen Werkzeuge können sowohl bei der komplett selbst gestrickten Softwareverteilung als auch bei der Anpassung von Komplettsystemen nützlich sein.

In naher Zukunft ist auch von der Open-Source-Gemeinde noch einiges zu erwarten. Inwieweit es beispielsweise Ximian gelingt, Red Carpet[3] distributionsübergreifend zu einer Art Standard zu machen, muss noch offen bleiben, wird bald bald zum Thema in einem späteren Linux-Magazin.