Leitfaden zur Einführung einer automatisierten Softwareverteilung

Page 6

Leitfaden zur Einführung einer automatisierten Softwareverteilung

I. Abkürzungsverzeichnis

CAD Computer Aided Design - Computerunterstütze Konstruktion CPU Central Processing Unit - Zentraleinheit DFÜ Datenfernübertragung DHCP Dynamic Host Configuration Protocol - Dienst zur automatischen Zuweisung von IP-Adressen DVD Digital Vrsatile Disc - “vielseitige digitale Scheibe“, Medium

EDV elektronische Datenverarbeitung GUI Graphical User Interface - Grafische Benutzerschnittstelle bzw. -oberfläche IP Internet Protokol - Internetprotokoll IT Informationstechnologie

Local Area Network - lokales Netzwerk ¹ LAN MSI Microsoft Installer

Multiple Virtual Storage - Großrechner-Betriebssystem von IBM ^® MVS

New Technology Kernel ^* NT

Red Hat ^® Package Manager - Installationspakete für Linux RPM SV Softwareverteilung TCP Transmission Control Protokol - Übertragungskontrollprotokoll TCP/IP Transmission Control Protokol/Internet Protokol (siehe TCP und IP)

Universal Serial Bus - Universeller serieller Bus, eine von Intel ^® USB

entwickelte Harwareschnittstelle Wide Area Network - Weitverkehrsnetz ² WAN

¹ siehe [Rie01] S. 106

^* Windows Systeme mit 32-Bit Kern

² siehe [Rie01] S. 106

Page 9

Leitfaden zur Einführung einer automatisierten Softwareverteilung

1 Einleitung und Motivation

Unternehmen, deren EDV-Landschaft sich ausweitet und die mehr und mehr die Computertechnologie nutzen, stehen irgendwann vor der Aufgabe, diese Computersysteme effizient d.h. mit geringem manuellen Aufwand verwalten zu können. Hierzu haben sich am Markt einige Standardlösungen etabliert; man spricht von Systems Management Software. Hierzu hört auch die Verteilung von Software.

Denn das von Hand Bespielen und Updaten von Computern stellt sich als eine zeit- und somit kostenaufwendige Aufgabe dar; viele Rechner müssen quasi mit denselben Softwarekomponenten versorgt werden, also eine sich mehrmals in gleicher Weise wiederholende Tätigkeit. Hinzu kommt, dass oftmals die Geräte über mehrere Standorte verteilt sind; der Standortwechsel des EDV-Personals stellt dann einen weiteren Zeit- und Kostenfaktor dar.

Wenn eine gewisse Anzahl von Computern im Unternehmen eingesetzt wird, entsteht somit die Notwendigkeit, diese automatisiert mit Software zu versorgen. Sowohl die Erstversorgung mit dem Betriebssystem, mit Systemsoftware und Anwendungen als auch das spätere Aktualisieren der Software durch Fixe (Fehlerkorrekturen) und Updates soll automatisiert erfolgen, ohne großen manuellen Aufwand des EDV-Personals. Auch soll im Falle eines Ausfalls eines Computersystems schnell und ohne allzu großen Aufwand ein Ersatzrechner bespielt werden können, der bestenfalls über die gleiche Betriebssystem-Installation und identische Anwendungsprogramme verfügt. Die Infrastruktur einer automatischen Softwareverteilung (kurz SV) spiegelt sich in einem verteilten System wider; es arbeiten Komponenten zusammen, die sich auf vernetzten Computern befinden und kommunizieren. ³ Diese werden in dieser Arbeit genannt und beschrieben.

Ziel der vorliegenden Arbeit ist es, allgemein aufzuzeigen, welche Systemkomponenten grundsätzlich notwendig oder optional sind, um eine automatische Softwareverteilung zu realisieren. Es werden Ansätze unterschiedlicher Konzeptionen erläutert. Es wird ein

³ [CouDolKin02] S. 17

Page 10

Leitfaden zur Einführung einer automatisierten Softwareverteilung

Leitfaden an die Hand gegeben, der hilft, die Anforderungen an eine SV zu definieren und Standardlösungen an diesen zu messen.

