Linux meistert auch die Softwareverteilung von Windows-PCs im Netzwerk mit Bravour. Am Beispiel des deutschen Produkts mit dem gut merkbaren Namen Opsi zeigt der Artikel, was möglich ist.
Man muss kein Securityspezialist sein, um zu merken, dass sich die Release-Zyklen der meisten Programme und Betriebssysteme verkürzen. Neue Versionen schließen Sicherheitslücken, beheben funktionale Fehler oder bauen zusätzliche Funktionen ein. Wer Admin eines Pools von Desktoprechnern ist, hat also Gründe genug, die ihm anvertrauten PCs softwaremäßig frisch zu halten.
Bei Linux-Maschinen ist das recht einfach, da alle Distributionen für PCs eine durchgängige Paketverwaltung besitzen. Windows und Applikationen für dieses Betriebssystem ist dieses Konzept jedoch fremd. Zwar bieten viele Programme automatische Online-Updates an, doch zum einen haben normale Benutzer keine Installationsrechte, zum anderen benötigt es viel Bandbreite, wenn alle Clients gleichzeitig das neue Office-Update aus Amerika herunterladen.
Auch die Konfiguration der Clients ist nicht unproblematisch: Die meisten Programme überfordern normale Anwender mit ihrer Fülle von Einstellungen schnell. Die Vorgaben sind für den Unternehmenseinsatz selten geeignet, sodass der Administrator gut daran tut, seinen Nutzern eine möglichst passende Einstellung vorzugeben. Erscheinungsbild, firmenweite Vorlagen, gemeinsame Verzeichnisse und vorkonfigurierte Konten verbessern den Komfort. Auch Sicherheitsrichtlinien lassen sich auf diesem Weg umsetzen, beispielsweise zentral definierte Zertifikate, das Benutzen von Proxyservern und das Sperren einzelner Funktionen.
SBC oder Deployment
Alle Ziele, also zentral gesteuerte Software-Installation, Patchmanagement und zentrale Konfiguration, lassen sich prinzipiell mit Server-based Computing, sprich dem Einsatz eines Terminalservers, erreichen [1]. Wer diesen Paradigmenwechsel scheut und zudem seinen Serverpark dafür nicht hochrüsten kann oder will, lässt alles wie gehabt und legt sich nur eine zentrale Softwareverteilung (Deployment-Lösung) zu.
Damit hat der Administrator ein mächtiges Werkzeug an der Hand und kann per Knopfdruck Software installieren oder updaten und alle Geräte identisch einrichten. Schulungszentren, die eine dedizierte Arbeitsumgebung für alle Teilnehmer brauchen, Universitäten, die Ausfallzeiten durch mutwillig beschädigte Installationen minimieren wollen, Testlabore, die konkrete Szenarien exakt nachstellen, und Firmen, die viele Rechner verwalten, sparen dadurch Zeit und Geld.
Zweistufige Installation
Dieser Artikel nimmt an, dass Windows als Clientsystem zum Einsatz kommt, weil das in vielen Firmen der Fall und zudem die schwierigere Aufgabe ist. Das Deployment eines Clients erfolgt in zwei Stufen. Zunächst stößt der Admin eine Netzwerk-Installation von Windows mit allen Treibern und Einstellungen an. Auf dem Basissystem ist zudem die Clientkomponente der Softwareverteilung integriert, welche die Installation aller weiteren Anwendungen erledigt. Dabei vergleicht der Dienst eine lokale Datenbank mit der des Servers und ermittelt, was zu installieren oder entfernen ist.
Um zu verhindern, dass sich Benutzer währenddessen anmelden und ein Neustart ihre Sitzung unterbricht, passieren alle Installationen noch während des Windows-Starts, erst danach zeigt sich das Anmeldefenster. In der Praxis hat es sich bewährt, die Verteilung nachts oder am Wochenende per Wake-on-LAN durchzuführen, damit sie den Arbeitsalltag nicht stört.
Jedes Programm muss in Form eines so genannten Installationspakets vorliegen. Es enthält Informationen darüber, mit welchen Parametern das Setup aufzurufen ist. Der eigentliche Vorgang läuft in einem automatischen Modus ab, der so genannten Silent- oder auch Unattended-Installation, bei der der Benutzer keine Eingaben tätigt.
Genau hier liegt das Problem, denn anders als Linux kennt Windows leider kein eindeutiges Paketformat. Zwar gibt es mit den MSI-Dateien für den Windows Installer einen Quasi-Standard, doch längst nicht jedes Programm beachtet ihn. Während unter Linux die nicht interaktive Installation Standard ist, gerät sie bei Windows zur Seltenheit.
Angebot und Nachfrage
Am Markt kursieren mehrere Konzepte, das Problem zu umgehen. Windows selbst enthält im Active Directory eine rudimentäre Softwareverteilung, jedoch nur für MSI-Pakete [2]. Als lizenzkostenbehaftete Angebote sind Microsofts Systems Management Server (SMS, [3], Nachfolger: System Center Configuration Manager), Materna DX-Union [4], Novell Zen for Desktops [5] sowie Teile von HP Open View [6] und IBM Tivoli [7] zu nennen. Daneben gibt es reine Communityprojekte wie WPKG [8], Unattended [9] oder Unattended-GUI [10]. Bei der Wahl einer Lösung sollte der Admin auf Kosten, Systemvoraussetzungen und das vorhandene Know-how achten.
So ist bei vielen kommerziellen Produkten ein Windows Server erforderlich, für den pro Maschine oder Benutzer entsprechende Clientlizenzen anfallen. Einige Hersteller gehen sogar so weit und unterstützen ausschließlich die speziell durch sie paketierte Software – bei jeder neuen Programmversion fallen dann also wieder Kosten an und der Administrator hat keine Möglichkeit, eigene Pakete zu erstellen.
Im Internet finden sich zahlreiche Seiten, die fertige Installationsskripte bereitstellen [11]. Mit Zeit und Erfahrung kann jeder Administrator damit die Paketierung selbst vornehmen (siehe auch Kasten “Softwareverteilung selbst bauen”). Als problematisch erweisen sich erfahrungsgemäß Spezialprogramme oder Software für Schule und Bildung, da diese oft auf vollkommen veralteten Installationssystemen aufbauen. Praktikabel ist daher eine Lösung, die dem Administrator sowohl die Freiheit lässt, selbst zu paketieren, als auch kommerzielle Unterstützung für diejenigen bietet, die nicht das Know-how oder die Zeit haben.
|
Softwareverteilung selbst |
|---|
|
Wer keine von der Stange will, kann sich natürlich auch seine eigene Software-Deployment-Lösung bauen. Für die Netzwerkinstallation des in Firmen häufig eingesetzten Windows XP benötigt der Administrator neben dem Original-Datenträger auch entsprechend konfigurierte DHCP-, TFTP- und Samba-Server. Weiterhin muss er den freien BINL-Server [12] betreiben – samt präpariertem Netzwerktreiber – und pro PC eine Datei namens »WINNT.SIF« respektive »UNATTEND.TXT«, die die Setups steuert [13] wie von anderen Lösungen gewohnt. Das Setup startet als PXE-Boot vom TFTP-Server, installiert die Netzwerktreiber per BINL und lädt dann die Steuerdatei sowie das Image über die Samba-Freigabe. In das Image müssen alle Treiber eingebunden sein, beispielsweise für Grafik, Sound oder Controller [14]. Der gesamte Prozess ist recht aufwändig und kompliziert. Glücklicherweise gibt es zahlreiche Anleitungen im Netz, beispielsweise unter [15], [16] und [17]. Wer ohnehin einen Windows-Server laufen hat, der kann über den integrierten RIS- beziehungsweise WDS-Dienst die Clients ganz komfortabel installieren und hat dann die freie Wahl, welche Softwareverteilung er einsetzt. Für Windows Vista übrigens hat Microsoft die Installation komplett neu geschrieben, sodass sich sowohl die eingesetzten Protokolle als auch deren Konfiguration stark von denen der Vorgänger unterscheiden, weswegen freie Lösungen dafür noch Mangelware sind. Zusammenfassend lässt sich sagen, dass ein komplett eigenes System nur für Administratoren mit speziellen Anforderungen geeignet ist. |
Opsi, die Linux-Lösung
Ein entsprechend geartetes Konzept bietet die Mainzer Firma UIB mit ihrem Produkt “Open PC Server Integration”, kurz Opsi [18] an. Opsi kann sowohl die Installation von Windows 2000, XP, Vista und Windows Server 2003/2008 übers Netzwerk durchführen als auch Anwendungsprogramme installieren. Es enthält eine Inventarisierung von Hard- und Software mit Anbindung an die Windows-Registry und eine Historyfunktion (Abbildungen 1 und 2). Damit verbunden ist ein übersichtliches Lizenzmanagement, das Keys automatisch zuteilt und freigibt, mehrere Lizenzpools verwaltet und dabei Downgrade-Lizenzen unterstützt (Abbildung 3).

