chef: Rechtschreibung und Ausdruck Teil II

bericht/chef/chef-comparison.tex

@@ -1,58 +1,60 @@
 \subsubsection{Funktionsweise von Chef}
 \label{ssub:funktionsweise_von_chef}
 
-\href{http://www.getchef.com/chef/}{Chef} ist ein Framework, welches es
-ermöglicht automatisiert Server zu konfigurieren und zu verwalten. Der
-Endanwender beschreibt hierbei die Systemresourcen und ihre Zustände in der
+\href{http://www.getchef.com/chef/}{Chef} ist ein Framework, welches eine
+automatisierte Serverkonfiguration und -verwaltung ermöglicht. (TODO -
+Provisionierung und Deployment) Der Endanwender
+beschreibt hierbei die Systemressourcen und ihre Zustände in der
 Programmiersprache \href{https://www.ruby-lang.org/}{Ruby}. Diese Definitionen
-werden von dem Program \emph{Chef-client} eingelesen und in notwendige Aktionen
+werden von dem Program \emph{Chef-Client} eingelesen und in notwendige Aktionen
 übersetzt, welche ausgeführt werden müssen, um den beschriebenen Zustand
 umzusetzen.
 
 Die Gesamtheit aller Definitionen/Einstellungen nennt man das \emph{Chef-repo}.
-Diese untergliedert sich in mehrere \emph{Cookbooks}\label{cookbook}, welche die
-Grundverwaltungseinheit darstellt. Jedes dieser Cookbooks, erfüllt einen
-bestimmten Teilaspekt des Systems, (z.B. die Einrichtung eines Webservers
-\href{https://github.com/opscode-cookbooks/apache2}{Apache}). Cookbooks
-können versioniert werden. Es können Abhängigkeiten zwischen mehreren
-Cookbooks angegeben werden.
+Ein solches untergliedert sich in mehrere \emph{Cookbooks}\label{cookbook}.  Ein
+Cookbook ist die Grundverwaltungseinheit in Chef. Es erfüllt einen bestimmten
+Teilaspekt des Systems (z.B. die Einrichtung eines Webservers
+\href{https://github.com/opscode-cookbooks/apache2}{Apache}). Cookbooks können
+versioniert werden. Es können Abhängigkeiten zwischen mehreren Cookbooks
+angegeben werden.
 
-Eine physikalische oder virtuelle Maschine wird als \emph{node} bezeichnet.
+Physikalische oder virtuelle Maschinen werden als \emph{Nodes} bezeichnet.
 Einer Node können \emph{Attributes}, \emph{Roles} und Cookbooks zugewiesen
-werden. Roles und Cookbooks werden dazu in die sogenannte \emph{Run-list} der
-Node eingefügt.  Diese gibt die Reihenfolge angibt, in welche Roles und
-Cookbooks angewendet werden. Roles bieten eine Möglichkeit Nodes, welche die
-gleiche Aufgaben in einer Organisation besitzen, zu gruppieren (z.B. Webserver).
+werden. Roles und Cookbooks werden dazu in die sogenannte \emph{Run-List} der
+Node eingefügt. Diese gibt die Reihenfolge an, in welcher Roles und Cookbooks
+angewendet werden. Roles bieten eine Möglichkeit, Nodes zu gruppieren, welche die
+gleichen Aufgaben in einer Organisation erfüllen (z.B. Webserver).
 
 Es gibt mehrere Möglichkeiten \emph{Chef} zu betreiben:
 
 \begin{description}
-  \item[Chef-solo] Dies ist die einfachste Ausführungsform. Hierbei werden alle
-    nötigen Daten aus einem lokalen Verzeichnis geladen. Im Gegensatz zu den
-    anderen Methoden heißt bei dieser das auszuführende Programm
-    \emph{chef-solo} statt \emph{chef-client}. Diese Form wurde für die
-    Umsetzung der Aufgabenstellung in
+  \item[Chef-Solo] Chef-Solo ist die einfachste Ausführungsform. Alle nötigen
+    Daten werden aus einem lokalen Verzeichnis geladen. Im Gegensatz zu
+    \emph{Chef-Server} und \emph{Enterprise Chef} wird bei Chef-Solo das
+    Programm \emph{chef-solo} an Stelle von \emph{chef-client} ausgeführt. Diese
+    Form wurde für die Umsetzung der Aufgabenstellung in
     Abschnitt~\ref{ssub:einrichtung-der-netzwerkdienste} gewählt.
-  \item[Chef-server] Hierbei authentifiziert sich \emph{Chef-client} über eine
-    \emph{REST-Api} zu einem \emph{Chef-server} mittels eines privaten RSA-Keys.
-    Auf diesem wird das Chef-repo zentral verwaltet. Der Chef-client bekommt von
+  \item[Chef-Server] Hierbei authentifiziert sich \emph{Chef-Client} über eine
+    \emph{REST-Api} zu einem \emph{Chef-Server} mittels eines privaten RSA-Keys.
+    Auf diesem wird das Chef-repo zentral verwaltet. Der Chef-Client bekommt von
     diesem alle nötigen Informationen für die zu provisionierende \emph{Node}.
-    Chef-server bietet eine webbasierte GUI für die Administration an. Die
-    Attribute aller Nodes sind über die eingebaute Suchemaschine \emph{Solr}
-    durchsuchbar.
-  \item[Enterprise Chef/Hosted Enterprise Chef] Ähnlich wie Chef-server bietet
-    aber eine bessere Skalierbarkeit, rolenbasierte Benutzerverwaltung, bessere
-    Überwachung, eine verbesserte Weboberfläche sowie Push-Deployment an.
-    Während Hosted Enterprise Chef die Firma Chef den Serverteil betreibt, ist
-    bei Enterprise Chef der Server in der eigenen
-    Organisation~\cite{chefenterprise}
+    Chef-Server bietet eine webbasierte GUI für die Administration an. Die
+    Attributes aller Nodes sind über die eingebaute Suchmaschine
+    \href{https://lucene.apache.org/solr/}{\emph{Solr}} durchsuchbar.
+  \item[Enterprise-Chef/Hosted-Enterprise-Chef] Enterprise-Chef bietet
+    zusätzlich zu den Funktionen der Opensource-Version Chef-Server eine
+    rollenbasierte Benutzerverwaltung, bessere Überwachung, eine verbesserte
+    Weboberfläche sowie Push-Deployment an. Während bei Hosted-Enterprise-Chef
+    die Firma Chef den Serverteil betreibt und die Skalierung des Dienstes
+    übernimmt, ist bei Enterprise-Chef der Server in der eigenen
+    Organisation~\cite{chefenterprise}.
 \end{description}
 
-\textbf{Aufbau eines Cookbook}
+\textbf{Aufbau eines Cookbooks}
 \label{aufbau_eines_cookbook}
 
-Hier ist die Ordnerstruktur eines Cookbooks am Beispiel von
-\href{https://github.com/opscode-cookbooks/apt}{apt} dargestellt:
+Nachfolgend ist die Ordnerstruktur eines Cookbooks am Beispiel von
+\href{https://github.com/opscode-cookbooks/apt}{apt} dargestellt.
 
 \begin{tikzpicture}
 \treeroot{apt-2.3.4}
@@ -92,43 +94,52 @@ Funktion. Dies hat den Vorteil, das man sich schnell in neuen Cookbooks zurecht
 findet. Hier nochmal die einzelnen Verzeichnisse im Überblick:
 
 \begin{description}
-  \item[attributes] setzt Standardwerte (Attribute) für das Cookbook. Dies
-    können Strings, Zahlen oder Arrays sein. Die gesetzten Attribute können in
-    Roles, Nodes oder von anderen Cookbooks überschrieben werden. Hierfür gibt
-    es die Prioritäten default, force\_default, normal und override um die
-    Reihenfolge zu beeinflussen. Attributes sind hierarchisch organisiert. In
-    der Regel ist die höchste Ebene der Name des Cookbooks. (z.B.
-    \emph{normal.mysql.client.packages})
-  \item[files] Hier können statische Dateien eingefügt werden, welche dann auf
-    dem Zielsystem in das entsprechende Verzeichnis kopiert werden können.
-  \item[libraries] In diesem Verzeichnis können Hilfsfunktionen und
+  \item[attributes] Attributes sind einfache Schlüssel-Wert-Beziehungen und
+    setzen Standardwerte für das Cookbook. Die Schlüssel sind hierarchisch
+    organisiert. In der Regel ist die höchste Ebene der Name des Cookbooks (z.B.
+    \emph{normal.mysql.client.packages}). Werte können Strings, Zahlen oder
+    Arrays sein. Die gesetzten Attributes können in Roles, Nodes oder von
+    anderen Cookbooks überschrieben werden. Hierfür werden die Attributes mit
+    den verschiedenen Prioritäten default, force\_default, normal und override
+    gesetzt (aufsteigender Wertigkeit) gesetzt, wobei eine höhere Priorität eine
+    Niedrigere überschreibt.
+  \item[files] In diesem Verzeichnis können statische Dateien eingefügt werden,
+    welche auf dem Zielsystem in das entsprechende Verzeichnis kopiert werden
+    können.
+  \item[libraries] In diesem Pfad können Hilfsfunktionen und
     Spracherweiterungen definiert werden.
-  \item[resources] Ressourcen beschreiben, die Bestandteile eines Systems. Eine
-    Ressource kann z.B. eine Datei, ein Prozess oder ein Packet sein. Man
+  \item[resources] Ressourcen beschreiben die Bestandteile eines Systems. Eine
+    Resource kann z.B. eine Datei, ein Prozess oder ein Paket sein. Man
     beschreibt, welchen Zustand (Action in Chef genannt) diese Ressource haben
-    soll und Chef versucht diesen Zustand  herzustellen. Chef liefert von Haus
-    viele wichtige Ressourcen mit. In Cookbooks können man darüber hinaus eigene
-    Ressourcen definiert werden.
+    soll und Chef versucht, diesen Zustand  herzustellen. Chef liefert bereits
+    viele wichtige Ressourcen mit. In Cookbooks können darüber hinaus eigene
+    Resources definiert werden.
   \item[providers] Während Ressourcen nur die Schnittstelle mit allen Attributes
     beschreiben, die gesetzt werden können, ist der Provider eine konkrete
     Implementierung. Deswegen muss für jede Ressource mindestens ein Provider
     existieren. Es kann mehrere Provider für eine Ressource geben, um zum
     Beispiel um mehrere Plattformenvarianten oder Betriebssysteme abdecken zu
-    können (z.B. bei Packetmanagern oder Initsystemen).
-  \item[recipes] In Recipes werden Ressourcen instantiiert, welche nötig sind
-    um die gewünschte Aufgabe zu erreichen. Dabei können Abhängigkeiten zwischen
-    diesen angegeben werden.
-  \item[definitions] Ressourcen, welche häufiger in verschiedenen Recipes auf
-    ähnliche Art und Weise benötigt werden, können in eine \emph{Definition}
-    ausgelagert werden.
+    können (z.B. bei Paketmanagern oder Initsystemen TODO - Initsystemen
+    erklären). In eigenen Cookbooks erstellte Resources/Provider nennt man LWRP
+    (Lightweight-Resource/Provider).
+  \item[recipes] In Recipes werden Ressourcen instanziiert, welche nötig sind,
+    um die gewünschte Ziel zu erreichen. Dabei können Abhängigkeiten zwischen
+    Recipes angegeben werden.
+  \item[definitions] Ressources, welche häufiger in verschiedenen Recipes in
+    ähnlicher Form benötigt werden, können in eine \emph{Definition}
+    ausgelagert werden. Ein Beispiel ist das Generieren eines SSH-Schlüssels
+    für verschiedene Nutzer auf dem System. Für komplexere Konstrukte sollten
+    jedoch LWRPs (siehe oben) bevorzugt werden.
   \item[templates] Häufig werden dynamisch generierte Dateien benötigt, um zum
-    Beispiel Konfigurationsdateien zu erzeugen. Chef bindet hierfür die
-    Templatesprache eRuby (Embedded Ruby) ein. Diese führt in den Templates
-    Rubycode, der sich zwischen den Tags \emph{<\%} und \emph{\%>} befindet, aus.
-    Dies erlaubt es Variablen zu interpolieren, sowie If-Statements und
-    Schleifen.
-  \item[metadata.rb] In dieser Datei kann der Name des Cookbook, die Version,
-    eine Beschreibung sowie Abhängigkeiten zu anderen Cookbooks angeben werden.
+    Beispiel Konfigurationsdateien zu erzeugen. In Chef wird für diesen Zweck
+    die Templatesprache eRuby (Embedded Ruby) verwendet. In ERB-Templates wird
+    Rubycode ausgeführt, der sich zwischen den Tags \emph{<\%} und \emph{\%>}
+    befindet. Dies erlaubt es einerseits den Inhalt von Variablen oder den
+    Rückgabewert von Methoden zu interpolieren, andererseits können in Templates
+    Kontrollstrukturen wie If-Statements und Schleifen verwendet werden.
+  \item[metadata.rb] In der Datei \emph{metadata.rb} kann der Name des Cookbook,
+    die eigene Version, eine Beschreibung sowie Abhängigkeiten zu anderen
+    Cookbooks angegeben werden.
 \end{description}
 
 Beispiel ERB-Template:
@@ -151,73 +162,98 @@ Beispiel ERB-Template:
 \end{lstlisting}
 
 \textbf{Ablauf einer Provisonierung}
-\label{ablauf_einer_provisionierung}
-
-Der genaue Ablauf wurde der Onlinedokumentation (~\cite{chefrun}) von Chef
-entnommen. Wie schon zu Beginn erwähnt wird die Provisonierung von einem
-Programm namens \emph{Chef-client} durchgeführt. Je nach Umgebung kann dieser
-periodisch vom Scheduler \emph{Cron} gestartet, permanent als Systemdienst
-laufen (z.B. bei Enterprise Chef) oder manuell gestartet werden (z.B. bei
-Vagrant - siehe~\ref{ssub:einrichtung-der-netzwerkdienste}).
+\label{ablauf_einer_provisionierung}\\
+Der genaue Ablauf wurde der Onlinedokumentation (\cite{chefrun}) von Chef
+entnommen. Wie schon zu Beginn erwähnt, wird die Provisonierung von einem
+Programm namens \emph{Chef-Client} durchgeführt. Je nach gewählter Umgebung kann
+dieser periodisch vom Scheduler \emph{Cron} gestartet, permanent als
+Systemdienst laufen (z.B. bei Enterprise Chef) oder manuell gestartet werden
+(z.B. bei Vagrant - siehe~\ref{ssub:einrichtung-der-netzwerkdienste}).
 
 Als erstes lädt dieser Prozess seine Konfiguration aus der Datei
-\emph{client.rb}. In dieser stehen beispielsweise Informationen mit welchen
-Chef-Server der Client sich verbinden soll, an welcher Stelle temporäre Daten
-gespeichert werden soll und der Name der Node. Letzteres ist wichtig um die Node
-richtig von Chef einordnen zu können und die richtigen Einstellungen zuzuweisen.
-Alternativ kann der Name auch von der der Bibliothek
+\emph{client.rb}. In dieser stehen beispielsweise die URL des Chef-Server, in
+welchem Pfad temporäre Dateien gespeichert werden und der Name der Node.
+Letzteres ist wichtig, um die Node in Chef einordnen zu können und die richtigen
+Einstellungen zuzuweisen.  Alternativ kann der Name auch von der Bibliothek
 \href{http://docs.opscode.com/ohai.html}{Ohai} gesetzt werden, in dem auf den
-Hostnamen oder der FQDN (Fully Qualified Domain Name) zurück gegriffen wird.
-Ohai sammelt noch andere systemrelevante Daten wie Details über
-Hardwarekomponenten (Anzahl der CPUs, Größe und Art des RAMs, Netzwerkanbindung,
-Festplatten/SSDs, \dots), Informationen über die Plattform (Art des
-Betriebssystems und Version, installierte Software) und die laufenden Prozesse.
-Diese Informationen sind durch eigene Ohai-Plugins erweiterbar und können im
-Provisionierungsprozess genutzt werden, um weitere Entscheidungen zu treffen.
-Sie sind darüber hinaus auch auf dem Server gespeichert und für andere Clients
-abrufbar.
+Hostnamen oder der FQDN (Fully Qualified Domain Name) zurückgegriffen wird.
+Ohai sammelt systemrelevante Daten wie Details über Hardwarekomponenten (Anzahl
+der CPUs, Größe und Art des RAMs, Netzwerkanbindung, Festplatten/SSDs, \dots),
+Informationen über die Plattform (Art des Betriebssystems und sowie dessen Version,
+installierte Anwendungssoftware) und die laufenden Prozesse.  Diese Informationen sind
+durch eigene Ohai-Plugins erweiterbar und können im Provisionierungsprozess
+genutzt werden, um weitere Entscheidungen zu treffen.  Sie sind darüber hinaus
+auch auf dem Server gespeichert und für andere Clients abrufbar.
 
-Nach dem alle Einstellungen eingelesen sind, folgt im Falle von Chef-Server, die
-Authentifizierung mit diesem über den vorher auf der Node abgelegten
-RSA-Schlüssel. Für Adminstratoren gibt es für den
+Nach dem alle Einstellungen eingelesen sind, verbindet sich Chef-Client mit
+Chef-Server. Die Authentifizierung erfolgt über den vorher auf der Node
+abgelegten RSA-Schlüssel. Für Administratoren gibt es einen Validator-Key. Im
 \href{http://docs.opscode.com/knife\_bootstrap.html}{Bootstraprozess}, in
-welchem Chef initial auf der Node installiert wird, dafür einen Validatorkey.
-Mit diesem kann eine Node auf dem Server registriert werden, umso einen
-Clientkey zu generieren.
+welchem Chef initial auf der Node installiert, kann mit diesem eine Node auf dem
+Server registriert werden und ein Clientkey generiert werden.
 
-Anschließend werden alte gesetzte Attributes und die Run-list vom Server
-übertragen. Beim 1. Durchlauf oder im Falle Chef-Solo sind diese Daten nicht
-vorhanden (ausgenommen der voreingestellten Run-list von Chef-Server).
-Stattdessen kann eine Datei im JSON-Format angegeben werden, um die Attributes
-und der Run-list für diese Node zu spezifizieren.
+Anschließend werden alte gesetzte Attributes und die Run-List vom Server
+übertragen. Im 1. Durchlauf oder bei Verwendung von Chef-Solo sind diese Daten
+nicht vorhanden.  Stattdessen kann eine Datei im JSON-Format angegeben werden,
+um die Attributes und der Run-List für die Node zu spezifizieren. Außerdem ist
+es möglich eine Run-List auf dem Chef-Server einzustellen, welche ausgeführt
+wird, wenn die Node keine eigene Run-List besitzt.
 
-Durch Auswertung der eingebunden Rollen und Recipes wird eine Liste der
-benötigen Cookbooks ermittelt. Der Client fordert für diese eine Liste aller
+Durch Auswertung der eingebunden Rollen und Recipes werden die benötigen
+Cookbooks ermittelt. Der Client fordert eine Liste aller darin enthaltenen
 Dateien und deren Checksumme an. Alle geänderten oder neuen Dateien werden
-darauf hin heruntergeladen und im lokalen Cache gespeichert.
+heruntergeladen und im lokalen Cache gespeichert.
 
 Nun werden die Attribute zurückgesetzt und aus den Cookbooks, Roles und der Node
-neu generiert und entsprechend ihrer Priorität gesetzt. Die in den Cookbooks
-definierten Resources werden geladen und mit den von Chef mitgelieferten
-Resources in der Resourcecollection zusammengefasst. Nachdem alle Definitions
-und Libraries geladen wurden, werden schließlich die Recipes verarbeitet. In
-diesen werden Resourcen des Systems beschrieben und durch Actions deren Zustand
-festgelegt.
+neu generiert und entsprechend ihrer Priorität gesetzt. Die, in den Cookbooks
+definierten, Resources werden geladen und mit den, von Chef mitgelieferten,
+Resources in der Resource-Collection zusammengefasst. Nachdem alle Definitions
+und Libraries geladen wurden, werden schließlich die Recipes verarbeitet. Die
+darin erstellten Resources beschreiben das System. Für jede Resource wird eine
+Action festgelegt, was gleichbedeutend mit deren Zustand ist.
 
-Im nächsten Schritt folgt das sogenannte Converging. Es werden alle Resources in
-der Reihenfolge abgearbeitet. Dabei wird für jede Resource der für die Plattform
-zugehörige Provider ausgewählt. Dieser überprüft den aktuellen Zustand der
-Resource und verändert wenn notwendig das System um den Sollzustand zu
-erreichen. Zum Schluss überträgt Chef-client die aktualisierten Attributes auf
-den Server, von welchem sie in Solr indexiert werden.
+Im nächsten Schritt folgt das sogenannte Converging (englisch für
+\emph{Angleichen}). Es werden alle Resources Schritt für Schritt abgearbeitet.
+Dabei wird für jede Resource, der für die Plattform zugehörige, Provider
+ausgewählt. Dieser überprüft den aktuellen Zustand der Resource und verändert,
+wenn notwendig, das System, um den Sollzustand zu erreichen. Zum Schluss überträgt
+Chef-Client die aktualisierten Attributes auf den Server, von welchem sie in
+Solr indexiert werden.
 
-Es besteht die Möglichkeit vor oder nach dem Provisioning Handler auszuführen.
-Diese können beispielsweise im Fehlerfall Benachrichtigungen an das
-Monitoringssystem oder per Email verschicken. In letzten Abschnitt
-(\ref{minitest_handler}) wird dieser Mechanismus genutzt um Tests auszuführen.
+Es besteht die Möglichkeit Handler vor oder nach dem Provisioning auszuführen.
+Diese können im Fehlerfall Benachrichtigungen an das Monitoringssystem oder per
+Email verschicken. In letzten Abschnitt (\ref{minitest_handler}) wird dieser
+Mechanismus genutzt um Tests auszuführen.
 
 \textbf{Vergleich mit puppet}
-\label{vergleich_mit_puppet}
+\label{vergleich_mit_puppet}\\
+Ein anderes weiteres verbreitetes Konfigurationsmanagmentsystem ist Puppet. Es
+ist das ältere der beiden Projekte. Während die erste Puppetrelease bereits im
+Jahr 2005 von den Puppet Labs veröffentlicht wurde, erschien Chef erst 4 Jahre
+später im Jahre 2009. Chef wurde stark beeinflusst von Puppet. Der Erfinder von
+Chef Adam Jacob war selbst langjähriger Puppetnutzer bevor er Chef oder wie es
+in den 1. Versionen hieß <TODO>, schrieb.
+- Konsultantfirma: Infrastruktur bis zum Deployment
+- mangelnde Abstraktionsmöglichkeiten
+\cite{chefhistory}.
 
+%- bei beiden Projekte ist Clientkomponente in Ruby geschrieben.
+%- Chef: Konfigurations in Ruby
+%- Puppet: eine auf Puppet optimierte, vereinfachte Sprache
+%  -> einfacher für Einsteiger und Nicht-Programmieren
+%  -> Grund für manche Firmen -> wird um Umschulung zu sparen
+%  -> weniger flexible als Ruby (Grund bei Facebook, TODO youtube-Link, mehre Cluster mit mehr als 10.000 Nodes mit Chef provisionier)
+%- Während die Regeln und Beschreibung in Chef standartmäßig in der Reihenfolge abgearbeitet
+%  wird in der sie geladen werden, sortiert Puppet diese um. In beiden kann die
+%  Reihenfolge durch Spezifikation von Abhängigkeiten umsortiert werden (Später
+%  ein Beispiel)
+%
+%Note:
+%- Puppet: eigene Sprache -> komplexere Codebasis
+%- Um die Größe der Community abzuschätzen (schwierig): Suchtreffer für Repositories bei Github
+%- Alter(Puppet) > Alter(Chef)
+%- Chef Enterprise vs Puppet Enterprise: Hinter beiden Projekten stehen Firmen, Weiterentwicklung des Produkt, bieten Support und Hosting an
+%- Resume: Ähnliche Projekte, lösen das gleiche Problem auf unterschiedliche
+%  Weise
 
 % vim: set spell spelllang=de_de

bericht/chef/chef-services.tex

@@ -2,33 +2,35 @@
 \label{ssub:einrichtung-der-netzwerkdienste}
 
 Für die Provisionierung der Netzwerkdienste wurde
-\href{http://vagrantup.com}{Vagrant} verwendet. Dies ist ein Programm um auf der
-Basis von Virtualbox und anderen Virtualisierungslösungen schnell und
+\href{http://vagrantup.com}{Vagrant} verwendet. Dies ist ein Programm, um auf
+der Basis von Virtualbox und anderen Virtualisierungslösungen schnell und
 reproduzierbar virtuelle Maschinen zu starten. Die Einstellungen hierfür werden
-in der Datei \emph{Vagrantfile} geschrieben, welches Vagrant beim Start
-einliest. Vagrant bietet eine gute Integration für Chef. Es bietet Optionen, mit
-welchen Einstellungen neue virtuelle Maschinen provisioniert werden sollen. Zum
-Einsatz kam das Betriebssystem Ubuntu in der Version 12.04. Das Basisimage
-hierfür wurde von \emph{Chef}, der gleichnamigen Firma hinter Chef,
-bereitgestellt. Es wurde ein Netzwerkinterface konfiguriert für die
-Kommunikation mit Vagrant und ein weiteres Internes für ein virtuelles Netzwerk
-zwischen den VMs zum Betreiben der Netzwerkdienste. Vagrant bietet für diese
-erweiterten Einstellungen keine Optionen. Um diese dennoch zu übernehmen, waren
-spezielle Kommandozeilenargumente an den Befehl \emph{VBoxManage} nötig, welches
-von Vagrant für Virtualbox genutzt wird. Dies schränkt Nutzung allerdings auf
-die Visualisierung Virtualbox ein. Vagrant bietet die Möglichkeit neben
-Provisionierungsystemen auch Shellskripte auszuführen. Diese wurde genutzt um
-Chef auf die zum damaligen Zeitpunkt aktuellste Version 11.8.2 upzudaten.
+in der Datei \emph{Vagrantfile} hinterlegt, welche Vagrant beim Start einliest.
+Vagrant kann Chef beim Erstellen von virtuellen Maschinen integrieren.  Es
+bietet Optionen, mit welchen Einstellungen neue virtuelle Maschinen
+provisioniert werden sollen. Zum Einsatz kam das Betriebssystem Ubuntu in der
+Version 12.04. Das Basisimage hierfür wurde von \emph{Chef}, der gleichnamigen
+Firma, bereitgestellt. Für die Kommunikation mit Vagrant wurde das
+Netzwerkinterface \emph{eth0} konfiguriert. Ein weiteres Netzwerkinterface
+(\emph{eth1}) wird für das interne virtuelle Netzwerk zwischen den VMs zum
+Betreiben der Netzwerkdienste benötigt.  Vagrant bietet für diese erweiterten
+Einstellungen keine Optionen. Um diese dennoch zu übernehmen, waren spezielle
+Kommandozeilenargumente an den Befehl \emph{VBoxManage} nötig, welches von
+Vagrant für Virtualbox genutzt wird. Dies schränkt die Nutzung allerdings auf
+den Hypervisor Virtualbox ein. Vagrant bietet die Möglichkeit, neben
+Provisionierungsystemen auch Shellskripte auszuführen. Diese wurde genutzt, um
+Chef auf die, zum damaligen Zeitpunkt, aktuellste Version 11.8.2 zu
+aktualisieren.
 
-Desweiteren wird Ruby auf dem Host benötigt um beispielsweise die Tests
-ausführen zu können. Auf Unix-basierten Systemen kann dies mit dem Befehl:
+Desweiteren wird Ruby auf dem Host benötigt, um beispielsweise die Tests
+ausführen zu können. Auf Unix-Ähnlichen Systemen kann dies mit dem Befehl:
 
 \shellcmd{curl -sSL https://get.rvm.io | bash -s stable}
 
-installiert werden. Auf Windows kann der
-\href{http://rubyinstaller.org/}{RubyInstaller} genutzt werden. Um die nötigen
-Abhängigkeiten zu installieren, müssen folgende Befehle ausgeführt im
-Projektverzeichnis werden:
+installiert werden. Auf dem Betriebssystem Windows kann auf den
+\href{http://rubyinstaller.org/}{RubyInstaller} zurückgegriffen werden. Um die
+benötigten Ruby-Bibliotheken zu installieren, müssen folgende 2 Befehle im
+Projektverzeichnis ausgeführt werden:
 
 \shellcmd{gem install bundler}
 
@@ -41,7 +43,7 @@ Datei namens Berkssfile angegeben (vergleichbar mit
 \href{http://bundler.io/}{Gemfiles} in Ruby).  Berkshelf unterstützt dabei
 verschiedene Quellen (per Api von der Communityseite von Opscode, Git, lokal)
 und kann Abhängigkeiten zu anderen Cookbooks auflösen. Um die Cookbooks initial
-zu laden muss der Befehl:
+zu laden, muss der Befehl:
 
 \shellcmd{berks install}
 
@@ -52,56 +54,65 @@ Für das Zusammenspiel mit Vagrant gibt es das Plugin
 dass die von Berkshelf verwalteten Cookbooks auch in Vagrant zur Verfügung
 stehen.
 
-Für bestimmte Funktionen wie geteilte Ordner zwischen VM und Host müssen die
-\emph{virtualbox-client-modules} in der VM installiert sein. Diese sind zwar in
-vielen Images, die es für Vagrant gibt, vorhanden. Allerdings muss die
-Virtualboxversion des Host mit Dem in der VM übereinstimmen. Abhilfe schafft das
-Vagrantplugin \href{https://github.com/dotless-de/vagrant-vbguest}{vagrant-vbguest}.
-Dieses vergleicht beim Start die Versionen und installiert gegeben falls eine
-Andere in der VM.
+Für bestimmte Funktionen, wie geteilte Ordner zwischen VM und Host, müssen die
+\emph{virtualbox-client-modules} in der VM installiert sein. Diese sind in
+meisten vielen Images vorhanden, die es für Vagrant gibt. Allerdings muss die
+Virtualboxversion des Host mit der Version in der VM übereinstimmen. Abhilfe
+schafft das Vagrantplugin
+\href{https://github.com/dotless-de/vagrant-vbguest}{vagrant-vbguest}. Beim
+Start installiert das Plugin die die gleiche Version des Modules in der VM.
+Wenn Virtualbox mit Linux als Hostsystem ausgeführt wird, sollte das
+Kernelmodule \emph{vboxdrv} geladen sein. Manche Linux-Distributionen
+installieren dieses Module bereits während der Installation von Virtualbox.
+Auf MacOS X und Windows sind keine weiteren Schritte notwendig.
 
-Beide Plugins werden diesen Befehlen installiert:
+Beide Plugins werden den Befehlen:
 
 \shellcmd{vagrant plugin install vagrant-vbguest}
 
 \shellcmd{vagrant plugin install vagrant-berkshelf}
 
+installiert.
+
 Gestartet wird die VM mit dem Befehl:
 
 \shellcmd{vagrant up}
 
-Beim 1. Start wird die VM mit Chef provisioniert. Später kann Chef erneut mit
-folgenden Befehl gestartet werden:
+Während des ersten Starts wird die VM mit Chef provisioniert. Später kann Chef
+erneut mit Befehl:
 
 \shellcmd{vagrant provision}
 
-Als Netzwerkdienste wurden die Protokolle DHCP, DNS und NTP gewählt. Die
-VMs wurden in 2 Gruppen geteilt, \emph{Headnodes}, die die genannten Dienste anbieten
-und \emph{Computenodes}. Die Computenodes fordern auf dem internen Netzwerk per
-DHCP eine IP-Adresse an und nutzen den DNS- und NTP-Dienst des jeweiligen
-Headnode.
+gestartet werden:
 
-Die Attribute der Roles und Node wurden in JSON-Dateien abgelegt in den Ordnern
-\emph{roles/} und \emph{nodes}. Es gibt je eine Role für die Computenode und
-Headnode. In der aktuellen Konfiguration erzeugt Vagrant eine Headnode
-mit dem Hostnamen \emph{node0.lctp} und zwei Computenodes (\emph{node1.lctp} und
-\emph{node2.lctp}).
+Als Netzwerkdienste wurden die Protokolle DHCP, DNS und NTP gewählt. Die VMs
+wurden in die zwei Gruppen \emph{Headnodes}und \emph{Computenodes} geteilt. Die
+Headnode bietet die genannten Dienste an. Die Computenodes fordern auf dem
+internen Netzwerk per DHCP eine IP-Adresse an und nutzen den DNS- und NTP-Dienst
+der jeweiligen Headnode.
+
+Die Attributes der Roles und der Node wurden in JSON-Dateien in den
+Verzeichnissen \emph{roles/} und \emph{nodes/} abgelegt. Es gibt je eine
+Role-Datei für Computenodes und Headnodes. In der aktuellen Konfiguration
+erzeugt Vagrant eine Headnode mit der FQDN \emph{node0.lctp} und zwei
+Computenodes (\emph{node1.lctp} und \emph{node2.lctp}).
 
 Für das Deployment wurden fünf Cookbooks geschrieben:
 \begin{description}
   \item[bind]
-    Als DNS-Server wurde bind gewählt. Dieses Cookbook richtet diesen Dienst ein
-    und fügt die in den Attributen konfigurierten DNS-Einträge hinzu zu den
+    Als DNS-Server wurde bind gewählt. Das Cookbook richtet diesen Dienst ein
+    und fügt, die in den Attributes konfigurierten, DNS-Einträge zu den
     entsprechenden Zonen hinzu.
   \item[dhcp]
-    Dieses Cookbook richtet den ISC DHCP-Server ein. Neben der Zuordnung von
-    festen IP-Adressen zu Nodes, kann ein DNS-Server und ein NTP-Server
+    Dieses Cookbook richtet den ISC-DHCP-Server (TODO Link) ein. Neben der
+    Zuordnung von festen IP-Adressen zu Nodes, kann ein DNS-Server und ein
+    NTP-Server
     festgelegt werden.
   \item[lctp-network] Dieses Cookbook ist ein Wrappercookbook um das
     \href{https://github.com/redguide/network_interfaces}{network\_interfaces}
     Cookbook. Wrappercookbooks werden häufig dazu benutzt um bestehende Cookbooks
     aus anderen Quellen um Funktionalität zu erweitern. In diesem Fall aktiviert
-    das Cookbook für die Computenodes dhcp auf dem interen Netzwerkinterface.
+    das Cookbook für die Computenodes DHCP auf dem interen Netzwerkinterface.
     Auf den Headnodes wird eine statische IP-Adresse gesetzt, der DNS-Server auf
     localhost festgelegt und IP-Forwarding sowie Masquerading via iptables für
     den Routerbetrieb aktiviert.
@@ -109,22 +120,22 @@ Für das Deployment wurden fünf Cookbooks geschrieben:
     Dieses Cookbook richtet den NTP-Deamon ein, welcher die Zeit zwischen den
     einzelnen Knoten synchron halten soll.
   \item[main]
-    Dieses Cookbook fast alle oben genannten Cookbooks für Compute- und
+    Dieses Cookbook fasst alle oben genannten Cookbooks für Compute- und
     Headnode zusammen. Man könnte dies prinzipiell auch in den jeweiligen
     Rollen erledigen. Rollen in Chef haben allerdings den Nachteil, dass diese
-    nicht versionierbar und (bei Chef-server) über alle Umgebungen gleich
+    nicht versionierbar und (bei Chef-Server) über alle Umgebungen identisch
     sind. Somit ist eine Trennung zwischen Test- und Produktivumgebung
     schwierig.
 \end{description}
 
 Es wurden folgende externen Cookbooks verwendet:
 \begin{description}
-  \item[apt] bringt die lokalen Packetquellen auf den aktuellen Stand und
-    aktualisiert den Packetcache.
+  \item[apt] bringt die lokalen Paketquellen auf den aktuellen Stand und
+    aktualisiert den Paketcache.
   \item[network\_interfaces] verwaltet Debians Netzkonfiguration
-    /etc/network/interfaces
-  \item[minitest-handler] Sammelt alle Tests in den Cookbooks führt diese
-    nach der Provisionierung aus (siehe~\ref{minitest_handler})
+    /etc/network/interfaces.
+  \item[minitest-handler] Sammelt alle Tests in den Cookbooks und führt diese
+    nach der Provisionierung aus (siehe~\ref{minitest_handler}).
 \end{description}
 
 % vim: set spell spelllang=de_de

bericht/chef/chef-task.tex

@@ -3,11 +3,11 @@
 
 \begin{itemize}
 \item Analysieren Sie die Funktionsweise von Chef und gehen Sie auf
-  Unterschiede zwischen Chef und Puppet ein
-\item Wählen Sie zwei Netzwerkdienste aus die während der Lehrveranstaltung
-  besprochen wurden und erstellen Sie Provisionierungsvorlagen für diese
-\item Beschreiben Sie wie die Verifikation von Provisionierungsvorlagen
-  bei der Bereitstellung von HPC-Software verwendet werden kann
+  Unterschiede zwischen Chef und Puppet ein.
+\item Wählen Sie zwei Netzwerkdienste aus, die während der Lehrveranstaltung
+  besprochen wurden und erstellen Sie Provisionierungsvorlagen für diese.
+\item Beschreiben Sie, wie die Verifikation von Provisionierungsvorlagen
+  bei der Bereitstellung von HPC-Software verwendet werden kann.
 \end{itemize}
 
 % vim: set spell spelllang=de_de

bericht/chef/chef-tests.tex

@@ -1,49 +1,51 @@
 \subsubsection{Verifikation}
 \label{ssub:verifikation}
 
-Wie auch Software müssen auch Provisionierungsskripte getestet werden.  Dies
-gestaltet sich oft als schwierig, weil nicht immer eine exakte Kopie des
-aktuellen Produktionssystem zur Verfügung steht. Mit steigender Komplexität
-steigt der Aufwand geschriebene Cookbooks manuell zu testen. Im Folgenden werden
-verschiedene Möglichkeiten aufgeführt, wie dies automatisiert werden kann.
+Wie auch in der Softwareentwicklung müssen Konfigurationssysteme getestet
+werden. Dies gestaltet sich oft als schwierig, weil nicht immer eine exakte
+Kopie des aktuellen Produktionssystem zur Verfügung steht. Mit steigender
+Komplexität steigt der Aufwand, geschriebene Cookbooks manuell zu testen. Im
+Folgenden werden verschiedene Möglichkeiten aufgeführt, wie dies automatisiert
+werden kann.
 
 Die erste und einfachste Methode ist der Befehl:
 
 \shellcmd{knife cookbook test [COOKBOOKS...]}
 
-Dieser überprüft den Rubyquellcode und die Templates des Cookbooks auf Syntaxfehler.
-Allerdings treten viele Fehler erst zur Laufzeit auf, insbesonderen da Ruby
-eine dynamische Programmiersprache. Ein anderes Programm ist foodcritic. Dies
-ist eine statische Codeanalyse ähnlich \href{http://www.jslint.com/}{JSlint}
-oder \href{http://perl-critic.stacka.to/}{Perl::Critic}. Dabei wird der
-Rubycode gegen einen Regelsatz getestet, um so schlechten Stil zu erkennen oder
-um Codingstandards innerhalb eines Projekts einzuhalten. Dieser Regelsatz kann
-durch eigene Regeln erweitern werden.
+Das Kommandozeilenprogramm \emph{knife} ist Teil von Chef. Es ist das primäre
+Verwaltungsprogramm für Adminstratoren.  Der Unterbefehl \emph{cookbook test}
+überprüft den Rubyquellcode und die Templates des Cookbooks auf Syntaxfehler.
+Allerdings treten viele Fehler erst zur Laufzeit auf, insbesonderes da Ruby eine
+dynamische Programmiersprache ist. Ein anderes Programm ist foodcritic. Es führt
+eine statische Codeanalyse ähnlich \href{http://www.jslint.com/}{JSlint} oder
+\href{http://perl-critic.stacka.to/}{Perl::Critic} auf der eigenen Codebasis
+durch. Dabei wird der Rubycode gegen einen Regelsatz getestet, um so häufige
+Programmierfehler zu erkennen oder um Codingstandards innerhalb eines Projekts
+einzuhalten. Dieser Regelsatz kann durch eigene Regeln erweitern werden.
 
 \textbf{Chefspec}
 \label{chefspec}
 
-Chefspec baut auf das in Ruby verbreitete Testframework
+Chefspec baut auf das, in Ruby verbreitete, Testframework
 \href{http://rspec.info/}{RSpec} auf. Rspec ist ein Testframework, welches auf
 \href{http://dannorth.net/2012/05/31/bdd-is-like-tdd-if/}{Behavior Driven
-Development} (kurz BDD) basiert. Hierbei werden die Testcases in derartiger Form
-auf geschrieben, dass sie sich selbst dokumentieren. RSpec kann aus den
-Beschreibungen Sätze bilden und so im Falle eines fehlgeschlagen Tests schnell
-darüber Auskunft zu geben, was der Test getestet hat und aus welchen Grund
-dieser fehlgeschlagen ist. Chefspec erweitert dabei RSpec um die Möglichkeit
-Cookbooks zu laden und stellt spezielle Matcher (RSpec-Terminologie für
-Assertions) bereit, um diese zu testen.  Wie bereits in
-Abschnitt~\ref{ablauf_einer_provisionierung} erwähnt, gibt es 2 Phasen bei der
-Ausführung von Chef. Bei Chefspec wird Provisionierungsprozess nur bis zur
-Convergingphase durchlaufen. Die eigenen Tests überprüfen nur die erzeugten
-Resources. Dies hat den Vorteil, das Tests sehr schnell durchlaufen werden, da
-keine Änderungen an einem System vorgenommen werden müssen. Dies hat Vorteile
-beim Entwickeln, weil man auf diese Weise schnell Feedback bekommt. Das
-Zusammenspiel mehrerer Cookbooks lässt sich dadurch gut testen. Außerdem
-ermöglicht es verschiedene Konfigurationen/Betriebssysteme durchzutesten, ohne
-das diese (zeit)aufwendig aufgesetzt werden müssen. Da Chefspec allerdings zu
-keinen Zeitpunkt Code auf dem System ausführt, sind weitere Integrationstest
-unerlässlich.
+Development} (kurz BDD) basiert. Hierbei dokumentieren sich Testcases selbst
+durch Einfügen von Beschreibungen. RSpec kann Sätze aus diesen Beschreibungen
+bilden und so im Falle eines fehlgeschlagen Tests schnell darüber Auskunft
+geben, was der Test getestet hat und aus welchen Grund dieser fehlgeschlagen
+ist. Chefspec erweitert dabei RSpec um die Funktion, Cookbooks zu laden und
+stellt spezielle Matcher (RSpec-Terminologie für Assertions) bereit, um diese zu
+testen.  Wie bereits in Abschnitt~\ref{ablauf_einer_provisionierung} erwähnt,
+gibt es zwei Phasen bei der Ausführung von Chef. Bei Chefspec wird der
+Provisionierungsprozess nur bis zur Convergingphase durchlaufen. Die eigenen
+Tests überprüfen nur die erzeugten \emph{Resources}. Dies hat den Vorteil, das
+Tests sehr schnell durchlaufen werden, da keine Änderungen an einem System
+vorgenommen werden müssen. Dies hat Vorteile beim Entwickeln, weil man auf diese
+Weise schnell Feedback bekommt. Das Zusammenspiel mehrerer Cookbooks lässt sich
+dadurch gut testen. Außerdem ermöglicht es, verschiedene
+Konfigurationen/Betriebssysteme durchzutesten, ohne das diese (zeit)aufwendig
+aufgesetzt werden müssen. Da Chefspec allerdings zu keinen Zeitpunkt Code auf
+dem System ausführt, sind weitere Integrationstest unerlässlich.
 
 Der folgende Test wurde aus dem selbst geschriebenen NTP-Cookbook
 (\ref{ssub:einrichtung-der-netzwerkdienste}) entnommen.
@@ -68,39 +70,42 @@ end
 Im \emph{chef\_run}-Block wird der fiktiven Node Attribute zugewiesen und das zu
 testende Cookbook ausgeführt. Das Ergebnis wird in diesem Beispiel in dem Objekt
 \emph{chef\_run} gespeichert. Gegen dieses Objekt wird getestet, ob bestimmte
-Resourcen korrekt initialisiert wurden. In diesem Fall wird überprüft, ob das
-Packet "ntp" installiert werden soll und ob das Subnetz in dem Template für
-Konfigurationsdatei \emph{/etc/ntp.conf} richtig gesetzt wird.
+\emph{Resources} korrekt initialisiert wurden. In diesem Fall wird überprüft, ob
+das Paket \emph{ntp} installiert werden soll und ob das Subnetz in dem Template
+in der Konfigurationsdatei \emph{/etc/ntp.conf} richtig gesetzt wird.
 
 Die Tests werden mit dem Befehl \emph{rspec} ausgeführt. Wenn keine weiteren Argumente
 angegeben sind, führt dieses Programm alle Dateien unterhalb des Ordners \emph{spec}
 aus, dessen Dateinamen auf \emph{\_spec.rb} enden.
 
-Um alle drei obgenannten Testmethoden gleichzeitig ausführen zu lassen, wurde
-ein Rakefile geschrieben. \href{http://rake.rubyforge.org/}{Rake} ist das in Ruby
-geschriebene Äquivalent zu Make, welches ein verbreitetes Buildprogramm auf
-UNIX-Basierten Plattformen ist. Die Ausführung der Tests geschieht mit dem Befehl:
+Um alle drei oben genannten Testmethoden gleichzeitig ausführen zu lassen, wurde
+ein Rakefile geschrieben. \href{http://rake.rubyforge.org/}{Rake} ist das, in
+Ruby geschriebene Äquivalent, zu Make, welches ein verbreitetes Buildprogramm
+auf Unix-Ähnlichen Plattformen ist. Die Tests werden durch den Task \emph{test}
+ausgeführt:
 
 \shellcmd{rake test}
 
-Dieser muss innerhalb Projektverzeichnis aufgerufen werden.
+Dieser muss innerhalb Projektverzeichnises aufgerufen werden.
 
-\textbf{Minitest Handler}
+\textbf{Minitest-Handler}
 \label{minitest_handler}
 
-\href{https://github.com/btm/minitest-handler}{Minitest Handler} hingegen wird nach jedem Provisionierungsdurchgang
-ausgeführt. Im Gegensatz zu Chefspec nutzt es das Minitest Framework, welches
-schon mit Ruby mitgeliefert wird. Allerdings kann man durch einbinden, der Zeile:
+\href{https://github.com/btm/minitest-handler}{Minitest-Handler} hingegen wird
+nach jedem Provisionierungsdurchgang ausgeführt. Im Gegensatz zu Chefspec nutzt
+es das Minitest-Framework, welches schon mit Ruby mitgeliefert wird. Allerdings
+kann man durch einbinden, der Zeile:
 
 \begin{lstlisting}
 require "minitest/spec"
 \end{lstlisting}
 
-eine RSpec sehr ähnliche Syntax benutzen. Um Minitest Handler zu nutzen, muss
-das Recipe aus minitest-handler-cookbook als erstes Recipe in der node geladen
-werden. Minitest Handler durchsucht beim Durchlauf in jedem anderen cookbook, in
-den Unterordnern in \emph{files/} nach dem Verzeichnis \emph{test} und lädt
-alle Tests aus diesem Verzeichnis. Über die Beschreibungszeile:
+eine Syntax benutzen, die RSpec sehr ähnliche ist. Um Minitest-Handler zu
+nutzen, muss das Recipe aus \emph{Minitest-Handler-Cookbook} als erstes Recipe
+in der node geladen werden. Minitest-Handler durchsucht beim Durchlauf in jedem
+anderen Cookbook, in den Unterordnern in \emph{files/} nach dem Verzeichnis
+\emph{test} und lädt alle Tests aus diesem Verzeichnis. Über die
+Beschreibungszeile:
 
 \begin{lstlisting}[language=Ruby]
 describe_recipe "ntp::default" do #
@@ -108,11 +113,11 @@ describe_recipe "ntp::default" do #
 end
 \end{lstlisting}
 
-wird angeben für, welches Recipe der Test gedacht ist (In diesem Fall das
+wird angeben, für welches Recipe der Test gedacht ist (In diesem Fall das
 Defaultrecipe aus dem NTP-Cookbook). Wenn das entsprechende Recipe von der Node
-ausgeführt wird, wird der dazugehörige Test nach dem Provisionierunsdurchlauf
-ebenfalls ausgeführt. Minitest Handler erweitert RSpec um nützliche Methoden um
-den Status des Systems zu überprüfen. Hier ein Beispiel aus dem Bindcookbook,
+ausgeführt wird, wird der dazugehörige Test nach dem Provisionierungsdurchlauf
+ebenfalls ausgeführt. Minitest-Handler erweitert RSpec um nützliche Methoden, um
+den Status des Systems zu überprüfen. Nachfolgend ein Beispiel aus dem Bind-Cookbook,
 welches in Abschnitt~\ref{ssub:einrichtung-der-netzwerkdienste} erwähnt wurde:
 
 \begin{lstlisting}[language=Ruby]
@@ -128,10 +133,12 @@ end
 
 Die Methode \emph{assert\_sh} überprüft den Exitstatus eines Befehls und schlägt
 fehl, wenn dieser ungleich Null ist, während die \emph{service}-Methode den
-Status eines Systemdienst sicherstellt. Es gibt noch weitere Testmethoden, wie
+Status eines Systemdienst sicherstellt.  Weitere Testmedhoden sind zum Beispiel
 das Überprüfen von Verzeichnissen, Inhalte von Dateien oder Mountpoints. Viele
 Fehler werden in der Regel schon von den Provider erkannt und festgestellt.
-Mit Minitest Handler kann dies Erweitern um zum Beispiel protokollspezifische
-Tests durchzuführen.
+Minitest-Handler kann dies Erweitern um protokollspezifische Tests durchzuführen
+oder das Testen von Funktionalität bestimmter Dienste.
+
+TODO Resume und Ausblick
 
 % vim: set spell spelllang=de_de

bericht/sources.bib

@@ -15,3 +15,12 @@
   year = {2014}
   note = "[Online, 20.03.2014]"
 }
+
+@online{chefhistory,
+  author = {chef}
+  title = {{History of Chef: What's in a Name? }}
+  howpublished =
+    "\url{http://www.youtube.com/watch?v=Ia2ItmjRsw8&feature=plcp}",
+  year = {2014}
+  note = "[Online, 24.03.2014]"
+}

bericht/sv/sv-filesystems.tex

@@ -87,7 +87,7 @@ Dateisystem in /fastfs entspricht. Die Rohdaten befinden sich in \emph{aufgabe3.
 
 \pgfplotstableread[header=false]{
   125 Lokal
-  104 NFS. 
+  104 NFS.
   67.9 GlusterFS
 }\readtable
 

bericht/sv/sv-iptables.tex

@@ -15,7 +15,7 @@ Das Internet wird durch folgende Regel in der NAT-Tabelle:
 -A POSTROUTING -o eth0 -j MASQUERADE
 \end{lstlisting}
 
-für die Compute-Nodes zugängig gemacht. Dazu musste noch die Datei \emph{/etc/sysctl.d} mit der Zeile: 
+für die Compute-Nodes zugängig gemacht. Dazu musste noch die Datei \emph{/etc/sysctl.d} mit der Zeile:
 
 \begin{lstlisting}
 net.ipv4.ip_forward = 1