Ziel ist es nicht, die am Markt verfügbaren Standardprodukte zu untersuchen, gegeneinander abzuwägen oder in einem Unternehmen einzuführen. Dennoch ist eine Betrachtung einzelner Teilaspekte mitunter hilfreich, die Funktionen und Konzepte der automatisierten SV besser zu verstehen.

Aufgrund des sehr hohen Marktanteils an Computern mit Microsoft Windows Betriebssystemen wird stellenweise auf Eigenheiten und Besonderheiten in diesem Umfeld detaillierter hingewiesen. Dennoch gilt das hier konzeptionell Erarbeitete auch für andere Umfelder.

2 Wirtschaftlichkeit

Hauptziel beim Einsatz von Systems Management Software ist es, EDV-Systeme von zentraler Stelle aus effizient verwalten und gleichzeitig die Betriebskosten für Änderungs-und Konfigurations-Management zu senken.

Es gilt, die Kosten für das Systems Management durch eine entsprechende Lösung zu minimieren, die optimal in die jeweilige Umgebung passt.

Page 12

Leitfaden zur Einführung einer automatisierten Softwareverteilung

werden soll und was noch manuell getan wird. Je mehr und je öfter Computer zu verteilen sind, umso eher lohnt es sich, stärker in die Automatisierung zu investieren.

2.1 Kosten bei manueller Installation

Grundsätzlich lassen sich Kosten in Personal, Technologie- und Prozesskosten aufteilen. Personalkosten sind in der Vergangenheit gestiegen und werden dies vermutlich auch weiterhin tun. Technologie hingegen wird, wenn man gleiche Kapazität und keinen Technologiewechsel unterstellt, günstiger. Prozesskosten sind stark individuell, lassen sich aber durch Automation senken. 6

Bei einer manuellen Installation fallen „nur“ die Kosten für die Erstinstallation und Installation von Updates an. Diese bestehen nicht lediglich aus reinen Personalkosten, sondern auch Reisekosten etc. müssen ggf. mitberücksichtigt werden. Diese Kosten sind nahezu proportional zur Anzahl der Systeme; Einsparungen aufgrund einer großen Anzahl von Installationen sind sehr gering.

2.2 Kosten bei Einsatz einer Softwareverteilung

Die Anzahl der Kostenpunkte ist hier deutlich größer; im Wesentlichen sind diese: 1. Beschaffungs- oder Entwicklungskosten aller notwendigen Softwarekomponenten 2. in der Regel zusätzliche Hardware 3. Schulung 4. Implementierung des Systems 5. Wartung des Systems

6. Herstellung von verteilfähigen Paketen (Softwarekomponenten) 7. Verteilung der Pakete

Bei einer größeren Anzahl von Systemen fallen die nichtproportionalen Kosten 1 - 6 zunehmend weniger ins Gewicht verglichen mit den Gesamtkosten. Die proportionalen Kosten, nämlich die Verteilung der Pakete (Punkt 7) ist sehr viel kostengünstiger als das manuelle Bespielen eines Rechners. Im Hinblick auf die Gesamtkosten ergeben sich also Skalenerträge oder Kostendegressionseffekte.

⁶ [BITKOM04] S. 6

Page 13

Leitfaden zur Einführung einer automatisierten Softwareverteilung

Unter Kostengesichtspunkten ist natürlich anzustreben, dass die oben genannten Posten möglichst gering ausfallen. Dabei ist unter anderem darauf zu achten, dass die vorhandene teuere Hardware optimal genutzt werden kann und dass die Herstellung von verteilfähigen Paketen überschaubar ist und nicht ein benutzerunfreundliches und fehleranfälliges Unterfangen wird.

Wie bei allen größeren IT-Projekten ist eine ausführliche Kosten/Nutzen-Analyse unumgänglich. Hierbei wird das Vorhaben wirtschaftlich beurteilt. Und zwar werden dabei die Auswirkungen unter Berücksichtigung relevanter Nebenwirkungen während der Zeit der Einführung vorausschauend ermittelt und dann auf den Zeitpunkt des Nutzungsbeginns bezogen in Geldgrößen bewertet. 7