Abbildung 1: Mit Opsis automatischer Hardware-Inventarisierung sind alle Details stets direkt verfügbar.
Der Hersteller versteht sich als Unterstützer von Open Source und legt seinem Produkt ein entsprechendes Modell zugrunde. Opsi fußt auf freien Komponenten wie Debian GNU/Linux, Samba, TFTP, DHCP sowie MySQL. Die meisten UIB-eigenen Funktionen sind großteils Open Source. Nur die Unterstützung für Windows Vista und Server 2008 (und laut Hersteller auch die für das ab Oktober erhältliche Windows 7), das Lizenzmanagement, die Anbindung per VPN und einige andere Features bleiben zahlenden Kunden vorbehalten (siehe Kasten “Kommerzieller Opsi-Support”). Die Firma verspricht, auch die Kommerzmodule als Open Source zu deklarieren, sobald sie die Entwicklungskosten dafür eingefahren hat.

Abbildung 3: Ordnung ins für proprietäre Software typische Lizenz-Chaos bringt die Lizenzverwaltung.
|
Kommerzieller |
|---|
|
UIB, der Hersteller von Opsi, bietet kostenpflichtigen Support (Community-, Professional- und Enterprise-Level), Einführungsworkshops und Schulungen sowie fünf Abonnements für Softwarepaketierungen an, wobei verschiedene Modelle zur Auswahl stehen [19]. Auch Anpassungsleistungen, wie die Erweiterung auf einen Fileserver, sowie die Remote-Administration in Form eines Komplettpaket haben die Mainzer im Angebot. Das Preismodell ist ein bisschen kompliziert und hängt von der jeweiligen Installation, dem Wartungs- und Schulungsbedarf sowie von der Anzahl der benötigten Pakete ab. |
Die Homepage weist auf die Möglichkeit hin, sich finanziell an der Entwicklung künftiger Funktionen zu beteiligen. Unter den ausgeschriebenen Projekten sind die Installation von Linux, die Unterstützung mehrerer Rollen, das zeitgesteuerte Installieren per Wake-on-LAN und Templates für einzelne Clients vorgesehen.
Offiziell ist Opsi für Debian, Ubuntu, Suse sowie den Univention Corporate Server erhältlich sowie integriert in eine installierbare Debian-DVD. Insbesondere für erste Tests interessant ist das ebenfalls downloadbare VMware-Image sowohl für den Server als auch den Client – damit kann jedermann Opsi testen, ohne sein bestehenden System zu modifizieren. Auf der DVD der DELUG-Variante dieser Linux-Magazin-Ausgabe findet sich das virtuelle Opsi-Image ebenfalls.
Im Test ging die Installation des Image schnell von der Hand. Nach dem Starten des Servers und Einrichten von Netzwerkkonfiguration, Benutzern sowie Zugangspasswörtern muss der Admin lediglich das System kurz per »apt-get« aktualisieren und entscheiden, ob Opsi auch als DHCP-Server fungieren oder ob er einen bestehenden Dienst nutzen soll. Danach ist das System per SSH und HTTPS erreichbar.
Pakete aus vielen Ecken
Die Mainzer Entwicklung eignet sich sowohl für bestehende Clients, auf denen man den Softwareverteilungsdienst dann nachinstalliert, als auch für neue Systeme, die Opsi direkt per Netzwerk einrichtet. Dazu kopiert der Admin lediglich den Inhalt der Windows-CD auf den Server. Sobald der PC dann via PXE-Boot oder Spezial-CD übers Netzwerk startet, lädt Opsi eine angepasste Linux-Umgebung, analysiert die Hardware und kopiert die Setupdateien. Die eigentliche Installation läuft dann ohne Benutzereingriff bis zum Windows-Anmeldebildschirm durch. Alternativ unterstützt Opsi auch die Installation über Festplattenimages.
In beiden Fällen übernimmt ab dann der Softwareverteilungsdienst. Er benötigt die erwähnten Pakete, wobei es dem Administrator freisteht, sie selbst zu erzeugen oder kostenpflichtig beim Hersteller zu abonnieren. Zum Selbsterzeugen bietet Opsi mehrere Methoden an: Snapshot, per Silent-Installation, Skript-basiert oder durch simulierte Tastatureingaben. Alternativ gibt es ein kostenfreies Communityforum [20], in dem sich Anwender austauschen, und ein Wiki [21] mit fertigen Installationsskripten.
Wichtige Updates wie die monatlichen Microsoft Security Fixes stellt der Hersteller nach eigenen Angaben seinen Abokunden innerhalb von drei Tagen ab Erscheinen paketiert bereit, was den Einsatz eines teuren Windows-Update-Servers spart. Andere Pakete und Service Packs bekommen Bezahlkunden binnen ein bis zwei Wochen aktualisiert.
Funktionsreiches Java-Interface
Der Admin verwaltet die Clients mit dem mitgelieferten und umfangreichen Java-Webinterface, das die Maschinen samt Hardware-Information und Softwarestand gruppier- und filterbar auflistet (Abbildung 4), oder aber per Kommandozeile oder direkt an der grafischen Konsole des Servers. Auch darf er mit den Opsi-Tools vom Client aus administrieren. Jedem PC lassen sich Betriebssystem und individuelle Softwarepakete zuordnen, beispielsweise die unterschiedliche Ausstattung für einzelne Abteilungen.
In Verbindung mit dem Soft- und Hardware-Management übermitteln die Clients detaillierte Informationen an den Server. Die Clients sind ihrerseits per Webinterface abfragbar, zum Beispiel danach, welcher Vista-PC mit mindestens 4 GByte RAM und einer für Videoschnitt geeigneten Grafikkarte ausgestattet ist. Bei der Installation unterstützt Opsi Paketabhängigkeiten sowie Installationsprioritäten und Client-spezifische Einstellungen. Vorgaben wie Windows-Keys lassen sich aber auch global machen.
Zu Protokoll geben
Für den Fall, dass eine Installation fehlschlägt, meldet Opsi das im Webinterface bei dem jeweiligen Paket (Abbildung 5). Zusätzlich erzeugt jeder Client ein detailliertes Protokoll, das Opsi zum einen zentral auf dem Server speichert, um es später im Browser studieren zu können. Zum anderen legt es das Protokoll auch auf dem betroffenen PC selbst ab – beispielsweise zur Diagnose bei Verbindungsproblemen.

