Bachelorarbeit. Konfigurationsmanagement. Sebastian Dahnert 5. Januar Betreuer: Prof. Dr. Paul Müller Tino Labudda Christian Peter.

Transkript

1 Bachelorarbeit Konfigurationsmanagement Sebastian Dahnert 5. Januar 2012 Betreuer: Prof. Dr. Paul Müller Tino Labudda Christian Peter Informatik ICSY - Integrated Communication Systems Universität Kaiserslautern Postfach Kaiserslautern

2

3 Hiermit erkläre ich, dass ich die von mir vorgelegte Arbeit selbständig verfasst habe, dass ich die verwendeten Quellen, Internet-Quellen und Hilfsmittel vollständig angegeben habe und dass ich die Stellen der Arbeit einschließlich Tabellen, Karten und Abbildungen, die anderen Werken oder dem Internet im Wortlaut oder dem Sinn nach entnommen sind, auf jeden Fall unter Angabe der Quelle als Entlehnung kenntlich gemacht habe. Kaiserslautern, den 5. Januar 2012 Sebastian Dahnert

4

5 Abstract (German) In der Arbeit wird zunächst das Konfigurations-Management näher definiert und eine Allgemeine Modellierung vorgestellt. Danach folgt ein kurzer Überblick über vier Opensource Konfigurations-Managementsysteme Chef, CFEngine, Puppet und STAF. Diese werden allgemein gegenüber gestellt. Die zwei bestbewertesten Systeme CFEngine und Puppet werden installiert und Testkonfigurationen erstellt um die Systeme miteinander vergleichen zu können. Die Entscheidung fiel auf Puppet, da der Verwaltungsaufwand geringer ist als bei CFEngine und in Puppet man automatisch eine Dokumentation für die Konfigurationen erstellen kann. Danach wurde Puppet für den Produktiveinsatz in Form eines Webservers getestet. Abstract (English) In this paper defines first the configuration management and suggest a general model. Then follows a short overview about four Open-Source configuration management systemes Chef, CFEngine, Puppet and STAF. This will be compared on a general way. The two systems CFEngine and Puppet would be installed and tested for a comparison. The dicision was for Puppet, because the administration effort is better than CFEngie. Puppet has the feature to generate automatically a documantion from the configurations. At last Puppet was tested in a productivity in terms of a webserver.

6

7 Inhaltsverzeichnis 1. Einleitung Definition Konfigurationsmanagement Kurzbeschreibung Definition Konfigurationsfunktionen Konfigurationsidentifikation (Configuration Identification) Konfigurationssteuerung (Configuration Control) Konfigurationsstatusüberwachung (Configuration Status Accounting) Konfigurationskontrolle (Configuration Verification & Audit) Funktionsbeschreibung für die Ausführung von Änderungen Gesamtüberblick Allgemeine Modellierung Basisnetzwerkkonfiguration Basiskonfiguration Konfigurationsklassen Gegenüberstellung der Konfigurationsmanagementsysteme Konfigurationsmanagementsoftwaresystem Chef Konfigurationsmanagementsoftwaresystem CFEngine Konfigurationsmanagementsoftwaresystem Puppet STAF Allgemeiner Vergleich der Konfigurationsmanagementsoftware Vergleich CFEngine und Puppet Testumgebung Erstellung der Testumgebung Installation und Konfiguration Puppet Installation und Konfiguration CFEngine Konfiguration der promises.cf Sektion 1: body common control Sektion 2: body agent control Sektion 3: body runagent control Sektion 4: body server control Sektion 5: bundle server access_rules Webinterfaces Implementierung der Testkonfigurationen Testkonfiguration Paketinstallation Verwalten der Status von Diensten

8 4.5.3 User hinzufügen Konfigurationsdateien ändern Dateiverwaltung Ergebnis Produktiveinsatz in Puppet Modul Webserver Beschreibung der Konfigurationsklassen Automatische Dokumentation Fazit Zusammenfassung und Ausblick Literaturverzeichnis Abbildungsverzeichnis