2.3 Nutzenaspekte

Beim Einsatz von Systems Management Lösungen, also auch bei einer automatisierten SV, stehen zwar Kostenaspekte im Vordergrund, aber auch die Vor- und Nachteile sind gegenüberzustellen. Die wichtigsten sollen folgend skizziert werden.

2.3.1 Vorteile

Einheitlicher Softwarestand: Werden Computersysteme automatisiert installiert, so besteht die Möglichkeit, Rechner auf einem definierten Stand zu halten. Man kann auf diese Weise vermeiden, dass ein “Wildwuchs“ entsteht. Auf allen Rechnern ist beispielsweise die gleiche Version eines Softwareproduktes installiert. Ferner kann man Konfigurationen gleichhalten, was bewirkt, dass sich die Systeme ähnlich verhalten. Beides ist bei manueller Installation nur sehr schwer und mit großem organisatorischem Aufwand zu realisieren, und dies umso stärker, je mehr Mitarbeiter mit diesen Aufgaben betraut sind.

Erreichbarkeit: Mit einer SV können sehr viele Systeme, die räumlich sehr weit auseinander stehen, innerhalb einer kurzen Zeitspanne durch wenig EDV-Personal mit Software verteilt werden. Als Beispiel mag hier eine Sparkasse oder Volksbank genannt werden, welche 1000 Systeme in einem Umkreis von 50 km betreibt. Es ist leicht

⁷ [HaNaBeBü97] S.. 490f

Page 14

Leitfaden zur Einführung einer automatisierten Softwareverteilung

einzusehen, dass diese nicht von Hand installiert bzw. aktualisiert werden können. Verbesserter interner Support: Interne Support-Anfragen entstehen oft durch defekte bzw. zerstörte Installationen oder Konfigurationen. Mit dem Einsatz einer SV ist es in der Regel möglich, schnell etwas nachzuverteilen, um den Fehler zu beseitigen. Zwar helfen Fernwartungs-Tools, mit denen man einen Rechner von der Ferne sehen und bedienen kann, beim Diagnostizieren, aber eine beschädigte Installation kann hiermit nur in seltenen Fällen oder nur mit sehr großem Aufwand korrigiert werden.

Benutzerfreundlichkeit: Für das EDV-Personal fallen deutlich weniger Routineaufgaben an. Neben den zeitlichen Aspekten ist dies auch vorteilhaft für die Motivation und Arbeitszufriedenheit der Mitarbeiter. 8

2.3.2 Nachteile

Die Vorteile einer SV müssen dem zu betreibenden Aufwand und den Kosten gegenübergestellt werden.

Eine automatisierte SV hat, wenn sie entsprechend den Bedürfnissen eingesetzt wird, keine besonderen Nachteile. Allerdings gelten die gleichen “Probleme“ wie bei jeder EDV-Lösung. Denn auch ein SV-System obliegt einem Lebenszyklus und muss gepflegt und in der Regel irgendwann abgelöst werden.

3 Anforderungskatalog einer Software-Verteilung

Dieser Abschnitt beschäftigt sich mit der Frage, was eine Implementierung für eine automatisierte SV leisten kann, soll oder muss. Einem Projektteam kann bei der Auswahl (oder Entwicklung) und Einführung eines Systems dieser Anforderungskatalog als Richtschnur dienen.

An dieser Stelle sei darauf hingewiesen, dass eine gewisse Standardisierung im Hinblick auf die eingesetzte Hard- und Software als Grundvoraussetzung für ein effizientes und kostengünstiges Systems Management angesehen werden kann.

⁸ vgl. [RoReDo99] S. 193-203

Page 15

Leitfaden zur Einführung einer automatisierten Softwareverteilung

3.1 Installation ohne Interaktion (unattended Installation)

Eine Installation via SV muss auch dann ablaufen, wenn niemand an dem Rechner angemeldet ist. Dies kann zum Beispiel dann notwendig sein, wenn der Rechner während der Installation (mehrmals) gebootet werden muss.

