chef: Rechtschreibfehler und Ausdruck

bericht/chef/chef-comparison.tex

@@ -5,46 +5,53 @@
 ermöglicht automatisiert Server zu konfigurieren und zu verwalten. Der
 Endanwender beschreibt hierbei die Systemresourcen und ihre Zustände in der
 Programmiersprache \href{https://www.ruby-lang.org/}{Ruby}. Diese Definitionen
-werden von \emph{Chef-client} eingelesen und in notwendige Aktionen übersetzt,
+werden von dem Program \emph{Chef-client} eingelesen und in notwendige Aktionen
-welche ausgeführt werden müssen, um den beschriebenen Zustand umzusetzen.
+ü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}). Coobooks
+\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.
 Einer Node können \emph{Attributes}, \emph{Roles} und Cookbooks zugewiesen
-werden. Roles und Cookbooks werden in eine sogenannte \emph{Run-list} eingefügt.
+werden. Roles und Cookbooks werden dazu in die sogenannte \emph{Run-list} der
-Diese gibt die Reihenfolge angibt, in welche Roles und Cookbooks angewendet
+Node eingefügt.  Diese gibt die Reihenfolge angibt, in welche Roles und
-werden. Roles bieten eine Möglichkeit Nodes, welche die gleiche Aufgaben in
+Cookbooks angewendet werden. Roles bieten eine Möglichkeit Nodes, welche die
-einer Organisation besitzen, zu gruppieren (z.B. webserver).
+gleiche Aufgaben in einer Organisation besitzen, zu gruppieren (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] Dies ist die einfachste Ausführungsform. Hierbei werden alle
     nötigen Daten aus einem lokalen Verzeichnis geladen. Im Gegensatz zu den
-    anderen Methoden wird bei dieser das Programm \emph{chef-solo} gestaret.
+    anderen Methoden heißt bei dieser das auszuführende Programm
-    Diese Form wurde für die Umsetzung der Aufgabenstellung gewählt.
+    \emph{chef-solo} statt \emph{chef-client}. Diese Form wurde für die
-  \item[chef-server] Hierbei authentifiziert sich \emph{Chef-client} über eine
+    Umsetzung der Aufgabenstellung in
-    \emph{REST-Api} zu einem \emph{chef-server} mittels eines privaten RSA-Keys.
+    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
-    diesem alle nötigen für die zu provisionierende \emph{node}. Chef-server
+    diesem alle nötigen Informationen für die zu provisionierende \emph{Node}.
-    bietet eine Weboberfläche für die Administrierung an. Die Attribute aller
+    Chef-server bietet eine webbasierte GUI für die Administration an. Die
-    Nodes sind über die eingebaute Suchemaschine \emph{Solr} durchsuchbar.
+    Attribute aller Nodes sind über die eingebaute Suchemaschine \emph{Solr}
-  \item[Enterprise Chef/Hosted Enterprise Chef] Ähnlich wie Chef-server aber
+    durchsuchbar.
-    bietet bessere Skalierbarkeit, rolenbasierte Benutzerverwaltung, bessere Überwachung,
+  \item[Enterprise Chef/Hosted Enterprise Chef] Ähnlich wie Chef-server bietet
-    Push-Deployment und eine verbesserte Weboberfläche~\cite{chefenterprise}
+    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}
 \end{description}
 
 \textbf{Aufbau eines Cookbook}
 \label{aufbau_eines_cookbook}
 
