Zu den Grundproblemen beim Software-Management gehören Softwarelagerung und -konfektionierung. Der Softwarevorrat wird von einem zentralen oder auch von mehreren, meistens hierarchisch im Netz angeordneten Systemen verwaltet (Depot oder Subdepot). Sie administrieren zudem physikalische Datei-Teilbäume, die lokal auf den Festplatten, auf ausgelagerten Datei-Teilsystemen (Mounted-File-Systeme, File-Server) oder auch auf archivierten Bändern und CDs liegen. Ein zentrales Depot ist normalerweise auf der gleichen Maschine angesiedelt, auf der auch das Manager-System läuft.

Das Paketieren und Einbringen von Softwareprodukten ins Depot kann bei allen Lösungen zentral erfolgen. Bei einigen ist dies auch "weiter unten", in den Subdepots, wo das jeweilige Programm benötigt wird, möglich.

Zur Belieferung der PCs mit Anwendungen wird meist von den bekannten Netzwerk-Betriebssystemen wie LAN Manager, Advanced Server for Unix, Windows NT Server, Netware, PC-NFS etc. Gebrauch gemacht. Das bedeutet, daß sich ein Depot oder Subdepot durch Shared Resources bildet und das Versorgen der angeschlossenen Zielsysteme direkt über die Mechanismen des jeweiligen Netzwerk-Betriebssystems erfolgt - nicht etwa über einen separaten File-Transfer, wie bei Unix-Plattformen üblich

Ein komplettes Softwareprodukt besteht in der Regel aus vielen Dateien, eignet sich für unterschiedliche Plattformen und existiert in mehreren Versionen. Aufgrund dieser undurchschaubaren Fülle hat sich ein besonderes Verfahren etabliert. Für das Handling mit Softwareprodukten und die Verteilung der Programme greift das Verwaltungswerkzeug nicht auf einzelne Dateien zu, sondern verwendet größere Dateneinheiten, umgangssprachlich als Paket bezeichnet.

Ein Paket korrespondiert normalerweise mit einem Produkt einer bestimmten Version für eine bestimmte Klasse von Systemen. Es gibt heute die unterschiedlichsten, teilweise proprietären Formate dafür. Als De-facto-Standard hat sich das PKG-Format von AT&T durchgesetzt, das auch von den meisten Unix-basierten Lösungen unterstützt wird. Allerdings wird dem Standard Posix 1003.7.2 (Portable Operating System Interface for Unix) für die Zukunft eine gewisse Bedeutung zugesprochen. Natürlich lassen sich die Pakete auch platzsparend in komprimierter Form deponieren.

Bei PC-Software ist der Begriff Paket unüblich, da hier Produkte durch einen Dateibaum dargestellt werden - ohne jegliche weitere Verpackung. Oft finden sich auch komprimierte "Executable Files", deren Ausführung zur Dekomprimierung der Programme führt. Eine strenge Trennung der Systemwelten existiert nicht, so verwalten Unix-orientierte Ma- nagement-Werkzeuge auch PC-Produkte. Diese werden dann ebenfalls als Pakete im Depot eingelagert, von dort aus mit den Unix-Mechanismen verteilt und erst kurz vor ihrer Installation entpackt.

Das Versenden der Software

Eine Depothierarchie - manchmal auch als kaskadierte Depots bezeichnet - ist für größere Umgebungen, insbesondere für Weitverkehrsnetze (WANs), besonders vorteilhaft, denn so braucht ein Paket nur einmal an ein entferntes (hierarchisch untergeordnetes) Depot übertragen zu werden. Von dort aus lassen sich dann wieder viele der dort angeschlossenen Systeme beziehungsweise weitere Depots verwalten und mit Software versorgen. Dieses Verfahren ist effizient und spart erheblich Leitungskosten.

Um eine bestehende Infrastruktur gut nutzen zu können, sind Subdepot-Lösungen meist auf mehreren Systemplattformen lauffähig. Entscheidend für die Benutzerfreundlichkeit eines Verfahrens mit kaskadierbaren Depots ist, daß sich der komplette Weg - vom Manager-System mit dem zentralen Depot über die dazwischenliegenden Subdepots bis hin zum Zielsystem - verwalten läßt und der Administrator von der Aufgabe entlastet wird, erstellte Aufträge zu kontrollieren.