9 1. Einleitung In der heutigen Zeit werden in Firmen immer mehr vernetzte Computer verwendet. Diese Arbeitsplätze müssen einzeln installiert und konfiguriert werden, was einen hohen Zeitaufwand erfordert. Um diesen zu kompensieren, wurde das Konfigurationsmanagement [AiSa10, RuCo12] entwickelt, damit dies automatisch und zentral gesteuert werden kann. Ein großer Vorteil vom Konfigurationsmanagement ist, dass die Installation und Konfiguration der einzelnen Arbeitsstationen zentral gesteuert und die entsprechende Dokumentation der Konfigurationen einem Standard entsprechen, um einen besseren Gesamtüberblick aller verwalteten Computer zu haben. Weiterhin geht es auch um die Gewährleistung der Sicherheitsaspekte für die jeweiligen Firmen, d.h. entsprechende Sicherheitsfeatures oder Programme können von den Administratoren zentral installiert und auf den verwalteten Computer eingerichtet werden. Es gibt auf dem Markt eine große Anzahl von Konfigurationsmanagementsoftwaresystemen. Doch nur einige der Konfigurationssoftware unterstützen mehrere Betriebssysteme, wie Linux und Windows gleichzeitig. Durch die Kosten und den unterschiedlichen Anforderungen in den heterogenen Umgebungen, wie in universitären- und Forschungseinrichtungen, wird selten ein Konfigurationsmanagement genutzt. Das heißt, die Installation, die Konfiguration sowie die Wartung der einzelnen Workstations werden dezentral durchgeführt, wodurch die Computer unterschiedliche Installationen und Konfigurationen besitzen. Das führt auch dazu, dass die Dokumentation unvollständig sein kann und dadurch können Sicherheitslücken übersehen werden. Somit vergrößert sich die Gefährdung, Opfer von Angriffen aus dem Internet zu werden. Im Konfigurationsmanagement werden sogenannte Templates implementiert, diese sorgen für eine einheitliche Installation auf den einzelnen Computern. Zum Beispiel für bestimmte Softwarepakete, oder die Umsetzung der Sicherheitsrichtlinien auf allen Computern des Unternehmens, beispielsweise die einheitliche Konfiguration der Firewall Regeln. Unter der Vorgabe, dass die Konfigurationsmanagementsoftware Open Source ist und auch Linux sowie Windows unterstützen soll, werden in meiner Arbeit nur die Softwarepakete, die diese Aspekte erfüllen, berücksichtigt. Durch die allgemeine Gegenüberstellung und den Vergleich der einzelnen Konfigurationsmanagementpakete wurde eine Auswahl getroffen. Durch den allgemeinen Vergleich entschied ich mich für das Softwarepaket Puppet und CFEngine. Beide wurden in einer nahezu identischen Testumgebung installiert und Testkonfigurationen wurden erstellt und getestet. Aufgrund meiner Bachelorarbeit kam es zur Entscheidung für ein Konfigurationsmanagementsystem. Dieses wird beim Fraunhofer- Institut für Techno- und Wirtschaftsmathematik (ITWM) eingeführt. Eine Modellierung für die spezifischen Bereiche des Fraunhofer ITWMs wurde erstellt und entsprechend in das Konfigurationsmanagementsystem implementiert. Auf dieses Ziel hinarbeitend, werde ich in Kapitel 2 zunächst das Konfigurationsmanagement genauer beschreiben. Außerdem werde ich die allgemeine Modellierung solcher Konfigurationen näher betrachten. Im dritten Kapitel stelle ich die verschiedenen Open Source Konfigurationsmanagementsysteme von Chef, CFEngine, Puppet und STAF gegenüber. Diese vier Systeme unterstützen sowohl das Betriebssystem Linux als auch Windows. Durch die Bewertung der vier Systeme entschied ich mich für die zwei Konfigurationsmanagementsysteme, CFEngine und Puppet. Im vierten Kapitel werden beide Systeme genauer beschrieben und welche Testaufgaben für beide Systeme durchgeführt wurden. Anschließend wird in Kapitel 5 in Puppet eine Webservermodellierung implementiert. Kapitel 6 schließt meine Arbeit mit einer Zusammenfassung ab. 3