-Hier ist die Ordnerstruktur des Cookbook
+Hier ist die Ordnerstruktur eines Cookbooks am Beispiel von
 \href{https://github.com/opscode-cookbooks/apt}{apt} dargestellt:
 
 \begin{tikzpicture}
@@ -87,33 +94,33 @@ 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 anderen Cookbooks überschrieben werden. Hierfür gibt es
+    Roles, Nodes oder von anderen Cookbooks überschrieben werden. Hierfür gibt
-    die Prioritäten default, force\_default, normal und override um das
+    es die Prioritäten default, force\_default, normal und override um die
-    überschreiben deterministisch zu machen. Attributes sind hierarchisch
+    Reihenfolge zu beeinflussen. Attributes sind hierarchisch organisiert. In
-    organisiert. In der Regel ist die höchste Ebene der Name des Cookbooks.
+    der Regel ist die höchste Ebene der Name des Cookbooks. (z.B.
-    (z.B. normal.mysql.client.packages)
+    \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
     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
-    beschreibt, welchen Zustand (action in Chef genannt) diese Ressource haben
+    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 kann man darüber hinaus eigene
+    viele wichtige Ressourcen mit. In Cookbooks können man darüber hinaus eigene
-    Ressourcen definieren.
+    Ressourcen definiert werden.
-  \item[providers] Während Ressourcen nur die Schnittstelle beschreiben, mit
+  \item[providers] Während Ressourcen nur die Schnittstelle mit allen Attributes
-    allen Attributen, die gesetzt werden können, ist der Provider eine konkrete
+    beschreiben, die gesetzt werden können, ist der Provider eine konkrete
-    Implementierung. Deswegen muss jede Ressource mindestens einen Provider
+    Implementierung. Deswegen muss für jede Ressource mindestens ein Provider
-    besitzen. Es kann mehrere Provider für eine Ressource geben, um zum Beispiel
+    existieren. Es kann mehrere Provider für eine Ressource geben, um zum
-    um mehrere Plattformen/Betriebssysteme abzudecken (z.B. bei Packetmanagern
+    Beispiel um mehrere Plattformenvarianten oder Betriebssysteme abdecken zu
-    oder Initsystemen).
+    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 häufiger in verschiedenen Recipies auf
+  \item[definitions] Ressourcen, welche häufiger in verschiedenen Recipes auf
-    ähnliche Art und Weise benötigt werden, können diese in eine
+    ähnliche Art und Weise benötigt werden, können in eine \emph{Definition}
-    \emph{Definition} ausgelagert werden.
+    ausgelagert 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
@@ -126,7 +133,7 @@ findet. Hier nochmal die einzelnen Verzeichnisse im Überblick:
 
 Beispiel ERB-Template:
 \begin{lstlisting}
-  Diese Zeile wird beim Render ohne Aenderung uebernommen
+  Diese Zeile wird beim Rendern ohne Aenderung uebernommen
   <%# Ein Kommentar%>
 
   Diese Node heisst: <%= @node.name %>
@@ -148,34 +155,35 @@ Beispiel ERB-Template:
 
 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 wieder 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).
+Vagrant - siehe~\ref{ssub:einrichtung-der-netzwerkdienste}).
 