Management-Tools nutzten zur Kommunikation die gängigen Protokolle für Transportschicht, File-Transfer und File-Server. Alle Produkte nutzen dabei den TCP/IP-Standard. Vorteilhaft im Hinblick auf die meist bunte Mischung an Übertragungsverfahren in den Unternehmen wäre, wenn die Lösungen auch wichtige proprietäre Protokolle unterstützten.

Neben der Möglichkeit der Datenkompression besteht bei der Übertragung von Software-Updates ein erhebliches Optimierungspotential durch Versionsdifferenzbildung: Dabei werden nur die Dateien übertragen, die sich, verglichen mit der Vorgängerversion, auch tatsächlich verändert haben.

Ein weiterer Pluspunkt dieses Verfahrens ist, daß bei einem Übertragungsfehler nicht das ganze Paket noch einmal übertragen werden muß, sondern der Versand an einem definierten Punkt fortgesetzt werden kann. Diese Fehlertoleranz implementieren meistens die File-Transfer-Protokolle. Netzwerk-Betriebssysteme leisten hier in der Regel wenig.

Die Adressierung der Zielsysteme

Es gibt zwei grundsätzliche Verfahren bei der Softwareverteilung:

- Push: Bei dieser Vorgehensweise wird zentral festgelegt, welche Systeme welche Software wann bekommen. Sie eignet sich für Programme und Daten, die nicht in der Verantwortung des Users liegen.

- Pull: Hier bestimmt der Benutzer, welches Softwareprodukt er beziehen will, und teilt seine Anforderung dem Management-System via PC mit. Das Pull-Verfahren wird meist nur als zusätzliche Möglichkeit angeboten.

Fast alle Systeme unterstützen die Push-Variante, weil sich damit am ehesten eine netzweite Konsistenz der verteilten Software sicherstellen läßt. So kann ein Ver- sions-Update eines Servers im Netz erfordern, daß auch alle Clients ein entsprechendes Update bekommen.

Ein bedeutendes Unterscheidungsmerkmal von Software-Management-Produkten liegt in den Möglichkeiten der Adressierung der Empfänger. Für einen Verteilauftrag können entweder einzelne Zielsysteme aufgelistet werden, oder man benutzt vordefinierte Zielsystemgruppen, wobei die Gruppenbildung nach den unterschiedlichsten Kriterien erfolgen kann. Mängel zeigen hier Win- dows-orientierte Werkzeuge. Dort lassen sich die Zielsysteme zwar durch formale Ausdrücke (mit Wildcards etc.) selektieren, eine Garantie dafür, daß das Softwareprodukt anschließend auch tatsächlich auf den einzelnen Zielsystemen installierbar und lauffähig ist, gibt es jedoch nicht.

Nur wenige Management-Systeme unterstützen auch die Installation eines (Netz-)Betriebssystems. Diese Aufgabe erfordert beim Zielsystem ein Minimalprogramm, das in einem PROM, auf einer Diskette etc. liegen kann.

Es läßt sich nicht immer vermeiden, daß Installationsversuche fehlschlagen. Die häufigste Fehlerquelle ist dabei das Installationsscript. Selbst beim Software-Management von Zielsystemen gleichen Typs hat man es oft mit etlichen unterschiedlichen Hard- und Software-Ausprägungen zu tun, so daß häufig per Script Einzelfälle für die Installation definiert werden müssen.

Theoretisch müßte in einem solchen Fall jede vorkommende Zielsystemkonfiguration getestet werden, was meist nicht möglich ist. Daher verzichten die Administratoren auf eine absolute Sicherheit und konzentrieren sich auf die Verteilung weniger wichtiger Produkte.

Damit Softwareverteilung nicht zum Abenteuer wird, muß unbedingt sichergestellt sein, daß sich der vorherige Zustand durch ein sogenanntes Rollback-Verfahren leicht wiederherstellen läßt. Manche Produkte bieten diese Option standardmäßig, bei anderen läßt sie sich jedoch nur durch ein entsprechendes Script realisieren.

Angeklickt

Es existieren bereits etliche Produkte für Software-Management. Dieser Artikel arbeitet heraus, auf welche Eigenschaften und Funktionalitäten es bei der Softwareverteilung vor allem ankommt. Nachdem im ersten Teil allgemeine Management-Aspekte behandelt wurden, geht es in Teil 2 um die konkreten Verfahren zur Verteilung und Installation von Softwareprodukten.

*Karl-Heinz Samson ist Spezialist für Software-Management bei der Siemens-Nixdorf Informationssysteme AG in Paderborn.