10 2. Definition Konfigurationsmanagement 2.1 Kurzbeschreibung Da es viele verschiedene Definitionen zum Konfigurationsmanagement gibt, nehme ich als Bezug die von der International Organization for Standardization (ISO) vereinheitliche Definition für das Konfigurationsmanagement in der ISO [Och09]. Die ISO beinhaltet eine genaue Beschreibung, was ein Konfigurationsmanagement beinhalten soll. Als erstes stellt sich die Frage, was ist ein Konfigurationsmanagement. Das Konfigurationsmanagement beinhaltet eine Sammlung von Tools, Techniken und Routinen, um die Kosten zu senken und die Leistung, für die in der Firma eingesetzten Computer, zu steigern. Zugleich ist es auch ein Verwaltungstool, in dem die Dokumentation für jeden einzelnen Computer erstellt, verwaltet und bearbeitet werden und auch Änderungen vor Ort an den PCs protokolliert und kontrolliert werden. Um dies gewährleisten zu können, muss das Konfigurationsmanagement folgende Bereiche unterstützen können: Hardware-, Softwaresowie Firmwareebene. Weiterhin müssen die Bereiche Dokumentation und Spezifikation abgedeckt werden. Deshalb sind auch in der ISO für das Konfigurationsmanagement mehrere Funktionen definiert. Die Funktionen lauten: -Konfigurationsidentifikation -Konfigurationssteuerung -Konfigurationsstatusüberwachung -Konfigurationskontrolle 2.2 Definition Das Konfigurationsmanagement[Och09, Fra02] ist ein Teil eines Managements, das fokussiert ist auf die Einrichtung und die Erhaltung der Konsistenz der verwalteten Workstations oder der Performance dieser Systeme und deren Funktionstüchtigkeit sowie der physikalischen Attribute (z.b. Taktfrequenz, Speichermedium usw.). Erforderlich ist es auch, dass das System, die Systemvoraussetzungen, operationale Informationen und Dokumentationen komplett erhalten bleiben und weiterhin verfügbar sein müssen. Durch die Kontrolle der Änderungen im Konfigurationsprozess müssen sämtliche Sicherheitsaspekte sowie die Sicherung des kompletten Lebenszyklus eines Informationssystems gesichert werden. Das heißt Hardware, Software, Firmware, Dokumentation, Test, Testzubehör und die Testdokumentation müssen vom Konfigurationsmanagement abgedeckt werden. 2.3 Konfigurationsfunktionen Konfigurationsidentifikation (Configuration Identification) Es ist ein Prozess zur Identifikation von den Attributen, welche für jeden Aspekt eines Konfigurationsitems definiert sind. Konfigurationsitems sind die Hardware- oder Softwareprodukte, die vom Benutzer benötigt werden. - Attributwerte sind in der Konfigurationsdokumentation dokumentiert - Basisattributwerte ermöglichen eine einheitliche Konfigurationsänderung und kontrollieren alle Phasen, in denen die Änderungen durchgeführt werden. 4

11 2.3.2 Konfigurationssteuerung (Configuration Control) Die Konfigurationsänderungssteuerung ist eine Reihe von Prozessen und Änderungsphasen, die benötigt werden, um die Attributwerte eines Konfigurationsitems zu ändern oder gegebenenfalls in den Ursprungszustand zurückzusetzen. Mögliche Änderungen sind zum Beispiel für die Konfigurationsitems: fehlerhafte Dateien zu korrigieren die Benutzerfreundlichkeit und Zuverlässigkeit zu verbessern Sicherheitsprobleme, bzw. Sicherheitslücken zu schließen einen Programmfehler korrigieren die Performance und/oder die Funktionalität erhöhen, die Produktivität steigern die Kosten reduzieren Integration neuer Kundenanforderungen Verbesserungen der Installation, der Dienste oder der Wartung. Für die Änderung der Konfigurationsitems wird ein Änderungsplan erstellt. In diesem Änderungsplan werden die jeweiligen Phasen identifiziert, die für die Ausführung der Änderungen verantwortlich sind. Um die Effektivität des Änderungsplanes zu spezifizieren gibt es zwei unterschiedliche Ausführungsarten, die Datumseffektivität oder die serielle Effektivität. Datumseffektivität ist normalerweise die traditionelle Art zum Definieren der Effektivität. Das heißt, zu einem vorher festgelegten Zeitpunkt muss die Änderung stattfinden oder durchgeführt sein. Serielle Effektivität ist typischerweise an die Konfigurationsitems gebunden, welche aufeinander folgend durchnummeriert sind. Die serielle Effektivität ist manchmal die vorteilhaftere Technik, da dort die geplante Konfiguration von den Konfigurations-Itemnummern abhängig ist und somit nicht abhängig von Änderungen des Konfigurationszeitplans Konfigurationsstatusüberwachung (Configuration Status Accounting) Die Konfigurationsstatusüberwachung dient der Benachrichtigung und dem Aufzeichnen jeder ausgeführten Konfiguration, welche über die Konfigurationsitems assoziiert werden. Daher sollten diese Statusmeldungen einen kompletten Schritt der Veränderung sowie in jede weitere Phase seines Lebenszyklus dokumentiert sein. Dafür gibt es folgende Phasen: 1. As-designed and as-planned configurations: Für Konfigurationsitems die schon implementiert sind oder für zukünftig geplante Implementierungen von Konfigurationsitems. 2. As-built configurations enthalten die Genehmigung für jede Veränderung von der asplanned configuration. 3. Change traceability: Ist die genaue Protokollierung der geplanten oder der offenstehenden Änderungen, inklusive der Effektivität Konfigurationskontrolle (Configuration Verification & Audit) Die Konfigurationskontrolle wird in zwei Teile aufgesplittet, in die funktionale und der physischen Konfigurationskontrolle. Dies geschieht immer, wenn eine Änderung bevorsteht oder ausgeführt wurde. Die funktionale Konfigurationskontrolle überprüft, ob die Funktionalattribute und die Leistungsattribute eines Konfigurationsitems erreicht werden. 5