Abbildung 5: Verläuft ein Installationsversuch erfolglos, informiert Opsi darüber per Java-Interface.
Optional übermittelt Opsi seine Meldungen auch an einen Syslog-Server. Wenn er die Softwarepakete erzeugt, kann der Admin darüber hinaus eigene Logeinträge einfügen. Bereits im Zuge der Opsi-gesteuerten Windows-Installation übers Netzwerk entstehen ebenfalls Logdateien am Server wie am Client.
Für Enterprise-Umgebungen unterstützt Opsi auch den Einsatz und das zentrale Konfigurieren mehrerer so genannter Depotserver zur Software-Installation, beispielsweise für mehrere Firmenstandorte. Solche Setups scheinen aber nicht ohne Probleme zu sein, jedenfalls rät der Hersteller dazu, diese nur im Rahmen eines Supportvertrags durchzuführen.
Installationssteuerung mit eigener Skriptsprache
Beim Windows-Start ruft der lokale Opsi-Dienst ein Programm namens »Winst.exe« auf, das die jeweiligen Pakete installiert (Abbildung 6). Ein fertiges Opsi-Paket besteht aus den ausführbaren Dateien, einigen Metadaten sowie je einem Skript für Installation, Update und Deinstallation.

Abbildung 6: Eine Statusanzeige begleitet die Opsi-Skript-gesteuerte Installation der einzelnen Programme.
Die Installationssteuerung ist in einer speziellen, semantisch umfangreichen Skriptsprache verfasst, die ein eigenes Installationshandbuch und eine Referenzkarte auf der Opsi-Webseite nebst Information zu verschiedenen Installationsprogrammen ausführlich dokumentieren [22]. Zum Einstieg eignet sich eine mit Opsi mitgelieferte Vorlage. Auch das erwähnte Wiki [21] mit seinen vielen Beispielskripten hilft dabei, das Konzept zu verdeutlichen.
Die Skriptsprache unterstützt alle Installationsvarianten, also Snapshot, Silent, Skript-basiert und simulierte Tastatureingaben, sodass unabhängig vom zu installierenden Programm die zugrunde liegende Sprache unverändert bleibt. Die Dateien sind ähnlich aufgebaut wie Windows-INI-Dateien, das heißt, sie sind in Sektionen unterteilt.
Opsi unterscheidet zwischen einer primären Sektion, die den grundlegenden Ablauf des Skripts und das Laufzeitverhalten von Winst steuert, und mehreren von dort aufgerufenen sekundären Sektionen (siehe Beispiel in Listing 1). In einer sekundären Sektion stehen Anweisungen, die wiederum in Funktionen ausgelagert sein oder aus externen Quellen stammen dürfen, beispielsweise einem Programm oder einem inkludierten Skript.
|
Listing 1: Skript zur |
|---|
01 [Initial] 02 Message=installiere tightvnc 1.2.9 ...... 03 04 [Aktionen] 05 ; Starte AutoIt als Hintergrund-Prozess, um 06 ; Fenster abzufangen, das erscheint, wenn 07 ; tightvnc während der Installation als Service 08 ; läuft. 09 winbatch_tightvnc_autoit_confirm /LetThemGo 10 ; starte das setup Programm als silent setup 11 winbatch_tightvnc_silent_install 12 11 [winbatch_tightvnc_autoit_confirm] 12 %SCRIPTPATH%autoit %SCRIPTPATH%confirm.aut 13 14 [winbatch_tightvnc_silent_install] 15 %SCRIPTPATH%tightvnc-1.2.9-setup.exe /silent |
Umfangreiche Syntax
Die Opsi-eigene Skriptsprache stellt Bedingungen (»if« und »else«), »for«-Schleifen und Stringlisten bereit, um den Ablauf der Installation von bestimmten Eigenschaften abhängig zu machen. Hinzu kommen belegbare Variablen, fertige Funktionen und globale Konstanten. Mit Letzteren lassen sich beispielsweise Systempfade, Laufwerksbuchstaben, Betriebssystemversionen, Umgebungsvariablen und Netzwerkeinstellungen im Skript referenzieren. Den Wert der globalen Konstanten ermittelt der Opsi-Dienst dann automatisch zur Laufzeit.
Der Code innerhalb der sekundären Sektionen kann vielfältige Änderungen am System durchführen, beispielsweise Dateien und Verzeichnisse kopieren oder Löschen, Registry-Einträge editieren sowie Verknüpfungen auf Startmenüs und Desktops anlegen und entfernen. Ebenfalls möglich ist es, externe Programme per Windows-API oder »cmd.exe« aufzurufen sowie das Zielsystem neu zu starten – und das auch in Abhängigkeit von Dateiversionen, Betriebssystem, Sprache, freiem Speicherplatz oder anderen Faktoren.
Der Admin darf auch das Erscheinungsbild seines Opsi-Dienstes mit eigenen Installationsmeldungen sowie Grafiken anpassen. Selbst das Neustartverhalten kann er im Skript beeinflussen. Für die zentrale Konfiguration von Software liefert die Opsi-Skriptsprache zudem Funktionen zum Patchen von Dateien, wobei sie mit INI-, Hosts-, XML-, BDE- und Mozilla-Konfigurationsdateien sowie Textdateien zurechtkommt.
Fazit
Die Vielfalt der Softwareverteilungen am Markt ist groß. Primär ist, dass der Administrator überhaupt die Notwendigkeit erkennt, seine Systeme zentral zu warten. In manchen Umgebungen ergeben speziell angepasste Lösungen Sinn, doch darf man den Aufwand zu deren Einrichtung und vor allem Pflege nicht unterschätzen.
Produkte, die dem Nutzer die Wahl lassen, wie viel Eigenarbeit er investiert und wie viel er durch kostenpflichtigen Herstellersupport abdeckt, sind ein guter Ansatz – insbesondere da der Administrator keinen zusätzlichen Windows-Server in Betrieb nehmen muss. Das Schöne ist, dass jeder die Wahl hat, welche Lösung er einsetzt oder ob er bestehende Konzepte mischen möchte. (jk)
|
Der Autor |
|---|
|
Florian Effenberger engagiert sich seit vielen Jahren für freie Software. Er ist Co-Lead des internationalen Marketingprojekts bei Openoffice.org und im Vorstand des Openoffice.org Deutschland e.V. aktiv. Seine anderen Arbeitsschwerpunkte liegen in der Konzeption von Unternehmens- und Schulnetzwerken samt Softwareverteilungen mit freier Software. Er schreibt regelmäßig für deutsch- und englischsprachige Fachpublikationen und beschäftigt sich mit rechtlichen Fragen. |