Auch darf es in der Regel nicht der Fall sein, dass die Installation auf Interaktionen des Benutzers wartet; alle Dialoge, die während einer herkömmlichen Installation stattfinden würden, müssen durch das EDV-Personal und die SV-Lösung automatisiert werden. Denn nur so ist sichergestellt, dass auf alle Installationsfragen die korrekten Antworten gefunden werden (z.B. wäre ein Sachbearbeiter nicht in der Lage, die Netzwerkanbindung zu konfigurieren). Dies wiederum ist eine wichtige Voraussetzung für eine korrekte und einheitliche oder bestimmten Regeln unterliegende Konfiguration der verteilten EDV-Systeme.

Damit eine SV ohne Interaktion des Benutzers durchgeführt werden kann, können die erforderlichen Informationen in einer Antwortdatei hinterlegt werden (Anhang B zeigt ein Beispiel einer Antwortdatei). Oder dem Installationsaufruf werden entsprechende Parameter mitgegeben (z.B. das Installationsverzeichnis).

Unattended Installation heißt also, dass die Installationsprozedur im Hintergrund abläuft, ohne dass der Benutzer aktiv werden muss oder bei seiner Arbeit eingeschränkt wird. Unattended Installation heißt aber nicht, dass Verteilungen ohne Informationen oder Einflussnahme der Benutzer ablaufen.

Wenn eine SV zur Arbeitszeit stattfinden würde ohne den Benutzer zu informieren, könnte dies unerwünschte Effekte mit sich bringen. Es ist leicht einsehbar, dass ein Computersystem nicht einfach selbstständig booten darf. Werden mehrere Verteilschritte gestartet, so mag es notwendig sein, den Rechner zwischen einzelnen Phasen zu booten. Ist dies der Fall, ist sicherzustellen, dass der Benutzer den Reboot unterdrücken beziehungsweise verzögern kann. Oder eine Verteilung ist aus irgendwelchen sonstigen Gründen zur Startzeit nicht erwünscht (z.B. wird mit dem System gerade eine Schulung oder Präsentation gehalten); auch dann sollte eine Verzögerung durch den Benutzer möglich sein.

Page 16

Leitfaden zur Einführung einer automatisierten Softwareverteilung

Wenn eine Installation nicht erfolgreich abgeschlossen werden kann, kann eine Meldung am Bildschirm ausgegeben werden. Der Benutzer weiß dann, dass der Rechner unter Umständen nicht in allen Bereichen ordnungsgemäß funktioniert. Ob eine solche Fehlermeldung angezeigt werden soll oder ob diese doch eher Verwirrung stiftet, liegt im Ermessen des EDV-Personals.

3.2 Individualisierbarkeit

Es dürfte in der Praxis nahezu unmöglich sein, mehrere Rechner genau identisch zu installieren und konfigurieren und diese dann in einem Netzwerk gemeinsam zu betreiben. Denn in aller Regel gibt es Unterschiede bei den Konfigurationswerten. Individualisierbarkeit bedeutet also in Verbindung mit einer SV-Lösung, dass man in der Lage ist, Rechner ganz gezielt unterschiedlich zu verteilen.

3.2.1 Maschinenspezifische Parameter

Eine komfortable und für ein großes Mengengerüst ausgelegte SV-Lösung ist in der Lage, maschinenspezifische Werte in die automatische SV einfließen zu lassen. Ziel dabei ist, nicht für jeden Rechner, der ein bestimmtes Software-Produkt erhalten soll, eine Antwort-Datei (hier sind in elektronischer Form alle für eine unattended SV benötigten Werte oder mit anderen Worten alle Antworten, die bei einer interaktiven Installation gegeben werden müssten, hinterlegt) individuell von Hand zu erstellen. Vielmehr ist zu realisieren, dass eine Antwortdatei aus allen relevanten Daten mit Hilfe einer Schablonendatei erzeugt und zur Installationszeit mitgegeben wird. Dies bedingt, dass alle maschinenspezifischen Werte, die für eine SV benötigt werden, in einer Datenbasis vorgehalten und gepflegt werden.

Folgende Tabelle zeigt ein Beispiel maschinenspezifischer Werte; eine solche Tabelle ist für jeden verteilbaren Rechner vorzuhalten:

Page 18

Leitfaden zur Einführung einer automatisierten Softwareverteilung

