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
+\href{http://www.getchef.com/chef/}{Chef} ist ein Framework, welches eine
-ermöglicht automatisiert Server zu konfigurieren und zu verwalten. Der
+automatisierte Serverkonfiguration und -verwaltung ermöglicht. (TODO -
-Endanwender beschreibt hierbei die Systemresourcen und ihre Zustände in der
+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
+Ein solches untergliedert sich in mehrere \emph{Cookbooks}\label{cookbook}.  Ein
-Grundverwaltungseinheit darstellt. Jedes dieser Cookbooks, erfüllt einen
+Cookbook ist die Grundverwaltungseinheit in Chef. Es erfüllt einen bestimmten
-bestimmten Teilaspekt des Systems, (z.B. die Einrichtung eines Webservers
+Teilaspekt des Systems (z.B. die Einrichtung eines Webservers
-\href{https://github.com/opscode-cookbooks/apache2}{Apache}). Cookbooks
+\href{https://github.com/opscode-cookbooks/apache2}{Apache}). Cookbooks können
-können versioniert werden. Es können Abhängigkeiten zwischen mehreren
+versioniert werden. Es können Abhängigkeiten zwischen mehreren Cookbooks
-Cookbooks angegeben werden.
+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
+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
+Node eingefügt. Diese gibt die Reihenfolge an, in welcher Roles und Cookbooks
-Cookbooks angewendet werden. Roles bieten eine Möglichkeit Nodes, welche die
+angewendet werden. Roles bieten eine Möglichkeit, Nodes zu gruppieren, welche die
-gleiche Aufgaben in einer Organisation besitzen, zu gruppieren (z.B. Webserver).
+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
+  \item[Chef-Solo] Chef-Solo ist die einfachste Ausführungsform. Alle nötigen
-    nötigen Daten aus einem lokalen Verzeichnis geladen. Im Gegensatz zu den
+    Daten werden aus einem lokalen Verzeichnis geladen. Im Gegensatz zu
-    anderen Methoden heißt bei dieser das auszuführende Programm
+    \emph{Chef-Server} und \emph{Enterprise Chef} wird bei Chef-Solo das
-    \emph{chef-solo} statt \emph{chef-client}. Diese Form wurde für die
+    Programm \emph{chef-solo} an Stelle von \emph{chef-client} ausgeführt. Diese
-    Umsetzung der Aufgabenstellung in
+    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
+  \item[Chef-Server] Hierbei authentifiziert sich \emph{Chef-Client} über eine
-    \emph{REST-Api} zu einem \emph{Chef-server} mittels eines privaten RSA-Keys.
+    \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
+    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
+    Chef-Server bietet eine webbasierte GUI für die Administration an. Die
-    Attribute aller Nodes sind über die eingebaute Suchemaschine \emph{Solr}
+    Attributes aller Nodes sind über die eingebaute Suchmaschine
-    durchsuchbar.
+    \href{https://lucene.apache.org/solr/}{\emph{Solr}} durchsuchbar.
-  \item[Enterprise Chef/Hosted Enterprise Chef] Ähnlich wie Chef-server bietet
+  \item[Enterprise-Chef/Hosted-Enterprise-Chef] Enterprise-Chef bietet
-    aber eine bessere Skalierbarkeit, rolenbasierte Benutzerverwaltung, bessere
+    zusätzlich zu den Funktionen der Opensource-Version Chef-Server eine
-    Überwachung, eine verbesserte Weboberfläche sowie Push-Deployment an.
+    rollenbasierte Benutzerverwaltung, bessere Überwachung, eine verbesserte
-    Während Hosted Enterprise Chef die Firma Chef den Serverteil betreibt, ist
+    Weboberfläche sowie Push-Deployment an. Während bei Hosted-Enterprise-Chef
-    bei Enterprise Chef der Server in der eigenen
+    die Firma Chef den Serverteil betreibt und die Skalierung des Dienstes
-    Organisation~\cite{chefenterprise}
+    ü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
+Nachfolgend ist die Ordnerstruktur eines Cookbooks am Beispiel von
-\href{https://github.com/opscode-cookbooks/apt}{apt} dargestellt:
+\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
+  \item[attributes] Attributes sind einfache Schlüssel-Wert-Beziehungen und
-    können Strings, Zahlen oder Arrays sein. Die gesetzten Attribute können in
+    setzen Standardwerte für das Cookbook. Die Schlüssel sind hierarchisch
-    Roles, Nodes oder von anderen Cookbooks überschrieben werden. Hierfür gibt
+    organisiert. In der Regel ist die höchste Ebene der Name des Cookbooks (z.B.
-    es die Prioritäten default, force\_default, normal und override um die
+    \emph{normal.mysql.client.packages}). Werte können Strings, Zahlen oder
-    Reihenfolge zu beeinflussen. Attributes sind hierarchisch organisiert. In
+    Arrays sein. Die gesetzten Attributes können in Roles, Nodes oder von
-    der Regel ist die höchste Ebene der Name des Cookbooks. (z.B.
+    anderen Cookbooks überschrieben werden. Hierfür werden die Attributes mit
-    \emph{normal.mysql.client.packages})
+    den verschiedenen Prioritäten default, force\_default, normal und override
-  \item[files] Hier können statische Dateien eingefügt werden, welche dann auf
+    gesetzt (aufsteigender Wertigkeit) gesetzt, wobei eine höhere Priorität eine
-    dem Zielsystem in das entsprechende Verzeichnis kopiert werden können.
+    Niedrigere überschreibt.
-  \item[libraries] In diesem Verzeichnis können Hilfsfunktionen und
+  \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
+  \item[resources] Ressourcen beschreiben die Bestandteile eines Systems. Eine
-    Ressource kann z.B. eine Datei, ein Prozess oder ein Packet sein. Man
+    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
+    soll und Chef versucht, diesen Zustand  herzustellen. Chef liefert bereits
-    viele wichtige Ressourcen mit. In Cookbooks können man darüber hinaus eigene
+    viele wichtige Ressourcen mit. In Cookbooks können darüber hinaus eigene
-    Ressourcen definiert werden.
+    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).
+    können (z.B. bei Paketmanagern oder Initsystemen TODO - Initsystemen
-  \item[recipes] In Recipes werden Ressourcen instantiiert, welche nötig sind
+    erklären). In eigenen Cookbooks erstellte Resources/Provider nennt man LWRP
-    um die gewünschte Aufgabe zu erreichen. Dabei können Abhängigkeiten zwischen
+    (Lightweight-Resource/Provider).
-    diesen angegeben werden.
+  \item[recipes] In Recipes werden Ressourcen instanziiert, welche nötig sind,
-  \item[definitions] Ressourcen, welche häufiger in verschiedenen Recipes auf
+    um die gewünschte Ziel zu erreichen. Dabei können Abhängigkeiten zwischen
-    ähnliche Art und Weise benötigt werden, können in eine \emph{Definition}
+    Recipes angegeben werden.
-    ausgelagert 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
+    Beispiel Konfigurationsdateien zu erzeugen. In Chef wird für diesen Zweck
-    Templatesprache eRuby (Embedded Ruby) ein. Diese führt in den Templates
+    die Templatesprache eRuby (Embedded Ruby) verwendet. In ERB-Templates wird
-    Rubycode, der sich zwischen den Tags \emph{<\%} und \emph{\%>} befindet, aus.
+    Rubycode ausgeführt, der sich zwischen den Tags \emph{<\%} und \emph{\%>}
-    Dies erlaubt es Variablen zu interpolieren, sowie If-Statements und
+    befindet. Dies erlaubt es einerseits den Inhalt von Variablen oder den
-    Schleifen.
+    Rückgabewert von Methoden zu interpolieren, andererseits können in Templates
-  \item[metadata.rb] In dieser Datei kann der Name des Cookbook, die Version,
+    Kontrollstrukturen wie If-Statements und Schleifen verwendet werden.
-    eine Beschreibung sowie Abhängigkeiten zu anderen Cookbooks angeben 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}
+\label{ablauf_einer_provisionierung}\\
-
+Der genaue Ablauf wurde der Onlinedokumentation (\cite{chefrun}) von Chef
-Der genaue Ablauf wurde der Onlinedokumentation (~\cite{chefrun}) von Chef
+entnommen. Wie schon zu Beginn erwähnt, wird die Provisonierung von einem
-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
-Programm namens \emph{Chef-client} durchgeführt. Je nach Umgebung kann dieser
+dieser periodisch vom Scheduler \emph{Cron} gestartet, permanent als
-periodisch vom Scheduler \emph{Cron} gestartet, permanent als Systemdienst
+Systemdienst laufen (z.B. bei Enterprise Chef) oder manuell gestartet werden
-laufen (z.B. bei Enterprise Chef) oder manuell gestartet werden (z.B. bei
+(z.B. bei Vagrant - siehe~\ref{ssub:einrichtung-der-netzwerkdienste}).
-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
+\emph{client.rb}. In dieser stehen beispielsweise die URL des Chef-Server, in
-Chef-Server der Client sich verbinden soll, an welcher Stelle temporäre Daten
+welchem Pfad temporäre Dateien gespeichert werden und der Name der Node.
-gespeichert werden soll und der Name der Node. Letzteres ist wichtig um die Node
+Letzteres ist wichtig, um die Node in Chef einordnen zu können und die richtigen
-richtig von Chef einordnen zu können und die richtigen Einstellungen zuzuweisen.
+Einstellungen zuzuweisen.  Alternativ kann der Name auch von der Bibliothek
-Alternativ kann der Name auch von der 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ückgegriffen wird.
-Ohai sammelt noch andere systemrelevante Daten wie Details über
+Ohai sammelt systemrelevante Daten wie Details über Hardwarekomponenten (Anzahl
-Hardwarekomponenten (Anzahl der CPUs, Größe und Art des RAMs, Netzwerkanbindung,
+der CPUs, Größe und Art des RAMs, Netzwerkanbindung, Festplatten/SSDs, \dots),
-Festplatten/SSDs, \dots), Informationen über die Plattform (Art des
+Informationen über die Plattform (Art des Betriebssystems und sowie dessen Version,
-Betriebssystems und Version, installierte Software) und die laufenden Prozesse.
+installierte Anwendungssoftware) und die laufenden Prozesse.  Diese Informationen sind
-Diese Informationen sind durch eigene Ohai-Plugins erweiterbar und können im
+durch eigene Ohai-Plugins erweiterbar und können im Provisionierungsprozess
-Provisionierungsprozess genutzt werden, um weitere Entscheidungen zu treffen.
+genutzt werden, um weitere Entscheidungen zu treffen.  Sie sind darüber hinaus
-Sie sind darüber hinaus auch auf dem Server gespeichert und für andere Clients
+auch auf dem Server gespeichert und für andere Clients abrufbar.
-abrufbar.
 
-Nach dem alle Einstellungen eingelesen sind, folgt im Falle von Chef-Server, die
+Nach dem alle Einstellungen eingelesen sind, verbindet sich Chef-Client mit
-Authentifizierung mit diesem über den vorher auf der Node abgelegten
+Chef-Server. Die Authentifizierung erfolgt über den vorher auf der Node
-RSA-Schlüssel. Für Adminstratoren gibt es für den
+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.
+welchem Chef initial auf der Node installiert, kann mit diesem eine Node auf dem
-Mit diesem kann eine Node auf dem Server registriert werden, umso einen
+Server registriert werden und ein Clientkey generiert werden.
-Clientkey zu generieren.
 
-Anschließend werden alte gesetzte Attributes und die Run-list vom Server
+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
+übertragen. Im 1. Durchlauf oder bei Verwendung von Chef-Solo sind diese Daten
-vorhanden (ausgenommen der voreingestellten Run-list von Chef-Server).
+nicht vorhanden.  Stattdessen kann eine Datei im JSON-Format angegeben werden,
-Stattdessen kann eine Datei im JSON-Format angegeben werden, um die Attributes
+um die Attributes und der Run-List für die Node zu spezifizieren. Außerdem ist
-und der Run-list für diese Node zu spezifizieren.
+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
+Durch Auswertung der eingebunden Rollen und Recipes werden die benötigen
-benötigen Cookbooks ermittelt. Der Client fordert für diese eine Liste aller
+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
+neu generiert und entsprechend ihrer Priorität gesetzt. Die, in den Cookbooks
-definierten Resources werden geladen und mit den von Chef mitgelieferten
+definierten, Resources werden geladen und mit den, von Chef mitgelieferten,
-Resources in der Resourcecollection zusammengefasst. Nachdem alle Definitions
+Resources in der Resource-Collection zusammengefasst. Nachdem alle Definitions
-und Libraries geladen wurden, werden schließlich die Recipes verarbeitet. In
+und Libraries geladen wurden, werden schließlich die Recipes verarbeitet. Die
-diesen werden Resourcen des Systems beschrieben und durch Actions deren Zustand
+darin erstellten Resources beschreiben das System. Für jede Resource wird eine
-festgelegt.
+Action festgelegt, was gleichbedeutend mit deren Zustand ist.
 
-Im nächsten Schritt folgt das sogenannte Converging. Es werden alle Resources in
+Im nächsten Schritt folgt das sogenannte Converging (englisch für
-der Reihenfolge abgearbeitet. Dabei wird für jede Resource der für die Plattform
+\emph{Angleichen}). Es werden alle Resources Schritt für Schritt abgearbeitet.
-zugehörige Provider ausgewählt. Dieser überprüft den aktuellen Zustand der
+Dabei wird für jede Resource, der für die Plattform zugehörige, Provider
-Resource und verändert wenn notwendig das System um den Sollzustand zu
+ausgewählt. Dieser überprüft den aktuellen Zustand der Resource und verändert,
-erreichen. Zum Schluss überträgt Chef-client die aktualisierten Attributes auf
+wenn notwendig, das System, um den Sollzustand zu erreichen. Zum Schluss überträgt
-den Server, von welchem sie in Solr indexiert werden.
+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.
+Es besteht die Möglichkeit Handler vor oder nach dem Provisioning auszuführen.
-Diese können beispielsweise im Fehlerfall Benachrichtigungen an das
+Diese können im Fehlerfall Benachrichtigungen an das Monitoringssystem oder per
-Monitoringssystem oder per Email verschicken. In letzten Abschnitt
+Email verschicken. In letzten Abschnitt (\ref{minitest_handler}) wird dieser
-(\ref{minitest_handler}) wird dieser Mechanismus genutzt um Tests auszuführen.
+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
+\href{http://vagrantup.com}{Vagrant} verwendet. Dies ist ein Programm, um auf
-Basis von Virtualbox und anderen Virtualisierungslösungen schnell und
+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
+in der Datei \emph{Vagrantfile} hinterlegt, welche Vagrant beim Start einliest.
-einliest. Vagrant bietet eine gute Integration für Chef. Es bietet Optionen, mit
+Vagrant kann Chef beim Erstellen von virtuellen Maschinen integrieren.  Es
-welchen Einstellungen neue virtuelle Maschinen provisioniert werden sollen. Zum
+bietet Optionen, mit welchen Einstellungen neue virtuelle Maschinen
-Einsatz kam das Betriebssystem Ubuntu in der Version 12.04. Das Basisimage
+provisioniert werden sollen. Zum Einsatz kam das Betriebssystem Ubuntu in der
-hierfür wurde von \emph{Chef}, der gleichnamigen Firma hinter Chef,
+Version 12.04. Das Basisimage hierfür wurde von \emph{Chef}, der gleichnamigen
-bereitgestellt. Es wurde ein Netzwerkinterface konfiguriert für die
+Firma, bereitgestellt. Für die Kommunikation mit Vagrant wurde das
-Kommunikation mit Vagrant und ein weiteres Internes für ein virtuelles Netzwerk
+Netzwerkinterface \emph{eth0} konfiguriert. Ein weiteres Netzwerkinterface
-zwischen den VMs zum Betreiben der Netzwerkdienste. Vagrant bietet für diese
+(\emph{eth1}) wird für das interne virtuelle Netzwerk zwischen den VMs zum
-erweiterten Einstellungen keine Optionen. Um diese dennoch zu übernehmen, waren
+Betreiben der Netzwerkdienste benötigt.  Vagrant bietet für diese erweiterten
-spezielle Kommandozeilenargumente an den Befehl \emph{VBoxManage} nötig, welches
+Einstellungen keine Optionen. Um diese dennoch zu übernehmen, waren spezielle
-von Vagrant für Virtualbox genutzt wird. Dies schränkt Nutzung allerdings auf
+Kommandozeilenargumente an den Befehl \emph{VBoxManage} nötig, welches von
-die Visualisierung Virtualbox ein. Vagrant bietet die Möglichkeit neben
+Vagrant für Virtualbox genutzt wird. Dies schränkt die Nutzung allerdings auf
-Provisionierungsystemen auch Shellskripte auszuführen. Diese wurde genutzt um
+den Hypervisor Virtualbox ein. Vagrant bietet die Möglichkeit, neben
-Chef auf die zum damaligen Zeitpunkt aktuellste Version 11.8.2 upzudaten.
+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
+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:
+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
+installiert werden. Auf dem Betriebssystem Windows kann auf den
-\href{http://rubyinstaller.org/}{RubyInstaller} genutzt werden. Um die nötigen
+\href{http://rubyinstaller.org/}{RubyInstaller} zurückgegriffen werden. Um die
-Abhängigkeiten zu installieren, müssen folgende Befehle ausgeführt im
+benötigten Ruby-Bibliotheken zu installieren, müssen folgende 2 Befehle im
-Projektverzeichnis werden:
+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
+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
+\emph{virtualbox-client-modules} in der VM installiert sein. Diese sind in
-vielen Images, die es für Vagrant gibt, vorhanden. Allerdings muss die
+meisten vielen Images vorhanden, die es für Vagrant gibt. Allerdings muss die
-Virtualboxversion des Host mit Dem in der VM übereinstimmen. Abhilfe schafft das
+Virtualboxversion des Host mit der Version in der VM übereinstimmen. Abhilfe
-Vagrantplugin \href{https://github.com/dotless-de/vagrant-vbguest}{vagrant-vbguest}.
+schafft das Vagrantplugin
-Dieses vergleicht beim Start die Versionen und installiert gegeben falls eine
+\href{https://github.com/dotless-de/vagrant-vbguest}{vagrant-vbguest}. Beim
-Andere in der VM.
+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
+Während des ersten Starts wird die VM mit Chef provisioniert. Später kann Chef
-folgenden Befehl gestartet werden:
+erneut mit Befehl:
 
 \shellcmd{vagrant provision}
 
-Als Netzwerkdienste wurden die Protokolle DHCP, DNS und NTP gewählt. Die
+gestartet werden:
-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.
 
-Die Attribute der Roles und Node wurden in JSON-Dateien abgelegt in den Ordnern
+Als Netzwerkdienste wurden die Protokolle DHCP, DNS und NTP gewählt. Die VMs
-\emph{roles/} und \emph{nodes}. Es gibt je eine Role für die Computenode und
+wurden in die zwei Gruppen \emph{Headnodes}und \emph{Computenodes} geteilt. Die
-Headnode. In der aktuellen Konfiguration erzeugt Vagrant eine Headnode
+Headnode bietet die genannten Dienste an. Die Computenodes fordern auf dem
-mit dem Hostnamen \emph{node0.lctp} und zwei Computenodes (\emph{node1.lctp} und
+internen Netzwerk per DHCP eine IP-Adresse an und nutzen den DNS- und NTP-Dienst
-\emph{node2.lctp}).
+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
+    Als DNS-Server wurde bind gewählt. Das Cookbook richtet diesen Dienst ein
-    und fügt die in den Attributen konfigurierten DNS-Einträge hinzu zu den
+    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
+    Dieses Cookbook richtet den ISC-DHCP-Server (TODO Link) ein. Neben der
-    festen IP-Adressen zu Nodes, kann ein DNS-Server und ein NTP-Server
+    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
+  \item[apt] bringt die lokalen Paketquellen auf den aktuellen Stand und
-    aktualisiert den Packetcache.
+    aktualisiert den Paketcache.
   \item[network\_interfaces] verwaltet Debians Netzkonfiguration
-    /etc/network/interfaces
+    /etc/network/interfaces.
-  \item[minitest-handler] Sammelt alle Tests in den Cookbooks führt diese
+  \item[minitest-handler] Sammelt alle Tests in den Cookbooks und führt diese
-    nach der Provisionierung aus (siehe~\ref{minitest_handler})
+    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
+  Unterschiede zwischen Chef und Puppet ein.
-\item Wählen Sie zwei Netzwerkdienste aus die während der Lehrveranstaltung
+\item Wählen Sie zwei Netzwerkdienste aus, die während der Lehrveranstaltung
-  besprochen wurden und erstellen Sie Provisionierungsvorlagen für diese
+  besprochen wurden und erstellen Sie Provisionierungsvorlagen für diese.
-\item Beschreiben Sie wie die Verifikation von Provisionierungsvorlagen
+\item Beschreiben Sie, wie die Verifikation von Provisionierungsvorlagen
-  bei der Bereitstellung von HPC-Software verwendet werden kann
+  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
+Wie auch in der Softwareentwicklung müssen Konfigurationssysteme getestet
-gestaltet sich oft als schwierig, weil nicht immer eine exakte Kopie des
+werden. Dies gestaltet sich oft als schwierig, weil nicht immer eine exakte
-aktuellen Produktionssystem zur Verfügung steht. Mit steigender Komplexität
+Kopie des aktuellen Produktionssystem zur Verfügung steht. Mit steigender
-steigt der Aufwand geschriebene Cookbooks manuell zu testen. Im Folgenden werden
+Komplexität steigt der Aufwand, geschriebene Cookbooks manuell zu testen. Im
-verschiedene Möglichkeiten aufgeführt, wie dies automatisiert werden kann.
+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.
+Das Kommandozeilenprogramm \emph{knife} ist Teil von Chef. Es ist das primäre
-Allerdings treten viele Fehler erst zur Laufzeit auf, insbesonderen da Ruby
+Verwaltungsprogramm für Adminstratoren.  Der Unterbefehl \emph{cookbook test}
-eine dynamische Programmiersprache. Ein anderes Programm ist foodcritic. Dies
+überprüft den Rubyquellcode und die Templates des Cookbooks auf Syntaxfehler.
-ist eine statische Codeanalyse ähnlich \href{http://www.jslint.com/}{JSlint}
+Allerdings treten viele Fehler erst zur Laufzeit auf, insbesonderes da Ruby eine
-oder \href{http://perl-critic.stacka.to/}{Perl::Critic}. Dabei wird der
+dynamische Programmiersprache ist. Ein anderes Programm ist foodcritic. Es führt
-Rubycode gegen einen Regelsatz getestet, um so schlechten Stil zu erkennen oder
+eine statische Codeanalyse ähnlich \href{http://www.jslint.com/}{JSlint} oder
-um Codingstandards innerhalb eines Projekts einzuhalten. Dieser Regelsatz kann
+\href{http://perl-critic.stacka.to/}{Perl::Critic} auf der eigenen Codebasis
-durch eigene Regeln erweitern werden.
+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
+Development} (kurz BDD) basiert. Hierbei dokumentieren sich Testcases selbst
-auf geschrieben, dass sie sich selbst dokumentieren. RSpec kann aus den
+durch Einfügen von Beschreibungen. RSpec kann Sätze aus diesen Beschreibungen
-Beschreibungen Sätze bilden und so im Falle eines fehlgeschlagen Tests schnell
+bilden und so im Falle eines fehlgeschlagen Tests schnell darüber Auskunft
-darüber Auskunft zu geben, was der Test getestet hat und aus welchen Grund
+geben, was der Test getestet hat und aus welchen Grund dieser fehlgeschlagen
-dieser fehlgeschlagen ist. Chefspec erweitert dabei RSpec um die Möglichkeit
+ist. Chefspec erweitert dabei RSpec um die Funktion, Cookbooks zu laden und
-Cookbooks zu laden und stellt spezielle Matcher (RSpec-Terminologie für
+stellt spezielle Matcher (RSpec-Terminologie für Assertions) bereit, um diese zu
-Assertions) bereit, um diese zu testen.  Wie bereits in
+testen.  Wie bereits in Abschnitt~\ref{ablauf_einer_provisionierung} erwähnt,
-Abschnitt~\ref{ablauf_einer_provisionierung} erwähnt, gibt es 2 Phasen bei der
+gibt es zwei Phasen bei der Ausführung von Chef. Bei Chefspec wird der
-Ausführung von Chef. Bei Chefspec wird Provisionierungsprozess nur bis zur
+Provisionierungsprozess nur bis zur Convergingphase durchlaufen. Die eigenen
-Convergingphase durchlaufen. Die eigenen Tests überprüfen nur die erzeugten
+Tests überprüfen nur die erzeugten \emph{Resources}. Dies hat den Vorteil, das
-Resources. Dies hat den Vorteil, das Tests sehr schnell durchlaufen werden, da
+Tests sehr schnell durchlaufen werden, da keine Änderungen an einem System
-keine Änderungen an einem System vorgenommen werden müssen. Dies hat Vorteile
+vorgenommen werden müssen. Dies hat Vorteile beim Entwickeln, weil man auf diese
-beim Entwickeln, weil man auf diese Weise schnell Feedback bekommt. Das
+Weise schnell Feedback bekommt. Das Zusammenspiel mehrerer Cookbooks lässt sich
-Zusammenspiel mehrerer Cookbooks lässt sich dadurch gut testen. Außerdem
+dadurch gut testen. Außerdem ermöglicht es, verschiedene
-ermöglicht es verschiedene Konfigurationen/Betriebssysteme durchzutesten, ohne
+Konfigurationen/Betriebssysteme durchzutesten, ohne das diese (zeit)aufwendig
-das diese (zeit)aufwendig aufgesetzt werden müssen. Da Chefspec allerdings zu
+aufgesetzt werden müssen. Da Chefspec allerdings zu keinen Zeitpunkt Code auf
-keinen Zeitpunkt Code auf dem System ausführt, sind weitere Integrationstest
+dem System ausführt, sind weitere Integrationstest unerlässlich.
-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
+\emph{Resources} korrekt initialisiert wurden. In diesem Fall wird überprüft, ob
-Packet "ntp" installiert werden soll und ob das Subnetz in dem Template für
+das Paket \emph{ntp} installiert werden soll und ob das Subnetz in dem Template
-Konfigurationsdatei \emph{/etc/ntp.conf} richtig gesetzt wird.
+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
+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
+ein Rakefile geschrieben. \href{http://rake.rubyforge.org/}{Rake} ist das, in
-geschriebene Äquivalent zu Make, welches ein verbreitetes Buildprogramm auf
+Ruby geschriebene Äquivalent, zu Make, welches ein verbreitetes Buildprogramm
-UNIX-Basierten Plattformen ist. Die Ausführung der Tests geschieht mit dem Befehl:
+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
+\href{https://github.com/btm/minitest-handler}{Minitest-Handler} hingegen wird
-ausgeführt. Im Gegensatz zu Chefspec nutzt es das Minitest Framework, welches
+nach jedem Provisionierungsdurchgang ausgeführt. Im Gegensatz zu Chefspec nutzt
-schon mit Ruby mitgeliefert wird. Allerdings kann man durch einbinden, der Zeile:
+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
+eine Syntax benutzen, die RSpec sehr ähnliche ist. Um Minitest-Handler zu
-das Recipe aus minitest-handler-cookbook als erstes Recipe in der node geladen
+nutzen, muss das Recipe aus \emph{Minitest-Handler-Cookbook} als erstes Recipe
-werden. Minitest Handler durchsucht beim Durchlauf in jedem anderen cookbook, in
+in der node geladen werden. Minitest-Handler durchsucht beim Durchlauf in jedem
-den Unterordnern in \emph{files/} nach dem Verzeichnis \emph{test} und lädt
+anderen Cookbook, in den Unterordnern in \emph{files/} nach dem Verzeichnis
-alle Tests aus diesem Verzeichnis. Über die Beschreibungszeile:
+\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
+ausgeführt wird, wird der dazugehörige Test nach dem Provisionierungsdurchlauf
-ebenfalls ausgeführt. Minitest Handler erweitert RSpec um nützliche Methoden um
+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,
+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
+Minitest-Handler kann dies Erweitern um protokollspezifische Tests durchzuführen
-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]"
+}