Auf Belegsvorlage gewechselt.

Dadurch gibt es für die Abschlussaufgaben eine Überschriftengliederung mehr.
Ich habe im nftables-Teil ein paar pagebreaks rausgenommen, welche sich
verschoben haben (evtl. an anderer Stelle neueinfügen)

bericht/bericht.tex

@@ -1,4 +1,4 @@
-\documentclass[german,plainarticle,utf8]{zihpub}
+\documentclass[german,utf8,beleg]{zihpub}
 
 \usepackage{multirow}
 \usepackage{hyperref}
@@ -23,6 +23,10 @@
 \usepackage[utf8x]{inputenc}
 \usepackage{ucs}
 
+\matno{TODO 3749175 und TODO}
+\betreuer{Michael Heyde}
+\bibfiles{sources}
+
 % directory listing im Chefabschnitt
 \usepackage{chngcntr}
 \newcounter{treeline}
@@ -43,10 +47,13 @@
   citecolor=black
 }
 
-\author{Patrick Schöps, Jörg Thalheim, Alfred Krohmer}
+\author{Patrick Schöps, Jörg Thalheim und Alfred Krohmer}
 \title{LCTP – Praktikum Wintersemester 2013 / 2014}
 
 \begin{document}
+
+\chapter{Praxisteil}
+
 \input{hardware}
 
 \input{cluster-layout}
@@ -63,6 +70,8 @@
 
 \input{bench/bench}
 
+\chapter{Abschlussaufgaben}
+
 \input{nftables/nftables}
 
 \input{chef/chef}
@@ -71,6 +80,4 @@
 
 \input{anhang}
 
-\bibliography{sources}{}
-\bibliographystyle{plain}
 \end{document}

bericht/chef/chef-comparison.tex