MSIEXEC.EXE /i v:\SV-Produkt-1\install.msi /l v:\LOG\SV-Produkt-1\%WORKSTATNAME%.log

computername = $Betriebssystem-Variable-1 workgroup = $Betriebssystem-Variable-2 Die grünen Werte sind Variablen. Das SV-System weiß den Namen des Gerätes und legt eine entsprechende Log-Datei an und die beiden Betriebssystem-Variablen werden aus der SV-Datenbank ermittelt und für die Verteilung eingesetzt.

Aus Gründen der Nachvollziehbarkeit empfiehlt es sich, festzuhalten, mit welchen Werten eine Verteilung stattgefunden hat. Denn die Werte mögen sich in der Datenbank ändern und es lässt sich dann nicht mehr nachvollziehen, wie eine Komponente verteilt wurde. Und dies kann später im Zuge von Support-Anfragen der Benutzer notwendig werden. Eine solche Datenbank ist dynamisch - auch im Hinblick auf die Variablen selbst und nicht nur ihrem Inhalt. Neue Anwendungen mögen per SV installierbar werden; diese mögen für eine unattended Installation Werte benötigen, die die Datenbasis nicht bereithält. Daher ist dafür zu sorgen - technisch oder organisatorisch - dass die Datenbasis gepflegt und bei Bedarf erweitert wird. Anmerkung:

Neben einer maschinenspezifischer ist auch eine benutzerspezifische Individualisierbarkeit realisierbar. Dies soll aber in dieser Arbeit nicht weiter vertieft werden.

3.2.2 Differenzierung in Funktionstypen

Ferner besteht die Möglichkeit, Rechner mit einer unterschiedlichen Konfiguration von Modulen aus einem Pool von verteilbaren Softwarekomponenten zu versehen. Ein Rechner in der Lagerverwaltung ist zum Beispiel mit anderen Komponenten zu bespielen als ein Rechner, der als CAD-Arbeitsplatz dient. Die folgende Tabelle soll dies veranschaulichen:

Page 19

Leitfaden zur Einführung einer automatisierten Softwareverteilung

3.3 Protokollierung und Nachvollziehbarkeit

3.3.1 Logging

Unter Logging ist quasi das Gegenstück zu einer Antwortdatei zu verstehen. Denn genauso wenig wie ein Benutzer bei einer unattended Installation Eingaben macht, genauso wenig werden am Bildschirm Ausgaben bezüglich der Verteilung an sich zur Kenntnis genommen. Die Ausgaben, die bei einer manuellen Installation am Bildschirm zu sehen sind, werden auch bei automatisierten Installationen festgehalten, allerdings meist in einem deutlich höheren Detailierungsgrad.

Um Fehler während der Verteilung oder später nicht ordnungsgemäß funktionierende Software recherchieren zu können, muss die Verteilung protokolliert werden. Dies wird dadurch erreicht, dass eine Log-Datei während der Installation geschrieben wird, die festhält, was während der Verteilung geschieht. Hierzu werden die Ergebnisse jedes Verteilschrittes in die Log-Datei geschrieben. Dabei kann man unterscheiden zwischen Einträgen, die informativen Charakter haben, solchen, die eine Warnung ausgeben und solchen, die Fehler protokollieren. Es folgen einige Beispiele für Log-Datei-Einträge:

Page 20

Leitfaden zur Einführung einer automatisierten Softwareverteilung

Mit Hilfe dieser Informationen ist es oftmals möglich, schnell Ursachen für Verteilfehler oder -abbrüche zu finden. Aber auch wenn eine SV an sich ordnungsgemäß abläuft, mag es sein, dass sich das Computersystem oder eine Anwendung anschließend nicht so verhält, wie es gewünscht ist. Dann erlauben es gegebenenfalls die Informationsmeldungen der Log-Datei, den Fehler einzugrenzen oder zu finden.