12 Die physische Konfigurationskontrolle stellt sicher, dass ein Konfigurationsitem installiert wird und mit den zuvor festgelegten Voraussetzungen übereinstimmt. 2.4 Funktionsbeschreibung für die Ausführung von Änderungen Die Konfigurationsdaten werden in Bitmustern auf der Festplatte gespeichert [Bur03, Bur04, Bur95]. Alle definierten Funktionen müssen auf dieser Bitebene operieren können. Außerdem muss sichergestellt werden, dass diese Funktionen den gewünschten Effekt haben. D.h. sie müssen von einer Funktion in eine andere Funktion überführt werden können, dies nennt man auch den "Konfigurationsraum". Dieser Konfigurationsraum definiert die Funktionen und deren Änderungsfunktionen. Um sicherzustellen, dass auch die Funktionen eindeutig und immer wieder die gleichen Änderungen durchführen, werden zwei zusätzliche Eigenschaften wie Konvergenz und Idempotenz benötigt. Die Konvergenz stellt sicher, dass man den aktuellen Systemzustand in den gewünschten Änderungszustand berechnen kann und dies auch so durchgeführt wird. Während die Idempotenz jede Operation als eine atomare Funktion gliedert, welche auch immer konvergent ist. Daher sind auch die Reihen von idempotenten Funktionen konvergent. Dies ermöglicht, dass das Konfigurationsmanagement den gewünschten Zielzustand erreicht oder falls doch nicht in der Lage ist dies per Logfile oder Fehlermeldung anzuzeigen. Darum werden auch in einigen Konfigurationsmanagementsystemen eigene deklarative "domain specific language" verwendet. Diese beruhen zwar auf vorhandenen Programmiersprachen, wurden jedoch erweitert um ein benutzerfreundlicheres "Interface" bereitzustellen und auch die Idempotenz und Konvergenz der Funktionen, sicherzustellen. Beispiel hierfür sind CFEngine und Puppet. Der Unterschied zwischen dieser deklarativen Sprache in CFEngine und eines UNIX Befehls zeigt das Beispiel für die Erstellung eines symbolischen Links: Der Befehl in CFEnigne lautet "file1-> file2" während bei UNIX der Konsolenbefehl "ln -s file2 file1" eingegeben werden muss. Weitere Beispiele befinden sich in [Bur95]. 6

13 2.5 Gesamtüberblick In den vorherigen Kapiteln wurden die einzelnen Punkte der ISO erläutert. Daraus ergibt sich, dass das Konfigurationsmanagement Änderungen jeder Art durchführt und gewährleistet, dass diese dokumentiert und protokolliert werden. Weiterhin ist auch das Monitoring wichtig, da durch die Überwachung der Clients, z.b. schwerwiegende Systemfehler oder Softwarefehler die auftraten, dokumentiert oder festgehalten werden und ebenso darauf geachtet wird, dass die Konfigurationen korrekt ausgeführt werden. Die nachfolgende Grafik veranschaulicht die zuvor beschriebenen Funktionen in einer gesamteinheitlichen Abbildung. Abbildung 1 Überblick über das Konfiguration Management [Och09] 2.6 Allgemeine Modellierung Damit das Konfigurationsmanagement entsprechend der Unternehmensstruktur die Konfigurationen implementieren kann, wird eine unternehmensspezifische Modellierung benötigt. Daher wird zunächst eine allgemein gültige Modellierung erstellt, mit der Option, dass jedes Unternehmen diese allgemein gültige Modellierung übernehmen kann und entsprechend ihrer Bedürfnisse und ihren Vorstellungen erweitern können. Hierzu wird eine Vererbungshierarchie von unten nach oben erstellt. D.h. es gibt dedizierte (reale Maschinen) oder virtuelle Maschinen mit ihren Hardwareeinstellungen. Danach folgt eine Kette von Konfigurationsklassen, die den entsprechenden Typ einer Maschine charakterisieren. 7

