replace \tt by \emph (\tt is deprecated)

bericht/anhang.tex

@@ -8,7 +8,7 @@ Software zu installieren, zu aktualisieren oder zu entfernen.
 
 \subsection{Paketlisten laden / Updates}
 
-Die Paketlisten werden mit {\tt pacman -Sy} neu geladen. Updates werden mit {\tt pacman -Su} installiert. Man kann auch beides kombiniert ausführen: {\tt pacman -Syu}
+Die Paketlisten werden mit \emph{pacman -Sy} neu geladen. Updates werden mit \emph{pacman -Su} installiert. Man kann auch beides kombiniert ausführen: \emph{pacman -Syu}
 
 \subsection{Offizielle Repositories}
 
@@ -21,14 +21,14 @@ installiert.
 \subsection{AUR (Arch User Repositories)}
 \label{sec:aur}
 
-Bei den \href{https://aur.archlinux.org/?setlang=de}{»Arch User Repositories«} handelt es sich um eine Sammlung von Paketen, die von der Community bereitgestellt wird. Um von diesem Repository ein Paket zu installieren, muss man sich die entsprechende {\tt PKGBUILD}-Datei herunterladen (ähnlich einem Makefile) und im gleichen Verzeichnis {\tt makepkg} ausführen. Dabei wird der Quellcode des Paketes von der Website des Quellcode-Autors (nicht aus dem AUR) heruntergeladen, kompiliert und in ein {\tt pacman}-Paket gepackt. Dieses kann man anschließen mit {\tt pacman -u <package-file>} installieren.
+Bei den \href{https://aur.archlinux.org/?setlang=de}{»Arch User Repositories«} handelt es sich um eine Sammlung von Paketen, die von der Community bereitgestellt wird. Um von diesem Repository ein Paket zu installieren, muss man sich die entsprechende \emph{PKGBUILD}-Datei herunterladen (ähnlich einem Makefile) und im gleichen Verzeichnis \emph{makepkg} ausführen. Dabei wird der Quellcode des Paketes von der Website des Quellcode-Autors (nicht aus dem AUR) heruntergeladen, kompiliert und in ein \emph{pacman}-Paket gepackt. Dieses kann man anschließen mit \emph{pacman -u <package-file>} installieren.
 
 \subsubsection{yaourt}
 
-Das Tool {\tt yaourt}, das man ebenfalls aus dem AUR beziehen kann,
+Das Tool \emph{yaourt}, das man ebenfalls aus dem AUR beziehen kann,
 automatisiert die Installation weiterer Pakete aus dem AUR und bietet ebenfalls
 die Möglichkeit, diese zu aktualisieren. Die Kommandozeilen-Argumente sind die
-gleichen wie bei {\tt pacman}, da das Tool im Grunde ein Wrapper für {\tt
+gleichen wie bei \emph{pacman}, da das Tool im Grunde ein Wrapper für {\tt
 pacman} ist.
 
 \subsubsection{Easybuild}

bericht/bench/bench-hpl.tex

@@ -6,7 +6,7 @@ Der HPL-Benchmark wurde mit folgenden Befehlen durchgeführt:
 \shellcmd{mpirun -x LD\_LIBRARY\_PATH -np 8 -hostfile allnodes -npernode 2 \textbackslash} \\
 \shellcmd{\hspace{1cm} /cluster/software/hpl/run\_hpl > hpl.out}
 
-In der Datei {\tt allnodes} sind die Hostnames der Computenodes hinterlegt.
+In der Datei \emph{allnodes} sind die Hostnames der Computenodes hinterlegt.
 Beim Basislauf wurde ein maximaler Wert von $3,842 \cdot 10^{-4}$ GFlops mit folgender Konfiguration erreicht:
 
 \begin{lstlisting}

bericht/bench/bench-iozone.tex

@@ -27,7 +27,7 @@ Testaufruf:
 
 \shellcmd{./iozone -azcR -+q 1 -U /fastfs -f /fastfs/testfile -b excel-fastfs.xls}
 
-Der Parameter {\tt -+q 1} sorgt für einen Delay zwischen den einzelnen Tests, ohne den der Benchmark fehlerhaft läuft.\\
+Der Parameter \emph{-+q 1} sorgt für einen Delay zwischen den einzelnen Tests, ohne den der Benchmark fehlerhaft läuft.\\
 
 \subsubsection{Auswertung}
 

bericht/bs/bs-git.tex

@@ -1,8 +1,8 @@
 \subsection{Git-Server}
 \label{sub:git_server}
 
-Zur Verwaltung von {\tt Git} haben wir uns für \href{https://github.com/sitaramc/gitolite}{gitolite} entschieden. Dies erlaubt eine Verwaltung von Zugriffsrechten auf Repositories.
-Die Authentifizierung erfolgt dabei über SSH-Keys. Hier für wird ein {\tt git} Nutzer eingerichtet:
+Zur Verwaltung von \emph{Git} haben wir uns für \href{https://github.com/sitaramc/gitolite}{gitolite} entschieden. Dies erlaubt eine Verwaltung von Zugriffsrechten auf Repositories.
+Die Authentifizierung erfolgt dabei über SSH-Keys. Hier für wird ein \emph{git} Nutzer eingerichtet:
 
 \shellcmd{useradd -m -U -r -s /bin/bash -d /srv/git git}
 
@@ -14,9 +14,9 @@ Nun kann die eigentliche Konfiguration per git heruntergeladen werden:
 
 \shellcmd{git clone git@141.76.90.104:gitolite-admin.git}
 
-Wir legten in dieser Konfiguration das Repository {\tt lctp} an und gaben allen
+Wir legten in dieser Konfiguration das Repository \emph{lctp} an und gaben allen
 Benutzern Zugriff darauf. Die gitolite-Konfiguration befindet sich als
-Git-Submodule im Verzeichnis {\tt aufgabe2.4/gitolite-admin}.
+Git-Submodule im Verzeichnis \emph{aufgabe2.4/gitolite-admin}.
 Das lctp-Repository wiederum lässt sich mit folgendem Befehl clonen:
 
 \shellcmd{git clone git@141.76.90.104:lctp.git lctp-gruppe4}
@@ -25,44 +25,44 @@ Das lctp-Repository wiederum lässt sich mit folgendem Befehl clonen:
 
 \subsubsection{etckeeper}
 
-Um die Konfiguration in {\tt /etc } versionierbar und damit nachvollziehbar zu machen installierten wir {\tt etckeeper}:
+Um die Konfiguration in \emph{/etc } versionierbar und damit nachvollziehbar zu machen installierten wir \emph{etckeeper}:
 
 \shellcmd{yaourt -S etckeeper \&\& sudo etckeeper init}
 
 \shellcmd{cd /etc/.git \&\& sudo git remote add git@zotac0:lctp.git}
 
-Dieses legt ein {\tt git}-Repository in {\tt /etc/.git} an und erstellt Commits bei Änderungen in {\tt /etc}.
+Dieses legt ein \emph{git}-Repository in \emph{/etc/.git} an und erstellt Commits bei Änderungen in \emph{/etc}.
 Um die Konfiguration vom Bericht zu trennen, haben wir uns entschieden, {\tt
-etckeeper} in ein dediziertes Repository ({\tt logs}) pushen und als Submodule
-im {\tt lctp}-Repository einzubinden:
+etckeeper} in ein dediziertes Repository (\emph{logs}) pushen und als Submodule
+im \emph{lctp}-Repository einzubinden:
 
 \shellcmd{sudo git remote add origin git@zotac0:etckeeper.git}
 
-Anders als bei anderen Paketmanagern wie {\tt apt} auf Debian, existieren in {\tt pacman} (\ref{sec:pacman})
+Anders als bei anderen Paketmanagern wie \emph{apt} auf Debian, existieren in \emph{pacman} (\ref{sec:pacman})
 keine Hooks.
 Um dennoch nach Systemaktualisierungen oder Paketinstallationen automatisch die
 neue Konfiguration zu commiten haben wir jeweils einen
-\href{https://gist.github.com/Mic92/7250403}{Wrapper-Script} für {\tt pacman}
-und {\tt yaourt} geschrieben und diese {\tt /usr/local/bin} abgelegt. Da in der
-Shell {\tt /usr/local/bin} für gewöhnlich eine höhere Priorität hat als {\tt
+\href{https://gist.github.com/Mic92/7250403}{Wrapper-Script} für \emph{pacman}
+und \emph{yaourt} geschrieben und diese \emph{/usr/local/bin} abgelegt. Da in der
+Shell \emph{/usr/local/bin} für gewöhnlich eine höhere Priorität hat als {\tt
 /usr/bin} werden Programme in diesem Verzeichnis vorrangig ausgeführt. (Die
 Wrapper befinden sich in \emph{aufgabe2.4/yaourt} sowie in \emph{aufgabe2.4/pacman}).
 Darüber hinaus haben wir das Shell-Script für tägliche automatische Commits,
 welches im
 \href{https://github.com/joeyh/etckeeper/blob/master/debian/cron.daily}{Git-Repository}
 (Stand 07.11.2013)
-von {\tt etckeeper} liegt, als cronjob installiert (siehe
+von \emph{etckeeper} liegt, als cronjob installiert (siehe
 \emph{aufgabe2.4/cron.daily/etckeeper}).
 
 \subsubsection{Logs in git}
 
-Arch Linux setzt in der Standard-Installation {\tt journald} als Logging-Daemon ein. Dieses benutzt im Unterschied zu herkömmlichen Syslog-Varianten ein Binärformat zum Speichern.
+Arch Linux setzt in der Standard-Installation \emph{journald} als Logging-Daemon ein. Dieses benutzt im Unterschied zu herkömmlichen Syslog-Varianten ein Binärformat zum Speichern.
 Dieses Dateiformat eignet sich aus offensichtlichen Gründen nicht um mithilfe
-von git verwaltet zu werden. Deswegen haben wir zusätzlich {\tt syslog-ng}
-installiert und {\tt journald} so konfiguriert, das dieses ebenfalls in das
+von git verwaltet zu werden. Deswegen haben wir zusätzlich \emph{syslog-ng}
+installiert und \emph{journald} so konfiguriert, das dieses ebenfalls in das
 syslog schreibt (siehe \emph{aufgabe2.4/journald.conf}).
-Für tägliche commits haben wir hierfür das Shell-Script {\tt git-commit-log}
-nach {\tt /etc/cron.daily/} installiert (siehe
+Für tägliche commits haben wir hierfür das Shell-Script \emph{git-commit-log}
+nach \emph{/etc/cron.daily/} installiert (siehe
 \emph{aufgabe2.4/cron.daily/git-commit-log}). Dieses pusht die Log-Dateien in das
-logs-Repository. Es ist als Submodule im Verzeichnis {\tt logs} im
+logs-Repository. Es ist als Submodule im Verzeichnis \emph{logs} im
 lctp-Repository eingebunden.

bericht/bs/bs-pdsh.tex

@@ -1,17 +1,17 @@
 \subsection{Parallel Distributed Shell (PDSH)}
 \label{sub:parallel_shell}
 
-Die {\tt pdsh} ist ein Tool, mit dem man parallel auf mehreren Rechnern gleichzeitig Befehle über SSH ausführen kann, um diese komplett synchron zu konfigurieren und zu administrieren.
+Die \emph{pdsh} ist ein Tool, mit dem man parallel auf mehreren Rechnern gleichzeitig Befehle über SSH ausführen kann, um diese komplett synchron zu konfigurieren und zu administrieren.
 
 Das entsprechende Paket war nicht im offiziellen Arch Linux Repository
 vorhanden, deshalb haben wir es über das AUR (siehe \ref{sec:aur}) installiert.
 
 \subsubsection{Gruppenverwaltung}
 Zur Verwaltung mehrerer Rechner in Gruppen (in unserem Fall Headnode und
-Computenodes) greift {\tt pdsh} auf die Gruppenbeschreibungsdatei {\tt
+Computenodes) greift \emph{pdsh} auf die Gruppenbeschreibungsdatei {\tt
 /etc/genders} (siehe \emph{aufgabe2.5/genders}) zurück. Dort können mehrere Hosts
 in verschiedene Gruppen eingeteilt werden.
 Um zu gewährleisten, dass pdsh den richtigen Befehl beim Verbinden benutzt, muss
-die Umgebungsvariable {\tt PDS\_RCMD\_TYPE} auf den Wert {\tt ssh} gesetzt sein. Dies
-lösten wir durch ein Wrapper-Script in {\tt /usr/local/bin}, das die
+die Umgebungsvariable \emph{PDS\_RCMD\_TYPE} auf den Wert \emph{ssh} gesetzt sein. Dies
+lösten wir durch ein Wrapper-Script in \emph{/usr/local/bin}, das die
 genannte Umgebungsvariable setzt (siehe \emph{aufgabe2.5/pdsh}).

bericht/bs/bs-ssh.tex

@@ -1,11 +1,11 @@
 \subsection{SSH-Server}
 \label{sub:ssh_server}
 
-Wir haben uns für {\tt OpenSSH} als SSH-Server entschieden. Diesen haben wir mit folgenden Shell-Befehl installiert:
+Wir haben uns für \emph{OpenSSH} als SSH-Server entschieden. Diesen haben wir mit folgenden Shell-Befehl installiert:
 
 \shellcmd{pacman -S openssh}
 
-Desweiteren wurden in {\tt /etc/ssh/sshd\_config} (siehe \emph{aufgabe2.3/sshd\_config}) folgende Zeilen verändert, um den ''root-Account'' zu deaktivieren und den passwortlosen Zugriff zu aktivieren:
+Desweiteren wurden in \emph{/etc/ssh/sshd\_config} (siehe \emph{aufgabe2.3/sshd\_config}) folgende Zeilen verändert, um den ''root-Account'' zu deaktivieren und den passwortlosen Zugriff zu aktivieren:
 
 \begin{lstlisting}
 PermitRootLogin no
@@ -16,14 +16,14 @@ ChallengeResponseAuthentication no
 \subsubsection{iptables}
 
 Um den Zugriff auf das universitätsinterne Netz zu beschränken wurde ein
-Filter-Chain {\tt uni} zur {\tt iptables.rules} unter {\tt /etc/iptables} (siehe
+Filter-Chain \emph{uni} zur \emph{iptables.rules} unter \emph{/etc/iptables} (siehe
 \emph{aufgabe2.3/iptables.rules}) hinzugefügt, der nur IP-Adressen aus den Bereichen 141.30.0.0/16 und 141.76.0.0/16 akzeptiert und die Zugriffe auf Port 22, 80 und 443 beschränkt.
 
 \subsubsection{Absicherung für externen Zugriff}
 
-Um den Zugriff aus einem externen Netz abzusichern, könnte man z.B. den externen SSH-Port auf einen anderen Port als 22 legen, so dass dieser nicht zu leicht erraten werden kann. Zusätzlich könnte man per {\tt fail2ban} IPs, die z.B. per Bruteforce zu häufig versuchen sich einzuloggen, aussperren. Außerdem könnte man den externen SSH-Port auch erst per Port-Knocking freischalten, bei dem der Client z.B. mit einem Script erst an mehrere Ports »klopfen« muss, bevor er sich verbinden kann. Desweiteren könnte man den Login von außen nur für bestimmte Benutzer erlauben.
+Um den Zugriff aus einem externen Netz abzusichern, könnte man z.B. den externen SSH-Port auf einen anderen Port als 22 legen, so dass dieser nicht zu leicht erraten werden kann. Zusätzlich könnte man per \emph{fail2ban} IPs, die z.B. per Bruteforce zu häufig versuchen sich einzuloggen, aussperren. Außerdem könnte man den externen SSH-Port auch erst per Port-Knocking freischalten, bei dem der Client z.B. mit einem Script erst an mehrere Ports »klopfen« muss, bevor er sich verbinden kann. Desweiteren könnte man den Login von außen nur für bestimmte Benutzer erlauben.
 
 \subsubsection{Automatisierung für neue Nutzer}
 
 Das automatisierte Hinzufügen neuer Nutzer haben wir über ein Script {\tt
-newuser} (siehe \emph{aufgabe2.3/newuser}) gelöst. Dieses Script legt einen neuen Benutzer an, erstellt sein Home-Verzeichnis, generiert ein neues Public-Private-Key-Paar für SSH und trägt den eigenen Public-Key in die {\tt authorized\_keys} sowie für den Zugriff auf das git-Repository ein.
+newuser} (siehe \emph{aufgabe2.3/newuser}) gelöst. Dieses Script legt einen neuen Benutzer an, erstellt sein Home-Verzeichnis, generiert ein neues Public-Private-Key-Paar für SSH und trägt den eigenen Public-Key in die \emph{authorized\_keys} sowie für den Zugriff auf das git-Repository ein.

bericht/bs/bs.tex

@@ -5,8 +5,8 @@
 
 Wir haben \href{http://www.archlinux.org/}{Arch Linux} als Betriebssystem gewählt.
 
-Es hat mit {\tt systemd} ein modernes und robustes init-System. Dieses verwaltet Abhängigkeiten zwischen den verschiedenen Systemdiensten. Gestartete Dienste werden überwacht und können im Fehlerfall neu gestartet werden.
-Das Logging delegiert {\tt systemd} an {\tt journald}. Dieses indexiert die Logs und speichert diese in komprimierter Form ab. Ersteres erlaubt das effiziente Filtern nach bestimmten Feldern, wie der Zeit.
+Es hat mit \emph{systemd} ein modernes und robustes init-System. Dieses verwaltet Abhängigkeiten zwischen den verschiedenen Systemdiensten. Gestartete Dienste werden überwacht und können im Fehlerfall neu gestartet werden.
+Das Logging delegiert \emph{systemd} an \emph{journald}. Dieses indexiert die Logs und speichert diese in komprimierter Form ab. Ersteres erlaubt das effiziente Filtern nach bestimmten Feldern, wie der Zeit.
 
 Archlinux ist eine Rolling-Release-Distribution. Das heißt, dass es keine festen Zeitpunkte gibt, zu denen eine neue Version veröffentlicht mit neuen Paketen veröffentlicht wird. Stattdessen werden diese von den Maintainern kontinuierlich eingepflegt. Deswegen befinden sich in den offiziellen Arch Linux Repository in den meisten Fällen die aktuellsten Versionen der benötigten Software.
 
@@ -18,24 +18,24 @@ Als Nachteile muss man hingegen aufführen, dass es leider keinen kommerziellen
 
 Wir sind bei der Installation grundlegend nach der Anleitung im \href{https://wiki.archlinux.org/index.php/Beginners'_Guide}{Arch Linux Wiki} vorgegangen.
 
-Die Partitionierung haben wir wie im Cluster-Layout angegeben mit {\tt fdisk} vorgenommen und die Daten-Partitionen jeweils mit {\tt mkfs.ext4} auf {\tt ext4} formatiert. Hier sollte man nicht vergessen, die Boot-Partition in {\tt fdisk} auch als {\tt bootable} zu markieren.
+Die Partitionierung haben wir wie im Cluster-Layout angegeben mit \emph{fdisk} vorgenommen und die Daten-Partitionen jeweils mit \emph{mkfs.ext4} auf \emph{ext4} formatiert. Hier sollte man nicht vergessen, die Boot-Partition in \emph{fdisk} auch als \emph{bootable} zu markieren.
 
-Nach ursprünglichen Schwierigkeiten mit dem Internet-Zugang im TGI-Labor (keine IP-Adresse über DHCP erhalten), konnten wir dann das Basis-System mittels {\tt pacstrap} installieren und danach mittels {\tt arch-chroot} in dieses wechseln. Dort wurden nach der Anleitung die Sprache, das Konsolen-Tastaturlayout, die Zeitzone, Datum und Uhrzeit und die Hostnames festgelegt sowie den Bootloader {\tt GRUB} installiert und konfiguriert.
+Nach ursprünglichen Schwierigkeiten mit dem Internet-Zugang im TGI-Labor (keine IP-Adresse über DHCP erhalten), konnten wir dann das Basis-System mittels \emph{pacstrap} installieren und danach mittels \emph{arch-chroot} in dieses wechseln. Dort wurden nach der Anleitung die Sprache, das Konsolen-Tastaturlayout, die Zeitzone, Datum und Uhrzeit und die Hostnames festgelegt sowie den Bootloader \emph{GRUB} installiert und konfiguriert.
 
-Nach dem erfolgreichen Reboot haben wir dann das Netzwerk auf eine statische IP-Adresse mittels {\tt netctl} konfiguriert. Damit waren sowohl die Headnode als auch der erste Computenode grundsätzlich einsatzfähig.
+Nach dem erfolgreichen Reboot haben wir dann das Netzwerk auf eine statische IP-Adresse mittels \emph{netctl} konfiguriert. Damit waren sowohl die Headnode als auch der erste Computenode grundsätzlich einsatzfähig.
 
 \subsubsection{Netzwerk-Konfiguration}
 
-Auf dem Headnode bzw. Computenode haben wir mit {\tt netctl} die beiden
-Netzwerk-Interfaces {\tt eth0} und {\tt eth1} bzw. {\tt enp1s0} auf eine
+Auf dem Headnode bzw. Computenode haben wir mit \emph{netctl} die beiden
+Netzwerk-Interfaces \emph{eth0} und \emph{eth1} bzw. \emph{enp1s0} auf eine
 statische IP-Adresse (wie im Cluster-Layout angegeben) konfiguriert (siehe
 \emph{aufgabe2.2/headnode/network} und \emph{aufgabe2.2/headnode/internal} bzw.
 \emph{aufgabe2.2/computenode/internal}).
 
-Auf dem Headnode mussten wir noch mittels {\tt iptables} das {\tt
-MASQUERADE}-Target in der {\tt POSTROUTING}-Chain in der {\tt nat}-Tabelle auf
-dem {\tt eth0}-Interface setzen (siehe \emph{aufgabe2.3/iptables.rules}) und mit
-{\tt sysctl} (\emph{/etc/sysctl.d}) die Option {\tt net.ipv4.ip\_forward = 1}
+Auf dem Headnode mussten wir noch mittels \emph{iptables} das {\tt
+MASQUERADE}-Target in der \emph{POSTROUTING}-Chain in der \emph{nat}-Tabelle auf
+dem \emph{eth0}-Interface setzen (siehe \emph{aufgabe2.3/iptables.rules}) und mit
+\emph{sysctl} (\emph{/etc/sysctl.d}) die Option \emph{net.ipv4.ip\_forward = 1}
 (siehe \emph{aufgabe2.2/10-ip-forward-conf}) freischalten, damit die Computenodes auch auf das Internet zugreifen können (Paketinstallationen, Updates, etc.).
 
 \input{bs/bs-ssh}

bericht/burnin.tex

@@ -8,7 +8,7 @@ Zur Überwachung und Aufzeichnung des Systems während des Burnin haben wir {\tt
 munin} eingerichtet. Dieses besteht aus einem Masterprozess, welches die gewünschten
 Daten aufzeichnet, und einem Nodeprozess, welches die Daten bereitstellt. Die
 Darstellung erfolgt über ein Webinterface, welches die Graphen aus einer
-{\tt rddtool}-Datenbank generiert. Auf dem Headnode haben wir den Masterprozess
+\emph{rddtool}-Datenbank generiert. Auf dem Headnode haben wir den Masterprozess
 installiert:
 
 \shellcmd{pacman -S munin}
@@ -18,7 +18,7 @@ Auf dem Computenode die Nodekomponente:
 
 \shellcmd{pacman -S munin-node}
 
-Für das Webfrontend richteten wir darüber hinaus den Webserver {\tt nginx} ein:
+Für das Webfrontend richteten wir darüber hinaus den Webserver \emph{nginx} ein:
 
 \shellcmd{pacman -S nginx}
 
@@ -31,10 +31,10 @@ Befehl:
 
 \shellcmd{systemctl start munin-graph.socket munin-html.socket}
 
-Die ab zu fragenden Nodes werden in die {\tt munin.conf} eingetragen ({\tt
+Die ab zu fragenden Nodes werden in die \emph{munin.conf} eingetragen ({\tt
 aufgabe2.6/munin.conf}).
 Da die Anzahl unserer Nodes verhältnismäßig klein ist, haben wir uns für die
-Aktualisierung der Leistungsdaten via {\tt munin-cron} entschieden:
+Aktualisierung der Leistungsdaten via \emph{munin-cron} entschieden:
 
 \shellcmd{crontab /etc/munin/munin-cron-entry -u munin}
 
@@ -51,7 +51,7 @@ Computenode haben wir folgende Plugins aktiviert:
 \item sensors\_temp
 \end{itemize}
 
-Zum Belasten des Systems über 48h verwendeten wir {\tt stress} mit jeweils 4 Workern für jeweils CPU-, IO-, Speicher- und Festplatten-Auslastung.
+Zum Belasten des Systems über 48h verwendeten wir \emph{stress} mit jeweils 4 Workern für jeweils CPU-, IO-, Speicher- und Festplatten-Auslastung.
 
 \pagebreak
 

bericht/prov/prov-cuda.tex

@@ -2,4 +2,4 @@
 \label{sub:cuda}
 
 Die für easybuild (\ref{sec:easybuild}) benötigten Paket-Beschreibungen sind in \emph{aufgabe4.6} zu finden. 
-Zusätzlich wurden die Pakete {\tt nvidia mesa glu libxi libmxu freeglut} installiert.
+Zusätzlich wurden die Pakete \emph{nvidia mesa glu libxi libmxu freeglut} installiert.

bericht/prov/prov-mpi.tex

@@ -1,11 +1,11 @@
 \subsection{Open MPI}
 \label{sub:open_mpi}
 
-OpenMPI wurde in der Version 1.7.3 mithilfe von easybuild (\ref{sec:easybuild}) installiert. Die für easybuild benötigten Paket-Beschreibungen sind in \emph{aufgabe4.5} zu finden. Zum Testen haben wir das Programm {\tt hello.cpp} (siehe \emph{aufgabe4.5/hello.cpp}) geschrieben, welches für jeden Node dessen Rank und Hostname ausgibt. Dieses kann durch folgenden Befehl compiliert werden:
+OpenMPI wurde in der Version 1.7.3 mithilfe von easybuild (\ref{sec:easybuild}) installiert. Die für easybuild benötigten Paket-Beschreibungen sind in \emph{aufgabe4.5} zu finden. Zum Testen haben wir das Programm \emph{hello.cpp} (siehe \emph{aufgabe4.5/hello.cpp}) geschrieben, welches für jeden Node dessen Rank und Hostname ausgibt. Dieses kann durch folgenden Befehl compiliert werden:
 
 \shellcmd{mpic++ hello.cpp} 
 
-Mit Hilfe einer {\tt hosts}-Datei, in der die Namen aller verwendeten Nodes eingetragen wird, kann das Programm mit folgenden Befehl ausgeführt werden:
+Mit Hilfe einer \emph{hosts}-Datei, in der die Namen aller verwendeten Nodes eingetragen wird, kann das Programm mit folgenden Befehl ausgeführt werden:
 
 \shellcmd{mpirun $--$hostfile hosts a.out}
 

bericht/prov/prov-provisioning.tex

@@ -7,9 +7,9 @@
 
 Wir verwenden Clonezilla um die Provisionierung durchzuführen. Wir haben uns für dieses Verfahren entschieden, weil bspw. ein Netzwerk-Boot, bei dem das gesamte Dateisystem per NFS eingebunden wird, in unserem Fall eher ineffektiv wäre, da auf den Festplatten der Compute-Nodes sowieso genügend Speicher für das Betriebssystem vorhanden ist und es dann bei jedem Zugriff auf das Dateisystem zu unnötigen Latenzen kommen würde.
 
-Um Clonezilla auf den Computenodes zu booten, haben wir den {\tt in.tftpd}-Server installiert und das Service-File für {\tt systemd} angepasst (siehe {\tt aufgabe4.4/tftpd.service}). Außerdem haben wir die Konfiguration des DHCP-Servers so angepasst, dass nun jeder Compute-Node eine eigene Konfigurationsdatei in {\tt /etc/dhcpd.d/} hat, die jeweils in von {\tt /etc/dhcpd.d/all} inkludiert wird.
+Um Clonezilla auf den Computenodes zu booten, haben wir den \emph{ in.tftpd}-Server installiert und das Service-File für \emph{ systemd} angepasst (siehe \emph{ aufgabe4.4/tftpd.service}). Außerdem haben wir die Konfiguration des DHCP-Servers so angepasst, dass nun jeder Compute-Node eine eigene Konfigurationsdatei in \emph{ /etc/dhcpd.d/} hat, die jeweils in von \emph{ /etc/dhcpd.d/all} inkludiert wird.
 
-Außerdem haben wir ein Script {\tt cluster} geschrieben, mit dem die Computenodes verwaltet werden können. Mit
+Außerdem haben wir ein Script \emph{ cluster} geschrieben, mit dem die Computenodes verwaltet werden können. Mit
 \begin{lstlisting}
 cluster add <HOSTNAME> <IP> <MAC>
 \end{lstlisting}
@@ -17,9 +17,9 @@ wird ein neuer Node hinzugefügt (DHCP- und DNS-Eintrag). Mit
 \begin{lstlisting}
 cluster set-<MODE> <HOSTNAME>
 \end{lstlisting}
-kann der Modus für den nächsten Boot des Nodes festgelegt werden. Hier kann man zwischen {\tt local} (Boot von lokaler Festplatte), {\tt live} (Boot in das Clonezilla Image), {\tt clone} (Clonen nach Boot) und {\tt restore} (Image laden nach Boot) wählen.
+kann der Modus für den nächsten Boot des Nodes festgelegt werden. Hier kann man zwischen \emph{ local} (Boot von lokaler Festplatte), \emph{ live} (Boot in das Clonezilla Image), \emph{ clone} (Clonen nach Boot) und \emph{ restore} (Image laden nach Boot) wählen.
 
-Um den Netzwerk-Boot zu ermöglichen, haben wir {\tt pxelinux} unter {\tt /srv/tftp/pxelinux} installiert und konfiguriert. In dieses Verzeichnis haben wir die Dateien {\tt vmlinuz}, {\tt initrd.img}  und {\tt filesystem.squashfs} aus der Clonezilla-Live-ISO kopiert, sowie außerdem noch {\tt ldlinux.c32, libcom32.c32, libutil.c32, menu.c32, chain.c32} und {\tt pxelinux.0} aus der {\tt syslinux}-Installation. Die Konfigurationsdateien liegen in {\tt /srv/tftp/pxelinux/pxelinux.cfg}.
+Um den Netzwerk-Boot zu ermöglichen, haben wir \emph{ pxelinux} unter \emph{ /srv/tftp/pxelinux} installiert und konfiguriert. In dieses Verzeichnis haben wir die Dateien \emph{ vmlinuz}, \emph{ initrd.img}  und \emph{ filesystem.squashfs} aus der Clonezilla-Live-ISO kopiert, sowie außerdem noch \emph{ ldlinux.c32, libcom32.c32, libutil.c32, menu.c32, chain.c32} und \emph{ pxelinux.0} aus der \emph{ syslinux}-Installation. Die Konfigurationsdateien liegen in \emph{ /srv/tftp/pxelinux/pxelinux.cfg}.
 
 \end{sloppypar}
 
@@ -27,14 +27,14 @@ Um den Netzwerk-Boot zu ermöglichen, haben wir {\tt pxelinux} unter {\tt /srv/t
 
 \begin{sloppypar}
 
-Um den Clone-Vorgang zu starten, wir nun mit {\tt sudo cluster set-clone <HOSTNAME>} und anschließendem (Neu-)Starten des Nodes das Clonezilla Live Image gebootet. Dieses holt sich nun vom Headnode ein Script und führt dieses aus. In diesem Script haben wir alle nötigen Befehle eingetragen, um das Clonen vorzubereiten und zu starten (siehe {\tt aufgabe4.4/clone.sh}). Dazu wird per NFS das {\tt /cluster}-Verzeichnis des Headnodes eingebunden und dort im Unterverzeichnis {\tt images} das Image der Festplatte abgelegt. Geclont werden nur die {\tt /}- und die {\tt /boot}-Partition.
+Um den Clone-Vorgang zu starten, wir nun mit \emph{ sudo cluster set-clone <HOSTNAME>} und anschließendem (Neu-)Starten des Nodes das Clonezilla Live Image gebootet. Dieses holt sich nun vom Headnode ein Script und führt dieses aus. In diesem Script haben wir alle nötigen Befehle eingetragen, um das Clonen vorzubereiten und zu starten (siehe \emph{ aufgabe4.4/clone.sh}). Dazu wird per NFS das \emph{ /cluster}-Verzeichnis des Headnodes eingebunden und dort im Unterverzeichnis \emph{ images} das Image der Festplatte abgelegt. Geclont werden nur die \emph{ /}- und die \emph{ /boot}-Partition.
 
-Zum Wiederherstellen des Images wird mit {\tt sudo cluster set-restore <HOSTNAME>} wieder der entsprechende Boot-Modus gesetzt und der Node neugestartet. Dort wird nun ein anderes Script vom Headnode geholt (siehe {\tt aufgabe4.4/restore.sh}) und die beiden Partitionen wiederhergestellt. Anschließend werden noch die Swap-Partition und die Daten-Partition für das verteilte Dateisystem neu formatiert und die alten UUIDs gesetzt.
+Zum Wiederherstellen des Images wird mit \emph{ sudo cluster set-restore <HOSTNAME>} wieder der entsprechende Boot-Modus gesetzt und der Node neugestartet. Dort wird nun ein anderes Script vom Headnode geholt (siehe \emph{ aufgabe4.4/restore.sh}) und die beiden Partitionen wiederhergestellt. Anschließend werden noch die Swap-Partition und die Daten-Partition für das verteilte Dateisystem neu formatiert und die alten UUIDs gesetzt.
 
-Da Clonezilla bei uns {\tt ext4} irgendwie nicht erkannt hat, hat es, um die Partitionen zu klonen, {\tt partclone.dd} verwendet, was allerdings sehr langsam ist, weil es die komplette Partition klont und freie Blöcke nicht auslässt. Deswegen haben wir zwei kleine Wrapper-Scripts geschrieben, die stattdessen {\tt partclone.ext4} aufrufen. (siehe {\tt aufgabe4.4/partclone.dd-clone} und {\tt partclone.dd-restore})
+Da Clonezilla bei uns \emph{ ext4} irgendwie nicht erkannt hat, hat es, um die Partitionen zu klonen, \emph{ partclone.dd} verwendet, was allerdings sehr langsam ist, weil es die komplette Partition klont und freie Blöcke nicht auslässt. Deswegen haben wir zwei kleine Wrapper-Scripts geschrieben, die stattdessen \emph{ partclone.ext4} aufrufen. (siehe \emph{ aufgabe4.4/partclone.dd-clone} und \emph{ partclone.dd-restore})
 
-Da wir in unserem Cluster gemischte Boards haben (Intel und Zotac), mussten wir anschließend außerdem noch das Ziel-Root-Verzeichnis mounten und dort mit {\tt mkinitcpio -p linux} ein neues {\tt initrd} erstellen lassen, damit die entsprechenden richtigen Treiber beim Bootvorgang geladen werden können.
+Da wir in unserem Cluster gemischte Boards haben (Intel und Zotac), mussten wir anschließend außerdem noch das Ziel-Root-Verzeichnis mounten und dort mit \emph{ mkinitcpio -p linux} ein neues \emph{ initrd} erstellen lassen, damit die entsprechenden richtigen Treiber beim Bootvorgang geladen werden können.
 
-Um die automatische Umbenennung der Netzwerk-Interfaces vorzubeugen, mussten wir außerdem einen Symlink {\tt /etc/udev/rules.d/80-net-name-slot.rules -> /dev/null} erstellen. Dieser verhindert, dass das Ethernet-Interface nicht enpXsY sondern fest eth0 benannt wird.
+Um die automatische Umbenennung der Netzwerk-Interfaces vorzubeugen, mussten wir außerdem einen Symlink \emph{ /etc/udev/rules.d/80-net-name-slot.rules -> /dev/null} erstellen. Dieser verhindert, dass das Ethernet-Interface nicht enpXsY sondern fest eth0 benannt wird.
 
 \end{sloppypar}

bericht/sv/sv-dhcp_dns.tex

@@ -3,10 +3,10 @@
 \subsubsection{Server}
 
 \begin{sloppypar}
-Wir haben uns für {\tt dhcpd} als DHCP-Server entschieden. Zur Konfiguration haben wir in {\tt /etc/dhcpd.conf} (siehe {\tt aufgabe3.2}) den Domain-Namen {\tt zotac} eintragen und den Headnode als DNS-Server eingestellt.
+Wir haben uns für \emph{dhcpd} als DHCP-Server entschieden. Zur Konfiguration haben wir in \emph{/etc/dhcpd.conf} (siehe \emph{aufgabe3.2}) den Domain-Namen \emph{zotac} eintragen und den Headnode als DNS-Server eingestellt.
 \end{sloppypar}
 
-Des Weiteren haben wir das Subnet {\tt 10.20.0.0/24} deklariert und wiederum den Headnode als verantwortlichen Router eingetragen.
+Des Weiteren haben wir das Subnet \emph{10.20.0.0/24} deklariert und wiederum den Headnode als verantwortlichen Router eingetragen.
 
 Die Pro-Host-Konfiguration sieht bei uns wie folgt aus:
 
@@ -20,38 +20,38 @@ host zotac<X> {
 
 Damit ist sichergestellt, dass die Hosts die im Cluster-Layout spezifizierte IP-Adresse entsprechend ihrer MAC-Adresse zugewiesen bekommen und gleichzeitig ihren Hostnamen gesagt bekommen. (Die IP-Adresse holt sich der DHCP-Server vom lokalen DNS-Server.)
 
-Zusätzlich haben wir das bereits in der Installation enthaltene {\tt systemd}-Service-File entsprechend so angepasst, dass man beim Starten und Aktivieren des Dienstes spezifizieren kann, auf welchem Netzwerk-Interface der Dienst hören soll. (siehe {\tt aufgabe3.2/dhcpd4@.service})
+Zusätzlich haben wir das bereits in der Installation enthaltene \emph{systemd}-Service-File entsprechend so angepasst, dass man beim Starten und Aktivieren des Dienstes spezifizieren kann, auf welchem Netzwerk-Interface der Dienst hören soll. (siehe \emph{aufgabe3.2/dhcpd4@.service})
 
 Starten kann man den Dienst nun mit:
 
 \shellcmd{systemctl start dhcpd4@eth1}
 
-wobei {\tt eth1} das Interface ist, das am internen LAN angeschlossen ist.
+wobei \emph{eth1} das Interface ist, das am internen LAN angeschlossen ist.
 
 \subsubsection{Client}
 
 \begin{sloppypar}
 
-Als Client verwenden wir {\tt dhcpcd}. \\
+Als Client verwenden wir \emph{dhcpcd}. \\
 
-Um den Hostnamen richtig vom DHCP-Server abholen zu können, mussten wir in {\tt /usr/lib/dhcpcd/dhcpcd-hooks/30-hostname} (siehe {\tt aufgabe3.2/30-hostname}) noch die Option {\tt hostname\_fqdn=false} setzen, damit der kurze Hostname ({\tt zotac<X>} statt {\tt zotac<X>.zotac}) verwendet wird. \\
+Um den Hostnamen richtig vom DHCP-Server abholen zu können, mussten wir in \emph{/usr/lib/dhcpcd/dhcpcd-hooks/30-hostname} (siehe \emph{aufgabe3.2/30-hostname}) noch die Option \emph{hostname\_fqdn=false} setzen, damit der kurze Hostname (\emph{zotac<X>} statt \emph{zotac<X>.zotac}) verwendet wird. \\
 
 Außerdem haben wir noch die Zeile:
 \begin{center}
-{\tt hostname \grqq{\$}1\grqq}
+\emph{hostname \grqq{\$}1\grqq}
 \end{center}
 durch:
 \begin{center}
-{\tt hostnamectl set-hostname \grqq{\$}1\grqq}
+\emph{hostnamectl set-hostname \grqq{\$}1\grqq}
 \end{center}
-ersetzt, damit der bezogene Hostname automatisch persistent ({\tt /etc/hostname}) gesetzt wird.
+ersetzt, damit der bezogene Hostname automatisch persistent (\emph{/etc/hostname}) gesetzt wird.
 
 \end{sloppypar}
 
 \subsection{DNS}
 \label{ssub:dns}
 
-Als DNS-Server haben wir {\tt Bind} installiert und eingerichtet.
+Als DNS-Server haben wir \emph{Bind} installiert und eingerichtet.
 Die Konfiguration ist in \emph{aufgabe3.2/named.conf} zu finden.
 Für das Auflösen der Hostnames haben wir die Domaine zotac \emph{aufgabe3.2/zotac.zone} angelegt und
 ein Zonefile für die Reverse-DNS-Auflösung \emph{aufgabe3.2/0.20.10.in-appr.arpa}.

bericht/sv/sv-filesystems.tex

@@ -8,11 +8,11 @@ Wir haben uns für das NFS-Dateisystem entschieden. Dieses ermöglicht
 ressourcensparend Verzeichnisse zwischen der Head-Node und den Compute-Nodes zu
 teilen.
 
-Unter Archlinux ist der NFS-Server im Packet {\tt nfs-utils} zu finden.
+Unter Archlinux ist der NFS-Server im Packet \emph{nfs-utils} zu finden.
 Um NFS zu exportieren starten wir auf dem Head-Node den rpc-mountd.service.
 Das ID-Mapping übernimmt in unserem Fall der ldap-Dienst (\ref{sub:ldap}).
-Auf den Compute-Node wurde jeweils ein Eintrag für die Verzeichnisse {\tt home}
-und {\tt cluster} in der fstab angelegt. (siehe {\tt aufgabe3.1/fstab}).
+Auf den Compute-Node wurde jeweils ein Eintrag für die Verzeichnisse \emph{home}
+und \emph{cluster} in der fstab angelegt. (siehe \emph{aufgabe3.1/fstab}).
 
 \subsubsection{Verteiltes Dateisystem}
 \label{ssub:verteiltes_dateisystem}
@@ -33,7 +33,7 @@ Als Dateisystem für GlusterFS wird xfs empfohlen. Dafür haben wir mit fstab ei
 
 \shellcmd{mkfs.xfs -i size=512 /dev/sda5}
 
-und nach {\tt /mnt/glusterfs} gemountet (siehe aufgabe3.3/fstab). Nach dem Starten des
+und nach \emph{/mnt/glusterfs} gemountet (siehe aufgabe3.3/fstab). Nach dem Starten des
 GlusterFS-Dienstes, sowohl auf Head- und Computenode:
 
 \shellcmd{systemctl enable glusterfs.service}
@@ -46,18 +46,17 @@ legten wir das Dateisystem an:
 
 \shellcmd{gluster volume start gv0}
 
-Letztendlich mounten wir das GlusterFS mit folgenden Eintrag in der {\tt
-aufgabe3.3/fstab}:
+Letztendlich mounten wir das GlusterFS mit folgenden Eintrag in der \emph{aufgabe3.3/fstab}:
 
 \begin{center}
-{\tt zotac0:/gv0 /fastfs glusterfs defaults 0 0}
+zotac0:/gv0 /fastfs glusterfs defaults 0 0
 \end{center}
 
-Um die Schreibrate zu ermitteln, verwendeten wir den Befehl {\tt dd}:
+Um die Schreibrate zu ermitteln, verwendeten wir den Befehl \emph{dd}:
 
 \shellcmd{dd bs=1M count=512 if=/dev/zero of=/path/to/file conv=fdatasync}
 
-um einen 512MB Block auf die Festplatte. Die Option {\tt conv=fdatasync} sorgt
+um einen 512MB Block auf die Festplatte. Die Option \emph{conv=fdatasync} sorgt
 für einen Dateisystem-Sync nach dem Schreiben um die korrekte Schreibrate zu
 ermitteln.
 Für Leserate haben wir folgenden Befehl benutzt um dieselbige erstellte Datei zu
@@ -72,7 +71,7 @@ diesem vor jedem Durchlauf geleert:
 
 Die Tests wurden auf dem Host zotac1 ausgeführt, wobei {\emph Lokal}, dem
 lokalen Ext4-Dateisystem entspricht, NFS dem gemounten NFS von zotac0 und GlusterFS, dem
-Dateisystem in /fastfs entspricht. Die Rohdaten befinden sich in {\tt aufgabe3.3/benchmark.txt}
+Dateisystem in /fastfs entspricht. Die Rohdaten befinden sich in \emph{aufgabe3.3/benchmark.txt}
 
 \pgfplotsset{
   select row/.style={

bericht/sv/sv-iptables.tex

@@ -3,7 +3,7 @@
 \subsubsection{Grundkonfiguration}
 
 \begin{sloppypar}
-Beim Systemstart wird der Dienst {\tt iptables.service} gestartet und die Filterregeln aus der {\tt /etc/iptables/iptables.rules} (siehe \emph{aufgabe3.1/iptables.rules}) übernommen. Diese wurde so konfiguriert, dass bestehende Verbindungen, sowie Verbindungen im internen LAN automatisch erlaubt werden. Der Zugriff von außerhalb ist auf den Port 22 beschränkt. Zusätzlich ist {\tt icmp} erlaubt. Zur Absicherung gegen BruteForce verwenden wird {\tt sshguard}, für das wir einen eigene Chain {\tt sshguard} in der {\tt iptables.rules} eingetragen haben. Alle Zugriffe auf Port 22 werden an diese Chain übergeben. Erfolgen in kurzer Zeit zu viele unautorisierte Zugriffe, trägt das Programm {\tt sshguard} automatisch temporär eine neue DROP-Regel in die {\tt sshguard}-Chain ein. Verbindungen nach außen werden alle durchgelassen, weil es nicht effektiv ist, einzelne Ports zu sperren, da ein Angreifer einfach auf anderen Ports Pakete versenden könnte.
+Beim Systemstart wird der Dienst \emph{iptables.service} gestartet und die Filterregeln aus der \emph{/etc/iptables/iptables.rules} (siehe \emph{aufgabe3.1/iptables.rules}) übernommen. Diese wurde so konfiguriert, dass bestehende Verbindungen, sowie Verbindungen im internen LAN automatisch erlaubt werden. Der Zugriff von außerhalb ist auf den Port 22 beschränkt. Zusätzlich ist \emph{icmp} erlaubt. Zur Absicherung gegen BruteForce verwenden wird \emph{sshguard}, für das wir einen eigene Chain \emph{sshguard} in der \emph{iptables.rules} eingetragen haben. Alle Zugriffe auf Port 22 werden an diese Chain übergeben. Erfolgen in kurzer Zeit zu viele unautorisierte Zugriffe, trägt das Programm \emph{sshguard} automatisch temporär eine neue DROP-Regel in die \emph{sshguard}-Chain ein. Verbindungen nach außen werden alle durchgelassen, weil es nicht effektiv ist, einzelne Ports zu sperren, da ein Angreifer einfach auf anderen Ports Pakete versenden könnte.
 \end{sloppypar}
 
 
@@ -15,7 +15,7 @@ Das Internet wird durch folgende Regel in der NAT-Tabelle:
 -A POSTROUTING -o eth0 -j MASQUERADE
 \end{lstlisting}
 
-für die Compute-Nodes zugängig gemacht. Dazu musste noch die Datei {\tt /etc/sysctl.d} mit der Zeile: 
+für die Compute-Nodes zugängig gemacht. Dazu musste noch die Datei \emph{/etc/sysctl.d} mit der Zeile: 
 
 \begin{lstlisting}
 net.ipv4.ip_forward = 1
@@ -26,11 +26,11 @@ erstellt werden.
 
 \subsubsection{Diagnose und Logging}
 
-Alle abgeblockten Verbindungen landen in der {\tt logging}-Chain, wo sie durch:
+Alle abgeblockten Verbindungen landen in der \emph{logging}-Chain, wo sie durch:
 
 \begin{lstlisting}
 -A logging -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
 \end{lstlisting}
 
-geloggt werden. Die Anzahl der Meldungen haben wir auf 2 pro Minute limitiert. Der Log kann unter {\tt /var/log/iptables.log} gefunden werden.
+geloggt werden. Die Anzahl der Meldungen haben wir auf 2 pro Minute limitiert. Der Log kann unter \emph{/var/log/iptables.log} gefunden werden.
 

bericht/sv/sv-ldap.tex

@@ -2,57 +2,71 @@
 \label{sub:ldap}
 
 \begin{sloppypar}
-Wir haben uns für den OpenLDAP-Server entschieden. Dazu haben wir als Basis-{\tt dn}:
+Wir haben uns für den OpenLDAP-Server entschieden. Dazu haben wir als Basis-\emph{dn}:
 \begin{center}
-{\tt dc=zotac,dc=lctp}
+\emph{dc=zotac,dc=lctp}
 \end{center} festgelegt.
 Die Benutzer legten wir unter
 \begin{center}
-{\tt dn: ou=users,dc=zotac,dc=lctp},
+\emph{dn: ou=users,dc=zotac,dc=lctp},
 \end{center}
 die Gruppen unter
 \begin{center}
-{\tt dn: ou=groups,dc=zotac,dc=lctp}
+\emph{dn: ou=groups,dc=zotac,dc=lctp}
 \end{center}
-ab. Für den Import dieser {\tt dn}s haben wir eine Datei \texttt{/etc/openldap/base.ldif} (siehe \texttt{aufgabe3.5/base.ldif}) erstellt. An verfügbaren Schemen haben wir \texttt{core, cosine, inetorgperson, nis} eingestellt (siehe \texttt{aufgabe3.5/slapd.conf}).
+ab. Für den Import dieser \emph{dn}s haben wir eine Datei
+\emph{/etc/openldap/base.ldif} (siehe \emph{aufgabe3.5/base.ldif}) erstellt. An
+verfügbaren Schemen haben wir \emph{core, cosine, inetorgperson, nis}
+eingestellt (siehe \emph{aufgabe3.5/slapd.conf}).
 
 \end{sloppypar}
 
 \subsubsection{Absicherung und Zugriff}
 
-Wir haben die Zugriffsrechte so konfiguriert, dass jeder Benutzer sein eigenes Passwort ändern, aber niemand das Passwort auslesen darf (darf nur zur Authentifizierung abgerufen werden). Alle anderen Attribute dürfen von allen Users gelesen werden. (siehe {\tt aufgabe3.5/slapd.conf})
+Wir haben die Zugriffsrechte so konfiguriert, dass jeder Benutzer sein eigenes
+Passwort ändern, aber niemand das Passwort auslesen darf (darf nur zur
+Authentifizierung abgerufen werden). Alle anderen Attribute dürfen von allen
+Users gelesen werden. (siehe \emph{aufgabe3.5/slapd.conf})
 
-Damit auf den Verzeichnisdienst zugegriffen werden kann, haben wir eine Datei {\tt /etc/ldap.secret} mit dem Passwort für den Administrator-Account in LDAP angelegt, die nur durch {\tt root} zugreifbar ist ({\tt chmod 600}).
+Damit auf den Verzeichnisdienst zugegriffen werden kann, haben wir eine Datei
+\emph{/etc/ldap.secret} mit dem Passwort für den Administrator-Account in LDAP
+angelegt, die nur durch \emph{root} zugreifbar ist (\emph{chmod 600}).
 
 \subsubsection{Client-Konfiguration (Headnode und Computenode)}
 
 \begin{sloppypar}
-Hierfür haben wir die Variablen {\tt BASE, URI, TIMEOUT, NETWORK\_TIMEOUT} in {\tt /etc/openldap/ldap.conf} entsprechend konfiguriert (siehe {\tt aufgabe3.5/ldap.conf}).
+Hierfür haben wir die Variablen \emph{BASE, URI, TIMEOUT, NETWORK\_TIMEOUT} in
+\emph{/etc/openldap/ldap.conf} entsprechend konfiguriert (siehe \emph{aufgabe3.5/ldap.conf}).
 \end{sloppypar}
 
 \paragraph{nsswitch}
 
-Damit die Standard-Unix-Dienste auf die Benutzer aus LDAP zurückgreifen können, haben wir {\tt /etc/nss\_ldap.conf} entsprechend konfiguriert (siehe {\tt aufgabe3.5/nss\_ldap.conf}), sowie in {\tt /etc/nsswitch.conf} unter {\tt files, shadow, group} jeweils noch {\tt ldap} hinzugefügt (siehe {\tt aufgabe3.5/nsswitch.conf}).
+Damit die Standard-Unix-Dienste auf die Benutzer aus LDAP zurückgreifen können,
+haben wir \emph{/etc/nss\_ldap.conf} entsprechend konfiguriert (siehe
+\emph{aufgabe3.5/nss\_ldap.conf}), sowie in \emph{/etc/nsswitch.conf} unter
+\emph{files, shadow, group} jeweils noch \emph{ldap} hinzugefügt (siehe \emph{aufgabe3.5/nsswitch.conf}).
 
-Dabei mussten wir darauf achten, dass in der {\tt nss\_ldap.conf} die Bind-Policy auf {\tt soft} gesetzt wird, da es andernfalls beim Boot zu einer Race-Condition kommen kann, wenn der LDAP-Server noch nicht gestartet ist und das System dennoch versucht, über LDAP User-Daten abzufragen.
+Dabei mussten wir darauf achten, dass in der \emph{nss\_ldap.conf} die
+Bind-Policy auf \emph{soft} gesetzt wird, da es andernfalls beim Boot zu einer Race-Condition kommen kann, wenn der LDAP-Server noch nicht gestartet ist und das System dennoch versucht, über LDAP User-Daten abzufragen.
 
 \paragraph{PAM}
 
-Um die PAM-Authentifizierung nutzen zu können, haben wir unter {\tt /etc/pam.d} folgende Dateien geändert (siehe Dateien in {\tt aufgabe3.5/pam.d}):
+Um die PAM-Authentifizierung nutzen zu können, haben wir unter \emph{/etc/pam.d}
+folgende Dateien geändert (siehe Dateien in \emph{aufgabe3.5/pam.d}):
 \begin{itemize}
 
-\item {\tt system-auth}:
+\item \emph{system-auth}:
 \begin{lstlisting}
 	auth      sufficient  pam_ldap.so
 	session   required    pam_exec.so     /usr/local/bin/first-login
 \end{lstlisting}
 
-\item {\tt sudo} und {\tt su}:
+\item \emph{sudo} und \emph{su}:
 \begin{lstlisting}
 	auth      sufficient  pam_ldap.so
 \end{lstlisting}
 
-\item {\tt passwd}:
+\item \emph{passwd}:
 \begin{lstlisting}
 	password  sufficient  pam_ldap.so
 \end{lstlisting}
@@ -60,26 +74,37 @@ Um die PAM-Authentifizierung nutzen zu können, haben wir unter {\tt /etc/pam.d}
 \end{itemize}
 
 \begin{sloppypar}
-Damit ist sichergestellt, dass sich die LDAP-Benutzter authentifizieren können, sowie {\tt sudo} und {\tt su} benutzen und ihr Passwort mit {\tt passwd} ändern können.
+Damit ist sichergestellt, dass sich die LDAP-Benutzter authentifizieren können,
+sowie \emph{sudo} und \emph{su} benutzen und ihr Passwort mit \emph{passwd} ändern können.
 
-Durch die Zeile mit {\tt pam\_exec.so} wird bei jedem Login das Script {\tt first-login} (siehe {\tt aufgabe3.5/first-login}) ausgeführt; das ist faktisch das Script aus Aufgabe 2.3, nur angepasst für die Einbindung in PAM. Dieses wird generell nur ausgeführt, wenn das Home-Verzeichnis des Nutzers noch nicht existiert.
+Durch die Zeile mit \emph{pam\_exec.so} wird bei jedem Login das Script
+\emph{first-login} (siehe \emph{aufgabe3.5/first-login}) ausgeführt; das ist faktisch das Script aus Aufgabe 2.3, nur angepasst für die Einbindung in PAM. Dieses wird generell nur ausgeführt, wenn das Home-Verzeichnis des Nutzers noch nicht existiert.
 
-Das Script erstellt das Home-Verzeichnis des Nutzers, ändert den Besitzer und die Gruppe des Verzeichnisses entsprechend, erzeugt ein Public-Private-Key-Paar für SSH, kopiert eine Beispiel-SSH-Konfiguration in sein Home-Verzeichnis und trägt den eigenen Public-Key in die {\tt authorized\_keys} ein, so dass der Benutzer sich fortan auf allen Nodes einloggen kann.
+Das Script erstellt das Home-Verzeichnis des Nutzers, ändert den Besitzer und
+die Gruppe des Verzeichnisses entsprechend, erzeugt ein Public-Private-Key-Paar
+für SSH, kopiert eine Beispiel-SSH-Konfiguration in sein Home-Verzeichnis und
+trägt den eigenen Public-Key in die \emph{authorized\_keys} ein, so dass der Benutzer sich fortan auf allen Nodes einloggen kann.
 \end{sloppypar}
 
 \paragraph{Anlegen und Löschen von Benutzern}
 
-Zum Anlegen und Löschen von Benutzern aus einer Text-Datei (wie in der Aufgabe gefordert) haben wir die Scripte {\tt ldap-users2ldif} (erstellt einen {\tt .ldif} Output anhand der Text-Datei), {\tt ldap-add-ldif} (fügt die im {\tt .ldif} Format vorliegenden Benutzerbeschreibungen zur LDAP-Datenbank hinzu) und {\tt ldap-delete-users} (löscht die in einer Text-Datei aufgelisteten Benutzer aus der LDAP-Datenbank) geschrieben (siehe Dateien in {\tt aufgabe3.5/ldap-tools}).
+Zum Anlegen und Löschen von Benutzern aus einer Text-Datei (wie in der Aufgabe
+gefordert) haben wir die Scripte \emph{ldap-users2ldif} (erstellt einen
+\emph{.ldif} Output anhand der Text-Datei), \emph{ldap-add-ldif} (fügt die im
+\emph{.ldif} Format vorliegenden Benutzerbeschreibungen zur LDAP-Datenbank
+hinzu) und \emph{ldap-delete-users} (löscht die in einer Text-Datei
+aufgelisteten Benutzer aus der LDAP-Datenbank) geschrieben (siehe Dateien in
+\emph{aufgabe3.5/ldap-tools}).
 
-Für eine Datei, z.B. {\tt user.txt}, die die hinzuzufügenden Benutzernamen zeilenweise enthält:
+Für eine Datei, z.B. \emph{user.txt}, die die hinzuzufügenden Benutzernamen zeilenweise enthält:
 
 \begin{itemize}
-\item {\tt sudo ldap-users2ldif user.txt > user.txt.ldif} \\
-	erstellt eine {\tt .ldif}-Datei; erstellt außerdem {\tt user.txt.passwords}, die die Benutzernamen und Passwörter zeilenweise enthält; die Benutzernamen werden escaped (nur Kleinbuchstaben, Zahlen und »\_«, invalide Zeichen durch »\_« ersetzt, »\_« am Anfang und am Ende gestript); Passwörter zufällig erzeugt (mindestens jeweils ein Großbuchstabe, Kleinbuchstabe, Sonderzeichen und mindestens eine Zahl, zwischen 10 und 16 Zeichen lang); bereits existierende Benutzer oder doppelt vorkommende Nutzer werden mit einer Warnmeldung quittiert und ignoriert
+\item \emph{sudo ldap-users2ldif user.txt > user.txt.ldif} \\
+	erstellt eine \emph{.ldif}-Datei; erstellt außerdem \emph{user.txt.passwords}, die die Benutzernamen und Passwörter zeilenweise enthält; die Benutzernamen werden escaped (nur Kleinbuchstaben, Zahlen und »\_«, invalide Zeichen durch »\_« ersetzt, »\_« am Anfang und am Ende gestript); Passwörter zufällig erzeugt (mindestens jeweils ein Großbuchstabe, Kleinbuchstabe, Sonderzeichen und mindestens eine Zahl, zwischen 10 und 16 Zeichen lang); bereits existierende Benutzer oder doppelt vorkommende Nutzer werden mit einer Warnmeldung quittiert und ignoriert
 
-\item {\tt sudo ldap-add-ldif user.txt.ldif} \\
-	fügt die {\tt .ldif}-Datei zu LDAP hinzu
+\item \emph{sudo ldap-add-ldif user.txt.ldif} \\
+	fügt die \emph{.ldif}-Datei zu LDAP hinzu
 
-\item {\tt sudo ldap-delete-users user.txt.passwords} \\
-	löscht die in der erzeugten Datei {\tt user.txt.passwords} zeilenweise aufgelisteten Benutzer und entfernt ihr Home-Verzeichnis (diese Datei ist notwendig, weil die Benutzernamen unter Umständen escaped wurden)
-\end{itemize}
+\item \emph{sudo ldap-delete-users user.txt.passwords} \\
+	löscht die in der erzeugten Datei \emph{user.txt.passwords} zeilenweise aufgelisteten Benutzer und entfernt ihr Home-Verzeichnis (diese Datei ist notwendig, weil die Benutzernamen unter Umständen escaped wurden)
+\end{itemize}

bericht/sv/sv-ntp.tex

@@ -1,9 +1,9 @@
 \subsection{NTP}
 
-Auf dem Head-Node wurde der Server {\tt time.zih.tu-dresden.de} als Zeitserver eingetragen und die folgende Zeile eingefügt:
+Auf dem Head-Node wurde der Server \emph{time.zih.tu-dresden.de} als Zeitserver eingetragen und die folgende Zeile eingefügt:
 
 \begin{lstlisting}
 restrict 10.20.0.0 mask 255.255.255.0 nomodify notrap nopeer
 \end{lstlisting}
 
-Auf dem Compute-Node wurde {\tt zotac0} als Zeitserver eingetragen.
+Auf dem Compute-Node wurde \emph{zotac0} als Zeitserver eingetragen.