Bachelorarbeit Überarbeitung eines Multi-Domain Softwaredeployments am Beispiel der Syxos GmbH - opus4.kobv.de
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Bachelorarbeit
Überarbeitung eines Multi-Domain
Softwaredeployments am Beispiel der Syxos
GmbH
FAKULTÄT: Informatik
STUDIENGANG: Informatik
VOR- UND ZUNAME: Stefan Rudolf Prieschl
Erstprüfer: Prof. Dr. Regensburger
Zweitprüfer: Prof. Dr. Göldner
Ausgegeben am 10.01.2021
Abgegeben am 14.01.2021
Eidesstattliche Versicherung
Hiermit erkläre ich, dass ich die vorliegende Arbeit eigenständig und ohne fremde Hilfe angefertigt
habe. Textpassagen, die wörtlich oder dem Sinn nach auf Publikationen oder Vorträgen anderer
Autoren beruhen, sind als solche kenntlich gemacht. Die Arbeit wurde bisher keiner anderen Prü-
fungsbehörde vorgelegt und auch noch nicht veröentlicht. Alle Bilder bzw. Zeichnungen ohne Li-
teraturverweis wurden selbst aufgenommen bzw. erstellt.
Ilmmünster, den
Name(Unterschrift)
2
Danksagung
Hiermit möchte ich meinem Betreuer und Geschäftsführer bei Syxos, Herrn Alexander Baumann
danken, dass er mir stets bei Fragen und Problemen zur Seite stand.
Auÿerdem wurden mir Zeit und Hardware zum Testen und anschlieÿendem Rollout der Produkte
bereitgestellt.
Des weiteren möchte ich meinem Erstprüfer Herrn Prof. Dr. Regensburger bedanken, welcher mir
bei der Themen ndung geholfen hat.
3
Zusammenfassung
Soll Software auf vielen Rechner gleichzeitig installiert werden, so ist automatischer Deployment-
mechanismus unabdingbar.
Jedoch kann es bei selbst programmierten Scripten schnell zu Problemen kommen, da diese meist
schlecht dokumentiert und gewartet sind.
Abhilfen können externe Tools für den Bereich Softwareverteilung darstellen. Diese müssen je nach
Anforderungen der einsetzenden Firma ausgesucht werden.
Im Fall der Syxos GmbH stellt sich heraus, dass das Tool opsi die meisten Punkte, welche sich in
der Anforderungsanalyse ergeben, erfüllt.
Für den speziellen Fall der BMW-Autohaus Anforderungen kann opsi jedoch nur bedingt angewen-
det werden, da bei jedem Update ein neues Paket gebaut werden müsste.
4
Inhaltsverzeichnis
1 Einleitung 8
1.1 Zielsetzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Rechenbeispiel Zeitersparnis automatisches Softwaredeployment . . . . . . . . . . . . 8
1.3 Funktionsweise der Installationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Funktionsweise von Deinstallationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Analyse und Schwächen des momentanen Systems 11
2.1 Über die Firma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Momentaner Ablauf des Softwaredeployments . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Deployment der Standardprogramme . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Deployment der BMW-Werkstatt-Programme . . . . . . . . . . . . . . . . . . 12
2.3 Probleme bzw. Einschränkungen des momentanen Systemes . . . . . . . . . . . . . . 14
2.4 Analyse der Kundensysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Aufbau des Netzwerkes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Anforderungen an das Softwaredeployment . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Marktübliche Deploymenttools 17
3.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Microsoft System Center Con guration Manager (SCCM) . . . . . . . . . . . . . . . 17
3.2.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2 Lizenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.3 Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Open PC Server Integration (opsi) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.2 Lizenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.3 Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 WPKG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.2 Lizenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.3 Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5 Panda Systems Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.2 Lizenz/Betriebskosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.3 Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6 Vergleich der Lösungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6.1 Preisgestaltung (Faktor 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6.2 Funktionsumfang (Faktor 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6.3 Managebarkeit (Faktor 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6.4 Domänenunabhängigkeit Faktor 1 . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4 Migration auf das neue System 34
4.1 Installation der Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5
4.2 Sicherheitsprobleme minimieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Installation auf den Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 Erzeugung eines Paketes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.1 opsi Setup Detektor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.2 opsi PackageBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5 Verarbeitung standort- und rmenspezi scher Scripte . . . . . . . . . . . . . . . . . . 41
4.6 Eignung von opsi im BMW-Umfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5 Fazit 42
6
Begriserklärungen
Windows-Domäne
Eine Domäne ist ein abgetrennter Netzwerkbereich, in dem Sicherheitsrichtlinien und Benutzerrechte
verteilt werden können. Diese Domänen werden in einem Windows Netzwerk durch einen speziellen
Windows Server, dem sogenannten Domänencontroller verwaltet, auf dem sich auch das Active
Directory be ndet. [vgl. 1]
Windows Gruppenrichtlinien
Mit Gruppenrichtlinien, welche zentral in einer Windows Domäne im Einsatz sind, können folgende
Einstellungen und Aktionen verwaltet werden:
Sicherheitseinstellungen vergeben und erzwingen
Kon guration von Diensten
An- und Abmeldescripte vorgeben
rudimentäre Softwareverteilung
Gruppenrichtlinien können sowohl auf Geräteebene als auch auf Benutzerebenen verwaltet werden.
[vgl. 2]
Virtual Private Network (VPN)
Ein VPN kann verwendet werden, um private Kommunikationen über nicht vertrauenswürdige Ver-
bindungen (hierzu zählt das Internet) zu realisieren. [vgl. 3, S.6]
Typische Einsatzgebiete für eine VPN Verbindung sind: [vgl. 3, S.9-11]
Mobile Mitarbeiter
Heimarbeitsplatz (Homeo ce)
Standortvernetzung bei verteilt agierenden Firmen
Absicherung von öentlichen WiFi-Verbindungen
Kundenanbindungen
Fernwartung
7
1 Einleitung
Um die Systemsicherheit in den Betrieben zu erhöhen, wird den einzelnen Usern das Recht der
eigenständigen Installation verweigert. Dies geschieht durch den Entzug sämtlicher Administrati-
onsrechte der Endanwender. Das hat zum Nachteil, dass sämtliche Software durch die Administra-
toren freigegeben und installiert werden muss. Wo die Installation einer Software auf einem Rechner
noch schnell erledigt ist, wird es umso zeitaufwändiger, je mehr Rechner bearbeitet werden müssen.
Diese Situation wird durch ständige Softwareupdates für Programme ohne eigenständigen Updater
noch verschlimmert. Bei der Integration von Software in eine Deploymentstruktur wird Anfangs we-
sentlich mehr Zeit benötigt, allerdings kann dieser anfängliche Mehraufwand bereits nach wenigen
Installationen relativiert werden.
Hierbei gibt es verschiedene Möglichkeiten, dies in Microsoft Windows Umgebungen umzusetzen:
Selbstgeschriebene Scripte in Verbindung mit Gruppenrichtlinien der Windows Domäne
Hochspezialisierte Software, welche meist über eine gut sortierte Ober äche verfügt, eine ein-
fache Verwaltung der einzelnen Rechner und Server möglich macht.
1.1 Zielsetzung der Arbeit
Die Verwendung selbst programmierter Scripte und Software führt in fast allen Fällen durch feh-
lende Wartung und Dokumentation früher oder später zu Problemen. Vertieft wird dies noch, wenn
die Anwendung nicht in Vollzeit betreut, sondern neben dem Tagesgeschäft verwaltet werden soll.
Abhilfe schat hier oft der Einsatz spezieller Software von Drittanbietern, welche sich mit ihrem
gesamten Know-How auf P ege und Wartung einer solchen Lösung konzentrieren können. Das Ziel
dieser Arbeit soll sein, speziell das Thema Softwaredeployment eines IT-Dienstleisters mit vielen
kleinen Kunden zu überdenken. Es soll geklärt werden, ob es sinnvoll ist, das jetzige System gegen
ein mächtiges Tool eines Anbieters zu wechseln. Ebenso soll die Eignung eines externen Tools für
den speziellen Einsatzbereich BMw-Autohaus geprüft werden.
1.2 Rechenbeispiel Zeitersparnis automatisches Softwaredeployment
Als Beispiel dient ein Deployment eines Virenschutzprogrammes, welches circa 1/3 der Kunden von
Syxos in Verwendung haben (Das entspricht insgesamt 302 Rechnern):
Einzelinstallationsdauer: circa 10 Minuten: Hier muss das Aufschalten auf den Rechner, so-
wie die Absprache mit den jeweiligen Benutzer erfolgen, um das Programm durch einfaches
Durchklicken zu installieren.
(t = n* 10 min)
Erstellen und Verteilen eines Installationsscripts auf die Kunden mit der momentanen Lösung:
120 Minuten. Als Pauschale für das Aktivieren der Scripte für neue Rechner bzw. neue Kun-
den, soll für diese Rechnung 2 Minuten pro Installation verwendet werden.
(t = 120 min + n* 2 min)
8
Installationen Arbeitszeit Einzelinstallation Arbeitszeit Deploymentmechanismus
1 10 min 122 min
10 100 min 140 min
50 500 min 220 min
100 1000 min 320 min
500 5000 min 1120 min
1.3 Funktionsweise der Installationen
Eine automatische Softwareverteilung wird meist durch das Ausführen von Scripten auf dem End-
rechner realisiert. Da der User selbst keine administrativen Rechte besitzt, um diese Scripte aus-
zuführen, müssen diese durch einen Mechanismus in einer administrativen Umgebung gestartet
werden.
Dies geschieht, indem das jeweilige Script, z.B. durch eine Gruppenrichtlinie beim Herunterfahren
oder auch durch spezielle Software zum Softwaremanagement ausgeführt wird.
Softwareinstallationen auf Windows Rechnern können grob in .msi- und .exe-Pakete unterteilt wer-
den:
.msi-Pakete müssen hierbei immer mit dem Programm msiexec.exe, einem Windows eigenen
Werkzeug installiert werden.
.exe-Pakete hingegen können durch den einfachen Aufruf der Datei über die Kommandozeile
aufgerufen werden.
Normalerweise würde beim Aufrufen der Installationspakete die Installationsmaske des jeweiligen
Programms auftauchen. Um dies zu verhindern, können sogenannte Switches an den Installations-
aufruf angehängt werden, um die Installationsvorgehensweise zu verändern.
Hier einige gängige Beispiele:
/silent bzw. /s oder /qn: Installation wird ohne Rückfragen auf das Standardverzeichnis aus-
geführt.
/log .log: es wird eine Log-Datei über die Installation erstellt.
/norestart: Ein Neustart nach der Installation wird verhindert.
[4, vgl. S.2-3]
Diese Switches sind allerdings nicht einheitlich über alle Programme gleich, da diese durch die
Hersteller der Software vorgegeben werden.
So sieht z.B. eine Google Chrome Installation der MSI-Version folgendermaÿen aus: [vgl. 5]
msiexec /q /l GoogleChrome . msi
Firefox als EXE-Version hingegen benutzt den /s Switch: [vgl. 6]
FirefoxInstaller . exe /s
Daher sollte bei jedem Programm die Herstellerseite aufgesucht werden, welche Einstellungen für
eine stumme Installation gesetzt werden müssen.
9
1.4 Funktionsweise von Deinstallationen
Soll ein Programm nach erfolgreicher Installation wieder deinstalliert werden, da es z.B. durch eine
andere Software ersetzt wird, kann dies auf verschiedene Weise durchgeführt werden:
Wenn der Hersteller einen Uninstaller mit in das Installationsverzeichnis legt, kann dieser
einfach ausgeführt werden. Das Programm sollte danach nahezu restlos entfernt sein.
Mit dem Befehl
wmic product where " description =' < programname >' " uninstall
können alle Programme, welche sich in der wmic Programmübersicht be nden, deinstalliert
werden [vgl. 7]
Programme, welche sich nicht in der Windows Programmliste be nden, sich somit nicht als
Programm registriert haben, können problemlos von dem jeweiligen Festplattenpfad gelöscht
werden. Ein Beispiel hier sind portable Programme
102 Analyse und Schwächen des momentanen
Systems
2.1 Über die Firma
Die Syxos GmbH fungiert als IT-Dienstleister für kleine und mittlere Unternehmen. Im Besonderen
spezialisiert man sich auf BMW-Autohäuser und die dazugehörige Software. Auch werden in diese
Richtung kleinere Tools und sonstige Helfer entwickelt. Zur Betreuung gehört natürlich auch die
Installation von Programmen auf den Arbeitsplatzrechnern, welche zu 99 Prozent aus Windows
Maschinen bestehen.
2.2 Momentaner Ablauf des Softwaredeployments
Zum Zeitpunkt des Verfassens dieser Arbeit wird mit einem zweigeteilten Mechanismus gearbei-
tet. Hier wird zwischen der Installation gängiger Standardprogramme, wie Google Chrome oder
Microsoft O ce, und der Spezialprogramme, welche in einem BMW-Autohaus eingesetzt werden,
unterschieden.
2.2.1 Deployment der Standardprogramme
Die Standardprogramme werden mit einer eigenständig entwickelten Script Struktur installiert.
Beim Herunterfahren des jeweiligen Rechners wird ein Powershell Script ausgeführt, welches nach-
einander folgende Scripte startet:
Global Script: Hier werden alle Softwarepakete abgedeckt, die für alle Kunden identisch sind,
z.B. 7zip, Chrome etc. Dieses wird zentral auf einem Server hinterlegt und nachts automatisch
zu den Kunden synchronisiert.
Company Script: Hier werden alle Softwarepakete abgedeckt, die für einen bestimmten Kunden
benötigt werden.
Branch Script: Hier werden alle Softwarepakete abgedeckt, die für einen Standort eines Kun-
den benötigt werden, z.B. spezielle Druckerscripte. Hier wird durch das Zuordnen der IP-
Subnetzmaske des Rechners bestimmt, an welchem Standort er betrieben wird.
11Abbildung 2.1: Diagramm Scriptablauf
Die jeweiligen Scripte überprüfen, ob im Ordner con guration\ der Compu-
tername als .txt Datei hinterlegt ist. Wenn das der Fall ist, wird überprüft, ob sich im Ordner
status\ eine Textdatei mit dem Namen des Programms be ndet. Sollte die Text-
datei bereits bestehen, dann bedeutet dies, dass die Software bereits installiert wurde und nicht
erneut installiert werde muss. Wenn keine Textdatei gefunden wird wird, das jeweilige Installations-
script für das Softwarepaket ausgeführt. Danach wird die Textdatei mit dem Programmnamen im
Statusordner des Rechners angelegt.
Die Scripte und Installationspakete liegen hierbei auf dem jeweiligen Domaincontroller des Kunden.
Diese sind per schreibgeschützter SMB-Freigabe für alle Rechner im Kundennetzwerk einseh- und
ausführbar. Da es allerdings nicht nur Rechner gibt, welche ständig im Lokalen Netzwerk des Kunden
sind, z.B. bei Firmen mit Mitarbeitern im Auÿendienst, welche nur sporadisch eine VPN Verbindung
zum Firmenserver aufbauen, wird in diesem Fall beim VPN Aufbau der Ordner mit den Scripten
und Installationspaketen lokal auf die Festplatte des Rechners kopiert. Diese Rechner sind dann so
kon guriert, dass die Scripte beim Herunterfahren lokal ausgeführt werden.
2.2.2 Deployment der BMW-Werkstatt-Programme
Für die Installation der BMW-Werkstatt-Programme hat Syxos ein eigenes Tool mit gra scher
Ober äche programmiert. Das sogenannte ISPI Next Tool. Die Installation dieses Programms er-
folgt hierfür auf jedem Werkstattrechner eines Autohauses. Das Management erfolgt über eine ad-
ministrative Version des Programms auf einem Windows-Server.
Auf der Übersichtseite kann hier für jeden Rechner mit installierter Clientsoft-
ware der Onlinestatus eingesehen und Installationen per Rechtsklick auf das jeweilige Feld geplant
werden.
12Abbildung 2.2: Screenshot Updateseite, Rechnernamen zensiert
Um die BMW-Programme nach der Installation ausführen zu können, muss der Rechner bei BMW
zentral registriert werden. Eigentlich hat jeder Mitarbeiter eines BMW-Autohauses ein solches Kon-
to, aus Sicherheitsgründen hat nicht jeder das Recht eine solche Registrierung durchzuführen. Eben-
falls wird diese Registrierung nach einiger Zeit zurückgesetzt, was einen Arbeitsstopp bis zur Eingabe
der Administrator-User-Daten zur Folge hat. Deshalb hat das Tool eine eigene Funktion, welche die
Registrierung des Rechners alle 10 Minuten überprüft und bei negativer Rückmeldung eine eigen-
ständige Neuregistrierung durchführt.
Abbildung 2.3: Screenshot Automatische Registration
In der BMW-Werkstatt fallen vor allem zwei Programme wegen ihrer groÿen Installationspakete
aus der Reihe. Dadurch ist ein Standard Deployment nicht möglich.
ISTA-P: >80GB (zur Analyse und Programmierung von älteren Autos vor 2004)
ISTA mit Programmierdaten >250GB (zur Analyse und Programmierung der neueren Autos
nach 2004)
13Diese Programme sind so groÿ, da diese o ine alle Programmupdates und Reparaturanleitungen
der entsprechenden BMW-Periode beinhalten. Um diese groÿen Softwarepakete nicht ständig neu
für jeden Rechner herunterladen zu müssen, werden diese auf einem NAS-System des Kunden bereit
gehalten. Der Download erfolgt hierbei über einen BMW-Downloader auf einem der Kundenserver.
Aufgrund ihrer Gröÿe können diese Programme natürlich nicht während des Tagesgeschäftes instal-
liert werden, da sonst der Rechner v.a. wenn noch eine drehende Festplatte verbaut ist, den ganzen
Tag nicht verwendet werden kann.
Daher werden diese Updates stets automatisch nachts installiert.
Um einen möglichen Totalausfall durch fehlerhafte Updatepakete oder das Überlasten des NAS-
Systems vorzubeugen, werden auch nicht alle Rechner in der gleichen Nacht auf den neuersten
Stand gebracht, sondern im Zwei- oder Dreitagesrythmus upgedatet.
Werden diese Updates über zwei Updatezyklen nicht durchgeführt, wird die jeweilige Softwarein-
stallation für das Auslesen und Programmieren von Fahrzeugen gesperrt. Daher ist es wichtig, einen
Überblick über die Aktualität der Software zu behalten. Ein Zentralreport zu Syxos, welcher alle
Kundeninstallationen auf einmal anzeigt, wird hierbei allerdings noch nicht zur Verfügung gestellt.
Deshalb muss ein Mitarbeiter alle zwei Wochen einen Komplettcheck über die installierten Softwa-
repakete auf jedem Kundensystem durchführen.
2.3 Probleme bzw. Einschränkungen des momentanen Systemes
Das momentan verwendete System hat einige Probleme:
Die Bedienung wurde niemals richtig dokumentiert, was die Einführung für neue Administra-
toren erheblich erschwert.
Programme können nur während eines Neustartes installiert werden, auch wenn es sich um
Software handelt, welche keinen Neustart nach der Installation erfordert.
Sämtliche Softwarepakete müssen bei VPN-Usern lokal auf dem Rechner gehalten werden,
auch wenn diese auf dem speziellen PC gar nicht benötigt werden, was einige GB an unnötigen
Dateien zur Folge hat.
Es gibt keine zentrale Übersicht, welche Software auf den Rechnern installiert ist.
Zum Entfernen von Programmen müsste ein Dreiinstallationsscript geschrieben werden.
Das Ausrollen von Updates ist sehr aufwändig.
Die Freigabe von Software kann nur über den Domaincontroller des Kunden erfolgen, was den
Aufwand erhöht.
Da das ISPI Next Tool auf einer SQLite Datenbank auf dem NAS des Kunden basiert, kann
es zu langen Wartezeiten während der Bedienung kommen (während eines Schreibvorgangs
wird die komplette Datenbank gesperrt). Dies geschieht vor allem, wenn es sich um groÿe
Autohäuser mit vielen Rechnern handelt.
Wenn kein Domaincontroller beim Kunden vorhanden ist, z.B. aus Kostengründen, kann das
momentane Shutdown-Script nicht ohne Weiteres per Gruppenrichtlinie ausgeführt werden.
142.4 Analyse der Kundensysteme
Aufbau eines BMW-Kunden-Netzwerkes:
Die Kunden haben nicht immer einen Domaincontroller.
Die Kunden müssen ein NAS-System zur Installation der groÿen BMW-Softwarepakete besit-
zen.
Die Rechner sind immer per VPN aus dem Syxos-Verwaltungsnetz erreichbar.
Durchschnittlich 50 MBit Anbindung, allerdings auch vereinzelt sehr schlechte Internetanbin-
dungen mit nur 10 MBit pro Standort.
Aufbau der restlichen Kunden:
Besitzen immer einen Windows Domaincontroller.
Besitzen kein NAS-System bzw. höchstens zum Backup.
Arbeiten teilweise nur über VPN-Verbindungen und be nden sich selten im Firmennetz.
2.5 Aufbau des Netzwerkes
Damit die Kundensysteme von einem zentralen Standpunkt erreicht werden können, sind alle Kun-
dennetze per VPN-Verbindung mit strengen Firewall Regeln an das Syxos-Netzwerk im Rechen-
zentrum angeschlossen. Hierüber werden z.B. nachts die aktuellen Scripte und Softwarepakete syn-
chronisiert. Haben Kunden mehrere Standorte, so sind diese Netzwerke ebenfalls untereinander per
VPN verbunden sowie einzeln an das Rechenzentrum.
Abbildung 2.4: Beispielaufbau des Netzwerkes zwischen Syxos und den Kunden
152.6 Anforderungen an das Softwaredeployment
Durch die vorhergehende Analyse der vorhanden Systeme und Absprache mit meinem Betreuer,
ergeben sich folgende Voraussetzungen für das überarbeitete Softwaredeployment:
Notwendig:
Unterstützung mehrerer unabhängiger Domänen ohne einer verp ichtenden Vertrauens-
stellung
Übersicht über installierte Programme mit einer Deinstallationsmöglichkeit
Kostengünstig: Die Rechnungen für eine solche Software müssen am Ende die Kunden
bezahlen, welche kaum bereit sein werden, viel Geld für etwas auszugeben, das Sie besten-
falls gar nicht mitbekommen. Dies könnte zu einer Teilung von Kunden in zwei Gruppen
führen und dadurch absolut keine Verbesserung bringen.
Vorteilhaft:
Lauähigkeit ohne Windows-Domäne: Da einige wenige Kunden keinen Domänencon-
troller und somit auch die Verwaltungsmöglichkeiten einer Domäne nicht besitzen ist es
sinnvoll wenn das Management unabhängig von einer Windows-Domäne ist.
Management über eine zentrale Instanz: Es sollte vermieden werden, sich für jede Instal-
lation auf die Server der Kunden schalten zu müssen.
Möglichkeit, die Softwarepakete nur bei Bedarf bei VPN-Kunden auf den Rechner über-
tragen zu müssen.
Möglichkeit, neue Software ohne Neustart installieren zu können: Die gilt natürlich nur
für Pakete, die nach der Installation keinen zwingenden Neustart benötigen
Automatische Installationsmöglichkeit des Deployment Clients: Dies spart Zeit und Pro-
bleme beim Wechsel auf eine mögliche neue Lösung
Unterstützung der Ausführung von CMD bzw. Powershell Scripten für die Installation:
Dies vereinfacht die Migration zu einem möglichen neuen System von der alten Land-
schaft.
163 Marktübliche Deploymenttools
3.1 Übersicht
Um die Situation des momentanen Deployments zu verbessern, soll überprüft werden, ob ein ex-
ternes Softwaredeploymenttool alle bzw. einige Teilbereiche des bisherigen Deployments ablösen
und verbessern kann. Da es sich bei den Arbeitsplatzrechnern ausschlieÿlich um Windows Geräte
handelt, fallen bereits alle Deploymentsysteme, welche nur andere Betriebssysteme wie Linux etc.
unterstützen, heraus. Natürlich ist es von Vorteil, wenn auch andere Systeme zusätzlich zu Windows
unterstützt werden, falls es doch einmal zu einem häu geren Einsatz von Servern bzw. Arbeitsplatz-
rechnern mit anderen Betriebssystemen kommen sollte.
Um die Funktionen der Softwaretools zu prüfen, wurden diese in einer Testumgebung mit virtuellen
Windows 10 Maschinen auf ihre rudimentäre Funktionsweise getestet.
Die Systeme werden nach Kompatibilität an unseren Anforderungen, Komplexität der Bedienung
und nicht zuletzt an teilweise anfallenden Lizenzgebühren beurteilt. Natürlich kann hier nicht bei
jeder Software tief in die Details gegangen werden.
3.2 Microsoft System Center Con guration Manager (SCCM)
3.2.1 Übersicht
Der SCCM stellt in diesm Vergleich die Lösung von Microsoft für die Vereinfachung von Softwa-
reverteilung in Windows-Netzen dar. Mit dem SCCM können Betriebssysteme und Anwendungen
verteilt und später auch wieder deinstalliert werden [8, vgl. S.1]
3.2.2 Lizenz
Der SCCM ist ein Teil des Microsoft System Centers. Um diesen betreiben zu dürfen/ können, ist es
notwendig, sowohl Serverlizenzen als auch Client Management Lizenzen zu kaufen. Letztere müssen
für jeden Rechner eines Betriebes beschat werden. [vgl. 9][vgl. 10]
Server Lizenzen:
Standard Lizenz mit bis zu 2 Servern: 1.323,00 $ exclusive MwSt. [vgl. 9]
Datacenter Lizenz ohne Begrenzung: 3.607,00 $ exclusive MwSt. [vgl. 9]
Client Management Lizenz: 99,08 e exclusive MwSt. pro Gerät [vgl. 11]
Hier kommen vor allem auf kleine Betriebe sehr hohe Kosten zu, da es nicht erlaubt ist nur eine
Datacenter Serverlizenz für Syxos zu kaufen und die alle Kunden mitzuversorgen. Bei gröÿeren
Betrieben sind die Serverlizenzen noch tragbar, allerdings würden sich die Arbeitsplatzlizenzen
auch extrem anhäufen.
173.2.3 Funktionen
Abbildung 3.1: Übersicht über die Geräte, welche mit dem SCCM verbunden sind [8, S.44]
In der Übersichtsseite des SCCM werden die Geräte aufgelistet. Von hier aus können Softwarepakete
verteilt und erstellt werden.
18Abbildung 3.2: Bereitstellung eines neuen Softwarepaketes [8, S.162]
Für ein neues Softwarepaket muss ein Netzwerkordner mit der dementsprechenden ausführbaren
Datei bereitgestellt werden. Im Bereich Installationsprogramm muss der dementsprechende Befehl
zur lautlosen Installation eingegeben werden.
Funktionen und Features des SCCM [8, vgl. S.1] :
Microsoft Intune: Tool zum Verwalten von Mobilgeräten
Windows Server Update Service (WSUS): Administration von Windows Updates durch ma-
nuelle Freigabe bzw. Verweigerung von Updatepaketen
Windows Automated Deployment Kit
Windows Bereitstellungsdienst (WDS)
Remotedesktop und Remoteunterstützung: Einfaches Starten des Zugries auf einen Rechner
193.3 Open PC Server Integration (opsi)
3.3.1 Übersicht
Opsi ist ein Open Source Client Management Tool, das auch heterogene Umgebungen managen
kann. Hierbei werden sowohl Windows als auch Linux Rechner unterstützt. Auÿerdem gibt es eine
Übersicht über installierte Software und der verbauten Hardware der eingesetzten Geräte.
Schlüsselfunktionen: [vgl. 12]
Softwareverteilung und Upadatemanagement
Automatische Installation von Betriebssystemen
Hard- und Software Inventarisierung
Unterstützung verteilter Standorte
3.3.2 Lizenz
Der Hauptteil von opsi ist open source und kostenlos erhältlich bzw. einsetzbar. Bestimmte Module
sind jedoch kostenp ichtig, werden aber nach erfolgreicher Finanzierung der Module in den Pool der
kostenlosen Erweiterungen übernommen. Es ist also theoretisch möglich, bei fast abgeschlossenen
Finanzierungsstatus abzuwarten, bis das Modul kostenlos verfügbar ist. [vgl. 13]
Finanzierungsstatus und Preise (Stand 08.12.2020): [14]
Modul Kosten Finanzierungsstatus
opsiclientd Windows Betriebssysteme frei 100%
Software on Demand (Kiosk Mode) frei 100%
Lizenzmanagement 2000e 78%
WAN-Anbindung von opsi-Clients 2000e 67%
MySQL-Backend für Kon gurationsdaten 2000e 75%
Hierarchische Gruppenverwaltung (Treeview) frei 100%
Dynamische Depotauswahl frei 100%
User Pro le Management frei 100%
Nagios Connector 2000 e 37%
Installation bei Shutdown frei 100%
Local Image/ VHD Reset 2000e 30%
Linux Agent 2000e 14%
UEFI/ GPT Support 1000e 29%
WIM-Cature 750e 15%
Scalability 1 2000e 13%
User-Roles 2000e -
Directory Connector 2000e -
Secureboot 2000e -
203.3.3 Funktionen
Opsi verügt über ein aufgeräumtes Managementinterface, wobei dieses auf einem Linux-Betriebssystem
gehosted wird. Auf dem Opsi Server be nden sich auÿerdem noch die Installationspakete, welche
aus einem Script und dem vom Hersteller bereitgestellten Installationsprogramm bestehen.
Abbildung 3.3: Übersicht der Geräte mit Onlinestatus etc.
Auf der Client Übersichtsseite können alle bei opsi registrierten Clients aufgelistet werden. Hier
wird auch die dazugehörige IP-Adresse, sowie der Letzte Onlinestatus angezeigt. Die Clients können
Gruppen bzw. Domänen hinzugefügt werden, was die Aufteilung nach Betrieben vereinfacht.
21Abbildung 3.4: Überischt über die installierten Pakete auf dem Gerät
Im Reiter "Produktkon guration" werden alle opsi Pakete, die auf dem Rechner installiert werden
können, angezeigt. Ist ein Gerät ausgewählt, so wird auch der jeweilige Installationsstatus des Pa-
ketes angezeigt. Während der Freigabe können auch mehrere Geräte gleichzeitig, bzw. auch ganze
Gruppen, ausgewählt werden. Dadurch muss man bei groÿen Installationsmengen nicht jeden Cli-
ent einzeln auswählen. Sind Pakete in einer neuen Version verfügbar, so können diese als Update
installiert werden. Auÿerhalb von opsi installierte Software wird auf diesem Reiter nicht angezeigt.
22Abbildung 3.5: Übersicht über alle installierten Programme auf dem Gerät
Durch das opsi eigene Paket "swaudit" können alle auf den Geräten installierten Programme, iden-
tisch zur Windows Programmau istung, auf dem Gerät angezeigt werden. Diese Ansicht zeigt auch
die Softwareversion und die Architektur, also ob das Programm als 32bit (x86) oder 64bit (x64)
Version installiert ist.
Über das Paket "hwaudit" kann die Verbaute Hardware des Rechners angezeigt werden. Dies er-
leichtert die Inventarisierung aller Rechner.
23Abbildung 3.6: Installationen können "on demand" ausgeführt werden
Soll ein Paket auf einem Rechner installiert werden, so muss für die jeweilige Software in Bereich
"Angefordert" auf Install gestellt werden. Im Normalfall wird das Installationsscript dann vor der
Anmeldung an dem Rechner ausgeführt. Wenn eine sofortige Installation gewollt ist, kann diese
über den Button "Jetzt on demand ausführen" sofort gestartet werden. Da es allerdings je nach
Paket eventuell zu einem Neustart bzw. zu einer optischen Anzeige auf dem Gerät kommt, was z.B.
Präsentationen des Users stören könnten, sollte diese Funktion nur in Absprache mit dem Kunden
erfolgen.
243.4 WPKG
3.4.1 Übersicht
WPKG ist genau wie opsi ein open-source Projekt, jedoch mit wesentlich geringerem Funktionsum-
fang. So besitzt es keine zentrale GUI, über die alle Rechner gesteuert werden können. Die Kon-
guration wird über ein zentraler Script realisiert. Auch ein Installationsstatus kann nicht zentral
eingesehen werden.
3.4.2 Lizenz
WPKG ist komplett kostenlos verwendbar. Auch werden keine weiteren kostenp ichtigen Pakete
angeboten. [vgl. 15]
3.4.3 Funktionen
WPKG besteht aus einer Clientanwendung, welche per .msi installiert werden kann, und einer
Netzwerkfreigabe auf einem Server.
Abbildung 3.7: Neztwerkfreigabe auf dem Server
In diesem Netzwerkshare be nden sich folgende wichtige (XML)-Dateien: [vgl. 16]
hosts.xml: Hier werden alle Host-Rechner de niert und einem Pro l zugeteilt.
pro les.xml: Hier werden die Installationspakete den Host-Pro len zugeteilt, vergleichbar mit
der Freigabe der Installation beim jetzigen System.
packages.xml: Hier werden die Installationspakete selbst de niert, also wie ein bestimmtes
Paket installiert werden soll.
con g.xml: Hier werden globale WPGK Con gurationen festgelegt.
wpkg.js: Hauptlogik der Software.
25Neben der Einstellungen auf dem Server durch die XML Dateien können auch auf dem Client-
Einstellungen bezüglich des Installationsvorgehens kon guriert werden. Dieses Kon gurationsfenster
kann nur mit Administrationsrechten auf dem Computer des Mitarbeiters aufgerufen werden.
Abbildung 3.8: Anmeldeinformationen am Server, Installationsuser
Unter dem Reiter "Path, users" kann eingestellt werden, mit welchem User sich der Rechner am
WPKG Server anmeldet, wo sich die Javascript-Datei zur Ausführung be ndet, sowie mit welchem
Systemuser die Installation letztendlich ausgeführt werden soll.
Abbildung 3.9: Ausführungszeitpunkt
Unter dem Reiter "Logon settings" kann eingestellt werden, wann die Software die Installationen
durchführen soll. Hier gibt es allerdings nur folgende Möglichkeiten: Beim Hochfahren oder beim
Herunterfahren des Rechners.
26Folgende Funktionen unterstützt WPKG nicht: [vgl. 16]
Betriebssysteminstallationen: so kann z.B. kein Windows oder Linux über WPKG zur Instal-
lation ausgeliefert werden.
"Software Push" Funktion: Eine Installation kann nicht aktiv über den WPKG Server gestartet
werden. Hier müsste ein Umweg eines Remote Procedure Calls gegangen werden, dieser ist
aus Sicherheitsgründen bei allen Syxos Kunden per Gruppenrichtlinie deaktiviert.
Signaturüberprüfung: Es wird nicht überprüft, ob ein Installationspaket eine gültige Signatur
aufweist, somit können fehlerhaft übertragene bzw. durch Hacker verändere Installationspa-
kete nicht vor der Ausführung identi ziert werden.
273.5 Panda Systems Management
3.5.1 Übersicht
Das Panda Systems Management stellt in diesem Vergleich die einzige Cloud-Lösung dar. Das
bedeutet, dass die einzelnen Rechner nicht mit einem lokal gehosteten und verwalteten Server kom-
munizieren, sondern mit einem Dienst in der Panda Cloud. In diesem Bereich gibt es noch zahlreiche
weitere Anbieter. Da Syxos bereits Panda Partner ist und somit auch eine kostenlose Testversion
zur Verfügung steht, el die Wahl auf diesen Anbieter.
3.5.2 Lizenz/Betriebskosten
Für das Panda Systems Management fallend laufend Kosten an, da der Betreiber die Ressourcen für
Speicher, Anbindung und Management übernimmt. Je mehr Lizenzen auf einmal gekauft werden,
desto günstiger werden diese. Eine Kostenreduktion pro Jahr kann auch erreicht werden, wenn eine
längere Laufzeit gekauft wird. [vgl. 17]
Menge Computer Laufzeit Kosten Kosten pro Rechner und Jahr
1-10 1 Jahr 29,00e 29,00e
1-10 3 Jahre 70,00e 23,33e
11-25 1 Jahr 28,00e 28,00e
11-25 3 Jahre 66,00e 22,00e
... ... ... ...
251-500 1 Jahr 19,00e 19,00e
251-500 3 Jahre 45,00e 15,00e
501-1000 1 Jahr 16,00e 16,00e
501-1000 3 Jahre 38,00e 12,67e
3.5.3 Funktionen
Anders als die anderen vorgestellten Lösungen, welche auf einem Server im Firmennetz zur Lagerung
der Softwarepakete und der Rechnerverwaltung setzen, läuft dies beim Panda System Management
alles über die Server der Betreiber.
Ein neuer Computer kann durch das Installieren des für den Kunden angepassten Installers auto-
matisch zum Panda System Management hinzugefügt werden.
28Abbildung 3.10: Übersicht Installationspaket
Die Installationspakete werden durch ein Kommando in einer Befehlszeile de niert. Es ist auch
möglich die Installationsdatei, mit in das Paket auf den Panda-Server zu hinterlegen. Dies ist al-
lerdings nur bei kleinen Softwaregröÿen sinnvoll, da diese jedes mal bei der Installation auf den
Client Rechner heruntergeladen werden. Dies kann sich bei vielen Rechnern ziemlich schnell häufen,
was unnötige Last auf die Internetverbindungen der Kunden generiert. Alternativ kann natürlich
auch ein Pfad im Netzwerk des Kunden im Script mitgegeben werden. Es reicht dann, groÿe Pakte
einmalig bei dem jeweiligen Kunden abzulegen.
Auch bietet Panda hier bereits vorde nierte Komponenten, für häu g verwende Software, wie 7-zip
und den Adobe Reader an, was den Verwaltungsaufwand reduziert.
Abbildung 3.11: Übersichtsseite des Geräteaudits
Auf der Übersichtsseite des Geräteaudits können alle Hardwareeigenschaften des Computers einge-
sehen werden. Dies erleichtert eine mögliche Inventarisierung.
29Weitere Hauptfunktionen des Panda Systems Management [vgl. 18, S. 8 -9]
Management von VMWare ESXI Servern, sowie von Geräten, welche das SNMP Protocol
unterstützen wie Drucker etc.
Software Lizenzmanager: Management von Softwarelizenzen anderer Programme.
Überwachung der Virenschutzsoftware
Selbstständiges Erkennen unverwalteter Geräte im gleichen Netzwerk
Fernzugri auf den Taskmanager, Registry-Editor und die Kommandozeile des Rechners
303.6 Vergleich der Lösungen
Die oben genannten Lösungen werden nun anhand der in der Analyse festgestellten, wichtigen Punk-
te untereinander verglichen. Nach der Auswertung der Liste kann ein Fazit gezogen werden, welche
Lösung sich bestmöglich für die Syxos GmbH eignet. Um dies zu erreichen, wird stets folgender
Punktespiegel verwenden und im Anschluss mit dem Faktor für die Wichtigkeit des Punktes Ver-
rechnet.
Punktevergabe: [vgl. 19]
Bewertung Punkt(e)
nicht erfüllt 0
gerade noch ausreichend 1
ausreichend 2
ausreichend - befriedigend 3
befriedigend 4
befriedigend - gut 5
gut 6
gut - sehr gut 7
sehr gut 8
sehr gut - überragend 9
überragend 10
3.6.1 Preisgestaltung (Faktor 3)
Der wichtigste Punkt für einen erfolgreichen Umstieg auf eine neue Softwareverteilung ist der Preis.
Ist dieser auch nur für einige Kunden zu teuer, führt dies zu einer Aufspaltung.
WPKG: 10 Punkte: da vollständig kostenlos
opsi: 8 Punkte: Hauptprogramm ist kostenlos, jedoch kann es nötig sein, bei groÿen Installati-
onsmengen, Pakete wie MySQL nachzukaufen. Hierbei sind die Preise auf die Gröÿenordnung
gerechnet sehr moderat.
Panda: 5 Punkte: Mit Preisen von knapp 13 e bis 20 e pro Jahr und Rechner noch vertretbar,
da keine groÿe Einmalzahlung auf die Kunden zukommt und im Gegenzug nicht mit eigener
Infrastruktur gearbeitet werden muss.
SCCM: 1 Punkt: Teure Einmalzahlung für den Server und hohe Gebühren für die einzelnen
Arbeitsplätze. Auch ist die Lizenz für den Windows Server für die Domäne, falls noch nicht
vorhanden, mit einzuberechnen.
3.6.2 Funktionsumfang (Faktor 2)
Der zweitwichtigste Punkt betrit den Funktionsumfang der Software, da bereits eine eingeschränkt
funktionierende Softwareverteilung (bedeutet zumindest bei Kunden mit Domaincontroller) in Ver-
wendung ist, muss die neue Lösung wesentlich mehr Funktionen bieten.
opsi: 9 Punkte: sehr umfangreiche Funktionen im Bereich Softwareverteilung, Unterstützung
verschiedener Betriebssysteme. Ebenfalls wird eine Verteilung von Neuinstallationen unter-
stützt. Inventarisierungen von Software und Hardware.
31 Panda: 9 Punkte: groÿer Funktionsumfang, nur eine Neuinstallation über den Anbieter läuft
aufgrund der Cloud-Struktur nicht. Inventarisierungen von Software und Hardware. Jede Men-
ge Zusatzfunktionen, welche aber schon aus Datenschutzgründen mit Vorsicht anzuwenden
sind. (z.B. der Fernzugri )
SCCM: 8 Punkte: hohe Integration in die Windows Domain Umgebung. Auch hier wird die
Bereitstellung von Betriebssystemen unterstützt.
WPKG: 4 Punkte: sehr eingeschränkte Funktionsweise, so kann keine Inventarisierung der
Geräte erstellt werden. Auch gibt es keine zentrale Übersicht, welche Software bereits installiert
wurde. Die Bereitstellung von kompletten Betriebssystemen wird nicht unterstützt.
3.6.3 Managebarkeit (Faktor 1)
Ein weiterer wichtiger Punkt ist ein gut funktionierendes Management der Installationen, sowie de-
ren Zeitpunkt. Die momentane Lösung kann hier Programme nur beim Herunterfahren installieren.
Opsi: 10 Punkte: gute Übersicht der Geräte, Softwareinstallationen können jederzeit oder beim
Herunterfahren bzw. Hochfahren installiert werden.
Panda 10 Punkte: gute Übersicht der Geräte, Gerät muss nicht mit Firmennetz verbunden
sein.
SCCM: 10 Punkte: gute Übersicht der Geräte, Softwareinstallationen können jederzeit oder
beim Herunterfahren bzw. Hochfahren installiert werden.
WPKG: 4 Punkte: relativ eingeschränkte Managebarkeit der Geräte, keinerlei gra sche Über-
sicht über den Installationsstatus, hier muss viel in Log Dateien überprüft werden. Installa-
tionen können nur an feste Gruppen bzw. einzelne Rechner verteilt werden.
Hier sind die Programme mit gra scher, zentraler Nutzerober äche natürlich im Vorteil
3.6.4 Domänenunabhängigkeit Faktor 1
Um mehrere Kunden über ein einzelnes Interface steuern zu können, ist es wichtig, dass diese
Domänen-unabhängig gesteuert werden können. Es ist wünschenswert, dass diese Programme ohne
eine Windows-Domäne lauähig sind.
Opsi: 9 Punkte: Es können Geräte unterschiedlichster Netzwerke und Windows-Domänen ohne
Vertrauensstellung miteinander verwaltet werden.
Panda: 8 Punkte: Es ist möglich, alle Kunden über einen einzigen Account zu managen, soll
dies nicht so verwaltet werden, müssen Pakete stets einzeln bei jedem Kunden im Konto
angelegt werden.
SCCM: 3 Punkte: Es ist nur möglich, mehrere Windowsdomänen mit Vertrauensstellung un-
tereinander zentral zu verwalten. Momentan bestehen keine Vertrauensstellungen zwischen
den einzelnen Domänen und Syxos. Der Kunde benötigt zum Betrieb einen Windows Domä-
nencontrollers mit allen verbundenen Kosten.
WPKG: 4 Punkte: WPKG spricht die Clients nur über den Namen an, ist dieser bei mehreren
Kunden gleich vertreten kann keine Zentralverwaltung verwendet werden.
323.6.5 Zusammenfassung
Vergleichspunkt SCCM opsi WPKG Panda Gesamt Möglich
Preisgestaltung 3 24 30 15 30
Funktionsumfang 16 18 8 18 20
Managebarkeit 10 10 4 10 10
Domänenunabhängikeit 3 9 4 8 10
Gesamtpunkte: 32 55 46 52 70
Im Vergleich der aufgeführten Verteillösungen hat sich für die Firma Syxos das Produkt opsi durch-
setzen können.
Zusammenfassend kann gesagt werden, dass sich opsi vor allem wegen seiner guten Preisgestal-
tung (Hauptteil kostenlos mit kostenp ichtige Addons, falls benötigt) als Sieger dieses Vergleiches
ergibt. Auch bei der Verwaltung konnte es überzeugen. Das Design der Software, welches beim
Hochfahren und Installieren zum Vorschein kommt, ist jedoch ein wenig überholt.
334 Migration auf das neue System
4.1 Installation der Server
Mit dem Wechsel auf opsi soll nach und nach die bisher verwendete Scriptstruktur abgelöst wer-
den. Um dies zu erreichen, wird ein zentraler Syxos opsi-Server eingerichtet. Da sich die Autohaus-
Kunden extrem von den restlichen Kunden aus Softwaresicht unterscheiden, wird die Verwaltung auf
zwei Hauptsysteme verteilt. Alle hier beschriebenen Methoden wurden auf einer Live-Systemumgebung
getestet, jedoch noch nicht auf einen Anwenderrechner als Client, sondern einer virtuellen Maschine.
Abbildung 4.1: Geplanter Aufbau des Softwareverteilnetzwerkes, Einzelkunde beispielhaft für alle
Kunden des Bereiches
Da wir auf verteilten Systemen mit mehr oder weniger guter Internetanbindung arbeiten, ist es
Sinnvoll nicht alle Installationen von einem syxos-eigenen Zentralserver zu verteilen, sondern bei
den Kunden eigene Depotserver zu betreiben, welche die Softwarepakete lokal im Kundennetz hal-
ten. Lokal gehaltene Softwarepakete werden dann direkt vom opsi-Depotserver des Kunden verteilt.
Bei Kunden, welche zu einem Groÿteil über eine VPN Verbindung am Laptop arbeiten, entsteht
durch diese Methode kein Geschwindigkeitsvorteil.
Hierfür muss zuerst eine Zentralinstanz auf einem syxos-eigenen Server eingerichtet, sowie das Rou-
ting auf das jeweilige Kundennetzwerk freigegeben werden. Zu diesem Zweck bietet die opsi Webseite
einen Komplettdownload einer vorkon gurierten virtuellen Maschine an, welche z.B. auf einem Vm-
Ware ESXI Server importiert werden kann. Somit ist der Zentralserver nun per IP-adresse aus dem
34jeweiligen Kundennetz erreichbar. Im Anschluss muss bei jedem Kunden, welcher an das System
angeschlossen werden soll, ein eingener opsi-Server installiert werden. Danach wird folgender Befehl
in einem root Terminal auf dem opsi-depotserver des Kunden ausgeführt:
opsi - setup -- register - depot
Dies bewirkt, dass dieser Server auf einem opsi-con g Server registriert werden kann. [vgl. 20, S.331-
340]
Abbildung 4.2: Eingabefenster Opsi-depot Registierung: Hier wird der Hostserver für die opsi-
Kon guration eingetragen.
Im erscheinenden Fenster können nun wichtige Einstellungen gesetzt werden.
Abbildung 4.3: Eingabefenster der Depotinformationen. Diese Einstellungen können auch nachträg-
lich noch verändert werden.
Da die Registrierung des Depotservers an den Kon gurationsserver per Namensau ösung funktio-
niert und wir in einem DNS-technisch abgetrennten Netz arbeiten, ist es noch nötig den DNS Namen
35des Kon gurationsservers in die Hosts Datei des Depotservers einzutragen. Hierzu die Datei
/etc/hosts mit root Rechnten editieren und den Hostnamen des Kon gurationsservers im gleichen
Stil wie die anderen Einträge nachtragen. [vgl. 21]
Im Anschluss daran sollte die Registrierung am Kon gurationsserver abgeschlossen sein.
4.2 Sicherheitsprobleme minimieren
Theoretisch ist es für einen Hacker möglich, nach dem Eindringen auf dem opsi-Server auf den
Arbeitsplätzen, aber auch den Servern Viren zu installieren, deshalb muss dieser bestmöglich von
auÿen abgeschirmt werden. Dieses Problem gab es zwar bereits vorher, da aber nun auf ein stark
dokumentiertes System gewechselt wird, ist es für den Angreifer einfacher, die benötigten Soft-
warepakete für sein Vorhaben zu verteilen. Deshalb sollten unbedingt alle folgenden Maÿnahmen
eingehalten werden: [vgl. 22]
Verwendung eines Virenschutzprogramms, sowohl auf dem Arbeitsplatzrechnern als auch auf
den Servern.
Regelmäÿige (mindestens tägliche) Komplettsicherungen der Server und Sicherung der Doku-
mente der Benutzer.
Minimalinstallation auf den Servern verwenden, also nur Software installieren, die wirklich
benötigt wird, da zusätzliche Pakete stets Sicherheitslücken mitbringen können.
Verwendung komplizierter und einzigartiger Passwörter für den Administrator.
Zugang auf dem Softwareserver nicht durch einen geöneten Port aus dem Internet sondern
nur durch eine VPN Verbindung.
4.3 Installation auf den Clients
Damit opsi den jeweiligen Client verwalten kann, ist es erforderlich, dass die opsi Software mit ent-
sprechender Bindung zum Depotserver auf dem Rechner installiert wird. Der einfachste Weg hierfür
ist, auf dem Zielrechner das Netzlaufwerk opsi_depot des jeweiligen opsi-depotservers des Kunden
mit dem Benutzer pcpatch zu mounten. [vgl. 23, S.142] Im Anschluss kann über die Kommandozei-
le :\opsi-client-agent\silent_setup.cmd ausgeführt werden. Nach der Eingabe der
Anmeldedaten für den Server und einem Neustart des Rechners ist dieser auf dem Depot registriert.
4.4 Erzeugung eines Paketes
Die einfachste und schnellste Methode- um ein neues opsi-Paket zu erzeugen, ist die Verwendung
der Programme opsi Setup Detektor in Verbindung mit dem opsi PackageBuilder. Der Opsi Setup
Detektor erzeugt alle nötigen Scripte für eine Installation und Deinstallation des Produktes. Das
dadurch entstehende Verzeichnis kann dann mithilfe des opsi PackageBuilder in ein .opsi Paket
verpackt werden, welches dann auf einem oder mehreren opsi depots installiert werden kann.
4.4.1 opsi Setup Detektor
Der einfachste Weg den opsi Setup Detektor zu erhalten, ist ihn über die vorde nierten Pakete eines
opsi-Servers auf einen Clienten zu installieren, welcher bereits auf einem opsi-Server registiert ist.
36Abbildung 4.4: opsi Paketverwaltung des Clients opsi-setup-detector Installation
Nachdem die Installation ausgeführt wurde, kann das Programm normal auf dem Client gestartet
werden. Beim Erststart sollte noch der Pfad zur Startdatei des opsi PackageBuilders angegeben
werden. Damit kann direkt nach der Scripterstellung ein Paket gebaut werden.
Abbildung 4.5: Eingabe des Pfades des opsi Packagebuilders, dieser be ndet sich normalerweise
unter C:\Program Files (x86)\opsi PackageBuilderNG\opsipackagebuilder.exe
Ist dies geschehen, kann über die Hauptseite eine .msi oder .exe Datei geladen werden. In diesem
Beispiel wird eine .msi eines BMW Betriebes geladen.
37Abbildung 4.6: Startauswahl opsi SetupDetektor
Im Anschluss sucht das Programm automatisch:
Befehl um eine Installation ohne Meldung zu erzeugen
Benötigter Speicherplatz für die Software
Version der Software
Der Installationspfad muss selbst eingegeben werden, dieser kann am besten nach der Testinstalla-
tion der Software mit dem Unattended Installations Kommando herausgefunden werden. In diesem
Fall legt der Installer keinen Deinstaller ab, wodurch das Feld für die Deinstallation frei bleiben
muss.
Abbildung 4.7: Setupeinstellungen der Software
Beim anschlieÿenden Erzeugen muss ein Pfad zu einer opsi Workbench angegeben werden. Hier
sollte das gemountete Netzlaufwerk opsi-workbench des opsi-servers angegeben werden. Wurde der
Pfad des opsi PackageBuilders angegeben, kann in der Auswahl direkt der Haken unter Erstelle opsi
Produkt Dateien und starte interaktiven Packagebuilder, ausgewählt werden.
38Abbildung 4.8: Erzeugen des Paketes
Nach einem Klick auf den Button opsi Paket erstellen, önet sich der opsi PackageBuilder. [vgl. 20]
4.4.2 opsi PackageBuilder
Der opsi PackageBuilder kann über die Webseite:
https://forum.opsi.org/viewtopic.php?f=22&t=7573
heruntergealden werden. Nach der Installation auf dem gleichem Gerät wie der opsi Setup Detektor,
sollte hier nach dem Erststart unter
Extras->Einstellungen der opsi-Server angegeben werden, auf dem das Paket nach dem Packen
geladen werden soll.
39Abbildung 4.9: Einstellung der Zugangsdaten des opsi-Servers
Danach kann der opsi PackageBuilder wieder geschlossen werden. Beim nächsten Start bzw. Start
durch den Setup Detektor sollte eine Verbindung mit dem opsi-depot aufgebaut werden.
Abbildung 4.10: Paketeinstellungen im ospi Package Builder
Nachdem die Paketeinstellungen noch einmal bearbeitet werden, kann im Anschluss eine .opsi Datei
mit einem Klick auf Packen auf dem opsi Depotserver erzeugt werden. Diese muss im Anschluss auf
dem opsi con g editor unter Server-Konsole -> opsi -> Paket-Installation noch installiert werden.
40Abbildung 4.11: Paketeinstellungen im ospi Package Builder hier muss das Paket ausgewählt und
die Depotauswahl getroen werden.
414.5 Verarbeitung standort- und rmenspezi scher Scripte
Scripte bzw. Programme, welche nur auf einem Standort bzw. nur bei einem Kunden verwendet
werden, können wie vorher beschrieben erzeugt aber dann nicht auf alle Depotserver verteilt, sondern
nur auf dem bestimmten Depotserver installiert werden. Dies verhindert, dass am Hauptserver und
auf allen restlichen Depots unnötig Speicherplatz verbraucht wird.
Beispielprogramme bzw. Scripte:
Virenschutzsoftware, welche nur ein einzelner Kunde in Verwendung hat.
Software, die für jeden Kunden einen angepassten Installer bereitstellt z.B. Banksoftware,
Virenschutz.
Software für Drucker, die nur der Kunde im Einsatz hat.
4.6 Eignung von opsi im BMW-Umfeld
Im Vergleich zum bereits in Verwendung be ndlichen ISPI-Next Tool ergibt sich ein entscheidender
Nachteil von opsi: Die Pakete müssen stets neu aufgebaut werden, wenn ein Update zur Verfügung
steht.
Auch kann es vorkommen, dass nicht alle Autohäuser zur selben Zeit für die selben Softwareupdates
freigeschaltet werden, was zu einer möglichen Sperre der Programme führen kann.
Deshalb sollte opsi in diesem Bereich nur als schnelle Installationsmöglichkeit für neue Software
verwendet werden. Hierfür eignet es sich hervorragend, da die Erstellung eines Paketes mit den
Tools in wenigen Minuten erreicht und im Anschluss schnell verteilt werden kann.
Das ISPI-Next Tool sollte für die Updates, welche regelmäÿig nachts laufen sollten weiterhin im Be-
trieb bleiben. Opsi kann jedoch zur Überprüfung der Updatestände mithilfe des Plugins "swaudit"
genutzt werden. Dies zeigt die momentan installierte Softwareversion an.
Die Alternative ist der Ausbau eines Reportingkanals auf dem Ispi-Next Tool um zentral die Instal-
lationsstände abfragen zu können.
425 Fazit
Der Wechsel von einer bereits bestehenden, selbst verwalteten Softwareverteilstruktur mag anfangs
sehr viel Arbeit bedeuten, im Anschluss an den Rollout einer solchen Software überwiegen die Vor-
teile jedoch ziemlich schnell.
So kann jetzt zentral der Installationsstatus von Softwarepaketen aus dem opsi Depot, sowie auch
generell installierte Software angezeigt und schneller verwaltet werden. Die Installation von Softwa-
reupdates können so auch e zienter gemacht werden, da keine Installationsstatusdateien auf dem
jeweiligen Kundensystemen gelöscht werden müssen.
Im Vergleich verschiedener Softwarelösungen war es vor allem wichtig, dass die Einsatzkosten pro
Kunde nicht allzu groÿ werden, da sich sonst einige Kunden enthalten würden, was den Sinn ei-
nes solchen Systems komplett zunichte gemacht hätte. Mit opsi wurde hier eine optimale Lösung
gefunden. Die Hauptversion ist kostenlos verfügbar und nur bei eventuell später benötigten Zusatz-
paketen, wie das MySQL Backend fallen Kosten an.
Für die Verwaltung der regelmäÿig upzudatenden Software im BMW-Betrieb (vor allem in der Werk-
statt, da hier Update Fristen gehalten werden müssen) werden wir jedoch weiterhin auf das selbst
programmierte Syxos ISPI-Next Tool zurückgreifen, da hier die Updates komplett ohne Eingreifen
unsererseits zusammengestellt und installiert werden. Hier wird es nur in Zukunft nötig, entweder
den Softwarestand mit opsi abzufragen oder einen Reportingkanal in das bestehende System ein-
zuarbeiten, damit bei fehlerhaften Installationen bzw. Downloads der Pakete schnell eingegrien
werden kann.
43Literatur
[1] Andreas Donner. Was ist eine Domäne / Netzwerkdomäne? (geprüft am 07.12.2020). 1.02.2019.
url: https://www.ip-insider.de/was-ist-eine-domaene-netzwerkdomaene-a-626054/.
[2] Holger Voges. Windows Gruppenrichtlinien (geprüft am 06.12.2020). url: https : / / www .
netz-weise-it.training/images/dokus/Gruppenrichtlinien.pdf.
[3] Bundesamt für Sicherheit in der Informationstechnik. Aufbau von Virtual Private Networks
(VPN) und Integration in Sicherheitsgateways (geprüft am 15.12.2020). url: https://www.
bsi.bund.de/SharedDocs/Downloads/DE/BSI/Internetsicherheit/vpn_pdf.pdf?__blob=
publicationFile.
[4] Proceedings of the
John B. Tyndall. Building an eective software deployment process. In:
40th annual ACM SIGUCCS conference. Hrsg. von Carol Rhodes. New York, NY: ACM, 2012,
S. 109. isbn: 9781450314947. doi: 10.1145/2382456.2382482.
[5] Google. 4. Bereitstellen und testen - Google Chrome Enterprise-Hilfe (geprüft am 22.12.2020).
22.12.2020. url: https://support.google.com/chrome/a/answer/7650247?hl=de.
[6] Mozilla. How to Silently Install/Uninstall Firefox for Enterprise | Firefox for Enterprise Help
(geprüft am 22.12.2020). 22.12.2020. url: https : / / support . mozilla . org / en - US / kb /
silently-install-uninstall-firefox-enterprise.
[7] Windows Command Line. Uninstall programs from windows command line (geprüft am 08.01.2021).
1.01.2021. url: https://www.windows-commandline.com/uninstall-programs-windows-
command-line/.
[8] Thomas Joos. Microsoft System Center Con guration Manager Current Branch: Der schnelle
Einstieg in die automatisierte Client- und Serververwaltung von Windows-Netzwerken. Hanser
eLibrary. München: Hanser, 2018. isbn: 9783446452497. doi: 10.3139/9783446452497.
[9] Microsoft. System Center 2016 Lizenzierungsdatenbaltt (geprüft am 02.12.2020). Hrsg. von Mi-
crosoft. https://www.microsoft.com/de-de/system-center/pricing. url: https://download.
microsoft . com / download / B / B / B / BBBA8880 - FECE - 4FB2 - BCCD - B50E3AE00023 / System _
Center_2016_licensing_datasheet_EN_US.pdf.
[10] Microsoft. System Center Lizenzierung und Preise (geprüft am 01.12.2020). Hrsg. von Mi-
crosoft. 1.12.2020. url: https://www.microsoft.com/de-de/system-center/pricing.
[11] ALSO. ALSO Deutschland GmbH - MS System Manager Lizenz (geprüft am 02.12.2020).
2020. url: https : / / www . also . com / ec / cms5 / 1010 / ProductDetailData . do ? prodId =
1440653&context=ASN3&keyword=System%20Center%20Cal.
[12] uib gmbh. about opsi - opsi.org (geprüft am 07.12.2020). 7.12.2020. url: https://www.opsi.
org/product/about-opsi.
[13] uib gmbh. opsi cofunding projects (geprüft am 07.12.2020). 7.12.2020. url: https://www.
uib.de/en/opsi-cofunding/cofunding/.
[14] uib gmbh. opsi Re nanzierungsbeiträge (geprüft am 08.12.2020). 8.12.2020. url: https://
www.uib.de/de/opsi-erweiterungen/preise-erweiterung.
44Sie können auch lesen