14 Im Bezug auf das Fraunhofer ITWM gibt es folgende Maschinen: Webserver Dateiserver Datenbankserver Lizenzserver Desktop-PC mobiles Endgerät Auf der Ebene der Vererbungshierarchie gibt es noch weitere Möglichkeiten verschiedene Typen je nach Unternehmensstruktur zu erstellen oder auf existierende Klassen zurück zu greifen. Es ist möglich, mehrere dieser Konfigurationsklassen auf derselben Maschine zu nutzen, ein Beispiel, die Webserverklasse und zugleich noch die Datenbankserverklasse. Nach der Vererbungshierarchie folgt die Basisnetzwerkkonfiguration und darauf baut die Basiskonfiguration auf, diese beiden Konfigurationen sind auf allen Maschinen identisch. Auf dieser Grundlage aufbauend, kann man nun für jedes Unternehmen seine spezifischen Einrichtungen über diese Modellierung erstellen. Dies bedeutet, dass man nun die entsprechenden Klassen der Vererbungshierarchie auswählen und diese im Konfigurationsmanagement implementieren kann. Grafik zu der Konfigurationsvererbungshierarchie: Abbildung 2 Klassendiagramm der Konfigurationen 8

15 2.6.1 Basisnetzwerkkonfiguration In der Basisnetzwerkkonfiguration werden die Netzwerkeinstellungen vorgenommen, die für das Unternehmen benötigt werden, damit die Maschinen im Unternehmensnetzwerk kommunizieren können. Zum Beispiel können zwei Netzwerkinterfaces erstellt und konfiguriert werden. Mit dem ersten Netzwerkinterface kann der User das Intranet nutzen und mit dem zweiten Netzwerkinterface, falls er die Berechtigung dafür hat, eine Verbindung zum Internet aufbauen. Als nächster Schritt wird der Maschine ihre IP-Adresse zugewiesen. Diesen Schritt könnte man auch mit der Konfiguration des Netzwerkinterfaces durchführen. Aber dies sollte nur geschehen, falls ein kleines Firmennetzwerk vorliegt und kein DHCP Server (Dynamic Host Configuration Protocol) zum Einsatz kommt. In den meisten Firmennetzwerken werden DHCP Server eingesetzt, da der Verwaltungsaufwand sehr groß ist, die IP-Adressen manuell zu vergeben und zu verwalten. Eventuell müssen auch vorhandene Proxyserver konfiguriert werden, wenn zum Beispiel die Maschinen nur über einen Sicherheitsserver eine Internetverbindung aufbauen können. Als nächstes wird das Domain Name System (DNS) konfiguriert. Die Hauptaufgabe von DNS ist die Namensauflösung, d.h. man kann die Computer in einem Netzwerk über die Hostnamen oder ihre IP-Adressen ansprechen. Die Router usw. verwenden IP-Adressen während der Mensch die Hostnamen bevorzugt und da sie sich leichter merken lassen. Daher gibt es in den Router DNS-Datenbanken in denen IP-Adressen mit den dazugehörigen Hostnamen gespeichert werden. Zum Beispiel für einen Linuxwebserver werden die IP-Adresse und die dazugehörigen Hostnamen in der /etc/hosts eintragen und sind somit durch den Hostnamen erreichbar. Als letztes wird der Lightweight Directory Access Protocol (LDAP) Client konfiguriert, welches ein Verzeichnisdienst ist, das in vielen Unternehmen zum Einsatz kommt. Das LDAP Protokoll beschreibt die Kommunikation zwischen den Clients und dem Verzeichnisserver. In einem Verzeichnis können objektbezogene Dateien stehen, wie zum Beispiel Personendaten oder Rechnerkonfigurationen. Die Kommunikation erfolgt auf Basis von Abfragen und muss daher auch auf den Maschinen konfiguriert werden Basiskonfiguration Die Basiskonfigurationklasse ist für alle Maschinen identisch. In der Basiskonfigurationklasse wird das Attribut Rechnername festgelegt, das für die eindeutige Identifizierung im Netzwerk des jeweiligen Unternehmens wichtig ist. Nach der Festlegung des Rechnernamens wird die Installation der benötigten Standardsoftware konfiguriert. Diese Liste kann von Unternehmen zu Unternehmen variieren und enthält die Softwarepakete, die für das jeweilige Unternehmen, bzw. für den Anwender notwendig sind. Softwarepakete sind zum Beispiel: Officeprogramme Entwicklungsumgebungen Bildbearbeitungsprogramme usw. Unter Umständen müssen einzelne Softwarepakete noch konfiguriert werden, da eventuelle unternehmensspezifische Einstellungen benötigt werden. Beispiele hierfür sind vorgefertigte Firmenformatvorlagen für Officeprogramme. Oder Projektpfadangaben für Entwicklungsumgebungen, die hinzugefügt werden müssen. Ebenso können auch sicherheitsrelevante Einstellungen nachträglich für Softwareanwendungen vorgenommen werden. 9