Bezüglich der Realisierung des Loggings ist anzumerken, dass es bei Lösungen wie dem Microsoft Installer (vgl. 6.2 Verteilung mittels Paketen) bereits vollständig implementiert ist; man setzt einen Schalter für den Level (Detailierungsgrad) und übergibt einen Parameter zur Log-Datei (z.B. /l d:\LOG\install.txt). Anders ist dies beim Einsatz von Scripten (vgl. 6.1 Installation / Konfiguration mit Scripten). Hier muss der Entwickler selbst für das Logging Sorge tragen; es gibt aber für einige Scriptsprachen Bibliotheken, die dabei unterstützen.

3.3.2 Verteilaufträge

Nicht nur die eigentliche Verteilung an sich, also die per SV ausgeführte Installation oder Konfiguration sollte protokolliert werden, sondern auch die Beauftragung der SV. Beauftragung heißt in diesem Zusammenhang, wann welche Pakete auf welche Rechner mit welchen Parametern oder Werten aus der Datenbank zur Individualisierung (vgl. 3.2 Individualisierbarkeit) verteilt wurden.

Denn arbeitet eine verteilte Software nicht ordnungsgemäß, kann dies an einer nicht korrekten Verteilung im Sinne einer fehlerhaften Verteilbeauftragung liegen, obwohl das verteilbare Paket an sich fehlerfrei ist. Als Beispiel sei hier die Installation einer verteilten Software genannt, die mit einem Server kommuniziert, der namentlich über die SV-Datenbank in eine Antwortdatei eingebaut wird. Der Server ist in der Datenbank für ein bestimmtes Zielsystem falsch eingetragen; damit funktioniert die Software nicht, da sie falsch konfiguriert ist. Ein solcher Fehler kann zwar in der Regel auch anhand der Log-

Page 21

Leitfaden zur Einführung einer automatisierten Softwareverteilung

Datei der eigentlichen Installation lokalisiert werden, aber eine kompakte Darstellung der Beauftragung ist übersichtlicher als eine sehr lange Log-Datei. Ferner kann es beim Finden von Fehlern hilfreich sein, festzuhalten, von welchem Server die Quelldateien kopiert wurden (vgl. 11.2 dezentrale Images (Mehrstufige Verteilung)). Verteilungen missglücken und werden in der Regel abgebrochen, wenn die Images nicht korrekt d.h. fehlerhaft, veraltet oder unvollständig sind. Kann beispielsweise eine bestimmte Datei gemäß dem Logging nicht kopiert werden, ist es zeitsparend, den benutzten Server über das SV-System in Erfahrung bringen zu können, ohne die in Frage kommenden Server manuell zu überprüfen.

3.4 Fehlermanagement

Nicht immer findet eine Softwareverteilung ohne Fehler statt. Denn das zu installierende Softwarepaket mag auf ein Umfeld treffen, mit dem es nicht umzugehen weiß. Denkbar wäre in diesem Zusammenhang beispielsweise, dass der Festplattenspeicher zur Installation nicht ausreicht. Oder aber es gibt Abhängigkeiten zu anderen Softwarekomponenten, die nicht erfüllt sind.

Ziel des Fehlermanagements im Zusammenhang mit SV ist es, Fehler schnell zu entdecken und möglichst schnell und effizient - also ohne großen manuellen Aufwand - zu beseitigen. Rechnersysteme, die eine SV nicht erhalten konnten, sind mehr oder weniger eingeschränkt in ihrer Einsatzfähigkeit. Im Extremfall ist ein solches System bis zur Fehlerbeseitigung gar nicht mehr nutzbar. *

Auch wenn SV-Pakete vor einem produktiven Einsatz ausgiebig getestet werden im Hinblick auf die Ablauffähigkeit und das ordnungsgemäße Verhalten des Systems hinterher, so können nicht 100% der Fehler gefunden werden. Denn erstens sind Referenz-Geräte “sauber“ und nicht händisch manipuliert und zweites können meist nicht alle Anwendungsfälle bis ins Detail überprüft werden (dies wäre nicht wirtschaftlich). Wenn Verteilungen misslingen, so sind in einem ersten Schritt die Fehlerursachen und die Tragweite zu diagnostizieren. Massenprobleme sind in der Regel wichtiger als einzelne

^* Es sei darauf hingewiesen, dass nur durch ein Testverfahren mit definierten Testfällen größere „Unfälle“

vermieden werden können