@@ -1,4 +1,4 @@
-\subsubsection{Funktionsweise von Chef}
+\subsection{Funktionsweise von Chef}
 \label{ssub:funktionsweise_von_chef}
 
 \href{http://www.getchef.com/chef/}{Chef} ist ein Framework, welches eine
@@ -50,7 +50,7 @@ Es gibt mehrere Möglichkeiten \emph{Chef} zu betreiben:
     Organisation~\cite{chefenterprise}.
 \end{description}
 
-\textbf{Aufbau eines Cookbooks}
+\subsubsection{Aufbau eines Cookbooks}
 \label{aufbau_eines_cookbook}
 
 Nachfolgend ist die Ordnerstruktur eines Cookbooks am Beispiel von
@@ -161,8 +161,8 @@ Beispiel ERB-Template:
   <% end %>
 \end{lstlisting}
 
-\textbf{Ablauf einer Provisonierung}
-\label{ablauf_einer_provisionierung}\\
+\subsubsection{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 gewählter Umgebung kann
@@ -225,8 +225,8 @@ 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}\\
+\subsubsection{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

bericht/chef/chef-services.tex

@@ -1,5 +1,5 @@
-\subsubsection{Einrichtung der Netzwerkdienste}
-\label{ssub:einrichtung-der-netzwerkdienste}
+\subsection{Einrichtung der Netzwerkdienste}
+\label{sub:einrichtung-der-netzwerkdienste}
 
 Für die Provisionierung der Netzwerkdienste wurde
 \href{http://vagrantup.com}{Vagrant} verwendet. Dies ist ein Programm, um auf

bericht/chef/chef-task.tex

@@ -1,4 +1,4 @@
-\subsubsection{Aufgabenstellung}
+\subsection{Aufgabenstellung}
 \label{ssub:aufgabenstellung}
 
 \begin{itemize}

bericht/chef/chef-tests.tex

@@ -1,4 +1,4 @@
-\subsubsection{Verifikation}
+\subsection{Verifikation}
 \label{ssub:verifikation}
 
 Wie auch in der Softwareentwicklung müssen Konfigurationssysteme getestet
@@ -23,7 +23,7 @@ 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}
+\subsubsection{Chefspec}
 \label{chefspec}
 
 Chefspec baut auf das, in Ruby verbreitete, Testframework
@@ -88,7 +88,7 @@ ausgeführt:
 
 Dieser muss innerhalb Projektverzeichnises aufgerufen werden.
 
-\textbf{Minitest-Handler}
+\subsubsection{Minitest-Handler}
 \label{minitest_handler}
 
 \href{https://github.com/btm/minitest-handler}{Minitest-Handler} hingegen wird

bericht/chef/chef.tex

@@ -1,8 +1,8 @@
-\subsection{Chef - Provisionierungssystem (Jörg Thalheim)}
+\section{Chef - Provisionierungssystem (Jörg Thalheim)}
 
 \input{chef/chef-task}
 \input{chef/chef-comparison}
 \input{chef/chef-services}
 \input{chef/chef-tests}
 
-\pagebreak
+\pagebreak

bericht/nftables/nftables-conc.tex

@@ -1,7 +1,7 @@
-\subsubsection{Schlussfolgerung / Fazit}
+\subsection{Schlussfolgerung / Fazit}
 
 \texttt{nftables} schneidet bezüglich Datendurchsatz bei einer mittleren Regelanzahl bis maximal 25 000 Regeln noch deutlich schlechter als \texttt{iptables} ab. Mehr als diese 25 000 Regeln werden in der Praxis eher selten benötigt. Um z.B. mehrere IP-Adressen gleichzeitig zu blockieren könnte man diese in ein \texttt{ipset} (\texttt{iptables}) oder in eine »(un)named set« (\texttt{nftables}) speichern und bräuchte dann nur noch eine Regel, um alle Pakete von diesen Adressen zu verwerfen.
 
 Zwar schneidet \texttt{iptables} bezüglich der Antwortzeit bei einer sehr großen Regelanzahl schlechter ab als \texttt{nftables}, dies hält sich mit ca. 12 ms bei 100 000 Regeln aber dennoch in Grenzen.
 
-Dieser Performance-Aspekt und die Tatsache, dass es bisher keine vollständige Dokumentation zu \texttt{nftables} gibt, führt zur Schlussfolgerung, dass \texttt{nftables} bisher \textbf{noch nicht} für den Produktiveinsatz bereit ist und es noch einige Zeit dauern wird, bis es \texttt{iptables} komplett ersetzen kann.
+Dieser Performance-Aspekt und die Tatsache, dass es bisher keine vollständige Dokumentation zu \texttt{nftables} gibt, führt zur Schlussfolgerung, dass \texttt{nftables} bisher \textbf{noch nicht} für den Produktiveinsatz bereit ist und es noch einige Zeit dauern wird, bis es \texttt{iptables} komplett ersetzen kann.

bericht/nftables/nftables-doc.tex

@@ -1,4 +1,4 @@
-\subsubsection{Dokumentation}
+\subsection{Dokumentation}
 
 Da \texttt{iptables} schon recht lange in Verwendung ist, gibt es hierzu ein breites Spektrum an Dokumentation, Tutorials, usw. \\
 
@@ -12,4 +12,4 @@ Inzwischen gibt es ein Wiki, das die verschiedenen Regeltypen usw. besser katego
 \item \url{http://wiki.nftables.org/wiki-nftables}
 \end{itemize}
 
-Abgesehen von diesen beiden Quellen gibt es bisher jedoch kaum weitere auffindbare Dokumentation, eine komplette Referenz zu allen möglichen Befehlen und Regeln fehlt z.B. noch.
+Abgesehen von diesen beiden Quellen gibt es bisher jedoch kaum weitere auffindbare Dokumentation, eine komplette Referenz zu allen möglichen Befehlen und Regeln fehlt z.B. noch.

bericht/nftables/nftables-perf.tex

@@ -1,6 +1,6 @@
-\subsubsection{Performance-Vergleich}
+\subsection{Performance-Vergleich}
 
-\paragraph{Testaufbau}
+\subsubsection{Testaufbau}
 
 Um die Performance der beiden Firewall-Lösungen vergleichen zu könne, habe ich jeweils zwei unserer Zotac-Boards mit der Onboard-Netzwerkkarte an einen zusätzlichen Firewall-Rechner, der mir bereitgestellt wurde, verbunden. Die Spezifikationen der Zotac-Boards sind dem Abschnitt »Hardware« zu entnehmen. \\
 
@@ -11,17 +11,15 @@ Der Firewall-Rechner soll nun über \texttt{iptables} und \texttt{nftables} den
 
 \includegraphics{bilder/nft-layout.pdf}
 
-\paragraph{Verwendete Software} Um schnell genug eine große Anzahl an Paketen pro Sekunde (PPS) erzeugen zu können um die Firewall-Lösungen zu benchmarken, habe ich \texttt{pktgen} verwendet. Hierbei handelt es sich um einen Paketgenerator, der als Kernel-Modul geladen wird und dadurch direkt im Kernel (ohne teure Kontext-Switches ins Userland) ausgeführt wird.
+\subsubsection{Verwendete Software} Um schnell genug eine große Anzahl an Paketen pro Sekunde (PPS) erzeugen zu können um die Firewall-Lösungen zu benchmarken, habe ich \texttt{pktgen} verwendet. Hierbei handelt es sich um einen Paketgenerator, der als Kernel-Modul geladen wird und dadurch direkt im Kernel (ohne teure Kontext-Switches ins Userland) ausgeführt wird.
 
 Zur Überwachung der Messdaten (Datenrate und PPS) habe ich auf allen vier Netzwerkschnittstellen das Tool \texttt{ifpps} aus dem \texttt{netsniff-ng}-Bundle laufen lassen.
 
-\paragraph{Testablauf} Die Benchmarks habe ich einigen Bash- und Python-Scripts realisiert. Vor Beginn jedes Tests loggt sich der steuernde Rechner mit SSH auf der Firewall ein (über das äußere Konfigurationsnetzwerk) und generiert dort mit einem Python-Script die entsprechende Anzahl an Regeln für das jeweilige Firewall-System. Anschließend werden die Regeln mit dem entsprechenden Tool angewendet.
+\subsubsection{Testablauf} Die Benchmarks habe ich einigen Bash- und Python-Scripts realisiert. Vor Beginn jedes Tests loggt sich der steuernde Rechner mit SSH auf der Firewall ein (über das äußere Konfigurationsnetzwerk) und generiert dort mit einem Python-Script die entsprechende Anzahl an Regeln für das jeweilige Firewall-System. Anschließend werden die Regeln mit dem entsprechenden Tool angewendet.
 
 Danach wird der Paketgenerator \texttt{pktgen} beim Sender gestartet und zunächst zwei Sekunden laufen gelassen. Anschließend werden per SSH über \texttt{ifpps} die Netzwerkauslastung und mit \texttt{top} die Prozessorauslastung bzw. mit \texttt{ping} die Antwortzeit gemessen.
 
-\pagebreak
-
-\paragraph{Testeinstellung} Zunächst habe ich die Datenrate und die PPS in Abhängigkeit der Ethernet Frame-Größe gemessen um festzustellen, mit welcher Paketgröße die Messungen am besten durchzuführen sind.  \\ \\
+\subsubsection{Testeinstellung} Zunächst habe ich die Datenrate und die PPS in Abhängigkeit der Ethernet Frame-Größe gemessen um festzustellen, mit welcher Paketgröße die Messungen am besten durchzuführen sind.  \\ \\
 
 \includegraphics{benchmarks/nft-size-load-rate-send.pdf}
 
@@ -31,8 +29,6 @@ Danach wird der Paketgenerator \texttt{pktgen} beim Sender gestartet und zunäch
 
 Beim Sender betrug die Prozessor-Last dauerhaft 100 \%, für den Empfänger ist die CPU-Last zusätzlich grün eingetragen.
 
-\pagebreak
-
 Wie aus den Diagrammen ersichtlich wird, wird bei Frame-Größen, die an die MTU des Ethernets (1500 Bytes) heranreichen, das Gigabit-Netzwerk mit ca. 980 MBit/s und ca. 82000 PPS fast komplett ausgereizt. Je kleiner die Frame-Größe wird, desto größer wird zunächst die Anzahl der PPS, da das Netzwerk immer noch gut ausgelastet wird; die Datenrate sinkt zunächst zur langsam. \\
 
 Beim Sender beginnt jedoch bei Frame-Größe kleiner 300 Byte die Datenrate linear zu sinken. Die PPS stagnieren dann bei ca. 450000 Paketen. Dies ist mit der Leistungsfähigkeit der Atom-Prozessoren zu erklären, da diese ab dieser Grenze komplett ausgelastet sind und die Pakete nicht schneller erzeugen können. \\
@@ -41,13 +37,11 @@ Beim Empfänger geschieht dieser Einbrauch schon bei ca. 450 Byte Frame-Größe.
 
 Um eine größtmögliche Auslastung des Gigabit-Netzwerkes zu ermöglichen und gleichzeitig die maximale Anzahl an PPS zu erhalten, habe ich also für die folgenden Benchmarks die Ethernet Frame-Größe auf 450 festgesetzt.
 
-\paragraph{Anfängliche Probleme} Anfangs habe ich auf dem Empfänger keine »Anwendung« laufen lassen, die die Pakete des Senders entgegennimmt. Deshalb musste der Kernel zusätzliche ein ICMP-Paket mit »Connection Refused«-Flag an den Sender zurückschicken und daraufhin weitere Fehlerbehandlungen durchführen.  Auf diese Weise habe ich am Empfänger zunächst nur ca. 110000 PPS empfangen können. Als Lösungsansatz habe ich dann \texttt{netcat} auf dem Port am Empfänger laufen lassen und die Daten nach \texttt{/dev/null} umgeleitet. Damit kamen keine Fehler mehr zustande und es konnten ca. 150000 PPS empfangen werden.  Dies liegt jedoch immer noch weit unter den am Sender losgeschickten 450000 PPS und ist damit zu erklären, dass es für jedes Paket zu einem Kontext-Switch vom Kernel zu \texttt{netcat} kam und deshalb wieder die Bearbeitungszeit pro Paket stieg. \\
+\subsubsection{Anfängliche Probleme} Anfangs habe ich auf dem Empfänger keine »Anwendung« laufen lassen, die die Pakete des Senders entgegennimmt. Deshalb musste der Kernel zusätzliche ein ICMP-Paket mit »Connection Refused«-Flag an den Sender zurückschicken und daraufhin weitere Fehlerbehandlungen durchführen.  Auf diese Weise habe ich am Empfänger zunächst nur ca. 110000 PPS empfangen können. Als Lösungsansatz habe ich dann \texttt{netcat} auf dem Port am Empfänger laufen lassen und die Daten nach \texttt{/dev/null} umgeleitet. Damit kamen keine Fehler mehr zustande und es konnten ca. 150000 PPS empfangen werden.  Dies liegt jedoch immer noch weit unter den am Sender losgeschickten 450000 PPS und ist damit zu erklären, dass es für jedes Paket zu einem Kontext-Switch vom Kernel zu \texttt{netcat} kam und deshalb wieder die Bearbeitungszeit pro Paket stieg. \\
 
 Letztendlich habe ich dazu entschieden, auf der Empfängerseite mit \texttt{iptables} die Pakete, die auf dem entsprechenden Port angekommen, direkt zu droppen. Dies hat auch keinen verzerrenden Einfluss auf den Benchmark, da letztendlich nur die Performance des Firewall-Systems gemessen werden soll, nicht der Empfängerhardware. Auf diese Weise konnten nun die zuvor erwähnten ca. 250000 PPS empfangen werden.
 
-\pagebreak
-
-\paragraph{Paketdurchsatz} Für den nachfolgenden Benchmark habe ich entsprechend viele Regeln generieren lassen, die besagen, dass von (zufällig gewählten) IP-Adressen alle Pakete gedropt werden sollen. \\
+\subsubsection{Paketdurchsatz} Für den nachfolgenden Benchmark habe ich entsprechend viele Regeln generieren lassen, die besagen, dass von (zufällig gewählten) IP-Adressen alle Pakete gedropt werden sollen. \\
 
 \includegraphics{benchmarks/nft-ipt-drop.pdf}
 
@@ -55,22 +49,16 @@ Zur besseren Anschaulichkeit auch in logarithmischer Ordinatenskalierung: \\
 
 \includegraphics{benchmarks/nft-ipt-drop-log.pdf}
 
-\pagebreak
-
 Die Datenrate und die Anzahl an PPS liegen initial bei den bereits zuvor gemessenen ca. 980 MBit/s und 250000 Paketen pro Sekunde. Jedoch bricht die Leistungsfähigkeit bei beiden Firewall-Lösungen schnell erheblich ein. So kann \texttt{iptables} bei 5000 Regeln nur noch ca. 100 MBit/s bei 28000 Paketen verarbeiten, \texttt{nftables} schafft hier nur ca. 50 MBit/s bei 14000 Paketen. Im weiteren Verlauf wird jedoch in der logarithmischen Skalierung sichtbar, dass \texttt{nftables} bei mehr als ca. 25000 Regeln beginnt besser zu skalieren. Die starken Schwankungen bei vielen Regeln lassen sich eventuell auf zu kleine statisch allokierte Buffer im Kernel oder durch zunehmenden RAM-Zugriff bei vollem Cache zurückführen. RAM-Zugriff würde auch die noch stärker abnehmende PPS-Rate bei sehr vielen Regeln erklären.
 
-\paragraph{Antwortzeit} Unter Verwendung der vorherigen Regeln habe ich nun die Antwortzeit gemessen. \\
+\subsubsection{Antwortzeit} Unter Verwendung der vorherigen Regeln habe ich nun die Antwortzeit gemessen. \\
 
 \includegraphics{benchmarks/nft-ipt-drop-response.pdf}
 
 In diesem Diagramm erkennt man, dass hier \texttt{nftables}, im Gegensatz zum Paketdurchsatz, bei der Antwortzeit bei Skalierung auf sehr viele Firewall-Regeln besser abschneidet als \texttt{iptables}. Bis ca. 20000 Regeln reagieren beide Firewall-Lösungen in etwa gleich schnell, danach entwickeln sich die Reaktionszeiten linear auseinander. Bei 100000 Regeln hat hier \texttt{nftables} einen Vorteil von ca. 4 ms.
 
-\pagebreak
-
-\paragraph{Weitere Regeln} Ursprünglich wollte ich für weitere Benchmarks noch andere Regeltypen verwenden. Dies scheiterte jedoch grundsätzlich an zwei Punkten:
+\subsubsection{Weitere Regeln} Ursprünglich wollte ich für weitere Benchmarks noch andere Regeltypen verwenden. Dies scheiterte jedoch grundsätzlich an zwei Punkten:
 \begin{itemize}
 \item \texttt{nftables} ist bisher sehr schlecht dokumentiert. Es ist mir bspw. nicht gelungen eine Möglichkeit zu finden, um komplette Pakete (nicht nur den Header) nach bestimmten Strings zu durchsuchen. Während dies auf Kernel-Seite durch die virtuelle Maschine eigentlich ohne Weiteres möglich sein sollte, ist diese Möglichkeit im Userspace-Tool \texttt{nft} offenbar noch nicht enthalten (oder nirgends dokumentiert).
 \item NAT-Regeln (oder generell modifizierende Regeltypen) lassen sich nicht ohne weiteres mit der Skalierung auf eine große Anzahl von Regeln benchmarken, da die Paketbearbeitung nach der ersten, den Filterkriterien entsprechenden Regel abbricht. Zukünftig sollte sich die Vereinheitlichung und die leichte Erweiterbarkeit von \texttt{nftables} gegenüber \texttt{iptables} durchsetzen können.
 \end{itemize}
-
-\pagebreak

bericht/nftables/nftables-tools.tex

@@ -1,5 +1,5 @@
-\subsubsection{Verfügbare Tools}
+\subsection{Verfügbare Tools}
 
 Für \texttt{iptables} heißt das primäre Tool wie die Firewall selbst: \texttt{iptables}. Inzwischen gibt es für \texttt{iptables} noch weitere Tools, die auf einer höheren Abstraktionsebene arbeiten, z.B. \texttt{ufw} (uncomplicated firewall) oder diverse Frontends von distributionsspezifischen Systemkonfigurationstools. Zumindest \texttt{iptables} selbst ist in fast jeder Linux Distribution enthalten, \texttt{ufw} und Konsorten sind oft ebenfalls verfügbar.
 
-Da \texttt{nftables} erst vor kurzem Einzug in den Linux-Kernel gehalten hat, gibt es in kaum einer Linux-Distribution entsprechende Tools für die Konfiguration der neuen Firewall-Lösung. Man hat also fast nur die Möglichkeit, sich das Userland-Programm \texttt{nft} selbst zu kompilieren. Bei Arch Linux bspw. gibt es ein Paket aus dem AUR, seit einigen Tagen aber auch im Community-Repository.
+Da \texttt{nftables} erst vor kurzem Einzug in den Linux-Kernel gehalten hat, gibt es in kaum einer Linux-Distribution entsprechende Tools für die Konfiguration der neuen Firewall-Lösung. Man hat also fast nur die Möglichkeit, sich das Userland-Programm \texttt{nft} selbst zu kompilieren. Bei Arch Linux bspw. gibt es ein Paket aus dem AUR, seit einigen Tagen aber auch im Community-Repository.

bericht/nftables/nftables-vs.tex

@@ -1,4 +1,4 @@
-\subsubsection{Rückblick}
+\subsection{Rückblick}
 
 Da es bereits vor \texttt{nftables} und \texttt{iptables} mehrere Firewall-Implementierungen für Linux gab, lohnt sich ein kleiner Rückblick.
 
@@ -12,7 +12,7 @@ Da es bereits vor \texttt{nftables} und \texttt{iptables} mehrere Firewall-Imple
 
 Wie man sieht mussten sich Linux-Nutzer, die eine Firewall benötigten, seit 1994 bis jetzt mit vier verschiedenen Firewall-Lösungen auseinander setzen. Die letzte davon, \texttt{iptables} ist nun bald seit 14 Jahr im Einsatz und soll jetzt auf Dauer von \texttt{nftables} abgelöst werden.
 
-\subsubsection{Funktionsweise}
+\subsection{Funktionsweise}
 
 \paragraph{\texttt{iptables}} selbst ist nur für das Firewalling des IPv4-Traffics verantwortlich. Für andere Protokolle gibt es weitere entsprechende Tools:
 \begin{itemize}
@@ -38,13 +38,11 @@ Darüber hinaus soll nun ein atomares Austauschen der Firewall-Regeln in einer e
 \item Man könnte zunächst in einem ersten Skript alle Regeln entfernen und noch in der gleichen Transaktion eine einzige Regel hinzufügen, die sämtlichen Datenverkehr verbietet. In einem zweiten Skript könnte man dann innerhalb einer zweiten Transaktion diese Regel wieder entfernen und gleichzeitig den gewünschten neuen Regelsatz einfügen. Auch hier hätte man dann kein Zeitfenster mehr, indem das System »offen« ist. Es besteht aber die Gefahr, dass man hier einen Fehler in den neuen Regeln hat, so dass diese gar nicht angewendet werden und man sich somit aus dem System aussperren könnte.
 \end{itemize}
 
-\subsubsection{table, chain, hook}
+\subsection{table, chain, hook}
 
 Während \texttt{iptables} noch vordefinierte Tabellen (\texttt{filter}, \texttt{nat}, \texttt{mangle}) und mehrere Chains (\texttt{PREROUTING}, \texttt{INPUT}, \texttt{FORWARD}, \texttt{OUTPUT}, \texttt{POSTROUTING}) in diesen Tabellen hatte, gibt es in \texttt{nftables} keine vorgefertigen Tabellen und Chains mehr. Stattdessen gibt es sogenannte Hooks, in die man sich in selbst erstellten Chains »einhängen« kann. Dabei kann man eine Priorität angeben, die die Reihenfolge der Abarbeitung der Chains angibt. Diese Hooks entsprechen dabei größtenteils den Tabellen und Chains aus \texttt{iptables}.
 
-\pagebreak
-
-\subsubsection{Syntax}
+\subsection{Syntax}
 
 Im folgenden werde ich einige Regeltypen zeigen und wie sich diese bei den beiden Firewall-System unterscheiden.
 
@@ -88,8 +86,6 @@ table filter {
 }
 \end{lstlisting}
 
-
-
 \paragraph{Mehrere benutzerdefinierte Chains} \mbox{} \\
 
 In \texttt{iptables} kann wie folgt eine neue Chain eingefügt werden: \\
@@ -172,4 +168,4 @@ Während sich bei \texttt{iptables} das Matching für IP-Adressen noch auf \text
 \shellcmd{nft add element filter ipmatches \enquote{\{ 10.30.44.7, 10.27.21.2 \}}} \\
 
 Gematcht werden können diese Sets dann wie folgt: \\
-\shellcmd{nft add rule ip input ip saddr @ipmatches drop} \\
+\shellcmd{nft add rule ip input ip saddr @ipmatches drop} \\

bericht/nftables/nftables.tex

@@ -1,4 +1,4 @@
-\subsection{Vergleich \texttt{nftables} und \texttt{iptables} (Alfred Krohmer)}
+\section{Vergleich \texttt{nftables} und \texttt{iptables} (Alfred Krohmer)}
 
 \input{nftables/nftables-vs}
 \input{nftables/nftables-tools}
@@ -6,4 +6,4 @@
 \input{nftables/nftables-doc}
 \input{nftables/nftables-conc}
 
-\pagebreak
+\pagebreak

bericht/ori/ori-con.tex

@@ -1 +1 @@
-\subsubsection{Fazit}
+\subsection{Fazit}

bericht/ori/ori-doc.tex

@@ -1,8 +1,8 @@
-\subsubsection{Dokumentation}
+\subsection{Dokumentation}
 
 Da das Projekt Ori erst im November 2013 publik gemacht wurde, gibt es bisher noch keine umfassende Dokumentation. Neben der Abhandlung >>Replication, History, and Grafting in the Ori File System<< unter: \\
 \url{http://sigops.org/sosp/sosp13/papers/p151-mashtizadeh.pdf} \\
 und der Projektseite: \\
  \url{http://ori.scs.stanford.edu} \\
 existiert noch das Git-Repo zu Ori auf der Code-Hosting-Plattform Bitbucket unter: \\
-\url{https://bitbucket.org/orifs/ori/wiki/Home}.
+\url{https://bitbucket.org/orifs/ori/wiki/Home}.

bericht/ori/ori-function.tex

@@ -1,4 +1,4 @@
-\subsubsection{Funktionsweise}
+\subsection{Funktionsweise}
 
 \hfill \includegraphics{ori/ori.pdf} \hspace*{\fill}
 
@@ -45,4 +45,4 @@ Wie aus dem Systemdiagramm ersichtlich ist, besteht Ori aus den Teilprogrammen \
 	\item[\emph{libori}] verwaltet die Repositorien bestehend aus Index, Objekt-Speicher und Objekt-Metadaten. Die Repositorien werden lokal unter \emph{.ori} im Home-Verzeichnis gespeichert.
 \end{description}
 
-\pagebreak
+\pagebreak

bericht/ori/ori-grafting.tex

@@ -1,4 +1,4 @@
-\subsubsection{Grafting}
+\subsection{Grafting}
 
 \hfill \includegraphics[scale=0.55]{bilder/grafting.png} \hspace*{\fill}
 
@@ -6,4 +6,4 @@ Die aus der Abhandlung \href{http://sigops.org/sosp/sosp13/papers/p151-mashtizad
 
 Wenn ein Verzeichnis Q als Verzeichnis Z in das Ziel-Dateisystem übertragen wird, wird dort ein spezieller Commit-Eintrag erstellt. Dieser enthält zusätzlich zu einem normalen Eintrag die UUID des Quell-Dateisystems \emph{graft-fsid}, den Quell-Pfadnamen \emph{graft-path}, einen Hash des Original-Commits aus dem Quell-Dateisystem \emph{graft-commit} und den Ziel-Pfadnamen \emph{graft-target}.
 
-\pagebreak
+\pagebreak

bericht/ori/ori-inst.tex

@@ -1,10 +1,10 @@
-\subsubsection{Vorbereitungen und Installation} 
+\subsection{Vorbereitungen und Installation} 
 
-\paragraph{Vorbereitungen}
+\subsubsection{Vorbereitungen}
 
 Da Ori seine Configs und Repositorien unter \emph{.ori} im Home-Verzeichnis des jeweiligen Nutzers ablegt und dieses auf allen Nodes eingebunden wird, würden zwangsweise Fehler auftreten. Deshalb wurde auf allen Computenodes eine neue Partition erstellt und unter \emph{/ori} gemounted. Mit \emph{useradd ori} wurde ein neuer User ori angelegt, dem mit \emph{chown /ori/home ori:ori} und \emph{usermod --home /ori/home ori} das Home-Verzeichnis \emph{/ori/home} zugeteilt wurde. Mit \emph{ssh-keygen} wurden auf Computenode 1 die ssh-Schlüssel erstellt und anschließend auf die anderen Computenodes übertragen. Desweiteren wurde der Public-Key in die \emph{authorized\_keys} eingetragen. Mit diesen Arbeitsschritten war nun ein passwortloser Zugriff für den Nutzer ori auf die einzelnen Coputenodes gewährleistet. 
 
-\paragraph{Installation}
+\subsubsection{Installation}
 
 Da sich die Entwicklung von Ori noch in der Anfangsphase befindet, gibt es momentan noch keine Paketquellen für Debian. Deshalb wurden die Quellcode-Dateien aus dem \href{http://bitbucket.org/orifs/ori.git}{Git-Repo} bezogen. Nach der Installation bzw. dem Update der Dependences:
 
@@ -19,4 +19,4 @@ Da sich die Entwicklung von Ori noch in der Anfangsphase befindet, gibt es momen
 
 wurde Ori mit \emph{scons} compiled und mit \emph{scons PREFIX=/usr/local install} installiert.
 
-\pagebreak
+\pagebreak

bericht/ori/ori-task.tex

@@ -1,8 +1,8 @@
-\subsubsection{Aufgabenstellung}
+\subsection{Aufgabenstellung}
 
 \begin{itemize}
 \item Analysieren Sie die Funktionsweise von Ori und beschreiben Sie den Funktionsumfang
 \item Erklären Sie das Prinzip >>Grafting<<
 \item Vergleichen Sie Ori mit Cloud-Speicherdiensten, verteilten Dateisystemen und verteilten Versionskontrollsystemen
 \item Stellen Sie die Leistungsfähigkeit der verschiedenen Systeme für verschiedene Anwendungsszenarien gegenüber
-\end{itemize}
+\end{itemize}

bericht/ori/ori.tex

@@ -1,4 +1,4 @@
-\subsection{Ori als Dropbox-Ersatz (Patrick Schöps)}
+\section{Ori als Dropbox-Ersatz (Patrick Schöps)}
 
 \input{ori/ori-task}
 \input{ori/ori-inst}
@@ -8,4 +8,4 @@
 \input{ori/ori-doc}
 \input{ori/ori-con}
 
-\pagebreak
+\pagebreak