16 Eine weitere eventuell wichtige Einrichtung in der Basiskonfiguration ist die Benutzerverwaltung, d.h. es werden auf den Maschinen die Benutzer angelegt und konfiguriert, die Zugriff auf den Rechner erhalten sollen. Weiterhin kann auch eine Secure Shell Konfiguration genutzt werden, in dem ein Benutzer mit dem entsprechenden Secure Shell Schlüssel hinzugefügt wird. Somit kann dieser Benutzer per Secure Shell Zugang auf die Maschine bekommen Konfigurationsklassen Die Glieder der Konfigurationsklassen entsprechen den verschiedenen Typklassen, wie Webserver, Datenbankserver, Dateiserver oder Lizenzserver usw. Jede dieser Klassen beinhaltet wiederum ihre eigenen Konfigurationseinstellungen. Jedoch besteht die Möglichkeit mehrere dieser Klassen auf nur einer Maschine zu verwenden. Ebenfalls können neben diesen Klassen noch weitere Typklassen hinzugefügt werden. Diese Klassen können sich auch in ihren Attributwerten unterscheiden, d.h. in verschiedenen Unternehmen können zum Beispiel die Klasse der Webserver unterschiedliche Attributwerte aufweisen. So zum Beispiel im Fraunhofer ITWM, dort werden Softwarepakete wie rkhunter, ein Rootkitscanner, und Zendframework, ein Framework für PHP, benötigt. Aber andere Unternehmen arbeiten mit anderen Softwarepaketen. Die Unternehmen können entsprechend ihrer Infrastruktur bestehende Typklassen nutzen, erweitern oder ersetzen, sowie neue Typklassen erstellen und in der Modellierung einfügen. Die unterste Ebene der Vererbungshierarchie bilden die dedizierten oder virtuellen Maschinen. Dort werden die entsprechenden Hardwarekonfigurationen durchgeführt und für jede der beiden können eine oder mehrere entsprechende Konfigurationsklassen ausgewählt werden. Jedoch sind für alle Maschinen die Basisnetzwerkkonfiguration und die Basiskonfiguration identisch. 10

17 3. Gegenüberstellung der Konfigurationsmanagementsysteme Es gibt eine Vielzahl an verschiedenen Konfigurationsmanagementsoftwaresystemen, wie in Abbildung 3 zu sehen ist. Für die heterogenen Umgebungen in Universitären- und Forschungseinrichtungen ist es wichtig, dass die Konfigurationsmanagementsoftwaresysteme sowohl Linux- als auch Windows Betriebssysteme unterstützen. Es werden ausschließlich Open Source Versionen betrachtet, weil dies eine der Vorgaben des Fraunhofer ITWMs war. Außerdem hat Open Source einige Vorteile, wie zum Beispiel, dass der Quellcode offen ist und daher leichter nachvollzogen oder entsprechend den Vorstellungen des Unternehmens, geändert werden kann. Diese Open Source Versionen haben eventuell eine große aktive Community, die das Entwicklerteam unterstützen kann, etwa für die Entwicklung einer neuen Version bzw. neuer Updates, oder bei Problemen zur Verfügung steht. Dies spielte aber bei der Auswahl der Konfigurationsmanagementsysteme keine Rolle. Aus der großen Anzahl von Open Source Konfigurationsmanagementsoftwaresystemen gibt es nur vier Anbieter, die die Vorgaben, wie die Unterstützung von Windows, erfüllen. Diese sind Chef [che, Önn12], CFEngine [cfe, Önn12], Puppet [pup, Önn12] und Software Testing Automation Framework (STAF) [sta]. Im nachfolgenden Kapitel werden diese vier Systeme kurz beschrieben und anschließend miteinander verglichen. Abbildung 3 Liste von Opensource Konfigurationsmanagementsystemen [wik12] 11