-Als erstes lädt dieser seine Konfiguration aus der Datei \emph{client.rb}. In
+Als erstes lädt dieser Prozess seine Konfiguration aus der Datei
-dieser stehen beispielsweise Informationen mit welchen Chef-Server der Client
+\emph{client.rb}. In dieser stehen beispielsweise Informationen mit welchen
-verbinden soll, an welcher Stelle temporäre Daten gespeichert werden soll und
+Chef-Server der Client sich verbinden soll, an welcher Stelle temporäre Daten
-der Name der Node. Letzteres ist wichtig um die Node richtig von Chef einordnen
+gespeichert werden soll und der Name der Node. Letzteres ist wichtig um die Node
-zu können und die richtigen Einstellungen zuzuweisen.  Alternativ kann der Name
+richtig von Chef einordnen zu können und die richtigen Einstellungen zuzuweisen.
-auch von der der Bibliothek \href{http://docs.opscode.com/ohai.html}{Ohai}
+Alternativ kann der Name auch von der der Bibliothek
-gesetzt werden, in dem auf den Hostnamen oder der FQDN (Fully Qualified Domain
+\href{http://docs.opscode.com/ohai.html}{Ohai} gesetzt werden, in dem auf den
-Name) zurück gegriffen wird.  Ohai sammelt noch andere systemrelevante Daten wie
+Hostnamen oder der FQDN (Fully Qualified Domain Name) zurück gegriffen wird.
-Details über Hardwarekomponenten (Anzahl der CPUs, Größe und Art des RAMs,
+Ohai sammelt noch andere systemrelevante Daten wie Details über
-Netzwerkanbindung, Festplatten/SSDs, \dots), Informationen über die Plattform
+Hardwarekomponenten (Anzahl der CPUs, Größe und Art des RAMs, Netzwerkanbindung,
-(Art des Betriebssystems und Version, installierte Software) und die laufenden
+Festplatten/SSDs, \dots), Informationen über die Plattform (Art des
-Prozesse.  Diese Informationen sind durch eigene Ohai-Plugins erweiterbar und
+Betriebssystems und Version, installierte Software) und die laufenden Prozesse.
-können dann im Provisionierungsprozess genutzt werden um weitere Entscheidungen
+Diese Informationen sind durch eigene Ohai-Plugins erweiterbar und können im
-zu treffen.  Sie sind darüber hinaus auch auf dem Server gespeichert und für
+Provisionierungsprozess genutzt werden, um weitere Entscheidungen zu treffen.
-andere Clients abrufbar.
+Sie sind darüber hinaus auch auf dem Server gespeichert und für andere Clients
+abrufbar.
 
-Nach dem alle Einstellungen eingelesen sind, folgte im Falle von Chef-Server,
+Nach dem alle Einstellungen eingelesen sind, folgt im Falle von Chef-Server, die
-die Authentifizierung mit diesem über den vorher auf der Node abgelegten
+Authentifizierung mit diesem über den vorher auf der Node abgelegten
 RSA-Schlüssel. Für Adminstratoren gibt es für den
 \href{http://docs.opscode.com/knife\_bootstrap.html}{Bootstraprozess}, in
-welchem Chef initial auf der Node installiert wird, einen Validatorkey, mit dem
+welchem Chef initial auf der Node installiert wird, dafür einen Validatorkey.
-eine Node auf dem Server registriert werden kann, umso einen Clientkey zu
+Mit diesem kann eine Node auf dem Server registriert werden, umso einen
-generieren.
+Clientkey zu generieren.
 
 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
@@ -199,8 +207,8 @@ festgelegt.
 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
+Resource und verändert wenn notwendig das System um den Sollzustand zu
-erreichen. Zum Schluss überträgt Chef-client, die aktualisierten Attributes auf
+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.

bericht/chef/chef-services.tex

@@ -2,21 +2,21 @@
 \label{ssub:einrichtung-der-netzwerkdienste}
 
 Für die Provisionierung der Netzwerkdienste wurde
-\href{http://vagrantup.com}{Vagrant} verwendet. Dies ein Programm um auf der
+\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{Opscode}, der Firma hinter Chef, bereitgestellt. Es
+hierfür wurde von \emph{Chef}, der gleichnamigen Firma hinter Chef,
-wurde ein Netzwerkinterface konfiguriert für die Kommunikation mit Vagrant und
+bereitgestellt. Es wurde ein Netzwerkinterface konfiguriert für die
-ein weiteres Internes für ein virtuelles Netzwerk zwischen den VMs zum Betreiben
+Kommunikation mit Vagrant und ein weiteres Internes für ein virtuelles Netzwerk
-der Netzwerkdienste. Vagrant bietet für diese erweiterten Einstellungen keine
+zwischen den VMs zum Betreiben der Netzwerkdienste. Vagrant bietet für diese
-Optionen. Um diese dennoch zu übernehmen, waren spezielle
+erweiterten Einstellungen keine Optionen. Um diese dennoch zu übernehmen, waren
-Kommandozeilenargumente an den Befehl \emph{VBoxManage} nötig, welches von
+spezielle Kommandozeilenargumente an den Befehl \emph{VBoxManage} nötig, welches
-Vagrant für Virtualbox genutzt wird. Dies schränkt Nutzung allerdings auf die
+von Vagrant für Virtualbox genutzt wird. Dies schränkt Nutzung allerdings auf
-Visualisierung Virtualbox ein. Vagrant bietet die Möglichkeit neben
+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.
 
@@ -38,7 +38,7 @@ Zur Verwaltung der externen und internen Cookbooks wurde die
 Abhängigkeitsverwaltung \href{http://berkshelf.com}{Berkshelf} verwendet. Bei
 diesem werden die zu ladenden Cookbooks und die gewünschte Version in einer
 Datei namens Berkssfile angegeben (vergleichbar mit
-\href{http://bundler.io/}{Gemfile} in Ruby).  Berkshelf unterstützt dabei
+\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:
@@ -49,16 +49,16 @@ im Projektverzeichnis ausgeführt werden.
 
 Für das Zusammenspiel mit Vagrant gibt es das Plugin
 \href{https://github.com/berkshelf/vagrant-berkshelf}{vagrant-berkshelf}, so
-dass die von Berkshelf verwalten Cookbooks auch in Vagrant zur Verfügung stehen.
+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 vorhanden, die es für Vagrant gibt. Allerdings muss die
+vielen Images, die es für Vagrant gibt, vorhanden. Allerdings muss die
-Virtualboxversion des Host mit dem der VM übereinstimmen. Abhilfe schafft das
+Virtualboxversion des Host mit Dem in der VM übereinstimmen. Abhilfe schafft das
-Vagrantplugin
+Vagrantplugin \href{https://github.com/dotless-de/vagrant-vbguest}{vagrant-vbguest}.
-\href{https://github.com/dotless-de/vagrant-vbguest}{vagrant-vbguest}. Dieses
+Dieses vergleicht beim Start die Versionen und installiert gegeben falls eine
-überprüft beim Start die Versionen und installiert gegeben falls eine Andere in
+Andere in der VM.
-der VM.
 
 Beide Plugins werden diesen Befehlen installiert:
 
@@ -70,7 +70,7 @@ Gestartet wird die VM mit dem Befehl:
 
 \shellcmd{vagrant up}
 
-Beim 1. Start wird die VM mit Chef provisioniert. Spätere kann Chef erneut mit
+Beim 1. Start wird die VM mit Chef provisioniert. Später kann Chef erneut mit
 folgenden Befehl gestartet werden:
 
 \shellcmd{vagrant provision}
@@ -90,20 +90,20 @@ mit dem Hostnamen \emph{node0.lctp} und zwei Computenodes (\emph{node1.lctp} und
 Für das Deployment wurden fünf Cookbooks geschrieben:
 \begin{description}
   \item[bind]
-    Als DNS-Server wurde bind gewählt. Dieses Cookbook diesen Dienst ein und
+    Als DNS-Server wurde bind gewählt. Dieses Cookbook richtet diesen Dienst ein
-    fügt die in den Attributen konfigurierten DNS-Einträge hinzu zu den
+    und fügt die in den Attributen konfigurierten DNS-Einträge hinzu 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
     festgelegt werden.
-  \item[lctp-network] Dieses Cookbook ist ein Wrappercoobook um das
+  \item[lctp-network] Dieses Cookbook ist ein Wrappercookbook um das
     \href{https://github.com/redguide/network_interfaces}{network\_interfaces}
-    Cookbook. Wrappercookbook werden häufig dazu benutzt um bestehende Cookbooks
+    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.
-    Auf den Headnodes wird eine statische IPadresse gesetzt, der DNS-Server auf
+    Auf den Headnodes wird eine statische IP-Adresse gesetzt, der DNS-Server auf
-    localhost festgelegt und Ipforwarding sowie Masquerading via iptables für
+    localhost festgelegt und IP-Forwarding sowie Masquerading via iptables für
     den Routerbetrieb aktiviert.
   \item[ntp]
     Dieses Cookbook richtet den NTP-Deamon ein, welcher die Zeit zwischen den
@@ -112,7 +112,7 @@ Für das Deployment wurden fünf Cookbooks geschrieben:
     Dieses Cookbook fast 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 sind und (bei Chef-server) über alle Umgebungen gleich
+    nicht versionierbar und (bei Chef-server) über alle Umgebungen gleich
     sind. Somit ist eine Trennung zwischen Test- und Produktivumgebung
     schwierig.
 \end{description}

bericht/chef/chef-tests.tex

@@ -1,12 +1,11 @@
 \subsubsection{Verifikation}
 \label{ssub:verifikation}
 
-Wie auch Software müssen auch Provisionierungsskripte getestet werden.
+Wie auch Software müssen auch Provisionierungsskripte getestet werden.  Dies
-Dies gestaltet sich oft als schwierig, weil nicht immer eine Kopie des
+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
+steigt der Aufwand geschriebene Cookbooks manuell zu testen. Im Folgenden werden
-werden verschiedene Möglichkeiten aufgeführt, wie dies automatisiert werden
+verschiedene Möglichkeiten aufgeführt, wie dies automatisiert werden kann.
-kann.
 
 Die erste und einfachste Methode ist der Befehl:
 
@@ -15,38 +14,39 @@ Die erste und einfachste Methode ist der Befehl:
 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 jslint oder perlcritics. Dabei wird der
+ist eine statische Codeanalyse ähnlich \href{http://www.jslint.com/}{JSlint}
-Rubycode gegen Regelsatz getestet, um so schlechten Stil zu erkennen oder
+oder \href{http://perl-critic.stacka.to/}{Perl::Critic}. Dabei wird der
-um Codeingstandards innerhalb eines Projekts einzuhalten. Diesen Regelsatz kann
+Rubycode gegen einen Regelsatz getestet, um so schlechten Stil zu erkennen oder
-man durch eigene Regeln erweitern.
+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 \emph{Rspec} auf. Rspec
+Chefspec baut auf das in Ruby verbreitete Testframework
-ist ein Testframework, welches auf
+\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
+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 wieso dieser
+darüber Auskunft zu geben, was der Test getestet hat und aus welchen Grund
-fehlgeschlagen ist. Chefspec erweitert dabei Rspec um die Möglichkeit Cookbooks
+dieser fehlgeschlagen ist. Chefspec erweitert dabei RSpec um die Möglichkeit
-zu laden und stellt spezielle Matcher (Rspec-Terminologie für Assertions)
+Cookbooks zu laden und stellt spezielle Matcher (RSpec-Terminologie für
-bereit, um diese zu testen.
+Assertions) bereit, um diese zu testen.  Wie bereits in
-Wie bereits in Abschnitt~\ref{ablauf_einer_provisionierung} erwähnt, gibt es 2
+Abschnitt~\ref{ablauf_einer_provisionierung} erwähnt, gibt es 2 Phasen bei der
-Phasen bei der Ausführung von Chef. Bei Chefspec wird Provisionierungsprozess
+Ausführung von Chef. Bei Chefspec wird Provisionierungsprozess nur bis zur
-nur bis zur Convergingphase durchlaufen. Die eigenen Tests überprüfen nur die
+Convergingphase durchlaufen. Die eigenen Tests überprüfen nur die erzeugten
-erzeugten Resources. Dies hat den Vorteil, das Tests sehr schnell durchlaufen
+Resources. Dies hat den Vorteil, das Tests sehr schnell durchlaufen werden, da
-werden, da keine Änderungen an einem System vorgenommen werden müssen. Dies hat
+keine Änderungen an einem System vorgenommen werden müssen. Dies hat Vorteile
-Vorteile beim Entwickeln, weil man auf diese Weise schnell Feedback bekommt. Das
+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 nicht
+das diese (zeit)aufwendig aufgesetzt werden müssen. Da Chefspec allerdings zu
-wirklich Code auf dem System ausführt, sind weitere Integrationstest
+keinen Zeitpunkt Code auf dem System ausführt, sind weitere Integrationstest
 unerlässlich.
 
-Der folgende Test wurde aus dem NTP-Cookbook
+Der folgende Test wurde aus dem selbst geschriebenen NTP-Cookbook
-(~\ref{ssub:einrichtung-der-netzwerkdienste}) entnommen.
+(\ref{ssub:einrichtung-der-netzwerkdienste}) entnommen.
 
 \begin{lstlisting}[language=Ruby]
 require_relative '../spec_helper'
@@ -69,7 +69,7 @@ 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
+Packet "ntp" installiert werden soll und ob das Subnetz in dem Template für
 Konfigurationsdatei \emph{/etc/ntp.conf} richtig gesetzt wird.
 
 Die Tests werden mit dem Befehl \emph{rspec} ausgeführt. Wenn keine weiteren Argumente
@@ -77,7 +77,7 @@ angegeben sind, führt dieses Programm alle Dateien unterhalb des Ordners \emph{
 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} das in Ruby
+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:
 
@@ -96,7 +96,7 @@ schon mit Ruby mitgeliefert wird. Allerdings kann man durch einbinden, der Zeile
 require "minitest/spec"
 \end{lstlisting}
 
-eine Rspec sehr ähnliche Syntax benutzen. Um Minitest Handler zu nutzen, muss
+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
@@ -111,8 +111,8 @@ end
 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
+ebenfalls ausgeführt. Minitest Handler erweitert RSpec um nützliche Methoden um
-den Status des Systems zu überprüfen. Hier ein Beispiel aus dem bind cookbook,
+den Status des Systems zu überprüfen. Hier ein Beispiel aus dem Bindcookbook,
 welches in Abschnitt~\ref{ssub:einrichtung-der-netzwerkdienste} erwähnt wurde:
 
 \begin{lstlisting}[language=Ruby]