18 3.1 Konfigurationsmanagementsoftwaresystem Chef Chef [Nels11] ist ein Konfigurationsmanagementsoftwaresystem, welches in Ruby geschrieben wurde. Chef benutzt die Sprache Ruby. Dadurch kann man auf die kompletten Funktionen von Ruby zurückgreifen. Es gibt zwei Softwareversionen von Chef, die Community und die Business Edition. Chef vereinigt zwei Architekturen, zu einem die Server-Client Architektur und zum anderen die serverlose Architektur. Der Server wird Chef Server und die Clients Chef Clients genannt. In der serverlosen Architektur wird die Maschine als Chef Solo bezeichnet. Die Konfigurationen heißen dort Rezepte und Kochbücher, die auf der Rubysprache aufbauen. Die Rezepte sind die eigentlichen Konfigurationsdateien. Während die Kochbücher sich aus mehreren Rezepten zusammensetzen, können jedoch beliebig mit weiteren Rezepten erweitert oder entfernt werden. Wie der Arbeitsablauf in Chef abläuft, zeigt die Abbildung 4. Der Server synchronisiert die Kochbücher und kompiliert diese. Darauf können nun die Chef Clients diese Änderungen durchführen und anschließend dem Server über die Änderungen benachrichtigen. Abbildung 4 Arbeitsablauf in Chef [Önn12] 3.2 Konfigurationsmanagementsoftwaresystem CFEngine CFEngine ist ein Konfigurationsmanagementsoftwaresystem, welches in C geschrieben wurde. CFEngine verwendet eine deklarative Sprache, die an C angelehnt ist. Vorteile sind hier die einfache Erlernung der Sprache und die Optimierung auf die Implementierung von Konfigurationen. Nachteil von CFEngine ist, dass die Sprache nur an C angelehnt ist, wodurch nicht alle Features von C genutzt werden können. Es gibt zwei Softwareversionen von CFEngine, die Community und die Enterprise Edition. CFEngine vereinigt zwei Architekturen, erstens eine Server-Client Architektur und eine multinode Architektur. Mit CFEngine können mehrere policy server erstellt werden, welche dann eine bestimmte Konfiguration an ihre Clients verschicken können. Die Konfigurationen heißen Promises und basieren auf einer deklarativen Sprache, sozusagen die Sprache der Promises. Diese Promises werden vom policy server verwaltet. Die Clients benutzen eine pull function um diese Promises zu bekommen, d.h. die Promises werden vom Server kopiert und lokal gespeichert. Erst dann werden diese Promises vom Client ausgeführt. Geht mal die Verbindung zum policy server verloren, hat CFEngine einen opportunistischen Ansatz, d.h. die Clients führen noch offenstehende Promises aus und tun ansonsten nichts mehr. Der Arbeitsablauf in CFEngine zeigt die folgende Abbildung 5. Hier ist der Host B ein policy server, dort wird der 12

19 Dienst Cf-server ausgeführt. Im Hintergrund läuft ebenfalls die Cf-execd, ein Hintergrundprozess, der dafür sorgt, dass zum Beispiel der Prozess cf-agent ausgeführt wird. Der Prozess Cf-agent auf dem Host A holt sich die Promises vom policy server und danach wird Cfrunagent ausgeführt, der die Promises startet und abarbeitet. Jeder dieser Prozesse kann unabhängig von den anderen Prozessen laufen, kann aber je nach Bedarf mit den anderen Prozessen kommunizieren. Abbildung 5 Arbeitsablauf in CFEngine [Önn12] 13

20 3.3 Konfigurationsmanagementsoftwaresystem Puppet Puppet ist ein Konfigurationsmanagementsoftwaresystem, welches in Ruby geschrieben wurde. Puppet verwendet eine deklarative Sprache, die an Ruby angelehnt ist. Diese Sprache ist daher speziell an die Implementierung von Konfigurationen angepasst. Dadurch wird die Implementierung von Konfigurationen erleichtert. Hier sind die Vor- und Nachteile identisch zu CFEngine. Es gibt zwei Softwareversionen von Puppet, die Opensource und die Enterprise Edition. Puppet ist eine Server-Client Architektur, in dem der Server Puppet Master genannt wird und die Clients Puppet agent genannt werden. In den Manifestes jedoch heißen die Clients nodes. Die Konfigurationen heißen hier Manifest und basieren auf einer deklarativen Sprache. Die Manifests werden zu einem Katalog kombiniert und danach synchronisiert und auf den entsprechenden Clients ausgeführt. Wie der Arbeitsablauf in Puppet abläuft zeigt die Abbildung 6. Der Server kompiliert die Manifests und erstellt daraus Kataloge und übergibt diese den nodes, damit diese den Katalog ausführen können. Abbildung 6 Arbeitsablauf in Puppet [Önn12] 3.4 STAF STAF ist ein Software Test Framework. Es ist für sogenannte wiederverwendbare Komponenten entwickelt worden, welche Dienste genannt werden. Diese Dienste sind zu einem die Prozessverwaltung, das Ressourcen Management, Monitoring und das Aufzeichnen von Logdateien. Hier gibt es nur eine Opensource Version. STAF ist eine einfache Architektur, in dem es nur STAF Clients gibt, die Konfigurationen können lokal geändert werden oder durch andere STAF Clients mit denen man direkt verbunden ist, also eine Peer-to-Peer Umgebung. Die Konfigurationen heißen service und können zum Beispiel in Java oder C++ geschrieben werden. Für STAF kann man eine der vielen Sprachen, wie schon erwähnt C++, Java, aber auch Python, C oder Perl, verwenden. Der Vorteil ist hier, dass man die kompletten Funktionen dieser Sprache benutzen kann. Der STAFProc Dienst führt diese Services aus. 14

21 3.5 Allgemeiner Vergleich der Konfigurationsmanagementsoftware Jetzt folgt der Vergleich der vier Konfigurationsmanagementsoftwaresysteme Chef, CFEngine, Puppet und STAF. Um diese Softwaresysteme allgemein vergleichen zu können, müssen zunächst allgemein gültige Vergleichspunkte festgelegt werden. Durch eine Diskussion mit den Betreuern vom Fraunhofer ITWM wurden folgende Anforderungen festgelegt: Monitoring, d.h. ob Softwarepakete korrekt installiert wurden oder sich unter Dateikontrolle befindlichen Dateien sich geändert haben etc. Sicherheit und Authentifizierung der Verbindung des Serverknotens zu den Clientknoten um vor Missbrauch und Attacken geschützt zu sein. Eine Client/Server Architektur, in der man zentral von einem Serverknoten eine Anzahl von Clients verwalten kann. Die Automatisierung der Konfigurationen, d.h. die Konfigurationstemplates werden automatisch oder bei zuvor festgelegten Zeitpunkten auf den Clients ausgeführt. Plattformunabhängigkeit des jeweiligen Konfigurationsmanagementsystems, d.h. Unterstützung der Betriebssysteme, wie Linux und Windows. Erweiterbarkeit der Konfigurationen, d.h. man kann entsprechend den Sicherheitsrichtlinien des Unternehmens etc. seine eigenen Templates implementieren. Sicherheit der Netzwerkverbindung, d.h. dass sich die Clients und die Server authentifizieren müssen oder sichere Verbindungen über SSL aufbauen. Vererbungshierarchie der Serverknoten, d.h. es gibt nur einen Masterknoten, jedoch kann eine Vererbungshierarchie aufgebaut werden, in dem die Kinderknoten wiederum neue Masterknoten für jeweils deren Kinderknoten sein können. Dies verdeutlicht die nachfolgende Grafik. Abbildung 7 Vererbungshierarchie in CFEngine [cfe] Lokale Konfiguration der Clients ist möglich. Die Clients können ohne Netzwerkverbindung mit dem Server konfiguriert werden, oder zumindest die offen stehenden Konfigurationen werden noch durchgeführt. Unterstützung von VMware, das im Fraunhofer ITWM eingesetzt wird. Es sollen Templates für virtuelle Hardwaretreiber von virtuellen Maschinen erstellt werden. Dokumentation der Konfigurationen, d.h. es gibt eine Möglichkeit automatisch aus den erstellten Templates entsprechende Dokumentationen zu erstellen, zum Beispiel in Form einer PDF-Datei oder einer Webseite. Damit ist gewährleistet, dass man so einen genauen Überblick über alle Templates hat und eventuelle Sicherheitslücken, etc. finden kann. 15